# 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/archive/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. " 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/ 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]." 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/ 118 3. Use Case Example GV> This section uses "admin groups" and maybe that is better spelled out as 'extended admin groups'? (this is similar for the sections 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. " 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. " 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 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) GV> When a receiving router does get such multiple FAERAGs, should there be a rate-limited error triggered (logging) suggested? 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. 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. " 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? Many thanks again for this document, Kind Regards, Gunter Van de Velde, RTG AD _______________________________________________ Lsr mailing list -- lsr@ietf.org To unsubscribe send an email to lsr-le...@ietf.org
