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

[Robert Raszuk <[e-mail]>]

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.

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.