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/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.
"
##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 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.
##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 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]
