RFC 9843
IGP Flexible Algorithms: Bandwidth, Delay, Metrics, and Constraints
RFC 9843: IGP Flexible Algorithms: Bandwidth, Delay, Metrics, and Constraints 🎀
Okay bestie, meet RFC 9843 💖 It's an IETF Standards Track document, so it's a real spec that implementers depend on, not just vibes. It was published in September 2025 under ISSN 2070-1721 ✨. The authors are S. Hegde, W. Britto, R. Shetty (Juniper Networks Inc.), B. Decraene (Orange), P. Psenak (Cisco Systems), and T. Li (Juniper Networks Inc.) 🫶. It updates RFC 9350 🦋, so keep that in mind when you read 9350 next to this one.
Abstract 🌸
So the gist is that lots of networks set the IGP link metric based on link capacity, and high bandwidth traffic gets routed over the big links 🚗. Flexible Algorithms are how you build constraint-based paths inside an IGP 💅. This spec defines a generic metric-type plus a set of bandwidth-related constraints you can use with Flexible Algorithms, and honestly it's giving main character energy 👑.
This document updates RFC 9350.
Status of This Memo 🧚
This is an Internet Standards Track document.
It's a product of the Internet Engineering Task Force (IETF), so it represents the consensus of the IETF community 🤝. It got public review and was approved for publication by the Internet Engineering Steering Group (IESG). If you want more on Internet Standards, check Section 2 of RFC 7841 📚.
Info about the current status of this document, any errata, and how to send feedback lives at https://www.rfc-editor.org/info/rfc9843 💌.
Copyright Notice 💜
Copyright (c) 2025 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. Please actually read these, because they spell out your rights and restrictions for 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 they're provided without warranty as described in the Revised BSD License 🍓.
Table of Contents 🗂️
1. Introduction
1.1. Requirements Language
2. Generic Metric Advertisement
2.1. IS-IS Generic Metric Sub-TLV
2.2. OSPF Generic Metric Sub-TLV
2.3. Generic Metric Applicability to Flexible Algorithm
Multi-Domain/Multi-Area Networks
3. FAD Constraint Sub-TLVs
3.1. IS-IS FAD Constraint Sub-TLVs
3.1.1. IS-IS Exclude Minimum Bandwidth Sub-TLV
3.1.2. IS-IS Exclude Maximum Delay Sub-TLV
3.2. OSPF FAD Constraint Sub-TLVs
3.2.1. OSPF Exclude Minimum Bandwidth Sub-TLV
3.2.2. OSPF Exclude Maximum Delay Sub-TLV
4. Bandwidth Metric Advertisement
4.1. Automatic Metric Calculation
4.1.1. Automatic Metric Calculation Modes
4.1.2. Automatic Metric Calculation Methods
4.1.3. IS-IS FAD Constraint Sub-TLVs for Automatic Metric
Calculation
4.1.4. OSPF FAD Constraint Sub-TLVs for Automatic Metric
Calculation
5. Bandwidth Metric Considerations
6. Calculation of Flex-Algorithm Paths
7. Backward Compatibility
8. Security Considerations
9. Operational Considerations
10. IANA Considerations
10.1. IGP Metric-Type Registry
10.2. IS-IS Sub-Sub-TLVs for Flexible Algorithm Definition
Sub-TLV
10.3. OSPF Sub-TLVs for Flexible Algorithm Definition Sub-TLV
10.4. IS-IS Sub-TLVs for TLVs Advertising Neighbor Information
10.5. Sub-Sub-TLV Codepoints for Application-Specific Link
Attributes
10.6. OSPFv2 Extended Link TLV Sub-TLVs
10.7. Types for Sub-TLVs of TE Link TLV (Value 2)
10.8. OSPFv3 Extended-LSA Sub-TLVs
11. References
11.1. Normative References
11.2. Informative References
Appendix A. Updated List of Rules for Pruning Links in
Flex-Algorithm Topology
Acknowledgements
Contributors
Authors' Addresses1. Introduction ✨
Okay so high bandwidth traffic, like residential Internet traffic and machine-to-machine elephant flows, really benefits from high capacity links 🐘. That's why lots of network operators set a link's metric relative to its capacity, to steer traffic toward the fatter pipes. But that's no guarantee the slower links get avoided, especially when stuff breaks 😭. If you want elephant flows to only land on high capacity links, it would be useful to explicitly keep the high throughput traffic off any link below a certain capacity 💖. Flex-Algorithm [RFC9350] gives you a way to build constrained paths by defining a set of parameters: a calculation-type, a metric-type, and a set of constraints. In this document, we add more extensions to the Flexible Algorithm Definition (FAD) so operators get extra control over their traffic flows, especially around bandwidth constraints 🎀.
Historically, IGPs computed paths by minimizing the sum of the link metrics along the path from source to destination 🛣️. The metric is administratively defined, but implementations have defaulted to a metric that's inversely proportional to link bandwidth. That pushed traffic onto higher bandwidth links, and it meant people had to manually tweak metrics to get the network loaded the way they wanted 🙄.
Over time, as different traffic types showed up, the need for other kinds of metrics grew 📈. Flex-Algorithm already supports the minimum link delay and the administratively assigned traffic-engineering metrics in path computation. Still, it's clear that other metrics could be useful in different situations ✨. A network operator might want to minimize operational costs, so they'd want a metric that reflects the actual fiscal cost of using a link 💸. Other traffic might need low jitter, which calls for a completely different set of metrics 🦋. With Flex-Algorithm, all of these metrics, and more, could be used at the same time on the same network 🌈.
Sometimes path computation constraints, like administrative groups, are used to make sure traffic avoids certain parts of the network 🚧. These strict constraints fit when there's an absolute requirement to avoid parts of the topology, even during failures 🙅♀️. But if the requirement is less strict, then putting a high metric on a portion of the topology may be a better fit 🧁.
This document defines a family of generic metrics that can advertise various types of administratively assigned metrics 📣. It introduces standard metric-types that have specific semantics and need standardization. It also specifies user-defined metric-types, where the specifics aren't defined, so administrators are free to assign whatever semantics they like 🎨.
Section 3 defines additional FAD [RFC9350] constraints that let the network administrator rule out low bandwidth links or high delay links 🚫. Section 4 specifies a new bandwidth-based metric-type to be used with Flex-Algorithm and other applications 💅.
Section 4.1 defines mechanisms to automatically calculate link metrics based on the parameters in the FAD and the advertised Maximum Link Bandwidth of each link 🤖. This is a big deal because administrators can change their criteria for metric assignment in one central place, without touching each link's metric across the whole network 🙌. The procedures here are meant to assign a metric to a link based on total link capacity. They are not meant to update the metric based on actual traffic flow 🚫📊. So these procedures don't replace the capability of a PCE [RFC4655], which has a dynamic view of the network and provides real-time bandwidth management, or a distributed bandwidth management protocol 🧠.
1.1. 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.
2. Generic Metric Advertisement 🌷
IS-IS [RFC1195] and OSPF [RFC2328] advertise a metric for each link in their respective link state advertisements 📡. Multiple metric-types are already supported 🙌. Administratively assigned metrics are described in the original OSPF and IS-IS specifications. The Traffic Engineering Default Metric is defined in [RFC5305] and [RFC3630], and the Unidirectional Link Delay is defined in [RFC8570] and [RFC7471] ⏱️. Other metrics, like jitter, reliability, and fiscal cost, may be helpful depending on the traffic class 💸. Rather than trying to list every metric someone might care about, this document specifies a generic mechanism for advertising metrics 🫶.
Each generic metric advertisement is on a per-link and per-metric-type basis 🔗. The metric advertisement has a metric-type field and a value for the metric. The metric-type field is assigned in the "IGP Metric-Type" IANA registry. Metric-types 0-127 are standard metric-types as assigned by IANA 📋. This document further specifies a user-defined metric-type space, metric-types 128-255, which an operator can assign for local use 🎀.
Implementations MUST support sending and receiving a Generic Metric sub-TLV in Application-Specific Link Attributes (ASLA) encodings, as well as in TLV 22 and Extended Link Opaque Link State Advertisements (LSAs) [RFC7684] and TE-LSAs 🛠️. The usage of a generic metric by an individual application is subject to the same rules that apply to other link attributes, as defined in [RFC3630], [RFC5305], [RFC9479], [RFC9492], and [RFC9350] 💅.
2.1. IS-IS Generic Metric Sub-TLV ✨
okay so the IS-IS Generic Metric sub-TLV is how a link's metric gets told to the world for a given metric-type 💅 and usually a network admin is the one picking that number 🎀. it shows up in these TLVs/sub-TLVs:
- a. TLV 22 (Extended IS reachability) [RFC5305]
- b. TLV 222 (MT-ISN) [RFC5120]
- c. TLV 23 (IS Neighbor Attribute) [RFC5311]
- d. TLV 223 (MT IS Neighbor Attribute) [RFC5311]
- e. TLV 141 (Inter-AS Reachability Information) [RFC9346]
- f. sub-TLV 16 (Application-Specific Link Attributes (ASLA)) of TLVs 22/222/23/223/141 [RFC9479]
- g. TLV 25 (L2 Bundle Member Attributes) [RFC8668]. Marked as "y(s)" (shareable among bundle members). 🫶
here's the layout bestie, it's giving very neat boxes 🦋
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 | metric-type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: IS-IS Generic Metric Sub-TLVnow the fields, lowkey the important part 🌸
Type (1 octet): an 8-bit field that IANA assigned (17). this value uniquely identifies the Generic Metric TLV, so it's basically its name tag 🏷️
Length (1 octet): an 8-bit field giving the total length, in octets, of the fields after it. for this TLV the Length is set to 4 📏
Metric-Type (1 octet): an 8-bit field that says what kind of metric this is. the value comes from the "IGP Metric-Type" registry that IANA keeps. the metric-type can be any value the "IGP Metric-Type" registry marks as allowed in the Generic Metric sub-TLV 🧚
Value (3 octets): a 24-bit unsigned integer that holds the metric value. the valid range is 0 to 16,777,215 (0xFFFFFF) 🔢
so the Generic Metric sub-TLV MAY be advertised multiple times 🎉 but for a particular metric-type, it MUST be advertised only once for a link when it's advertised in TLVs 22, 222, 23, 223, and 141. when it's advertised in ASLA, each metric-type MUST be advertised only once per application for a link 💜 and if a link has multiple Generic Metric sub-TLVs for the same metric-type (and the same application in the ASLA case) across one or more received Link State Protocol Data Units (LSPDUs), the advertisement in the lowest-numbered fragment MUST be used, and the later instances MUST be ignored 🙈
next up, legacy metrics. for a link, if the metric-type matches one that already has a legacy advertisement mechanism (like the IGP Metric, the Min Unidirectional Link Delay, or the Traffic Engineering Default Metric), the legacy metric-types MUST be utilized from the existing TLV or sub-TLVs. if a Generic Metric advertises a legacy metric, it MUST be ignored 💅
the max metric moment 😭 a metric value of 0xFFFFFF is treated as a maximum link metric, and a link with that value MUST be used during Flex-Algorithm calculations as a last resort link, as described in Section 15.3 of [RFC9350]. and if you want a link to be totally unusable by Flex-Algorithm, just leave out the Generic Metric advertisement for the metric-type that the Flex-Algorithm uses, as described in [RFC9350] 💀
and during router maintenance, the Generic Metric for all the links on the node MAY be set to the max value of 16,777,215 (0xFFFFFF), since that's the maximum usable link metric for the Flex-Algorithm calculations 🛠️✨
2.2. OSPF Generic Metric Sub-TLV 🌈
the OSPF version is giving the same energy: it sets the link metric for a given metric-type, and a network admin usually picks it 🎀. it gets advertised in these TLVs:
- a. sub-TLV of TE Link TLV (type 2) of OSPF TE LSA [RFC3630].
- b. sub-TLV of TE Link TLV (type 2) of OSPFv2 Inter-AS-TE-v2 LSA [RFC5392].
- c. sub-TLV of TE Link TLV (type 2) of OSPFv3 Intra-Area-TE-LSA [RFC5329].
- d. sub-TLV of TE Link TLV (type 2) of OSPFv3 Inter-AS-TE-v3 LSA [RFC5392].
- e. sub-TLV of Application-Specific Link Attributes (ASLA) sub-TLV [RFC9492] of the OSPFv2 Extended Link TLV [RFC7684].
- f. sub-TLV of Application-Specific Link Attributes (ASLA) sub-TLV [RFC9492] of the OSPFv3 Router-Link TLV [RFC8362].
- g. sub-TLV of the OSPFv2 L2 Bundle Member Attributes sub-TLV [RFC9356].
- h. sub-TLV of the OSPFv3 L2 Bundle Member Attributes sub-TLV [RFC9356].
the Generic Metric sub-TLV (types 25/36/34) is 8 octets long, so here's the picture 🦋
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| metric-type | Reserved (MBZ) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: OSPF Generic Metric Sub-TLVfield by field, bestie 💖
Type (2 octets): a 16-bit field that IANA assigned (25/36/34). this value uniquely identifies the Generic Metric TLV 🏷️
Length (2 octets): a 16-bit field giving the total length, in octets, of the fields after it. for this TLV the Length is set to 8 📏
Metric-Type (1 octet): an 8-bit field that says what kind of metric this is. the value comes from the "IGP Metric-Type" registry maintained by IANA. the metric-type can be any value that the "IGP Metric-Type" registry marks as allowed in the Generic Metric sub-TLV 🧚
Reserved (3 octets): MUST set to zero by the sender and MUST be ignored by the receiver 🤍
Value (4 octets): a 32-bit unsigned integer that holds the metric value. the valid range is 0 to 4,294,967,295 (0xFFFFFFFF) 🔢
the Generic Metric sub-TLV MAY be advertised multiple times here too 🎉 for a particular metric-type it MUST be advertised only once for a link when it's advertised as (a) through (d) above. when it's a sub-TLV of ASLA, it MUST be advertised only once per application for a link 💜 and if there are multiple Generic Metric sub-TLVs for a link with the same metric-type (and the same application in the ASLA case) across one or more received LSAs, the advertisement in the lowest-numbered LSA MUST be used, and the subsequent instances MUST be ignored 🙈
the legacy stuff is the same vibe: for a link, if the metric-type has a legacy advertisement mechanism (like the IGP Metric, the Min Unidirectional Link Delay, or the Traffic Engineering Default Metric), the legacy metric-types MUST be utilized from the existing TLV or sub-TLVs. if a Generic Metric advertises a legacy metric, it MUST be ignored 💅
max metric alert 😭 a metric value of 0xFFFFFFFF is considered a maximum link metric, and a link with this metric value MUST be used during Flex-Algorithm calculations as a last resort link, as described in Section 15.3 of [RFC9350]. and yes, a link can be made unusable by Flex-Algorithm by leaving out the Generic Metric advertisement of the metric-type that the Flex-Algorithm uses, as described in [RFC9350] 💀
and during router maintenance, the Generic Metric for all the links on the node MAY be set to the max value of 4,294,967,295 (0xFFFFFFFF), since it's the maximum usable link metric for the Flex-Algorithm calculations 🛠️✨
2.3. Generic Metric Applicability to Flexible Algorithm Multi-Domain/Multi-Area Networks 🌸
okay so Generic Metric can be used by Flex-Algorithm just by putting the metric-type in the Flexible Algorithm Definitions 🦋 when Flex-Algorithm runs in a multi-area network, [RFC9350] defines the Flexible Algorithm Prefix Metric (FAPM) sub-TLV, which carries the Flexible-Algorithm-specific metric 🧚 the metrics carried in FAPM are equal to the metric to reach the prefix for that Flex-Algorithm in its source area or domain (the source area from the Area Border Router (ABR) perspective) 👑 and when Flex-Algorithm uses Generic Metric, the same procedures from Section 13 of [RFC9350] are used to send and process the FAPM sub-TLV 🫶
3. FAD Constraint Sub-TLVs 💜
so picture this: large high throughput flows are called "elephant flows" 🐘 and if an elephant flow gets sent down a low-bandwidth link, it might congest that link and make other critical application traffic on it drop 😭 so in the context of Flex-Algorithm, it would be super useful to constrain the topology to only the links that can handle a minimum amount of bandwidth 💅
if the capacity of a low-bandwidth link is constant, you can already avoid those links with administrative groups 🎀 but when a Layer 3 link is really a bunch of Layer 2 links (a Link Aggregation Group (LAG) / Layer 2 Bundle), the link bandwidth changes depending on which constituent links are active 🌈 you could automate that by having an implementation vary the advertised administrative groups based on bandwidth, but that seems unnecessarily complex 🙈 expressing the requirement as a direct constraint on the topology is simpler. it's also a win if the minimum required bandwidth changes, because this constraint gives you a single, centralized, coordinated point of control 👑
so to cover this, this document defines an Exclude Minimum Bandwidth constraint ✨ when this constraint is advertised in a FAD, a link gets pruned from the Flex-Algorithm topology if the link's advertised maximum link bandwidth value is below the FAD advertised minimum bandwidth value 🔥
same energy with the Exclude Maximum Link Delay constraint 🦋 applications like High-Frequency Trading are sensitive to link delays, and they can perform poorly in networks that are prone to delay variability, like networks with transparent Layer 2 link recovery mechanisms or satellite links 🛰️ there are already mechanisms to measure link delay dynamically and advertise it in the IGP, so networks that use dynamic link-delay measurement might want to exclude links whose delay is over a given threshold 🧚
3.1. IS-IS FAD Constraint Sub-TLVs 🌷
3.1.1. IS-IS Exclude Minimum Bandwidth Sub-TLV 💖
okay so the IS-IS Flex-Algorithm Exclude Minimum Bandwidth (FAEMB) sub-TLV is a sub-TLV of the IS-IS FAD sub-TLV 🎀 here's how it's laid out:
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Min Bandwidth |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: IS-IS FAEMB Sub-TLVwhere:
Type (1 octet): an 8-bit field assigned by IANA (6) ✨ this value uniquely identifies the FAEMB sub-TLV, so it's basically its ID card 🪪
Length (1 octet): an 8-bit field showing the total length, in octets, of the fields that come after it 📏 for this sub-TLV, the Length is set to 4.
Min Bandwidth (4 octets): a 32-bit field giving the link bandwidth in IEEE floating point format (32 bits) [IEEE754-2019] 🌈 the units are bytes per second.
ok the FAEMB sub-TLV MUST appear once at most in the FAD sub-TLV 👑 if it shows up more than once, the IS-IS FAD sub-TLV MUST be ignored by the receiver 💀 no double-dipping allowed bestie.
the minimum bandwidth value advertised in the FAEMB sub-TLV MUST be compared with the maximum link bandwidth value advertised in sub-sub-TLV 9 of the ASLA sub-TLV [RFC9479] 🔥 and if the L-flag is set in the ASLA sub-TLV, then the minimum bandwidth value in the FAEMB sub-TLV MUST be compared with the maximum link bandwidth value as advertised in the sub-TLV 9 of the TLVs 22/222/23/223/141 [RFC5305], as defined in Section 4.2 of [RFC9479] 🧚
if the maximum link bandwidth value is lower than the minimum link bandwidth value advertised in the FAEMB sub-TLV, the link MUST be excluded from the Flex-Algorithm topology 🙈 and if a link doesn't have the Maximum Link Bandwidth advertised but the FAD contains the FAEMB sub-TLV, then that link MUST NOT be excluded from the topology based on the Minimum Bandwidth constraint 🫶 the link gets to stay, no cap.
3.1.2. IS-IS Exclude Maximum Delay Sub-TLV 🌸
okay next up, the IS-IS Flex-Algorithm Exclude Maximum Delay (FAEMD) sub-TLV, which is also a sub-TLV of the IS-IS FAD sub-TLV 🦋 layout time:
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Max Link Delay |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: IS-IS FAEMD Sub-TLVwhere:
Type (1 octet): an 8-bit field assigned by IANA (7) 🪪 this uniquely identifies the FAEMD sub-TLV.
Length (1 octet): an 8-bit field showing the total length, in octets, of the fields after it 📏 for this sub-TLV, the Length is set to 3.
Max Link Delay (3 octets): a 24-bit field giving the Maximum link delay in microseconds ⏱️
the FAEMD sub-TLV MUST appear only once in the FAD sub-TLV 💅 if it appears more than once, the IS-IS FAD sub-TLV MUST be ignored by the receiver 😭 rules are rules, bestie.
the maximum link delay value advertised in the FAEMD sub-TLV MUST be compared with the Min Unidirectional Link Delay advertised in sub-sub-TLV 34 of the ASLA sub-TLV [RFC9479] 🌈 and if the L-flag is set in the ASLA sub-TLV, the maximum link delay value advertised in the FAEMD sub-TLV MUST be compared with the Min Unidirectional Link Delay as advertised by the sub-TLV 34 of the TLVs 22/222/23/223/141 [RFC8570], as defined in Section 4.2 of [RFC9479] ✨
if the Min Unidirectional Link Delay value is higher than the Maximum Link Delay advertised in the FAEMD sub-TLV, the link MUST be excluded from the Flex-Algorithm topology 🚫 and if the Min Unidirectional Link Delay isn't advertised but the FAD contains the FAEMD sub-TLV, then that link MUST NOT be excluded from the topology based on the Maximum Delay constraint 🍓 it's giving "benefit of the doubt."
3.2. OSPF FAD Constraint Sub-TLVs 🧚
3.2.1. OSPF Exclude Minimum Bandwidth Sub-TLV 💜
okay so the OSPF Flex-Algorithm Exclude Minimum Bandwidth (FAEMB) sub-TLV is a sub-TLV of the OSPF FAD TLV 🎀 here's the layout:
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Min Bandwidth |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5: OSPF FAEMB Sub-TLVwhere:
Type (2 octets): a 16-bit field assigned by IANA (6) 🪪 this uniquely identifies the OSPF FAEMB sub-TLV.
Length (2 octets): a 16-bit field showing the total length, in octets, of the fields after it 📏 for this sub-TLV, the Length is set to 4.
Min Bandwidth (4 octets): a 32-bit field giving the link bandwidth in IEEE floating point format (32 bits)[IEEE754-2019] 🌈 the units are bytes per second.
the FAEMB sub-TLV MUST only appear once in the FAD sub-TLV 👑 if it appears more than once, the OSPF FAD TLV MUST be ignored by the receiver 💀
the Maximum Link Bandwidth as advertised in the Extended Link TLV in the Extended Link Opaque LSA in OSPFv2 [RFC7684], or as a sub-TLV of the Router-Link TLV of the E-Router-LSA Router-Link TLV in OSPFv3 [RFC8362], MUST be compared against the Minimum Bandwidth advertised in the FAEMB sub-TLV 🔥 if the link bandwidth value is lower than the Minimum Bandwidth advertised in the FAEMB sub-TLV, the link MUST be excluded from the Flex-Algorithm topology 🙈
if a link doesn't have the Maximum Link Bandwidth advertised but the FAD contains the FAEMB sub-TLV, then that link MUST be included in the topology and proceed to apply further pruning rules for the link 🦋 so it doesn't get cut yet, it just keeps going through the checks.
3.2.2. OSPF Exclude Maximum Delay Sub-TLV 🌈
okay the OSPF Flex-Algorithm Exclude Maximum Delay (FAEMD) sub-TLV is a sub-TLV of the OSPF FAD TLV 💅 here's the layout:
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RESERVED | Max Link Delay |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6: OSPF FAEMD Sub-TLVwhere:
Type (2 octets): a 16-bit field assigned by IANA (7) 🪪 this uniquely identifies the OSPF FAEMD sub-TLV.
Length (2 octets): a 16-bit field showing the total length, in octets, of the fields after it 📏 for this sub-TLV, the Length is set to 4.
Reserved (1 octet): MUST be set to zero by the sender and MUST be ignored by the receiver 🫧
Max Link Delay (3 octets): a 24-bit field giving the Maximum link delay in microseconds ⏱️
the FAEMD sub-TLV MUST only appear once in the OSPF FAD TLV ✨ if it appears more than once, the OSPF FAD TLV MUST be ignored by the receiver 😭
the Min Delay value advertised via the Min/Max Unidirectional Link Delay of the ASLA sub-TLV [RFC9492] MUST be compared against the Maximum Delay advertised in the FAEMD sub-TLV 🌸 if the Min Unidirectional Link Delay is higher than the Maximum Delay advertised in the FAEMD sub-TLV, the link MUST be excluded from the Flex-Algorithm topology 🚫 and if the Min/Max Unidirectional Link Delay isn't advertised for a link but the FAD contains this sub-TLV, then that link MUST NOT be excluded from the topology based on the Maximum Delay constraint 🍓
4. Bandwidth Metric Advertisement 🌈
okay so historically, IGP implementations have made default metric assignments based on link bandwidth 🫶 that's been useful, but the defaults were different across implementations, and link bandwidths have grown super fast 🚀 with Flex-Algorithm, the network admin can define a function that produces a metric for each link, and every node automatically computes each link's metric from its bandwidth 🧮 so no more guessing.
this document defines a standard metric-type for this called the "Bandwidth Metric" ✨ the Bandwidth Metric MAY be advertised in the Generic Metric sub-TLV with the metric-type set to "Bandwidth Metric" 🎀 IS-IS and OSPF will advertise this type of metric in their link advertisements 🦋 the Bandwidth Metric is a link attribute, and it MUST follow Section 12 of [RFC9350] for its advertisement and processing during Flex-Algorithm calculation 💅
Flex-Algorithm uses this metric-type by specifying the bandwidth metric as the metric-type in a FAD TLV 👑 a FAD TLV may also specify an automatic computation of the bandwidth metric based on a link's advertised bandwidth 🧚 an explicit advertisement of a link's bandwidth metric using the Generic Metric sub-TLV overrides this automatic computation 🔥 and the automatic Bandwidth metric calculation sub-TLVs are advertised in the FAD TLV, and these parameters apply to applications like Flex-Algorithm that use the FAD TLV 💖
4.1. Automatic Metric Calculation 🧮
okay so networks that are designed to be highly regular and follow uniform metric assignment might want to simplify operations by automatically calculating the bandwidth metric 🌸 when a FAD advertises the metric-type as Bandwidth Metric and the link doesn't have the Bandwidth Metric advertised, automatic metric derivation can be used along with the additional FAD constraint advertisement described in this section 🫶
if a link's bandwidth changes, the delay in learning about the change may create the possibility of micro-loops in the topology 😬 this is no different from the IGP's susceptibility to micro-loops during a metric change 🌀 the micro-loop avoidance procedures described in [SR-LOOP-AVOID], or any other mechanism described in the framework [RFC5715], can be used to avoid micro-loops when automatic metric calculation is deployed 🛡️
computing the metric between adjacent systems based on bandwidth gets more complex with parallel adjacencies 🙃 if there are parallel adjacencies between systems, then the bandwidth between the systems is the sum of the bandwidth of the parallel links ➕ this is a bit more complex to deal with, so there is an optional mode for computing the aggregate bandwidth 🍰
4.1.1. Automatic Metric Calculation Modes 💜
4.1.1.1. Simple Mode 🫧
in Simple Mode, the Maximum Link Bandwidth of a single Layer 3 link is used to derive the metric 🎯 this mode is suitable for deployments that don't use parallel Layer 3 links ✨ in this case, the computation of the metric is straightforward 💅 if a Layer 3 link is composed of a Layer 2 bundle, then the link bandwidth is the sum of the bandwidths of the working components, and it may vary with Layer 2 link failures 🌈 bestie, that's the whole vibe.
4.1.1.2. Interface Group Mode 🧚
Okay so Simple Mode might not vibe when there are multiple parallel Layer 3 interfaces between two nodes 😩. Ideally, the metric between two systems should be the same for the same bandwidth, whether that bandwidth comes from parallel Layer 2 links or parallel Layer 3 links 💅. To fix this, in Interface Group Mode, nodes MUST compute the aggregate bandwidth of all parallel adjacencies, MUST derive the metric based on that aggregate bandwidth, and MUST apply the resulting metric to each of the parallel adjacencies 🔥. ngl, a single elephant flow is normally pinned to a single Layer 3 interface 🐘. If one Layer 3 link's bandwidth isn't enough for any single elephant flow, the mechanisms to solve that are outside the scope of this document 🙈.
A------B====C====F====D
| |
------E-------
Figure 7: Parallel InterfacesHere's an example with that diagram 🎀. There are two parallel links between B->C, C->F, and F->D. Let's say the link bandwidth is a uniform 10 Gbps on all links. When bandwidth is used to derive the metric for the links, the metric for each link will be the same. Traffic from B to D will go B->E->D because that metric is lower. But since the bandwidth is higher on the B->C->F->D path, that path's metric should be lower than the B->E->D path to attract the traffic 🦋. Interface Group Mode should be preferred in cases where there are parallel Layer 3 links ✨.
In Interface Group Mode, every node MUST identify the set of parallel links between a pair of nodes based on IGP link advertisements, and MUST consider the cumulative bandwidth of the parallel links while arriving at the metric of each link 🫶.
The parallel Layer 3 links between two nodes may not have the same bandwidth. In that case, the method described in Interface Group Mode will give all the parallel links the same metric, which may cause undesired load balancing on the links 😭. So a device may locally apply a load-balancing factor relative to the link bandwidth on the ECMP next hops 💜. The load-balancing mechanisms are outside the scope of this document 🌸.
4.1.2. Automatic Metric Calculation Methods 🌈
For automatic metric calculation in Simple and Interface Group Mode, the Maximum Link Bandwidth of the links is used to derive the metric. There are two types of automatic metric derivation methods 👑:
- Reference bandwidth method
- Bandwidth thresholds method
4.1.2.1. Reference Bandwidth Method 💖
In many networks, the metric is inversely proportional to the link bandwidth 📉. The administrator or implementation selects a reference bandwidth, and the metric is derived by dividing the reference bandwidth by the advertised Maximum Link Bandwidth. Advertising the reference bandwidth in the FAD constraints lets the metric computation happen on every node for each link 🧠. The metric is computed using the reference bandwidth and the advertised link bandwidth. Centralized control of this reference bandwidth makes management simpler when the reference bandwidth changes 🎯. To make sure small bandwidth changes don't change the link metric, it helps to define the granularity of the bandwidth you care about 🔍. The link bandwidth gets truncated to this granularity before the metric is derived ✂️.
For example:
reference bandwidth = 1000G
Granularity = 20G
The derived metric is 10 for link bandwidth in the range 100G to
119G4.1.2.2. Bandwidth Thresholds Method 🍓
The reference bandwidth approach above gives a uniform metric value for a range of link bandwidths. Sometimes, though, you need non-proportional metric values for different ranges of link bandwidth 🤸. For example, bandwidths from 10G to 30G are assigned metric value 100, bandwidths from 30G to 70G are assigned a metric value of 50, and bandwidths greater than 70G have a metric of 10. To support this, a staircase mapping based on bandwidth thresholds is supported in the FAD. This advertisement contains a set of threshold values and their associated metrics 🪜💅.
4.1.3. IS-IS FAD Constraint Sub-TLVs for Automatic Metric Calculation 🎀
4.1.3.1. Reference Bandwidth Sub-TLV 🦄
This section gives the FAD constraint advertisement details for the reference bandwidth method of metric calculation, as described in Section 4.1.2.1. The Flexible Algorithm Definition Reference Bandwidth (FADRB) 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 | Flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reference Bandwidth |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Granularity Bandwidth |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 8: IS-IS FADRB Sub-TLVHere's what each field means 🔎:
- Type (1 octet): An 8-bit field assigned by IANA (8). This value uniquely identifies the IS-IS FADRB sub-TLV 🏷️.
- Length (1 octet): An 8-bit field indicating the total length, in octets, of the subsequent fields. For this sub-TLV, the Length is set to 9 📏.
- Flags (1 octet): An 8-bit field containing flags 🚩.
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
|G| |
+-+-+-+-+-+-+-+-+- G-flag: When set, Interface Group Mode MUST be used to derive the total link bandwidth. Unassigned bits MUST be set to zero and MUST be ignored by the receiver 🙌.
- Reference Bandwidth (4 octets): A 32-bit field with Bandwidth encoded in IEEE floating point format [IEEE754-2019]. The units are bytes per second 💧.
- Granularity Bandwidth (4 octets): A 32-bit field with Bandwidth encoded in IEEE floating point format [IEEE754-2019]. The units are bytes per second 💧.
The Granularity Bandwidth value makes sure the metric doesn't change when the link bandwidth changes a little 🛡️. Here's the math 🧮.
When granularity_bw is less than or equal to Total_link_bandwidth:
Metric calculation: (Reference_bandwidth) / (Total_link_bandwidth -
(Modulus of(Total_link_bandwidth, granularity_bw)))When granularity_bw is greater than Total_link_bandwidth:
Metric calculation: Reference_bandwidth / Total_link_bandwidthThe division used here is integer division. The Modulus of operation is defined as the remainder value when two numbers are divided ➗.
The IS-IS FADRB sub-TLV MUST NOT appear more than once in an IS-IS FAD sub-TLV. If it does appear more than once, the IS-IS FAD sub-TLV MUST be ignored by the receiver 🚫. The value advertised in the Reference Bandwidth field MUST be non-zero. If a zero value is advertised in the Reference Bandwidth field in the IS-IS FADRB sub-TLV, the sub-TLV MUST be ignored 🙅♀️.
If a Generic Metric sub-TLV with a Bandwidth metric-type is advertised for a link, the Flex-Algorithm calculation MUST use the advertised Bandwidth Metric and MUST NOT use the automatically derived metric for that link. That's a big deal, bestie 🚨.
For Interface Group Mode, these rules apply to parallel links 👯:
- If all the parallel links have been advertised with the Bandwidth Metric: The individual link Bandwidth Metric MUST be used ✅.
- If only some of the parallel links have advertised the Bandwidth Metric:
- The Bandwidth Metric for those links MUST be ignored 🙈.
- Automatic metric calculation MUST be used to derive the link metric 🔄.
If the calculated metric evaluates to zero, a metric of 1 MUST be used 1️⃣.
If the calculated metric evaluates to a number greater than 0xFFFFFF, it is set to 0xFFFFFF 🌟.
4.1.3.2. Bandwidth Threshold Sub-TLV 🎀
okay bestie, this section is the FADBT sub-TLV, and it's the one for the Bandwidth Thresholds method from Section 4.1.2.2 🫶 it's a sub-TLV of the IS-IS FAD sub-TLV, and it looks like this 👇
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 | Flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Bandwidth Threshold 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Threshold Metric 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Bandwidth Threshold 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Threshold Metric 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Bandwidth Threshold 3 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
.....
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Threshold Metric N-1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Bandwidth Threshold N |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Threshold Metric N |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Figure 9: IS-IS FADBT Sub-TLV
here's what each field does 💅
Type (1 octet): an 8-bit field that IANA assigned the value (9) ✨ this is what uniquely identifies the IS-IS FADBT sub-TLV, so it's basically its ID card 🪪
Length (1 octet): an 8-bit field for the total length in octets of the stuff after it. for this one it's calculated as (1+N*7), where N is the number of Threshold Metrics. N MUST be greater than or equal to 1, so there's always at least one threshold 🍓
Flags (1 octet):
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
|G| | | |
+-+-+-+-+-+-+-+-+- G-flag: when this is set, Interface Group Mode MUST be used to derive the total link bandwidth 🧚 any unassigned bits MUST be set to zero and MUST be ignored by the receiver, no exceptions bestie 🙈
now the staircase part, which is giving stairs of bandwidth 🌈 it's a list of bandwidth thresholds, each one paired with its own metric value:
Bandwidth Threshold 1 (4 octets): the Minimum Link Bandwidth, encoded in IEEE floating point format (32 bits) [IEEE754-2019]. the units are bytes per second 💜
Threshold Metric 1 (3 octets): the metric value range is 1 - 16,777,215 (0xFFFFFF) 🦋
Bandwidth Threshold N (4 octets): the Maximum Link Bandwidth, encoded in IEEE floating point format (32 bits) [IEEE754-2019]. again, the units are bytes per second 🫧
Threshold Metric N (3 octets): the metric value range is 1 - 16,777,215 (0xFFFFFF) ✨
when the G-flag is set, the cumulative bandwidth of the parallel links is computed the way Section 4.1.1.2 describes. if the G-flag is not set, the advertised Maximum Link Bandwidth is used instead 🎀
okay here comes the main event 👑 how the Bandwidth Metric gets assigned for a link during the Flex-Algorithm Shortest Path First (SPF) calculation. this part is serious, so pay attention 💅
The Bandwidth Metric for a link during the Flex-Algorithm Shortest Path First (SPF) calculation MUST be assigned according to the following rules:
- When the computed link bandwidth is less than Bandwidth Threshold 1:
The Bandwidth Metric MUST be set to the maximum metric value of 4,261,412,864. 😭
- When the computed link bandwidth is greater than or equal to Bandwidth Threshold 1 and less than Bandwidth Threshold 2:
The Bandwidth Metric MUST be set to Threshold Metric 1. 🌸
- When the computed link bandwidth is greater than or equal to Bandwidth Threshold 2 and less than Bandwidth Threshold 3:
The Bandwidth Metric MUST be set to Threshold Metric 2. 💖
- In general, for all integer values of X such that
1 ≤ X < N:
When the computed link bandwidth is greater than or equal to Bandwidth Threshold X and less than Bandwidth Threshold X+1:
The Bandwidth Metric MUST be set to Threshold Metric X. 🧚
- When the computed link bandwidth is greater than or equal to Bandwidth Threshold N:
The Bandwidth Metric MUST be set to Threshold Metric N. 🦋
a few notes to keep in your head bestie 📝
- The term "Bandwidth Threshold X" just means a predefined threshold value for the index X 🫶
- The term "Threshold Metric X" is the metric value tied to Bandwidth Threshold X 🌈
- N is the total number of bandwidth thresholds defined in the system ✨
implementations MUST ensure that these rules are consistently applied, so the network stays interoperable and the path computation stays optimal 🔥
also, the IS-IS FADBT sub-TLV MUST NOT appear more than once in an IS-IS FAD sub-TLV. if it shows up more than once, the IS-IS FAD sub-TLV MUST be ignored by the receiver 🙈
a FAD MUST NOT contain both the FADBT sub-TLV and the FADRB sub-TLV. if both are advertised in the same FAD for a Flexible Algorithm, the FAD MUST be ignored by the receiver. no double dipping allowed 💀
if a Generic Metric sub-TLV with Bandwidth metric-type is advertised for a link, then the Flex-Algorithm calculation MUST use the Bandwidth Metric advertised on the link and MUST NOT use the automatically derived metric for that link. the manual one wins, periodt 💅🎀
and for Interface Group Mode with parallel links, here's the drama:
- if all the parallel links have been advertised with the Bandwidth Metric:
- the individual link Bandwidth Metric MUST be used 🌸
- if only some of the parallel links have advertised the Bandwidth Metric:
- the Bandwidth Metric for those links MUST be ignored 😭
- automatic metric calculation MUST be used to derive the link metric 🧚
4.1.4. OSPF FAD Constraint Sub-TLVs for Automatic Metric Calculation ✨
okay so now we switch to the OSPF side of things 🦋 this is the OSPF FAD constraint sub-TLVs for automatic metric calculation, and the first one up is the Reference Bandwidth one.
4.1.4.1. Reference Bandwidth Sub-TLV 🌈
the Flexible Algorithm Definition Reference Bandwidth (FADRB) sub-TLV is a sub-TLV of the OSPF FAD TLV. it looks like this 👇
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reference Bandwidth |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Granularity Bandwidth |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Figure 10: OSPF FADRB Sub-TLV
the fields, explained for bestie 💖
Type (2 octets): a 16-bit field that IANA assigned the value (8) 🎀 this uniquely identifies the OSPF FADRB sub-TLV ✨
Length (2 octets): a 16-bit field for the total length in octets of the stuff after it. for this sub-TLV, Length is set to 14 🧚
Flags (1 octet):
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
|G| | | |
+-+-+-+-+-+-+-+-+- G-flag: when set, Interface Group Mode MUST be used to derive the total link bandwidth 🫧 unassigned bits MUST be set to zero and MUST be ignored by the receiver 🌸
Reference Bandwidth (4 octets): bandwidth encoded in 32 bits in IEEE floating point format [IEEE754-2019]. the units are in bytes per second 🦋
Granularity Bandwidth (4 octets): bandwidth encoded in 32 bits in IEEE floating point format [IEEE754-2019]. the units are in bytes per second 💜
now the math bit, which is lowkey the spiciest part 🌶️ the metric calculation depends on whether granularity_bw is less than or equal to Total_link_bandwidth.
When granularity_bw is less than or equal to Total_link_bandwidth, then:
Metric calculation:
(Reference_bandwidth) / (Total_link_bandwidth - (Modulus
of(Total_link_bandwidth, granularity_bw)))When granularity_bw is greater than Total_link_bandwidth, then:
Metric calculation:
Reference_bandwidth/ Total_link_bandwidththe division used here is integer division 🔢 and modulus is defined as the remainder value when two numbers are divided 🧮
the Granularity Bandwidth value is there so the metric doesn't change when there's a small change in the link bandwidth. it's giving stability 🫶
some more rules, and these ones are important:
- the OSPF FADRB 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 🙈
- the value advertised in the Reference Bandwidth field MUST be non-zero 💅
- if a zero value is advertised in the Reference Bandwidth field in the OSPF FADRB sub-TLV, the sub-TLV MUST be ignored 💀
- if a Generic Metric sub-TLV with Bandwidth metric-type is advertised for a link, the Flex-Algorithm calculation MUST use the advertised Bandwidth Metric on the link and MUST NOT use the automatically derived metric for that link 👑
and yes, Interface Group Mode has its own drama for OSPF too 🌈
- when all parallel links have advertised the Bandwidth Metric:
- the individual link Bandwidth Metric MUST be used for each link 🌸
- when only a subset of the parallel links have advertised the Bandwidth Metric:
- the Bandwidth Metric advertisements for those links MUST be ignored 😭
- automatic metric calculation MUST be used to derive the link metrics for all parallel links 🧚
last but not least, the fallback rules 🫶
if the calculated metric evaluates to zero, a metric of 1 MUST be used. ✨
if the calculated metric evaluates to a number greater than 0xFFFFFFFF, it is set to 0xFFFFFFFF. 🦋
4.1.4.2. Bandwidth Threshold Sub-TLV ✨
okay bestie, so the Flex-Algorithm Definition Bandwidth Threshold (FADBT) sub-TLV lives inside the OSPF FAD TLV 🎀 and it's giving staircase energy. Here's the layout:
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Bandwidth Threshold 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Threshold Metric 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Bandwidth Threshold 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Threshold Metric 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Bandwidth Threshold 3 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
.....
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Threshold Metric N-1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Bandwidth Threshold N |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Threshold Metric N |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 11: OSPF FADBT Sub-TLVHere's what each field does 💅
Type (2 octets): a 16-bit field assigned by IANA (9). It's how everyone knows this is the OSPF FADBT sub-TLV 🦋
Length (2 octets): a 16-bit field for the total length, in octets, of the fields after it. For this sub-TLV, Length is set to 2 + N*8 octets, where N is the number of Threshold Metrics you've specified. N MUST be greater than or equal to 1. no zero-threshold drama allowed 🙈
Flags (1 octet):
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
|G| |
+-+-+-+-+-+-+-+-+G-flag: when this is set, Interface Group Mode MUST be used to derive the total link bandwidth 🌈 Any unassigned bits MUST be set to zero, and the receiver MUST ignore them. ignore the leftovers, periodt 💖
Now for the staircase itself 🪜
Bandwidth Threshold 1 (4 octets): the Minimum Link Bandwidth, encoded in IEEE floating point format (32 bits)[IEEE754-2019]. The units are bytes per second ✨
Threshold Metric 1 (4 octets): the metric value, in the range 1 - 4,294,967,296 (0xFFFFFFFF) 🍓
Bandwidth Threshold N (4 octets): the Maximum Link Bandwidth, encoded in IEEE floating point format (32 bits)[IEEE754-2019]. The units are bytes per second 🌸
Threshold Metric N (4 octets): the metric value, in the range 1 - 4,294,967,296 (0xFFFFFFFF) 💜
When the G-flag is set, the cumulative bandwidth of the parallel links is computed as described in Section 4.1.1.2. If the G-flag is not set, the advertised Maximum Link Bandwidth is used 🎀
The assignment of the Bandwidth Metric based on the computed link bandwidth works like this:
During the Flex-Algorithm SPF calculation, the Bandwidth Metric for a link MUST be assigned according to the following rules 👑
- When the computed link bandwidth is less than Bandwidth Threshold 1, the Bandwidth Metric MUST be set to the maximum metric value of 4,294,967,296. bottom of the staircase, no notes 💀
- When the computed link bandwidth is greater than or equal to Bandwidth Threshold 1 and less than Bandwidth Threshold 2, the Bandwidth Metric MUST be set to Threshold Metric 1.
- When the computed link bandwidth is greater than or equal to Bandwidth Threshold 2 and less than Bandwidth Threshold 3, the Bandwidth Metric MUST be set to Threshold Metric 2.
- In general, for all integer values of X where
1 ≤X < N: when the computed link bandwidth is greater than or equal to Bandwidth Threshold X and less than Bandwidth Threshold X+1, the Bandwidth Metric MUST be set to Threshold Metric X. - When the computed link bandwidth is greater than or equal to Bandwidth Threshold N, the Bandwidth Metric MUST be set to Threshold Metric N. top step, iconic 👑
A few notes to keep you sane 🧚
- Bandwidth Threshold X refers to the predefined bandwidth threshold at index X.
- Threshold Metric X is the metric value tied to Bandwidth Threshold X.
- N is the total number of bandwidth thresholds defined in the system.
Implementations MUST consistently apply these rules to ensure accurate path computations and maintain interoperability within the network 🫶
Some more hard rules, bestie 🔥 The OSPF FADBT sub-TLV MUST NOT appear more than once in an OSPF FAD sub-TLV. If it does show up twice, the OSPF FAD sub-TLV MUST be ignored by the receiver. Also, a FAD MUST NOT contain both the FADBT sub-TLV and the FADRB sub-TLV. If both are advertised in the same FAD for a Flexible Algorithm, the FAD MUST be ignored by the receiver. no double-dipping 💅
If a Generic Metric sub-TLV with Bandwidth metric-type is advertised for a link, the Flex-Algorithm calculation MUST use the Bandwidth Metric advertised on the link and MUST NOT use the automatically derived metric for that link. the advertised value wins, always 🏆
Metric Assignment in Interface Group Mode:
When a link does not have a configured Bandwidth Metric, the automatically derived metric MUST be used for that link 🦋
For Interface Group Mode, these rules apply to parallel links:
- If all parallel links have advertised the Bandwidth Metric, the individual link Bandwidth Metric MUST be used for each link during path computation. everyone shows up, everyone counts ✨
- If only some of the parallel links have advertised the Bandwidth Metric:
- The Bandwidth Metric advertisements for those links MUST be ignored.
- Automatic metric calculation MUST be used to derive the link metrics for all parallel links. partial hype doesn't count, sorry not sorry 🙈
This approach keeps the metric calculation consistent and avoids discrepancies caused by partial Bandwidth Metric advertisements among parallel links 🌈
5. Bandwidth Metric Considerations 🎀
This section specifies the rules for deriving the Bandwidth Metric if and only if the winning FAD for the Flex-Algorithm specifies the metric-type as "Bandwidth Metric" 💖
- If the Generic Metric sub-TLV with Bandwidth metric-type is advertised for the link as described in Section 4, it MUST be used during the Flex-Algorithm calculation. the explicit advert goes first, obviously 🥇
- If the Generic Metric sub-TLV with Bandwidth metric-type is not advertised for the link, and the winning FAD for the Flex-Algorithm does not specify the automatic Bandwidth metric calculation (as defined in Section 4.1), the link is treated as if the Bandwidth Metric is not available for the link. no auto-math, no bandwidth 🤷♀️
- If the Generic Metric sub-TLV with Bandwidth metric-type is not advertised for the link, and the winning FAD (Section 5.3 of [RFC9350]) for the Flex-Algorithm specifies the automatic Bandwidth metric calculation (as defined in Section 4.1), the Bandwidth Metric MUST be automatically calculated per the procedures defined in Section 4.1. If the Link Bandwidth is not advertised for a link, the link MUST be pruned for the Flex-Algorithm calculations. no bandwidth info, no entry to the party 🚫
- In IS-IS, for Flex-Algorithm purposes, the Link Bandwidth is advertised as a sub-sub-TLV 9 of the Flex-Algorithm-specific ASLA sub-TLV. It is also possible to advertise the link bandwidth or Flex-Algorithm in sub-TLV 9 of TLVs 22/222/23/223/141 [RFC5305] together with the L-flag set in the Flex-Algorithm-specific ASLA advertisement. In the absence of both of these advertisements, the bandwidth of the link is not available for Flex-Algorithm purposes. two routes to the same bandwidth, pick your favorite 🧚
6. Calculation of Flex-Algorithm Paths 💅
Two new rules get added on top of the existing Flex-Algorithm calculation rules in Section 13 of [RFC9350], so here they are, boxed up and ready to go ✨
| 6. Check if any exclude FAEMB rule is part of the Flex-Algorithm
| definition. If such exclude rule exists and the link has
| 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 of the Flex-Algorithm
| definition. If such exclude rule exists and the link has 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.7. Backward Compatibility 🌸
This extension brings no new backward-compatibility issues 🫶 This document defines new FAD constraints in Sections 3, 4.1.3, and 4.1.4. As described in [RFC9350], any node that does not understand sub-TLVs in a FAD TLV stops participation in the corresponding Flex-Algorithm. The new extensions can be deployed among the nodes that are upgraded to understand them, without affecting the nodes that aren't upgraded yet 🦋
This document also defines a new metric advertisement, as described in Section 2. As per Section 13 of [RFC9350], when the links do not advertise the metric-type specified by the selected FAD, the link is pruned from Flex-Algorithm calculations. The new metric-types, and the Flex-Algorithms that use them, can be deployed in the network without affecting existing deployments 🌈
8. Security Considerations 💀
This document inherits security considerations from [RFC9350]. Take those seriously, bestie, because the whole Flex-Algorithm machinery depends on them 🔥
9. Operational Considerations 🧚
The operational considerations defined in [RFC9350] generally apply to the extensions in this document as well 💖 This document defines a metric-type range for user-defined metrics. When user-defined metrics are used in an inter-area or inter-level network, all the domains should assign the same meaning to the particular metric-type 👑 The YANG data models for Flex-Algorithm extensions are defined in the documents [OSPF-AUGMENTATION] and [ISIS-AUGMENTATION] ✨
Before a router goes into maintenance, the traffic needs to be diverted away from it. This is done by setting the overload bit, or by setting link metrics on the router to a high value. For Generic Metric, the link metrics can be set to a Maximum usable metric for OSPF and IS-IS. The traffic will then be diverted away from the router onto a shorter available path. If there are no alternate paths available, traffic will stay on the router, because the links are not removed from the Flex-Algorithm calculation when they are set to a maximum metric per [RFC9350] 🙈
10. IANA Considerations 🧚
10.1. IGP Metric-Type Registry 💖
okay so the "IGP Metric-Type" registry got a glow-up 💅✨ It now has an extra column that says whether each metric-type is allowed in the Generic Metric sub-TLV 🦋 The 128-255 range is also now user-defined, and it doesn't need a Standards Action [RFC8126]. no gatekeeping here 🫶
+=========+===========================+===========+================+
| Type | Description | Reference | Allowed in |
| | | | Generic-Metric |
+=========+===========================+===========+================+
| 0 | IGP Metric | Section | No |
| | | 5.1 of | |
| | | [RFC9350] | |
+---------+---------------------------+-----------+----------------+
| 1 | Min Unidirectional Link | Section | No |
| | Delay as defined in | 5.1 of | |
| | [RFC8570], Section 4.2 | [RFC9350] | |
| | and [RFC7471], | | |
| | Section 4.2 | | |
+---------+---------------------------+-----------+----------------+
| 2 | Traffic Engineering | Section | No |
| | Default Metric as defined | 5.1 of | |
| | in [RFC5305], Section 3.7 | [RFC9350] | |
| | and Traffic Engineering | | |
| | Metric as defined in | | |
| | [RFC3630], Section 2.5.5 | | |
+---------+---------------------------+-----------+----------------+
| 3 | Bandwidth Metric | RFC 9843 | Yes |
+---------+---------------------------+-----------+----------------+
| 128-255 | Reserved for User-Defined | RFC 9843 | Yes |
| | Metric | | |
+---------+---------------------------+-----------+----------------+Table 1: IGP Metric-Type Registry
10.2. IS-IS Sub-Sub-TLVs for Flexible Algorithm Definition Sub-TLV 🌸
the "IS-IS Sub-Sub-TLVs for Flexible Algorithm Definition Sub-TLV" registry lives in the "IS-IS TLV Codepoints" registry group 🧚 here's what's in it:
Type: 6
Description: IS-IS Exclude Minimum Bandwidth
Reference: RFC 9843, Section 3.1.1
Type: 7
Description: IS-IS Exclude Maximum Delay
Reference: RFC 9843, Section 3.1.2
Type: 8
Description: IS-IS Reference Bandwidth
Reference: RFC 9843, Section 4.1.3.1
Type: 9
Description: IS-IS Bandwidth Threshold
Reference: RFC 9843, Section 4.1.3.210.3. OSPF Sub-TLVs for Flexible Algorithm Definition Sub-TLV 🦋
the "OSPF Flexible Algorithm Definition TLV Sub-TLVs" registry is part of the "Open Shortest Path First (OSPF) Parameters" registry group ✨ same vibe, different protocol:
Type: 6
Description: OSPF Exclude Minimum Bandwidth
Reference: RFC 9843, Section 3.2.1
Type: 7
Description: OSPF Exclude Maximum Delay
Reference: RFC 9843, Section 3.2.2
Type: 8
Description: OSPF Reference Bandwidth
Reference: RFC 9843, Section 4.1.4.1
Type: 9
Description: OSPF Bandwidth Threshold
Reference: RFC 9843, Section 4.1.4.210.4. IS-IS Sub-TLVs for TLVs Advertising Neighbor Information 🌈
the "IS-IS Sub-TLVs for TLVs Advertising Neighbor Information" registry is part of the "IS-IS TLV Codepoints" registry group 💜 the Generic Metric entry is the star of the show:
Type: 17
Description: Generic Metric
TLVs set to "Y": 22, 23, 25, 141, 222, and 223
Reference: RFC 9843, Section 2.110.5. Sub-Sub-TLV Codepoints for Application-Specific Link Attributes 🎀
the "IS-IS Sub-Sub-TLV Codepoints for Application-Specific Link Attributes" registry is part of the "IS-IS TLV Codepoints" registry group, and Generic Metric shows up here too 🍓
Type: 17
Description: Generic Metric
Reference: RFC 9843, Section 2.110.6. OSPFv2 Extended Link TLV Sub-TLVs 🧚
the "OSPFv2 Extended Link TLV Sub-TLVs" registry is part of the "Open Shortest Path First v2 (OSPFv2) Parameters" registry group 🌸
Value: 25
Description: Generic Metric
L2BM: Y
Reference: RFC 9843, Section 2.210.7. Types for Sub-TLVs of TE Link TLV (Value 2) 💅
the "Types for sub-TLVs of TE Link TLV (Value 2)" registry is part of the "Open Shortest Path First (OSPF) Traffic Engineering TLVs" registry group ✨
Value: 36
Description: Generic Metric
Reference: RFC 9843, Section 2.210.8. OSPFv3 Extended-LSA Sub-TLVs 👑
the "OSPFv3 Extended-LSA Sub-TLVs" registry is part of the "Open Shortest Path First v3 (OSPFv3) Parameters" registry group 🫶
Value: 34
Description: Generic Metric
L2BM: Y
Reference: RFC 9843, Section 2.211. References 📚
11.1. Normative References 🔥
these are the normative refs, the ones you actually need to read, bestie 🙈
[IEEE754-2019] IEEE, "IEEE Standard for Floating-Point Arithmetic", IEEE Std 754-2019, DOI 10.1109/ieeestd.2019.8766229, 22 July 2019, <https://doi.org/10.1109/ieeestd.2019.8766229>.
[RFC1195] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and dual environments", RFC 1195, DOI 10.17487/RFC1195, December 1990, <https://www.rfc-editor.org/info/rfc1195>.
[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>.
[RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, DOI 10.17487/RFC2328, April 1998, <https://www.rfc-editor.org/info/rfc2328>.
[RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering (TE) Extensions to OSPF Version 2", RFC 3630, DOI 10.17487/RFC3630, September 2003, <https://www.rfc-editor.org/info/rfc3630>.
[RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic Engineering", RFC 5305, DOI 10.17487/RFC5305, October 2008, <https://www.rfc-editor.org/info/rfc5305>.
[RFC5329] Ishiguro, K., Manral, V., Davey, A., and A. Lindem, Ed., "Traffic Engineering Extensions to OSPF Version 3", RFC 5329, DOI 10.17487/RFC5329, September 2008, <https://www.rfc-editor.org/info/rfc5329>.
[RFC5392] Chen, M., Zhang, R., and X. Duan, "OSPF Extensions in Support of Inter-Autonomous System (AS) MPLS and GMPLS Traffic Engineering", RFC 5392, DOI 10.17487/RFC5392, January 2009, <https://www.rfc-editor.org/info/rfc5392>.
[RFC7684] Psenak, P., Gredler, H., Shakir, R., Henderickx, W., Tantsura, J., and A. Lindem, "OSPFv2 Prefix/Link Attribute Advertisement", RFC 7684, DOI 10.17487/RFC7684, November 2015, <https://www.rfc-editor.org/info/rfc7684>.
[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>.
[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>.
[RFC8362] Lindem, A., Roy, A., Goethals, D., Reddy Vallem, V., and F. Baker, "OSPFv3 Link State Advertisement (LSA) Extensibility", RFC 8362, DOI 10.17487/RFC8362, April 2018, <https://www.rfc-editor.org/info/rfc8362>.
[RFC8668] Ginsberg, L., Ed., Bashandy, A., Filsfils, C., Nanduri, M., and E. Aries, "Advertising Layer 2 Bundle Member Link Attributes in IS-IS", RFC 8668, DOI 10.17487/RFC8668, December 2019, <https://www.rfc-editor.org/info/rfc8668>.
[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>.
[RFC9356] Talaulikar, K., Ed. and P. Psenak, "Advertising Layer 2 Bundle Member Link Attributes in OSPF", RFC 9356, DOI 10.17487/RFC9356, January 2023, <https://www.rfc-editor.org/info/rfc9356>.
[RFC9479] Ginsberg, L., Psenak, P., Previdi, S., Henderickx, W., and J. Drake, "IS-IS Application-Specific Link Attributes", RFC 9479, DOI 10.17487/RFC9479, October 2023, <https://www.rfc-editor.org/info/rfc9479>.
[RFC9492] Psenak, P., Ed., Ginsberg, L., Henderickx, W., Tantsura, J., and J. Drake, "OSPF Application-Specific Link Attributes", RFC 9492, DOI 10.17487/RFC9492, October 2023, <https://www.rfc-editor.org/info/rfc9492>.
11.2. Informative References ✨
[ISIS-AUGMENTATION] Lindem, A., Qu, Y., and S. Litkowski, "IS-IS YANG Model Augmentations for Additional Features - Release 1", Work in Progress, Internet-Draft, draft-ietf-lsr-isis-yang-augmentation-v1-10, 6 July 2025, <https://datatracker.ietf.org/doc/html/draft-ietf-lsr-isis-yang-augmentation-v1-10>.
[OSPF-AUGMENTATION] Lindem, A. and Y. Qu, "OSPF YANG Model Augmentations for Additional Features - Release 1", Work in Progress, Internet-Draft, draft-ietf-lsr-ospf-yang-augmentation-v1-17, 6 July 2025, <https://datatracker.ietf.org/doc/html/draft-ietf-lsr-ospf-yang-augmentation-v1-17>.
[RFC4655] Farrel, A., Vasseur, J.-P., and J. Ash, "A Path Computation Element (PCE)-Based Architecture", RFC 4655, DOI 10.17487/RFC4655, August 2006, <https://www.rfc-editor.org/info/rfc4655>.
[RFC5120] Przygienda, T., Shen, N., and N. Sheth, "M-ISIS: Multi Topology (MT) Routing in Intermediate System to Intermediate Systems (IS-ISs)", RFC 5120, DOI 10.17487/RFC5120, February 2008, <https://www.rfc-editor.org/info/rfc5120>.
[RFC5311] McPherson, D., Ed., Ginsberg, L., Previdi, S., and M. Shand, "Simplified Extension of Link State PDU (LSP) Space for IS-IS", RFC 5311, DOI 10.17487/RFC5311, February 2009, <https://www.rfc-editor.org/info/rfc5311>.
[RFC5715] Shand, M. and S. Bryant, "A Framework for Loop-Free Convergence", RFC 5715, DOI 10.17487/RFC5715, January 2010, <https://www.rfc-editor.org/info/rfc5715>.
[RFC7471] Giacalone, S., Ward, D., Drake, J., Atlas, A., and S. Previdi, "OSPF Traffic Engineering (TE) Metric Extensions", RFC 7471, DOI 10.17487/RFC7471, March 2015, <https://www.rfc-editor.org/info/rfc7471>.
[RFC8570] Ginsberg, L., Ed., Previdi, S., Ed., Giacalone, S., Ward, D., Drake, J., and Q. Wu, "IS-IS Traffic Engineering (TE) Metric Extensions", RFC 8570, DOI 10.17487/RFC8570, March 2019, <https://www.rfc-editor.org/info/rfc8570>.
[RFC9346] Chen, M., Ginsberg, L., Previdi, S., and D. Xiaodong, "IS-IS Extensions in Support of Inter-Autonomous System (AS) MPLS and GMPLS Traffic Engineering", RFC 9346, DOI 10.17487/RFC9346, February 2023, <https://www.rfc-editor.org/info/rfc9346>.
[SR-LOOP-AVOID] Bashandy, A., Filsfils, C., Litkowski, S., Decraene, B., Francois, P., and P. Psenak, "Loop avoidance using Segment Routing", Work in Progress, Internet-Draft, draft-bashandy-rtgwg-segment-routing-uloop-17, 29 June 2024, <https://datatracker.ietf.org/doc/html/draft-bashandy-rtgwg-segment-routing-uloop-17>.
Appendix A. Updated List of Rules for Pruning Links in Flex-Algorithm Topology 💅
Okay bestie, this appendix is the whole cheat sheet of rules for pruning links from the Flex-Algorithm topology during the Flexible Algorithm calculation 🧚. It includes the original rules from Section 13 of [RFC9350] plus the brand new rules 6 and 7 from this document 🌸.
For all links in the topology:
- Look at the Flex-Algorithm Definition and check for any exclude Administrative Group rule. If there's one, check whether any color in that exclude rule is also set on the link. If such a color is set, the link MUST be pruned from the computation 🚫.
- Check for any exclude SRLG rule in the Flex-Algorithm Definition. If there is one, check whether the link is part of any SRLG that also appears in that SRLG exclude rule. If it is, the link MUST be pruned from the computation 🙈.
- Check for any include-any Administrative Group rule in the Flex-Algorithm Definition. If there is one, check whether any color in that include-any rule is also set on the link. If no such color is set, the link MUST be pruned from the computation 💀.
- Check for any include-all Administrative Group rule in the Flex-Algorithm Definition. If there is one, check whether all of the colors in that include-all rule are set on the link. If the link doesn't have all of those colors set, the link MUST be pruned from the computation ✨.
- If the Flex-Algorithm Definition uses something other than the IGP metric (Section 5 of [RFC9350]), and that metric isn't advertised for the link in the topology the computation is being done for, the link MUST be pruned from the computation. A metric of value 0 MUST NOT be assumed in that case 🍓.
- Check for any exclude FAEMB rule in the Flex-Algorithm Definition. If there is one and the link has Maximum Link Bandwidth advertised, check whether 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 🎀.
- Check for any exclude FAEMD rule in the Flex-Algorithm Definition. If there is one and the link has Min Unidirectional Link Delay advertised, check whether 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 👑.
Acknowledgements 🫶
Many thanks to Chris Bowers, Krzysztof Szarcowitz, Julian Lucek, Ram Santhanakrishnan, Ketan Talaulikar, and Acee Lindem for the discussions and input 💜.
Contributors 🦋
Salih K.A. Juniper Networks Email: salih@juniper.net
Authors' Addresses 🌈
Shraddha Hegde Juniper Networks Inc. Exora Business Park Bangalore 560103 Karnataka India Email: shraddha@juniper.net
William Britto Juniper Networks Inc. Email: bwilliam@juniper.net
Rajesh Shetty Juniper Networks Inc. Email: mrajesh@juniper.net
Bruno Decraene Orange Email: bruno.decraene@orange.com
Peter Psenak Cisco Systems Email: ppsenak@cisco.com
Tony Li Juniper Networks Inc. Email: tony.li@tony.li
📦 where this page comes from
- ietf: rfc9843 2025-09
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms