Robert,
On 21/03/2024 20:52, Robert Raszuk wrote:
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.
affinities have always been applied in a single direction only. We have
defined reverse affinities so we ca apply in reverse direction.
What you suggest is to have a new affinity type, which is bidirectional.
Given what we already have, this looks redundant to me.
thanks,
Peter
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.
_______________________________________________
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr
