Re: [Lsr] I-D Action: draft-ietf-lsr-igp-flex-algo-reverse-affinity-02.txt
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
Re: [Lsr] I-D Action: draft-ietf-lsr-igp-flex-algo-reverse-affinity-02.txt
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. ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
Re: [Lsr] I-D Action: draft-ietf-lsr-igp-flex-algo-reverse-affinity-02.txt
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 O 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 Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
Re: [Lsr] I-D Action: draft-ietf-lsr-igp-flex-algo-reverse-affinity-02.txt
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 O 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 Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
Re: [Lsr] I-D Action: draft-ietf-lsr-igp-flex-algo-reverse-affinity-02.txt
Robert, On 21/03/2024 17:52, Robert Raszuk wrote: Hi, > When Flex-Algorithm calculation processes the link A to B, it may look at > the 'colors' of the link in the reverse direction, e.g., link B to A. This would > allow the operator to exclude such link from the Flex-Algorithm topology. 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. 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. > An operator may measure the rate of such input errors and set certain 'color' on a link > locally on node B when the input error rate crosses a certain threshold. IMO the draft should go into more detail or at least provide a pointer to another document with description how to protect from continued churn in propagating those colors when oscillate and go below and above a set threshold many times per second. the draft defines the mechanism how to advertise and use the reverse affinities. When to set it and how frequently, is not something that this draft specifies. Not that I disagree with you, but the same applies to any link attribute that is used during any calculation, being it TE or flex-algo. It's not specific to reverse affinities at all. Then aside from reducing the propagation frequency local protection from continued SPF runs should also be mentioned. I guess you assume that this is in place anyway. absolutely. > The IS-IS Flexible Algorithm Exclude Reverse Admin Group (FAERAG) I think "FAERAG" is very hard to say. How about just "ERAG" as an acronym ? whatever you like :) thanks, Peter Thx, R. On Mon, Mar 18, 2024 at 9:12 AM wrote: Internet-Draft draft-ietf-lsr-igp-flex-algo-reverse-affinity-02.txt is now available. It is a work item of the Link State Routing (LSR) WG of the IETF. Title: IGP Flexible Algorithms Reverse Affinity Constraint Authors: Peter Psenak Jakub Horn Amit Dhamija Name: draft-ietf-lsr-igp-flex-algo-reverse-affinity-02.txt Pages: 9 Dates: 2024-03-18 Abstract: An IGP Flexible Algorithm (Flex-Algorithm) allows IGPs to compute constraint-based paths. This document extends IGP Flex-Algorithm with additional constraints. The IETF datatracker status page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-lsr-igp-flex-algo-reverse-affinity/ There is also an HTMLized version available at: https://datatracker.ietf.org/doc/html/draft-ietf-lsr-igp-flex-algo-reverse-affinity-02 A diff from the previous version is available at: https://author-tools.ietf.org/iddiff?url2=draft-ietf-lsr-igp-flex-algo-reverse-affinity-02 Internet-Drafts are also available by rsync at: rsync.ietf.org::internet-drafts ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
Re: [Lsr] I-D Action: draft-ietf-lsr-igp-flex-algo-reverse-affinity-02.txt
Hi, > When Flex-Algorithm calculation processes the link A to B, it may look at > the 'colors' of the link in the reverse direction, e.g., link B to A. This would > allow the operator to exclude such link from the Flex-Algorithm topology. 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 ? Can't we just use the reverse metrics locally by computing node without flooding anything new ? > An operator may measure the rate of such input errors and set certain 'color' on a link > locally on node B when the input error rate crosses a certain threshold. IMO the draft should go into more detail or at least provide a pointer to another document with description how to protect from continued churn in propagating those colors when oscillate and go below and above a set threshold many times per second. Then aside from reducing the propagation frequency local protection from continued SPF runs should also be mentioned. I guess you assume that this is in place anyway. > The IS-IS Flexible Algorithm Exclude Reverse Admin Group (FAERAG) I think "FAERAG" is very hard to say. How about just "ERAG" as an acronym ? Thx, R. On Mon, Mar 18, 2024 at 9:12 AM wrote: > Internet-Draft draft-ietf-lsr-igp-flex-algo-reverse-affinity-02.txt is now > available. It is a work item of the Link State Routing (LSR) WG of the > IETF. > >Title: IGP Flexible Algorithms Reverse Affinity Constraint >Authors: Peter Psenak > Jakub Horn > Amit Dhamija >Name:draft-ietf-lsr-igp-flex-algo-reverse-affinity-02.txt >Pages: 9 >Dates: 2024-03-18 > > Abstract: > >An IGP Flexible Algorithm (Flex-Algorithm) allows IGPs to compute >constraint-based paths. > >This document extends IGP Flex-Algorithm with additional constraints. > > The IETF datatracker status page for this Internet-Draft is: > > https://datatracker.ietf.org/doc/draft-ietf-lsr-igp-flex-algo-reverse-affinity/ > > There is also an HTMLized version available at: > > https://datatracker.ietf.org/doc/html/draft-ietf-lsr-igp-flex-algo-reverse-affinity-02 > > A diff from the previous version is available at: > > https://author-tools.ietf.org/iddiff?url2=draft-ietf-lsr-igp-flex-algo-reverse-affinity-02 > > Internet-Drafts are also available by rsync at: > rsync.ietf.org::internet-drafts > > > ___ > Lsr mailing list > Lsr@ietf.org > https://www.ietf.org/mailman/listinfo/lsr > ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
