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

[Robert Raszuk <[e-mail]>]

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.