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.
_______________________________________________
Lsr mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/lsr
