Hi Peter, Thanks for the responses and the updates. Let me know when the revised version is available.
I did notice that RFC 9350 sections 6.1 to 6.4 define only EAG sub-TLVs based on RFC 7308 but then allow matching with Flex-Algo applications based on either AG (RFC 5305) or EAG (RFC 7308). It does feel a bit confusing at first, but I get the logic, it follows the principle of being conservative in what we send, but liberal in what we accept. Since this is a behavior now documented in RFC 7308, we'll have to accept this for this extension. With that in mind, I agree it makes sense to stick with the naming you've used in the current document. I had originally used the EAG naming from RFC 7308 instead of AG from RFC 5305 in a few places, so it might be worth doing a quick sanity check in case any of that wording got copied over. G/ -----Original Message----- From: Peter Psenak <[email protected]> Sent: Tuesday, April 22, 2025 10:20 AM To: Gunter van de Velde (Nokia) <[email protected]>; [email protected] Cc: lsr <[email protected]> Subject: Re: [Shepherding AD review] review of draft-ietf-lsr-igp-flex-algo-reverse-affinity-05 CAUTION: This is an external email. Please be very careful when clicking links or opening attachments. See the URL nok.it/ext for additional information. Hi Gunter, thanks for your valuable comments. Please see my responses inline (##PP): On 15/04/2025 17:02, Gunter van de Velde (Nokia) wrote: > # Gunter Van de Velde, RTG AD, comments for > draft-ietf-lsr-igp-flex-algo-reverse-affinity-05 > > # The line numbers used are rendered from IETF idnits tool: > https://author-tools.ietf.org/api/idnits?url=https://www.ietf.org/arch > ive/id/draft-ietf-lsr-igp-flex-algo-reverse-affinity-05.txt > > # Many thanks for this document, it is simple and focussed to the procedures. > A welcome fun extension to Flexible Algorithms technology. > > # Can you have a look at the below review observations. Once discussed more i > will request LC. > > # Detailed Review > # =============== > > 14 IGP protocols historically computed the best paths over the network > 15 solely based on the IGP metric assigned to the links. An IGP > 16 Flexible Algorithm (Flex-Algorithm) allows IGPs to compute > 17 constraint-based paths. Flex-Algorithm provides mechanisms to > 18 include or exclude links during the Flex-Algorithm path calculation. > 19 These allow the operator to influence the IGP best path selection. > 20 > 21 This document extends IGP Flex-Algorithm with additional constraints > 22 for inclusion or exclusion of links in the path based on Admin Groups > 23 associated with the reverse direction of the SPF path computation. > > GV> Alternate abstract proposal: > > " > An IGP Flexible Algorithm (Flex-Algorithm) enables the computation of > constraint-based paths within an IGP domain, allowing operators to > influence path selection according to administrative policies. This > document defines an extension to Flex-Algorithm that allows the > inclusion or exclusion of links from path computation based on Administrative > Groups (also known as link affinities) associated with the reverse direction > of the path under computation. > > This extension enhances the path selection capabilities of > Flex-Algorithm by enabling reverse-affinity-based constraints, which > are particularly useful for scenarios where path symmetry or directional link > attributes are operationally significant. > " ##PP done > > 87 IGP protocols historically computed the best paths over the network > 88 solely based on the IGP metric assigned to the links. An IGP Flex- > 89 Algorithm as specified in [RFC9350] allows IGPs to compute a > 90 constraint-based paths. Several mechanisms to include or exclude the > 91 link during the Flex-Algorithm path calculation have been defined > 92 already: > > GV> s/assigned to the links/assigned locally to the links/ ##PP done > > 94 - link inclusion or exclusion based on the presence of a specific > 95 Admin Group(s) - [RFC9350] > > GV> technically we are not talking admin groups but Extended Administrative > Groups. This also specified in RFC9350 section6.1 and 7.1: > > "Extended Administrative Group, as defined in [RFC7308]." #PP both Administrative Group or Extended Administrative Group encodings are supported by the Flex-algo as specified in section 12 of RFC9350. > > 106 This document extends IGP Flex-Algorithm with additional constraints > 107 for inclusion or exclusion of links in the path based on Admin Groups > 108 associated with the reverse direction of the SPF path computation. > > GV> Maybe an idnit, but it is the reverse direction of a link. Maybe explicit > mention this: > > s/associated with the reverse direction of the SPF path > computation/associated with the reverse direction of the link of the > SPF path computation/ ##PP I changed to "associated with the link in the reverse direction of the SPF path computation." > > 118 3. Use Case Example > > GV> This section uses "admin groups" and maybe that is better spelled > GV> out as 'extended admin groups'? (this is similar for the sections > GV> 4, 5, 6, 7, 8 and 9) > > 120 The Flexible Algorithm definition can specify Admin Groups that are > 121 used by the operator to include or exclude links during the Flex- > 122 Algorithm path computation. These link Admin Groups are checked in > 123 the path direction of the SPF computation, e.g., in the direction > 124 from the root vertex toward verticies of increasing distance. > > GV> What about the following textblob: > > " > This section employs terminology from basic graph theory to clarify the > intent of the use cases described herein: > > * Vertex (plural: Vertices): Represents a node or point in a graph, typically > corresponding to a network element or location. > * Edge: Represents a connection between two vertices, corresponding to a > unidirectional or bidirectional link in the network topology. > > The Flexible Algorithm definition allows the specification of constraints > based on Extended Administrative Groups (EAGs) that enable the inclusion or > exclusion of edges during path computation. In the context of SPF algorithms, > these constraints are applied to directed edges in the direction of > traversal, that is, from the root vertex toward vertices such that the > shortest-path distance is increasing. The EAG values are evaluated on each > edge along the directed path being computed. ##PP I'm not sure above is needed. RFC9350 clearly specifies how to apply EAG inclusion/exclusion and this draft makes no modification of that. > " > > 126 In some cases, it is beneficial to check the Admin Groups of the link > 127 from the reverse direction of the path computation. For example, on > 128 a point-to-point link between endpoints A and B and for the path > 129 copmputed in a direction from A to B, the input errors can only be > 130 detected at node B. An operator may measure the rate of such input > 131 errors, CRC errors, etc. The operator can set a threshold on these > 132 errors over a certain period of time. When the input error rate > 133 exceeds such threshold, specific Admin Groups can be set on a link > 134 locally on node B. When the Flex-Algorithm calculation processes the > 135 link A to B, it may look at the Admin Groups of link's reverse > 136 direction, e.g., from B to A. This would allow the operator to > 137 exclude such link from the Flex-Algorithm topology. > > GV> What about following textblob: > > " > In certain scenarios, it is beneficial to evaluate the Extended > Administrative Groups associated with the reverse direction of a link, > rather than solely those in the direction of path computation. > Consider a point-to-point link represented as a pair of directed edges > between two nodes, A and B. When computing a path from A to B, issues > such as input errors on the link, detectable only at the receiving > node B, may be operationally significant. An operator might monitor > metrics like CRC errors or other input-related faults at node B and > apply thresholds over a defined observation period. If such a threshold is > exceeded, node B may locally assign specific Extended Administrative Groups > to the link in the direction from B to A. > > To accommodate this operational intent, the Flex-Algorithm can be > extended to inspect the Extended Administrative Groups of the > reverse-direction edge (from B to A) when evaluating the forward-direction > edge (from A to B) during path > computation. This enables the exclusion of links from the computed > topology based on conditions detected at the far end of the link, > improving network reliability and policy control. ##PP replaced the text with the above. > " > > 171 The IS-IS FAERAG Sub-TLV MUST NOT appear more than once in a single > 175 The IS-IS FAERAG Sub-TLV MUST NOT appear more than once in the set of > > GV> Would this "MUST NOT" be a SHOULD instead of a MUST NOT? Mainly > GV> because when > it does happen, which is strongly discouraged obviously, the received MUST > ignore the associated FAD sub TLV. > While flex-algo will not properly work, the remaining ISIS instance > behaviour is not broken. (similar text exists in section 5, 6, 7, 8 > and 9) ##PP "MUST NOT" is correct here. The text further specifies what to do if the condition is not met. We use the exact same approach for many other FAD constraints. > GV> When a receiving router does get such multiple FAERAGs, should there be a > rate-limited error triggered (logging) suggested? ##PP I would say it's an implementation choice that does not need to be mandated by the RFC. > > 305 Three new rules are added to the existing rules specified in > 306 Section 13 of [RFC9350]: > 307 > 308 Check if any exclude reverse Admin Group rule is part of the Flex- > 309 Algorithm definition. If such exclude rule exists, check if any > 310 Admin Group that is part of the exclude rule is also set on the > 311 link in the reverse direction. If such Admin Group is set on the > 312 link in the reverse direction, the link MUST be pruned from the > 313 computation. > 314 > 315 Check if any include-any reverse Admin Group rule is part of the > 316 Flex-Algorithm definition. If such include-any rule exists, check > 317 if any Admin Group that is part of the include-any rule is also > 318 set on the link in the reverse direction. If no such Admin Group > 319 is set on the link in the reverse direction, the link MUST be > 320 pruned from the computation. > 321 > 322 Check if any include-all reverse Admin Group rule is part of the > 323 Flex-Algorithm definition. If such include-all rule exists, check > 324 if all Admin Groups that are part of the include-all rule are also > 325 set on the link in the reverse direction. If all such Admin > 326 Groups are not set on the link in the reverse direction, the link > 327 MUST be pruned from the computation. > > GV> > > " > The following procedures augment the rules defined in Section 13 of > [RFC9350] by introducing additional constraints based on > Administrative Groups (AGs) associated with the reverse direction of a > link. In the context of a directed graph representing the network > topology, each bidirectional link is modelled as a pair of directed > edges. These rules apply to the edge being evaluated during path > computation, while referencing the AGs of the edge in the opposite direction. ##PP I'm fine with the first sentence, the rest is not needed IMHO. > > Reverse Direction Administrative Group Evaluation Rules: > > 1. Exclude Rule (Reverse EAG): > If the Flex-Algorithm definition includes an exclude rule referencing > reverse-direction EAGs, then for each link under consideration, the > corresponding reverse-direction edge MUST be evaluated. If any EAG > listed in the exclude rule is present on the reverse-direction edge, the > original link MUST be excluded from the computation. > > 2. Include-Any Rule (Reverse EAG): > If the Flex-Algorithm definition includes an include-any rule > referencing reverse-direction EAGs, the reverse-direction edge MUST be > evaluated. If none of the EAGs listed in the rule are present on the > reverse-direction edge, the original link MUST be excluded from the > computation. > > 3. Include-All Rule (Reverse EAG): > If the Flex-Algorithm definition includes an include-all rule > referencing reverse-direction EAGs, the reverse-direction edge MUST be > evaluated. If any of the EAGs specified in the rule are not present on > the reverse-direction edge, the original link MUST be excluded from the > computation. > " ##PP I would prefer to keep the text defining the new rules unchanged. It was written to be consistent with the text used for other include/exclude rules defined in RFC9350 and ietf-lsr-flex-algo-bw-con. > > 378 11.3. IGP Flex-Algo Path Computation Rules Registry > > GV> The ordered set of rules increments in steps of '1' from 1 to 10. > GV> This does not allow to insert rules in the future. It only allows to > postpend rules. Is this intentional WG decision? ##PP It allows the insertion of the new rules by shifting exiting rules. Any new specification needs to define the complete set. That is the intention of the registry. thanks, Peter > > Many thanks again for this document, > > Kind Regards, > Gunter Van de Velde, > RTG AD > > _______________________________________________ Lsr mailing list -- [email protected] To unsubscribe send an email to [email protected]
