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

[Peter Psenak <[e-mail]>]

Hi Robert,

On 21/03/2024 18:26, Robert Raszuk wrote:
> Hey Peter,
>
>>     Why do we need the notion of "reverse direction" to be any
>>     different then
>>     the notion of forward direction from node B to A on a link ?
>
>     For a link A->B, we typically use attributes in the direction
>     A->B. .e.g. link delay, link affinities, etc.
>
>     The reason why we want to be able to use reverse affinities is
>     that for some cases, it is only B that knows about certain
>     properties that relates to traffic A->B. For example only B can
>     detect that there is a high rate of errors on that link for
>     incoming traffic.
>
>
> That is clear from the draft and I think that extension of computation 
> is useful. I am only asking about the flooding granularity.
>
>>     Can't we just use the reverse metrics locally by computing node
>>     without flooding
>>     anything new ?
>
>     no, because we want to use the metric in the forwarding direction,
>     but be able to exclude link if the errors are detected on the
>     other side of the link in the incoming direction.
>
>
> What I meant to say was not really not to flood anything .. but not to 
> flood any "reverse" colors. Meaning if node B notices errors coming on 
> link to node A he floods it as some color.
>
> Then node running flex-algo can treat such flooding as reverse locally 
> if instructed so.
>
> Example: Node B sees 1000 RX CRC errors on link to A. it checks Ooooo 
> it crossed threshold 999 so I flood it as color GRAY. Why there is 
> need to have this flooded with notion of "reverse" that is my question ?

You need to distinguish which affinites to use in regular and which one 
in reverse direction. You can not mix them.

Let's say a node B advertises 10 different affinites for link B->A, how 
do you know which one to use in which direction?

To do what you propose you would have to advertise the direction of each 
affiniity together with the value, or somehow associate the direction 
with it upfront. I think this would be very confusing. Having a 
completely different affinity space for each direction is way simpler.


>
> Does the "REVERSE" really means that those are RX errors as opposed to 
> TX errors ?

reverse means that it should be considered in A->B direction even though 
it is advertised with B->A link.

In our example it is used for Rx errors only. Tx errors on B are not 
relevant for A->B traffic.

>
> I think you want to differentiate the link direction and say if I see 
> RX errors this link should be removed from computation A --> B, yet in 
> the same time I there is no TX errors it would be fine to keep that 
> link in data direction B --> A  Is this the case ?

yes, more precisely for some very sensitive traffic, I want to avoid 
using the link even in the case of a minimal error rate.
>
> Would it be better to just declare link as crap bidirectionally ? :)

not necessarily.


thanks,

Peter


>
> Thx,
> R.
>
>
>
>