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
