Flex-Algo rev. affinity: IGP Flexible Algorithms Reverse Affinity Constraint
Lets Flex-Algorithm prune links using the Admin Groups set on the reverse direction of a link.
Psenak, P., Horn, J., and A. Dhamija, "IGP Flexible Algorithms Reverse Affinity Constraint", RFC 9917, DOI 10.17487/RFC9917, January 2026, <https://www.rfc-editor.org/info/rfc9917>.
@misc{rfc9917,
series = {Request for Comments},
number = 9917,
howpublished = {RFC 9917},
publisher = {RFC Editor},
doi = {10.17487/RFC9917},
url = {https://www.rfc-editor.org/info/rfc9917},
author = {P. Psenak and J. Horn and A. Dhamija},
title = {{IGP Flexible Algorithms Reverse Affinity Constraint}},
pagetotal = 12,
year = 2026,
month = jan,
} RFC text
Contents
Internet Engineering Task Force (IETF) P. Psenak
Request for Comments: 9917 J. Horn
Updates: 9350, 9843 Cisco Systems
Category: Standards Track A. Dhamija
ISSN: 2070-1721 Arrcus
January 2026
IGP Flexible Algorithms Reverse Affinity Constraint
Abstract
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 document updates RFCs 9350 and 9843 by introducing the new IANA
registry that specifies the ordered set of rules that are used to
prune links from the topology during the Flex-Algorithm path
computation.
Status of This Memo
This is an Internet Standards Track document.
This document is a product of the Internet Engineering Task Force
(IETF). It represents the consensus of the IETF community. It has
received public review and has been approved for publication by the
Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 7841.
Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
https://www.rfc-editor.org/info/rfc9917.
Copyright Notice
Copyright (c) 2026 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Revised BSD License text as described in Section 4.e of the
Trust Legal Provisions and are provided without warranty as described
in the Revised BSD License.
Table of Contents
1. Introduction
2. Requirements Language
3. Use Case Example
4. Deployment Consideration
5. IS-IS Flexible Algorithm Exclude Reverse Admin Group Sub-TLV
6. IS-IS Flexible Algorithm Include-Any Reverse Admin Group
Sub-TLV
7. IS-IS Flexible Algorithm Include-All Reverse Admin Group
Sub-TLV
8. OSPF Flexible Algorithm Exclude Reverse Admin Group Sub-TLV
9. OSPF Flexible Algorithm Include-Any Reverse Admin Group Sub-TLV
10. OSPF Flexible Algorithm Include-All Reverse Admin Group Sub-TLV
11. Calculation of Flexible Algorithm Paths
12. IANA Considerations
12.1. Sub-Sub-TLVs for Flexible Algorithm Definition Sub-TLV
12.2. OSPF Flexible Algorithm Definition TLV Sub-TLV Registry
12.3. IGP Flex-Algorithm Path Computation Rules Registry
12.3.1. Guidance for Designated Experts
13. Security Considerations
14. References
14.1. Normative References
14.2. Informative References
Authors' Addresses
1. Introduction
IGP protocols historically computed the best paths over the network
solely based on the IGP metric assigned to the links. An IGP Flex-
Algorithm as specified in [RFC9350] allows IGPs to compute
constraint-based paths. Several mechanisms to include or exclude the
link during the Flex-Algorithm path calculation have been defined
already:
* link inclusion or exclusion based on the presence of a specific
Admin Group(s) [RFC9350]
* link exclusion based on the presence of a specific Shared Risk
Link Group (SRLG) [RFC9350]
* link exclusion based on minimum bandwidth [RFC9843]
* link exclusion based on maximum delay [RFC9843]
This document extends IGP Flex-Algorithm with additional constraints
for inclusion or exclusion of links in the path based on Admin Groups
associated with the reverse direction of the Shortest Path First
(SPF) computation.
This document updates [RFC9350] and [RFC9843] by creating the new
IANA registry that specifies the ordered set of rules that are used
to prune links from the topology during the Flex-Algorithm path
computation (refer to Section 12.3.1).
The term OSPF in this document is used to cover both OSPFv2 and
OSPFv3 protocols.
2. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in
BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
3. Use Case Example
The Flexible Algorithm Definition (FAD) can specify Extended
Administrative Groups that are used by the operator to include or
exclude links during the Flex-Algorithm path computation [RFC9350].
These link Extended Administrative Groups are checked in the path
direction of the SPF computation, e.g., in the direction from the
root vertex toward vertices of increasing distance.
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 Cyclic Redundancy Check (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.
4. Deployment Consideration
Threshold-based setting of the link Extended Administrative Groups
must be done with care to avoid excessive flooding and constant Flex-
Algorithm path recalculation.
One possible approach is to use two different thresholds when setting
and unsetting the Extended Administrative Group on the link. For
example, when setting the Extended Administrative Group on the link
based on the percentage of certain incoming errors, higher threshold
is used for setting and lower threshold is used for unsetting the
Extended Administrative Group on the link.
Many implementations provide a throttling mechanism that limits the
rate at which the Link State PDU (LSP) in case of IS-IS, or Link
State Advertisement (LSA) in case of OSPFv2 and OSPFv3, is updated at
the originator. Such mechanism is typically not specific to any
particular link attribute, but rather considers any change in the LSP
or LSA. Application of such throttling mechanism can also be used to
avoid frequent changes in the setting of the Extended Administrative
Group on a link to affect the stability of the receivers.
5. IS-IS Flexible Algorithm Exclude Reverse Admin Group Sub-TLV
The IS-IS Flexible Algorithm Exclude Reverse Admin Group (FAERAG)
Sub-TLV is used to advertise the exclude rule that is used during the
Flex-Algorithm path calculation as specified in Section 11.
The IS-IS FAERAG Sub-TLV is a sub-TLV of the IS-IS FAD Sub-TLV. It
has the following format:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Extended Admin Group |
+- -+
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
where:
Type (1 octet): 10
Length (1 octet): Variable, dependent on the size of the Extended
Admin Group. The length MUST be a multiple of 4 octets. If the
length is not a multiple of 4 octets, the entire sub-TLV MUST be
ignored by the receiver.
Extended Administrative Group: Extended Administrative Group as
defined in [RFC7308].
The IS-IS FAERAG Sub-TLV MUST NOT appear more than once in a single
IS-IS FAD Sub-TLV. If it appears more than once, the IS-IS FAD Sub-
TLV MUST be ignored by the receiver.
The IS-IS FAERAG Sub-TLV MUST NOT appear more than once in the set of
FAD Sub-TLVs for a given Flex-Algorithm from a given IS. If it
appears more than once in such set, the IS-IS FAERAG Sub-TLV in the
first occurrence in the lowest-numbered LSP from a given IS MUST be
used and any other occurrences MUST be ignored by the receiver.
6. IS-IS Flexible Algorithm Include-Any Reverse Admin Group Sub-TLV
The IS-IS Flexible Algorithm Include-Any Reverse Admin Group Sub-TLV
is used to advertise the include-any rule that is used during the
Flex-Algorithm path calculation as specified in Section 11.
The format of the IS-IS Flexible Algorithm Include-Any Reverse Admin
Group Sub-TLV is identical to the format of the FAERAG Sub-TLV in
Section 5.
IANA has assigned Type value of 11 for the IS-IS Flexible Algorithm
Include-Any Reverse Admin Group Sub-TLV.
The IS-IS Flexible Algorithm Include-Any Reverse Admin Group Sub-TLV
MUST NOT appear more than once in a single IS-IS FAD Sub-TLV. If it
appears more than once, the IS-IS FAD Sub-TLV MUST be ignored by the
receiver.
The IS-IS Flexible Algorithm Include-Any Reverse Admin Group Sub-TLV
MUST NOT appear more than once in the set of FAD Sub-TLVs for a given
Flex-Algorithm from a given IS. If it appears more than once in such
set, the IS-IS Flexible Algorithm Include-Any Reverse Admin Group
Sub-TLV in the first occurrence in the lowest-numbered LSP from a
given IS MUST be used and any other occurrences MUST be ignored by
the receiver.
7. IS-IS Flexible Algorithm Include-All Reverse Admin Group Sub-TLV
The IS-IS Flexible Algorithm Include-All Reverse Admin Group Sub-TLV
is used to advertise the include-all rule that is used during the
Flex-Algorithm path calculation as specified in Section 11.
The format of the IS-IS Flexible Algorithm Include-All Reverse Admin
Group Sub-TLV is identical to the format of the FAERAG Sub-TLV in
Section 5.
IANA has assigned Type value of 12 for the IS-IS Flexible Algorithm
Include-All Reverse Admin Group Sub-TLV.
The IS-IS Flexible Algorithm Include-All Reverse Admin Group Sub-TLV
MUST NOT appear more than once in a single IS-IS FAD Sub-TLV. If it
appears more than once, the IS-IS FAD Sub-TLV MUST be ignored by the
receiver.
The IS-IS Flexible Algorithm Include-All Reverse Admin Group Sub-TLV
MUST NOT appear more than once in the set of FAD Sub-TLVs for a given
Flex-Algorithm from a given IS. If it appears more than once in such
set, the IS-IS Flexible Algorithm Include-All Reverse Admin Group
Sub-TLV in the first occurrence in the lowest-numbered LSP from a
given IS MUST be used and any other occurrences MUST be ignored by
the receiver.
8. OSPF Flexible Algorithm Exclude Reverse Admin Group Sub-TLV
The OSPF Flexible Algorithm Exclude Reverse Admin Group (FAERAG) Sub-
TLV is used to advertise the exclude rule that is used during the
Flex-Algorithm path calculation as specified in Section 11.
The OSPF FAERAG Sub-TLV is a sub-TLV of the OSPF FAD TLV. It has the
following format:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Extended Admin Group |
+- -+
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
where:
Type (2 octets): 10
Length (2 octets): Variable, dependent on the size of the Extended
Admin Group. The length MUST be a multiple of 4 octets. If the
length is not a multiple of 4 octets, the entire sub-TLV MUST be
ignored by the receiver.
Extended Administrative Group: Extended Administrative Group as
defined in [RFC7308].
The OSPF FAERAG Sub-TLV MUST NOT appear more than once in an OSPF FAD
TLV. If it appears more than once, the OSPF FAD TLV MUST be ignored
by the receiver.
9. OSPF Flexible Algorithm Include-Any Reverse Admin Group Sub-TLV
The OSPF Flexible Algorithm Include-Any Reverse Admin Group Sub-TLV
is used to advertise the include-any rule that is used during the
Flex-Algorithm path calculation as specified in Section 11.
The format of the OSPF Flexible Algorithm Include-Any Reverse Admin
Group Sub-TLV is identical to the format of the OSPF FAERAG Sub-TLV
in Section 8.
IANA has assigned Type value of 11 for the OSPF Flexible Algorithm
Include-Any Reverse Admin Group Sub-TLV.
The OSPF Flexible Algorithm Include-Any Reverse Admin Group Sub-TLV
MUST NOT appear more than once in an OSPF FAD TLV. If it appears
more than once, the OSPF FAD TLV MUST be ignored by the receiver.
10. OSPF Flexible Algorithm Include-All Reverse Admin Group Sub-TLV
The OSPF Flexible Algorithm Include-All Reverse Admin Group Sub-TLV
is used to advertise the include-all rule that is used during the
Flex-Algorithm path calculation as specified in Section 11.
The format of the OSPF Flexible Algorithm Include-All Reverse Admin
Group Sub-TLV is identical to the format of the OSPF FAERAG Sub-TLV
in Section 8.
IANA has assigned Type value of 12 for the OSPF Flexible Algorithm
Include-All Reverse Admin Group Sub-TLV.
The OSPF Flexible Algorithm Include-All Reverse Admin Group Sub-TLV
MUST NOT appear more than once in an OSPF FAD TLV. If it appears
more than once, the OSPF FAD TLV MUST be ignored by the receiver.
11. Calculation of Flexible Algorithm Paths
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.
* Check if any exclude reverse Admin Group rule is part of the Flex-
Algorithm definition. If such exclude rule exists, check if any
Admin Group that is part of the exclude rule is also set on the
link in the reverse direction. If such Admin Group is set on the
link in the reverse direction, the link MUST be pruned from the
computation.
* Check if any include-any reverse Admin Group rule is part of the
Flex-Algorithm definition. If such include-any rule exists, check
if any Admin Group that is part of the include-any rule is also
set on the link in the reverse direction. If no such Admin Group
is set on the link in the reverse direction, the link MUST be
pruned from the computation.
* Check if any include-all reverse Admin Group rule is part of the
Flex-Algorithm definition. If such include-all rule exists, check
if all Admin Groups that are part of the include-all rule are also
set on the link in the reverse direction. If all such Admin
Groups are not set on the link in the reverse direction, the link
MUST be pruned from the computation.
Please see rules 8, 9, and 10 in Section 12.3 for these added rules.
12. IANA Considerations
12.1. Sub-Sub-TLVs for Flexible Algorithm Definition Sub-TLV
IANA has registered the following in the "IS-IS Sub-Sub-TLVs for
Flexible Algorithm Definition Sub-TLV" registry under the "IS-IS TLV
Codepoints" registry group:
Type: 10
Description: Flexible Algorithm Exclude Reverse Admin Group
MP: n
Reference: RFC 9917, Section 5
Type: 11
Description: Flexible Algorithm Include-Any Reverse Admin Group
MP: n
Reference: RFC 9917, Section 6
Type: 12
Description: Flexible Algorithm Include-All Reverse Admin Group
MP: n
Reference: RFC 9917, Section 7
12.2. OSPF Flexible Algorithm Definition TLV Sub-TLV Registry
This document makes the following registration in the "OSPF Flexible
Algorithm Definition TLV Sub-TLVs" registry under the "Open Shortest
Path First (OSPF) Parameters" registry group:
Type: 10
Description: Flexible Algorithm Exclude Reverse Admin Group
Reference: RFC 9917, Section 8
Type: 11
Description: Flexible Algorithm Include-Any Reverse Admin Group
Reference: RFC 9917, Section 9
Type: 12
Description: Flexible Algorithm Include-All Reverse Admin Group
Reference: RFC 9917, Section 10
12.3. IGP Flex-Algorithm Path Computation Rules Registry
IANA has created a new registry called "IGP Flex-Algorithm Path
Computation Rules" within the "Interior Gateway Protocol (IGP)
Parameters" registry group. The registration procedure for the new
registry is Expert Review [RFC8126]. Section 12.3.1 provides
guidance for designated experts.
The "IGP Flex-Algorithm Path Computation Rules" registry specifies
the ordered set of rules that are used to prune links from the
topology during the Flex-Algorithm path computation.
There is no upper bound on the number of rules that the registry
supports.
In Table 1, "FAEMB" means "Flex-Algorithm Exclude Minimum Bandwidth",
and "FAEMD" means "Flex-Algorithm Exclude Maximum Delay".
+==========+===========================================+===========+
| Sequence | Description | Reference |
| Number | | |
+==========+===========================================+===========+
| 1 | Check if any exclude Administrative Group | Section |
| | rule is part of the Flex-Algorithm | 13 of |
| | Definition. If such exclude rule exists, | [RFC9350] |
| | check if any color that is part of the | |
| | exclude rule is also set on the link. If | |
| | such a color is set, the link MUST be | |
| | pruned from the computation. | |
+----------+-------------------------------------------+-----------+
| 2 | Check if any exclude SRLG rule is part of | Section |
| | the Flex-Algorithm Definition. If such | 13 of |
| | exclude rule exists, check if the link is | [RFC9350] |
| | part of any SRLG that is also part of the | |
| | SRLG exclude rule. If the link is part | |
| | of such SRLG, the link MUST be pruned | |
| | from the computation. | |
+----------+-------------------------------------------+-----------+
| 3 | Check if any include-any Administrative | Section |
| | Group rule is part of the Flex-Algorithm | 13 of |
| | Definition. If such include-any rule | [RFC9350] |
| | exists, check if any color that is part | |
| | of the include-any rule is also set on | |
| | the link. If no such color is set, the | |
| | link MUST be pruned from the computation. | |
+----------+-------------------------------------------+-----------+
| 4 | Check if any include-all Administrative | Section |
| | Group rule is part of the Flex-Algorithm | 13 of |
| | Definition. If such include-all rule | [RFC9350] |
| | exists, check if all colors that are part | |
| | of the include-all rule are also set on | |
| | the link. If all such colors are not set | |
| | on the link, the link MUST be pruned from | |
| | the computation. | |
+----------+-------------------------------------------+-----------+
| 5 | If the Flex-Algorithm Definition uses | Section |
| | something other than the IGP metric | 13 of |
| | (Section 5 of [RFC9350]), and such metric | [RFC9350] |
| | is not advertised for the particular link | |
| | in a topology for which the computation | |
| | is done, such link MUST be pruned from | |
| | the computation. A metric of value 0 | |
| | MUST NOT be assumed in such a case. | |
+----------+-------------------------------------------+-----------+
| 6 | Check if any exclude FAEMB rule is part | Section 6 |
| | of the Flex-Algorithm definition. If | of |
| | such exclude rule exists and the link has | [RFC9843] |
| | Maximum Link Bandwidth advertised, check | |
| | if the link bandwidth satisfies the FAEMB | |
| | rule. If the link does not satisfy the | |
| | FAEMB rule, the link MUST be pruned from | |
| | the Flex-Algorithm computation. | |
+----------+-------------------------------------------+-----------+
| 7 | Check if any exclude FAEMD rule is part | Section 6 |
| | of the Flex-Algorithm definition. If | of |
| | such exclude rule exists and the link has | [RFC9843] |
| | Min Unidirectional link delay advertised, | |
| | check if the link delay satisfies the | |
| | FAEMD rule. If the link does not satisfy | |
| | the FAEMD rule, the link MUST be pruned | |
| | from the Flex-Algorithm computation. | |
+----------+-------------------------------------------+-----------+
| 8 | Check if any exclude reverse Admin Group | Section |
| | rule is part of the Flex-Algorithm | 11 of RFC |
| | definition. If such exclude rule exists, | 9917 |
| | check if any Admin Group that is part of | |
| | the exclude rule is also set on the link | |
| | in the reverse direction. If such Admin | |
| | Group is set on the link in the reverse | |
| | direction, the link MUST be pruned from | |
| | the computation. | |
+----------+-------------------------------------------+-----------+
| 9 | Check if any include-any reverse Admin | Section |
| | Group rule is part of the Flex-Algorithm | 11 of RFC |
| | definition. If such include-any rule | 9917 |
| | exists, check if any Admin Group that is | |
| | part of the include-any rule is also set | |
| | on the link in the reverse direction. If | |
| | no such Admin Group is set on the link in | |
| | the reverse direction, the link MUST be | |
| | pruned from the computation. | |
+----------+-------------------------------------------+-----------+
| 10 | Check if any include-all reverse Admin | Section |
| | Group rule is part of the Flex-Algorithm | 11 of RFC |
| | definition. If such include-all rule | 9917 |
| | exists, check if all Admin Groups that | |
| | are part of the include-all rule are also | |
| | set on the link in the reverse direction. | |
| | If all such Admin Groups are not set on | |
| | the link in the reverse direction, the | |
| | link MUST be pruned from the computation. | |
+----------+-------------------------------------------+-----------+
Table 1: IGP Flex-Algorithm Path Calculation Rules
12.3.1. Guidance for Designated Experts
Since the original Flex-Algorithm specification [RFC9350], many Flex-
Algorithm extensions have been proposed and standardized. Many of
them added additional rules to the Flex-Algorithm path computation.
Maintaining an IANA registry for these rules allows specification
across multiple documents progressing independently. The new "IGP
Flex-Algorithm Path Computation Rules" registry has been created and
is specified in Section 12.3.
This section provides the guidance for designated experts on
evaluating new registrations in the "IGP Flex-Algorithm Path
Computation Rules" registry:
1. When a new constraint is defined, the rule associated with that
constraint MAY be inserted at any position. Backwards
compatibility is guaranteed because nodes that don't support the
new constraint will not participate in an algorithm where the FAD
specifies a constraint they don't support.
2. The relative ordering of existing rules MUST NOT be altered.
Doing so has the potential to create backwards compatibility
issues.
3. Deletion of the rules MUST NOT be done. Given that the rules are
only used conditionally based on the information carried in the
winning FAD, deletion of the rule is not necessary.
4. Merging or repeating of the rules MUST NOT be done.
13. Security Considerations
This document inherits security considerations from [RFC9350].
14. References
14.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC7308] Osborne, E., "Extended Administrative Groups in MPLS
Traffic Engineering (MPLS-TE)", RFC 7308,
DOI 10.17487/RFC7308, July 2014,
<https://www.rfc-editor.org/info/rfc7308>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC9350] Psenak, P., Ed., Hegde, S., Filsfils, C., Talaulikar, K.,
and A. Gulko, "IGP Flexible Algorithm", RFC 9350,
DOI 10.17487/RFC9350, February 2023,
<https://www.rfc-editor.org/info/rfc9350>.
[RFC9843] Hegde, S., Britto, W., Shetty, R., Decraene, B., Psenak,
P., and T. Li, "IGP Flexible Algorithms: Bandwidth, Delay,
Metrics, and Constraints", RFC 9843, DOI 10.17487/RFC9843,
September 2025, <https://www.rfc-editor.org/info/rfc9843>.
14.2. Informative References
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
Writing an IANA Considerations Section in RFCs", BCP 26,
RFC 8126, DOI 10.17487/RFC8126, June 2017,
<https://www.rfc-editor.org/info/rfc8126>.
Authors' Addresses
Peter Psenak
Cisco Systems
Apollo Business Center
Mlynske nivy 43
82109 Bratislava
Slovakia
Email: ppsenak@cisco.com
Jakub Horn
Cisco Systems
Milpitas, CA 95035
United States of America
Email: jakuhorn@cisco.com
Amit Dhamija
Arrcus
Email: amitd@arrcus.com
ISO Plain Language
On this page
§1Introduction
IGP protocols historically computed the best paths over the network solely based on the IGP metric assigned to the links. An IGP Flex-Algorithm, as specified in RFC 9350, allows IGPs to compute constraint-based paths. Several mechanisms to include or exclude a link during the Flex-Algorithm path calculation have already been defined: link inclusion or exclusion based on the presence of specific Admin Groups, link exclusion based on the presence of a specific Shared Risk Link Group, link exclusion based on minimum bandwidth, and link exclusion based on maximum delay.
This document extends IGP Flex-Algorithm with additional constraints for inclusion or exclusion of links in the path, based on Admin Groups associated with the reverse direction of the shortest path first computation.
The document updates RFC 9350 and RFC 9843 by creating a new IANA registry that specifies the ordered set of rules used to prune links from the topology during the Flex-Algorithm path computation. The term OSPF in this document covers both OSPFv2 and OSPFv3 protocols.
A Flex-Algorithm is a named set of rules that an interior routing protocol uses to pick a path for traffic of a particular kind. Some of those rules keep a link out of the path when the link carries a certain mark. This document adds rules that look at the mark on the link in the opposite direction, so that a problem reported by one router can keep traffic away from the link in both directions.
§3Use Case Example
The Flexible Algorithm Definition can specify Extended Administrative Groups that the operator uses to include or exclude links during the Flex-Algorithm path computation. These link Extended Administrative Groups are checked in the path direction of the computation, for example in the direction from the root vertex towards vertices of increasing distance.
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 Cyclic Redundancy Check 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 when evaluating the forward-direction edge 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.
Take two routers joined by a link. The link is really two one-way edges, and each can carry its own marks. Errors on the link are noticed by the router that receives the traffic, so the router at the far end is the one that can see them and act on them. It can mark the edge pointing back towards its own side, but it cannot mark the edge in the direction the traffic is going, because that mark would have to come from the other router. This document lets the path calculation read the mark on the far end's edge and act on it.
- A link is two edgesThe link between A and B is a pair of directed edges, and each can carry its own administrative groups.
- Errors are seen at the far endInput errors on the link are detected by the node that receives the traffic, at node B.
- The far end marks the other edgeNode B can set administrative groups on the edge pointing back from B to A.
- The calculation looks backwardsThe new rules let the path computation act on the forward link because of what the reverse edge says.
§4Deployment Consideration
Threshold-based setting of the link Extended Administrative Groups must be done with care, to avoid excessive flooding and constant Flex-Algorithm path recalculation.
One possible approach is to use two different thresholds when setting and unsetting the Extended Administrative Group on the link. For example, when setting the Extended Administrative Group on the link based on the percentage of certain incoming errors, a higher threshold is used for setting and a lower threshold for unsetting the group.
Many implementations provide a throttling mechanism that limits the rate at which the Link State PDU in the case of IS-IS, or the Link State Advertisement in the case of OSPFv2 and OSPFv3, is updated at the originator. Such a mechanism is typically not specific to any particular link attribute, but considers any change in the PDU or advertisement. Applying such a throttling mechanism can also avoid frequent changes in the setting of the Extended Administrative Group on a link affecting the stability of the receivers.
Because the mark is advertised to the whole network, a mark that flickers on and off will cause a storm of updates and make every router recompute its paths. Two habits help. Use a higher threshold to set the mark than to clear it, so that a fault near the threshold does not flap. And use the throttling that routers already have for link state updates, so that repeated changes are sent out at a steady rate rather than all at once.
§5The Reverse Admin Group Sub-TLVs
The IS-IS Flexible Algorithm Exclude Reverse Admin Group Sub-TLV advertises the exclude rule used during the Flex-Algorithm path calculation. It is a sub-TLV of the IS-IS Flexible Algorithm Definition Sub-TLV, with a one-octet Type field whose value is 10, a one-octet Length field that is variable and dependent on the size of the Extended Admin Group, and the Extended Administrative Group value itself. The length must be a multiple of 4 octets; if it is not, the entire sub-TLV must be ignored by the receiver.
The sub-TLV must not appear more than once in a single IS-IS Flexible Algorithm Definition Sub-TLV, and if it does, that Definition Sub-TLV must be ignored. It must also not appear more than once in the set of Definition Sub-TLVs for a given Flex-Algorithm from a given IS; if it does, the sub-TLV in the first occurrence in the lowest-numbered Link State PDU from that IS is used and the others are ignored.
The IS-IS Flexible Algorithm Include-Any Reverse Admin Group Sub-TLV has an identical format, with the type value 11, and the same occurrence rules. The IS-IS Flexible Algorithm Include-All Reverse Admin Group Sub-TLV has an identical format, with the type value 12, and the same occurrence rules.
The OSPF equivalents follow the same pattern inside the OSPF Flexible Algorithm Definition TLV. The OSPF Flexible Algorithm Exclude Reverse Admin Group Sub-TLV has a two-octet Type field with the value 10 and a two-octet Length field with the same multiple-of-4 requirement; the include-any and include-all sub-TLVs have type values 11 and 12. The OSPF occurrence rules are the same, except that the sub-TLV must not appear more than once in a given OSPF Flexible Algorithm Definition TLV, and if it does, that TLV must be ignored.
Each rule travels in its own small record inside the record that defines the Flex-Algorithm. The IS-IS version numbers its records with one byte and the OSPF version with two, and the numbers are 10 for exclude, 11 for include-any and 12 for include-all. The length of the record must be a multiple of four bytes, because the group value it carries is made of four-byte groups. A record that is duplicated makes the whole definition unusable, so a router ignores it rather than guess.
| Field | Name | Size | Value | Description |
|---|---|---|---|---|
TYPE | Type | 1 byte | 10 for exclude, 11 for include-any, 12 for include-all. | |
LENGTH | Length | 1 byte | The length in octets, which must be a multiple of 4. | |
ADMIN-GROUP | Extended Admin Group | 4 bytes | The administrative group value, in the format of RFC 7308. |
§11Path Calculation
The procedures augment the rules defined in Section 13 of RFC 9350 by introducing additional constraints based on Administrative Groups associated with the reverse direction of a link.
First, check whether any exclude reverse Admin Group rule is part of the Flex-Algorithm definition. If such a rule exists, check whether any Admin Group that is part of the exclude rule is also set on the link in the reverse direction. If such an Admin Group is set on the link in the reverse direction, the link must be pruned from the computation.
Second, check whether any include-any reverse Admin Group rule is part of the Flex-Algorithm definition. If such a rule exists, check whether any Admin Group that is part of the include-any rule is also set on the link in the reverse direction. If no such Admin Group is set on the link in the reverse direction, the link must be pruned from the computation.
Third, check whether any include-all reverse Admin Group rule is part of the Flex-Algorithm definition. If such a rule exists, check whether all Admin Groups that are part of the include-all rule are also set on the link in the reverse direction. If all such Admin Groups are not set on the link in the reverse direction, the link must be pruned from the computation.
Three rules run during the calculation, and each one can remove a link. The exclude rule removes the link if the reverse direction carries any of the listed marks. The include-any rule removes the link if the reverse direction carries none of them. The include-all rule removes the link unless the reverse direction carries every one of them. In each case the mark that matters is the one on the link pointing the other way.
| Rule | What is checked on the reverse link | When the link is pruned |
|---|---|---|
| Exclude reverse Admin Group | Whether any Admin Group in the exclude rule is set | When such a group is set |
| Include-any reverse Admin Group | Whether any Admin Group in the include-any rule is set | When no such group is set |
| Include-all reverse Admin Group | Whether all Admin Groups in the include-all rule are set | When not all of them are set |
§12IANA Considerations
IANA has registered types 10, 11 and 12 in the IS-IS Sub-Sub-TLVs for Flexible Algorithm Definition Sub-TLV registry under the IS-IS TLV Codepoints registry group, for the exclude, include-any and include-all reverse Admin Group sub-TLVs. The same three types have been registered in the OSPF Flexible Algorithm Definition TLV Sub-TLVs registry under the Open Shortest Path First Parameters registry group.
IANA has created a new registry called IGP Flex-Algorithm Path Computation Rules within the Interior Gateway Protocol Parameters registry group, with a registration procedure of Expert Review. The registry specifies the ordered set of rules used to prune links from the topology during the Flex-Algorithm path computation, and there is no upper bound on the number of rules it supports. The initial entries are the ten rules that exist today, and this document's three reverse Admin Group rules are numbers 8, 9 and 10.
The guidance for the designated expert says that when a new constraint is defined, the rule associated with it may be inserted at any position, because backwards compatibility is guaranteed by nodes not taking part in an algorithm whose definition specifies a constraint they do not support. The relative ordering of the existing rules must not be altered, because doing so has the potential to create backwards compatibility issues. Rules must not be deleted, because they are only used conditionally on the information carried in the winning definition. Rules must not be merged or repeated.
The document registers the new record types for both protocols, and it creates a list of all the pruning rules in the order they are applied. That list matters because the rules can be added by later documents without disturbing the ones already there: a new rule can go anywhere in the list, the existing order must not be changed, and nothing is ever removed.
§13Security Considerations
This document inherits the security considerations of RFC 9350. It adds no new mechanisms of its own, and the new sub-TLVs carry only administrative group values, which are the same kind of link attribute that the existing Flex-Algorithm sub-TLVs already carry.
The document adds no new security considerations of its own and follows the rules already set for Flex-Algorithm. The new records carry only the same kind of link attribute that the existing ones carry, so they do not open anything new.