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 ? Does the "REVERSE" really means that those are RX errors as opposed to TX errors ? 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 ? Would it be better to just declare link as crap bidirectionally ? :) Thx, R.
_______________________________________________ Lsr mailing list [email protected] https://www.ietf.org/mailman/listinfo/lsr
