Re: [Lsr] I-D Action: draft-ietf-lsr-igp-flex-algo-reverse-affinity-02.txt

[Peter Psenak <[e-mail]>]

Robert,

On 21/03/2024 20:52, Robert Raszuk wrote:
> Peter,
>
> Ok I think what you are proposing is pretty granular and that is fine. 
> We may still disagree if link should be used at all if there are 
> errors on this link in *ANY* direction.
>
> So my suggestion here is to have that support build in as well in the 
> nodes computing the topology and not always require to flood REVERSE 
> colors.
>
> In other words a color GRAY can be injected by node B irrespective if 
> errors appear in TX or RX direction of the link. And that GRAY color 
> should remove the link from computation bidirectionally.

affinities have always been applied in a single direction only. We have 
defined reverse affinities so we ca apply in reverse direction.

What you suggest is to have a new affinity type, which is bidirectional. 
Given what we already have, this looks redundant to me.

thanks,
Peter



>
> In the same time sure for those who want to remove given link only in 
> one direction your proposal provides tool for that.
>
> > In our example it is used for Rx errors only. Tx errors on B are not 
> relevant for A->B traffic.
>
> +
>
> > I want to avoid using the link even in the case of a minimal error rate.
>
> Well typically packet errors are expressed as counters not rates. Only 
> active measurements express quality of the links as rates.
>
> If this is just a counter then the moment it crosses threshold there 
> is no return till operator or script resets this counter :)  Not very 
> OPS friendly ....
>
> Thx,
> R.
>
>
>
>