IGP Flexible Algorithms: Bandwidth, Delay, Metrics, and Constraints

IGP Flexible Algorithms: Bandwidth, Delay, Metrics, and Constraints Juniper Networks Inc.

Exora Business Park Bangalore Karnataka 560103 India shraddha@juniper.net

Juniper Networks Inc.

bwilliam@juniper.net

Juniper Networks Inc.

mrajesh@juniper.net

Orange

bruno.decraene@orange.com

Cisco Systems

ppsenak@cisco.com

Juniper Networks Inc.

tony.li@tony.li

RTG lsr AS IGP Many networks configure the IGP link metric relative to the link capacity, and high bandwidth traffic gets routed per the link capacity. Flexible Algorithms provide mechanisms to create constraint-based paths in an IGP. This specification documents a generic metric-type and a set of bandwidth-related constraints to be used in Flexible Algorithms. This document updates RFC 9350.

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 .

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 () 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

. Introduction
- . Requirements Language
. Generic Metric Advertisement
- . IS-IS Generic Metric Sub-TLV
- . OSPF Generic Metric Sub-TLV
- . Generic Metric Applicability to Flexible Algorithm Multi-Domain/Multi-Area Networks
. FAD Constraint Sub-TLVs
- . IS-IS FAD Constraint Sub-TLVs
  - . IS-IS Exclude Minimum Bandwidth Sub-TLV
  - . IS-IS Exclude Maximum Delay Sub-TLV
- . OSPF FAD Constraint Sub-TLVs
  - . OSPF Exclude Minimum Bandwidth Sub-TLV
  - . OSPF Exclude Maximum Delay Sub-TLV
. Bandwidth Metric Advertisement
- . Automatic Metric Calculation
  - . Automatic Metric Calculation Modes
  - . Automatic Metric Calculation Methods
  - . IS-IS FAD Constraint Sub-TLVs for Automatic Metric Calculation
  - . OSPF FAD Constraint Sub-TLVs for Automatic Metric Calculation
. Bandwidth Metric Considerations
. Calculation of Flex-Algorithm Paths
. Backward Compatibility
. Security Considerations
. Operational Considerations
. IANA Considerations
- . IGP Metric-Type Registry
- . IS-IS Sub-Sub-TLVs for Flexible Algorithm Definition Sub-TLV
- . OSPF Sub-TLVs for Flexible Algorithm Definition Sub-TLV
- . IS-IS Sub-TLVs for TLVs Advertising Neighbor Information
- . Sub-Sub-TLV Codepoints for Application-Specific Link Attributes
- . OSPFv2 Extended Link TLV Sub-TLVs
- . Types for Sub-TLVs of TE Link TLV (Value 2)
- . OSPFv3 Extended-LSA Sub-TLVs
. References
- . Normative References
- . Informative References
. Updated List of Rules for Pruning Links in Flex-Algorithm Topology
Acknowledgements
Contributors
Authors' Addresses

Introduction High bandwidth traffic such as residential Internet traffic and machine-to-machine elephant flows benefit from using high capacity links. Accordingly, many network operators define a link's metric relative to its capacity to help direct traffic to higher bandwidth links, but this is no guarantee that lower bandwidth links will be avoided, especially in failure scenarios. To ensure that elephant flows are only placed on high capacity links, it would be useful to explicitly exclude the high throughput traffic from utilizing links below a certain capacity. Flex-Algorithm provides a mechanism to create constrained paths by defining a set of parameters consisting of calculation-type, metric-type, and a set of constraints. In this document, we define further extensions to the Flexible Algorithm Definition (FAD) that will allow operators additional control over their traffic flows, especially with respect to bandwidth constraints. Historically, IGPs have done path computation by minimizing the sum of the link metrics along the path from source to destination. While the metric has been administratively defined, implementations have defaulted to a metric that is inversely proportional to link bandwidth. This has driven traffic to higher bandwidth links and has required manual metric manipulation to achieve the desired loading of the network. Over time, with the addition of different traffic types, the need for alternate types of metrics has evolved. Flex-Algorithm already supports using the minimum link delay and the administratively assigned traffic-engineering metrics in path computation. However, it is clear that additional metrics may be of interest in different situations. A network operator may seek to minimize their operational costs and thus may want a metric that reflects the actual fiscal costs of using a link. Other traffic may require low jitter, leading to an entirely different set of metrics. With Flex-Algorithm, all of these different metrics, and more, could be used concurrently on the same network. In some circumstances, path computation constraints, such as administrative groups, can be used to ensure that traffic avoids particular portions of the network. These strict constraints are appropriate when there is an absolute requirement to avoid parts of the topology, even in failure conditions. However, if the requirement is less strict, then using a high metric in a portion of the topology may be more appropriate. This document defines a family of generic metrics that can advertise various types of administratively assigned metrics. This document introduces standard metric-types that have specific semantics and require standardization. This document also specifies user-defined metric-types where specifics are not defined so that administrators are free to assign semantics as they see fit. defines additional FAD constraints that allow the network administrator to preclude the use of low bandwidth links or high delay links. specifies a new bandwidth-based metric-type to be used with Flex-Algorithm and other applications. defines mechanisms to automatically calculate link metrics based on the parameters defined in the FAD and the advertised Maximum Link Bandwidth of each link. This is advantageous because administrators can change their criteria for metric assignment centrally, without individual modification of each link metric throughout the network. The procedures described in this document are intended to assign a metric to a link based on the total link capacity, and they are not intended to update the metric based on actual traffic flow. Thus, the procedures described in this document are not a replacement to the capability of a PCE , which has a dynamic view of the network and provides real-time bandwidth management or a distributed bandwidth management protocol.

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 when, and only when, they appear in all capitals, as shown here.

Generic Metric Advertisement IS-IS and OSPF 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 and , and the Unidirectional Link Delay is defined in and . Other metrics, such as jitter, reliability, and fiscal cost may be helpful, depending on the traffic class. Rather than attempt to enumerate all possible metrics of interest, 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 consists of a metric-type field and a value for the metric. The metric-type field has been 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 of metric-types 128-255. They can be assigned by an operator 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) 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 , , , , and .

IS-IS Generic Metric Sub-TLV The IS-IS Generic Metric sub-TLV specifies the link metric for a given metric-type. Typically, this metric is assigned by a network administrator. The Generic Metric sub-TLV is advertised in the TLVs/sub-TLVs below:

TLV 22 (Extended IS reachability)
TLV 222 (MT-ISN)
TLV 23 (IS Neighbor Attribute)
TLV 223 (MT IS Neighbor Attribute)
TLV 141 (Inter-AS Reachability Information)
sub-TLV 16 (Application-Specific Link Attributes (ASLA)) of TLVs 22/222/23/223/141
TLV 25 (L2 Bundle Member Attributes) . Marked as "y(s)" (shareable among bundle members).

Type (1 octet):: An 8-bit field assigned by IANA (17). This value uniquely identifies the Generic Metric TLV.
Length (1 octet):: An 8-bit field indicating the total length, in octets, of the subsequent fields. For this TLV, the Length is set to 4.
Metric-Type (1 octet):: An 8-bit field specifying the type of metric. The value is taken from the "IGP Metric-Type" registry maintained by IANA. The metric-type may be any value that is indicated as allowed in the Generic Metric sub-TLV by the "IGP Metric-Type" registry.
Value (3 octets):: A 24-bit unsigned integer representing the metric value. The valid range is from 0 to 16,777,215 (0xFFFFFF).

The Generic Metric sub-TLV MAY be advertised multiple times. For a particular metric-type, the Generic Metric sub-TLV MUST be advertised only once for a link when advertised in TLVs 22, 222, 23, 223, and 141. When the Generic Metric sub-TLV is advertised in ASLA, each metric-type MUST be advertised only once per-application for a link. If there are multiple Generic Metric sub-TLVs advertised for a link for the same metric-type (and the same application in case of ASLA) in one or more received Link State Protocol Data Units (LSPDUs), advertisement in the lowest-numbered fragment MUST be used, and the subsequent instances MUST be ignored. For a link, if the metric-type corresponds to a metric-type for which legacy advertisement mechanisms exist (e.g., 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. A metric value of 0xFFFFFF is considered a maximum link metric, and a link having this metric value MUST be used during Flex-Algorithm calculations as a last resort link as described in . A link can be made unusable by Flex-Algorithm by leaving out Generic Metric advertisement of the particular metric-type that the Flex-Algorithm uses, as described in . During the router maintenance activity, the Generic Metric for all the links on the node MAY be set to a maximum value of 16,777,215 (0xFFFFFF), as it is the maximum usable link metric for the Flex-Algorithm calculations.

OSPF Generic Metric Sub-TLV The OSPF Generic Metric sub-TLV specifies the link metric for a given metric-type. Typically, this metric is assigned by a network administrator. The Generic Metric sub-TLV is advertised in the TLVs below:

sub-TLV of TE Link TLV (type 2) of OSPF TE LSA .
sub-TLV of TE Link TLV (type 2) of OSPFv2 Inter-AS-TE-v2 LSA .
sub-TLV of TE Link TLV (type 2) of OSPFv3 Intra-Area-TE-LSA .
sub-TLV of TE Link TLV (type 2) of OSPFv3 Inter-AS-TE-v3 LSA .
sub-TLV of Application-Specific Link Attributes (ASLA) sub-TLV of the OSPFv2 Extended Link TLV .
sub-TLV of Application-Specific Link Attributes (ASLA) sub-TLV of the OSPFv3 Router-Link TLV .
sub-TLV of the OSPFv2 L2 Bundle Member Attributes sub-TLV .
sub-TLV of the OSPFv3 L2 Bundle Member Attributes sub-TLV .

The Generic Metric sub-TLV, types 25/36/34, is 8 octets in length.

OSPF Generic Metric Sub-TLV 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ where:

Type (2 octets):: A 16-bit field assigned by IANA (25/36/34). This value uniquely identifies the Generic Metric TLV.
Length (2 octets):: A 16-bit field indicating the total length, in octets, of the subsequent fields. For this TLV, the Length is set to 8.
Metric-Type (1 octet):: An 8-bit field specifying the type of metric. The value is taken from the "IGP Metric-Type" registry maintained by IANA. The metric-type may be any value that is indicated as allowed in the Generic Metric sub-TLV by the "IGP Metric-Type" registry.
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 representing the metric value. The valid range is from 0 to 4,294,967,295 (0xFFFFFFFF).

The Generic Metric sub-TLV MAY be advertised multiple times. For a particular metric-type, the Generic Metric sub-TLV MUST be advertised only once for a link when advertised as (a) through (d) above. When the Generic Metric sub-TLV is advertised as a sub-TLV of ASLA, it MUST be advertised only once per application for a link. If there are multiple Generic Metric sub-TLVs advertised for a link for the same metric-type (and the same application in case of ASLA) in one or more received LSAs, advertisement in the lowest-numbered LSA MUST be used, and the subsequent instances MUST be ignored. For a link, if the metric-type corresponds to a metric-type for which legacy advertisement mechanisms exist (e.g., 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. A metric value of 0xFFFFFFFF is considered a maximum link metric, and a link having this metric value MUST be used during Flex-Algorithm calculations as a last resort link, as described in . A link can be made unusable by Flex-Algorithm by leaving out Generic Metric advertisement of the particular metric-type that the Flex-Algorithm uses, as described in . During the router maintenance activity, the Generic Metric for all the links on the node MAY be set to a maximum value of 4,294,967,295 (0xFFFFFFFF), as it is the maximum usable link metric for the Flex-Algorithm calculations.

Generic Metric Applicability to Flexible Algorithm Multi-Domain/Multi-Area Networks Generic Metric can be used by Flex-Algorithm by specifying the metric-type in the Flexible Algorithm Definitions. When Flex-Algorithm is used in a multi-area network, defines the Flexible Algorithm Prefix Metric (FAPM) sub-TLV that carries the Flexible-Algorithm-specific metric. Metrics carried in FAPM will be equal to the metric to reach the prefix for that Flex-Algorithm in its source area or domain (source area from the Area Border Router (ABR) perspective). When Flex-Algorithm uses Generic Metric, the same procedures as described in are used to send and process the FAPM sub-TLV.

FAD Constraint Sub-TLVs Large high throughput flows are referred to as "elephant flows". Directing an elephant flow down a low-bandwidth link might congest the link and cause other critical application traffic flowing on the link to drop. Thus, in the context of Flex-Algorithm, it would be useful to be able to constrain the topology to only those links capable of supporting a minimum amount of bandwidth. If the capacity of a low bandwidth link is constant, constraining the topology to avoid those links can already be achieved through the use of administrative groups. However, when a Layer 3 link is actually a collection of Layer 2 links (Link Aggregation Group (LAG) / Layer 2 Bundle), the link bandwidth will vary based on the set of active constituent links. This could be automated by having an implementation vary the advertised administrative groups based on bandwidth, but this seems unnecessarily complex and expressing this requirement as a direct constraint on the topology seems simpler. This is also advantageous if the minimum required bandwidth changes, as this constraint would provide a single centralized, coordinated point of control. To satisfy this requirement, this document defines an Exclude Minimum Bandwidth constraint. When this constraint is advertised in a FAD, a link will be pruned from the Flex-Algorithm topology if the link's advertised maximum link bandwidth value is below the FAD advertised minimum bandwidth value. Similarly, this document defines an Exclude Maximum Link Delay constraint. Applications, such as High-Frequency Trading are sensitive to link delays and may perform poorly in networks prone to delay variability, such as those with transparent Layer 2 link recovery mechanisms or satellite links. Mechanisms already exist to measure the link delay dynamically and advertise it in the IGP. Networks that employ dynamic link-delay measurement, may want to exclude links that have a delay over a given threshold.

IS-IS FAD Constraint Sub-TLVs

IS-IS Exclude Minimum Bandwidth Sub-TLV IS-IS Flex-Algorithm Exclude Minimum Bandwidth (FAEMB) sub-TLV is a sub-TLV of the IS-IS FAD sub-TLV. It has the following format:

IS-IS FAEMB Sub-TLV 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ where:

Type (1 octet):: An 8-bit field assigned by IANA (6). This value uniquely identifies the FAEMB 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 4.
Min Bandwidth (4 octets):: A 32-bit field specifying the link bandwidth encoded in IEEE floating point format (32 bits) . The units are bytes per second.

The FAEMB sub-TLV MUST appear once at most in the FAD sub-TLV. If it appears more than once, the IS-IS FAD sub-TLV MUST be ignored by the receiver. The minimum bandwidth value advertised in the FAEMB sub-TLV MUST be compared with maximum link bandwidth value advertised in sub-sub-TLV 9 of the ASLA sub-TLV . If the L-flag is set in the ASLA sub-TLV, the minimum bandwidth value advertised 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 , as defined in . 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. If a link does not 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.

IS-IS Exclude Maximum Delay Sub-TLV IS-IS Flex-Algorithm Exclude Maximum Delay (FAEMD) sub-TLV is a sub-TLV of the IS-IS FAD sub-TLV. It has the following format:

IS-IS FAEMD Sub-TLV 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ where:

Type (1 octet):: An 8-bit field assigned by IANA (7). This value uniquely identifies the FAEMD 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 3.
Max Link Delay (3 octets):: A 24-bit field specifying 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. The maximum link delay value advertised in the FAEMD sub-TLV MUST be compared with Min Unidirectional Link Delay advertised in sub-sub-TLV 34 of the ASLA sub-TLV . 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 Min Unidirectional Link Delay as advertised by the sub-TLV 34 of the TLVs 22/222/23/223/141 , as defined in . 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. If a link does not have the Min Unidirectional Link Delay 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.

OSPF FAD Constraint Sub-TLVs

OSPF Exclude Minimum Bandwidth Sub-TLV OSPF Flex-Algorithm Exclude Minimum Bandwidth (FAEMB) sub-TLV is a sub-TLV of the OSPF FAD TLV. It has the following format:

OSPF FAEMB Sub-TLV 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ where:

Type (2 octets):: A 16-bit field assigned by IANA (6). This value uniquely identifies the OSPF FAEMB sub-TLV.
Length (2 octets):: A 16-bit field indicating the total length, in octets, of the subsequent fields. For this sub-TLV, the Length is set to 4.
Min Bandwidth (4 octets):: A 32-bit field specifying the link bandwidth encoded in IEEE floating point format (32 bits). 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 or as a sub-TLV of the Router-Link TLV of the E-Router-LSA Router-Link TLV in OSPFv3 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 does not 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.

OSPF Exclude Maximum Delay Sub-TLV The OSPF Flex-Algorithm Exclude Maximum Delay (FAEMD) sub-TLV is a sub-TLV of the OSPF FAD TLV. It has the following format.

OSPF FAEMD Sub-TLV 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ where:

Type (2 octets):: A 16-bit field assigned by IANA (7). This value uniquely identifies the OSPF FAEMD sub-TLV.
Length (2 octets):: A 16-bit field indicating the total length, in octets, of the subsequent fields. 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 specifying 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 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. If the Min/Max Unidirectional Link Delay is not 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.

Bandwidth Metric Advertisement Historically, IGP implementations have made default metric assignments based on link bandwidth. This has proven to be useful but has suffered from having different defaults across implementations and from the rapid growth of link bandwidths. With Flex-Algorithm, the network administrator can define a function that will produce a metric for each link and have each node automatically compute each link's metric based on its bandwidth. This document defines a standard metric-type for this purpose 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 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. The automatic Bandwidth metric calculation sub-TLVs are advertised in the FAD TLV, and these parameters are applicable to applications such as Flex-Algorithm that make use of the FAD TLV.

Automatic Metric Calculation Networks that are designed to be highly regular and that follow uniform metric assignment may want to simplify their operations by automatically calculating the bandwidth metric. When a FAD advertises the metric-type as Bandwidth Metric and the link does not have the Bandwidth Metric advertised, automatic metric derivation can be used with additional FAD constraint advertisement as described in this section. If a link's bandwidth changes, then 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 or any other mechanism as described in the framework can be used to avoid micro-loops when the automatic metric calculation is deployed. Computing the metric between adjacent systems based on bandwidth becomes more complex in the case of 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 somewhat more complex to deal with, so there is an optional mode for computing the aggregate bandwidth.

Automatic Metric Calculation Modes

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 do not 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 may vary with Layer 2 link failures.

Interface Group Mode The Simple Mode of metric calculation may not work well when there are multiple parallel Layer 3 interfaces between two nodes. Ideally, the metric between two systems should be the same given the same bandwidth, whether the bandwidth is provided by parallel Layer 2 links or parallel Layer 3 links. To address this, in Interface Group Mode, nodes MUST compute the aggregate bandwidth of all parallel adjacencies, MUST derive the metric based on the aggregate bandwidth, and MUST apply the resulting metric to each of the parallel adjacencies. Note that a single elephant flow is normally pinned to a single Layer 3 interface. If the single Layer 3 link bandwidth is not sufficient for any single elephant flow, the mechanisms to solve this issue are outside the scope of this document.

Parallel Interfaces A------B====C====F====D | | ------E------- For example, in the above diagram, there are two parallel links between B->C, C->F, F->D. Let us assume the link bandwidth is 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 be forwarded as B->E->D because the metric will be lower. Since the bandwidth is higher on the B‑>C->F->D path, the metric for that path should be lower than the B->E->D path to attract the traffic on the B->C->F->D path. Interface Group Mode should be preferred in cases where there are parallel Layer 3 links. In the 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 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 such cases, the method described in Interface Group Mode will result in the same metric being used for all the parallel links, which may cause undesired load balancing on the links. In such cases, 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.

Automatic Metric Calculation Methods In automatic metric calculation for simple and Interface Group Mode, 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

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 allows the metric computation to be done on every node for each link. The metric is computed using reference bandwidth and the advertised link bandwidth. Centralized control of this reference bandwidth simplifies management in the case where the reference bandwidth changes. In order to ensure that small bandwidth changes do not change the link metric, it is useful to define the granularity of the bandwidth that is of interest. The link bandwidth will be truncated to this granularity before deriving the metric. For example, reference bandwidth = 1000G Granularity = 20G The derived metric is 10 for link bandwidth in the range 100G to 119G

Bandwidth Thresholds Method The reference bandwidth approach described above provides a uniform metric value for a range of link bandwidths. In certain cases, there may be a need to define non-proportional metric values for the varying ranges of link bandwidth. For example, bandwidths from 10G to 30G are assigned metric value 100, bandwidth from 30G to 70G are assigned a metric value of 50, and bandwidths greater than 70G have a metric of 10. In order to support this, a staircase mapping based on bandwidth thresholds is supported in the FAD. This advertisement contains a set of threshold values and associated metrics.

IS-IS FAD Constraint Sub-TLVs for Automatic Metric Calculation

Reference Bandwidth Sub-TLV This section provides FAD constraint advertisement details for the reference bandwidth method of metric calculation, as described in . 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:

IS-IS FADRB Sub-TLV 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ where:

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 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 . The units are bytes per second.
Granularity Bandwidth (4 octets):: A 32-bit field with Bandwidth encoded in IEEE floating point format . The units are bytes per second.

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_bandwidth

The division used here is integer division. Modulus of operation is defined as a remainder value when two numbers are divided. The Granularity Bandwidth value ensures that the metric does not change when there is a small change in the link bandwidth. The IS-IS FADRB sub-TLV MUST NOT appear more than once in an IS-IS FAD sub-TLV. If it appears 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. In case of Interface Group Mode, the following 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 links among the parallel links have advertised the Bandwidth Metric:
- The Bandwidth Metric for such 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. If the calculated metric evaluates to a number greater than 0xFFFFFF, it is set to 0xFFFFFF.

Bandwidth Threshold Sub-TLV This section provides FAD constraint advertisement details for the Bandwidth Thresholds method of metric calculation as described in . The Flexible Algorithm Definition Bandwidth Threshold (FADBT) sub-TLV is a sub-TLV of the IS-IS FAD sub-TLV. It has the following format:

IS-IS FADBT Sub-TLV 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ where:

Type (1 octet):

An 8-bit field assigned by IANA (9). This value uniquely identifies the IS-IS FADBT 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 calculated as (1+N*7). Here, N is equal to the number of Threshold Metrics specified. N MUST be greater than or equal to 1.

Flags (1 octet):

0 1 2 3 4 5 6 7 +-+-+-+-+-+-+-+-+ |G| | | | +-+-+-+-+-+-+-+-+

G-flag:: When set, Interface Group Mode MUST be used to derive total link bandwidth. Unassigned bits MUST be set to zero and MUST be ignored by the receiver.

Following is the staircase bandwidth threshold and associated metric values.

Bandwidth Threshold 1 (4 octets):: Minimum Link Bandwidth is encoded in IEEE floating point format (32 bits). The units are bytes per second.
Threshold Metric 1 (3 octets):: Metric value range (1 - 16,777,215 (0xFFFFFF))
Bandwidth Threshold N (4 octets):: Maximum Link Bandwidth is encoded in IEEE floating point format (32 bits). The units are bytes per second.
Threshold Metric N (3 octets):: Metric value range (1 - 16,777,215 (0xFFFFFF))

When the G-flag is set, the cumulative bandwidth of the parallel links is computed as described in . If the G-flag is not set, the advertised Maximum Link Bandwidth is used. The assignment of the Bandwidth Metric based on computed link bandwidth is described below. 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.

Notes:

The term "Bandwidth Threshold X" refers to a predefined threshold value corresponding to the index X.
The term "Threshold Metric X" refers to the metric value associated with Bandwidth Threshold X.
N represents the total number of bandwidth thresholds defined in the system.

Implementations MUST ensure that these rules are consistently applied to maintain interoperability and optimal path computation within the network. The IS-IS FADBT sub-TLV MUST NOT appear more than once in an IS-IS FAD sub-TLV. If it appears 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 of these sub-TLVs are advertised in the same FAD for a Flexible Algorithm, the FAD MUST be ignored by the receiver. 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. In case of Interface Group Mode, the following 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 links among the parallel links have advertised the Bandwidth Metric:
- The Bandwidth Metric for such links MUST be ignored.
- Automatic metric calculation MUST be used to derive the link metric.

OSPF FAD Constraint Sub-TLVs for Automatic Metric Calculation

Reference Bandwidth Sub-TLV The Flexible Algorithm Definition Reference Bandwidth (FADRB) sub-TLV is a sub-TLV of the OSPF FAD TLV. It has the following format:

OSPF FADRB Sub-TLV 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ where:

Type (2 octets):

A 16-bit field assigned by IANA (8). This value uniquely identifies the OSPF FADRB sub-TLV.

Length (2 octets):

A 16-bit field indicating the total length, in octets, of the subsequent fields. 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 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 . The units are in bytes per second.

Granularity Bandwidth (4 octets):

Bandwidth encoded in 32 bits in IEEE floating point format . The units are in bytes per second.

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_bandwidth

The division used here is integer division. Modulus of operation is defined as a remainder value when two numbers are divided. The Granularity Bandwidth value is used to ensure that the metric does not change when there is a small change in the link bandwidth. 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. In the case of Interface Group Mode, the following procedures apply:

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. In this scenario, automatic metric calculation MUST be used to derive the link metrics for all parallel links.

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.

Bandwidth Threshold Sub-TLV The Flexible Algorithm Definition Bandwidth Threshold (FADBT) sub-TLV is a sub-TLV of the OSPF FAD TLV. It has the following format:

OSPF FADBT Sub-TLV 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ where:

Type (2 octets):

A 16-bit field assigned by IANA (9). This value uniquely identifies the OSPF FADBT sub-TLV.

Length (2 octets):

A 16-bit field indicating the total length, in octets, of the subsequent fields. For this sub-TLV, Length is set to 2 + N*8 octets. Here, N is equal to the number of Threshold Metrics specified. N MUST be greater than or equal to 1.

Flags (1 octet):

0 1 2 3 4 5 6 7 +-+-+-+-+-+-+-+-+ |G| | +-+-+-+-+-+-+-+-+

G-flag:: When set, Interface Group Mode MUST be used to derive total link bandwidth. Unassigned bits MUST be set to zero and MUST be ignored by the receiver.

Following is the staircase bandwidth threshold and associated metric values.

Bandwidth Threshold 1 (4 octets):: Minimum Link Bandwidth is encoded in IEEE floating point format (32 bits). The units are bytes per second.
Threshold Metric 1 (4 octets):: Metric value range (1 - 4,294,967,296 (0xFFFFFFFF))
Bandwidth Threshold N (4 octets):: Maximum Link Bandwidth is encoded in IEEE floating point format (32 bits). The units are bytes per second.
Threshold Metric N (4 octets):: Metric value 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 . If the G-flag is not set, the advertised Maximum Link Bandwidth is used. The assignment of the Bandwidth Metric based on computed link bandwidth is described below. 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.
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.

Notes:

Bandwidth Threshold X refers to the predefined bandwidth threshold corresponding to index X.
Threshold Metric X is the metric value associated with Bandwidth Threshold X.
N represents 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. The OSPF FADBT sub-TLV MUST NOT appear more than once in an OSPF FAD sub-TLV. If it appears more than once, the OSPF 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 these sub-TLVs are advertised in the same FAD for a Flexible Algorithm, the FAD MUST be ignored by the receiver. 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. 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. In case of Interface Group Mode, the following 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.
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.

This approach ensures consistent metric calculation and avoids discrepancies caused by partial Bandwidth Metric advertisements among parallel links.

Bandwidth Metric Considerations This section specifies the rules of 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 , it MUST be used during the Flex-Algorithm calculation.
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 ), the link is treated as if the Bandwidth Metric is not available for the link.
If the Generic Metric sub-TLV with Bandwidth metric-type is not advertised for the link and the winning FAD () for the Flex-Algorithm specifies the automatic Bandwidth metric calculation (as defined in ), the Bandwidth Metric MUST be automatically calculated per the procedures defined in . If the Link Bandwidth is not advertised for a link, the link MUST be pruned for the Flex-Algorithm calculations.
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 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.

Calculation of Flex-Algorithm Paths The following two new additional rules are added to the existing rules in the Flex-Algorithm calculations specified in :

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.

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.

Backward Compatibility This extension brings no new backward-compatibility issues. This document defines new FAD constraints in Sections , , and . As described in , 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 the new extensions without affecting the nodes that are not upgraded. This document also defines a new metric advertisement as described in . As per , 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 Flex-Algorithms using the new metric-types can be deployed in the network without affecting existing deployment.

Security Considerations This document inherits security considerations from .

Operational Considerations Operational considerations defined in generally apply to the extensions defined 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 same meaning to the particular metric-type. The YANG data models for Flex-Algorithm extensions are defined in documents and . Before the router goes into maintenance activity, the traffic needs to be diverted away from the router. This is achieved by setting the overload bit or setting link metrics on the router to a high value. In case of Generic Metric, the link metrics can be set to a Maximum usable metric for OSPF and IS-IS. The traffic will be diverted away from the router to a shorter available path. If there are no alternate paths available, traffic will stay on the router as the links are not removed from the Flex-Algorithm calculation when they are set to a maximum metric per .

IANA Considerations

IGP Metric-Type Registry The "IGP Metric-Type" registry has been updated to include another column specifying whether the particular metric-type is allowed in the Generic Metric sub-TLV. The range 128-255 is redefined by this document as a user-defined range, and this range does not require Standards Action . IGP Metric-Type Registry

Type	Description	Reference	Allowed in Generic-Metric
0	IGP Metric		No
1	Min Unidirectional Link Delay as defined in and		No
2	Traffic Engineering Default Metric as defined in and Traffic Engineering Metric as defined in		No
3	Bandwidth Metric	RFC 9843	Yes
128-255	Reserved for User-Defined Metric	RFC 9843	Yes

IS-IS Sub-Sub-TLVs for Flexible Algorithm Definition Sub-TLV The "IS-IS Sub-Sub-TLVs for Flexible Algorithm Definition Sub-TLV" registry is part of the "IS-IS TLV Codepoints" registry group.

Type:: 6
Description:: IS-IS Exclude Minimum Bandwidth
Reference:: RFC 9843,

Type:: 7
Description:: IS-IS Exclude Maximum Delay
Reference:: RFC 9843,

Type:: 8
Description:: IS-IS Reference Bandwidth
Reference:: RFC 9843,

Type:: 9
Description:: IS-IS Bandwidth Threshold
Reference:: RFC 9843,

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.

Type:: 6
Description:: OSPF Exclude Minimum Bandwidth
Reference:: RFC 9843,

Type:: 7
Description:: OSPF Exclude Maximum Delay
Reference:: RFC 9843,

Type:: 8
Description:: OSPF Reference Bandwidth
Reference:: RFC 9843,

Type:: 9
Description:: OSPF Bandwidth Threshold
Reference:: RFC 9843,

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.

Type:: 17
Description:: Generic Metric
TLVs set to "Y":: 22, 23, 25, 141, 222, and 223
Reference:: RFC 9843,

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.

Type:: 17
Description:: Generic Metric
Reference:: RFC 9843,

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,

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,

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,

References Normative References IEEE Standard for Floating-Point Arithmetic IEEE Use of OSI IS-IS for routing in TCP/IP and dual environments This memo specifies an integrated routing protocol, based on the OSI Intra-Domain IS-IS Routing Protocol, which may be used as an interior gateway protocol (IGP) to support TCP/IP as well as OSI. This allows a single routing protocol to be used to support pure IP environments, pure OSI environments, and dual environments. This specification was developed by the IS-IS working group of the Internet Engineering Task Force. [STANDARDS-TRACK] Key words for use in RFCs to Indicate Requirement Levels In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. OSPF Version 2 This memo documents version 2 of the OSPF protocol. OSPF is a link- state routing protocol. [STANDARDS-TRACK] Traffic Engineering (TE) Extensions to OSPF Version 2 This document describes extensions to the OSPF protocol version 2 to support intra-area Traffic Engineering (TE), using Opaque Link State Advertisements. IS-IS Extensions for Traffic Engineering This document describes extensions to the Intermediate System to Intermediate System (IS-IS) protocol to support Traffic Engineering (TE). This document extends the IS-IS protocol by specifying new information that an Intermediate System (router) can place in Link State Protocol Data Units (LSP). This information describes additional details regarding the state of the network that are useful for traffic engineering computations. [STANDARDS-TRACK] Traffic Engineering Extensions to OSPF Version 3 This document describes extensions to OSPFv3 to support intra-area Traffic Engineering (TE). This document extends OSPFv2 TE to handle IPv6 networks. A new TLV and several new sub-TLVs are defined to support IPv6 networks. [STANDARDS-TRACK] OSPF Extensions in Support of Inter-Autonomous System (AS) MPLS and GMPLS Traffic Engineering This document describes extensions to the OSPF version 2 and 3 protocols to support Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) Traffic Engineering (TE) for multiple Autonomous Systems (ASes). OSPF-TE v2 and v3 extensions are defined for the flooding of TE information about inter-AS links that can be used to perform inter-AS TE path computation. No support for flooding information from within one AS to another AS is proposed or defined in this document. [STANDARDS-TRACK] OSPFv2 Prefix/Link Attribute Advertisement OSPFv2 requires functional extension beyond what can readily be done with the fixed-format Link State Advertisements (LSAs) as described in RFC 2328. This document defines OSPFv2 Opaque LSAs based on Type-Length-Value (TLV) tuples that can be used to associate additional attributes with prefixes or links. Depending on the application, these prefixes and links may or may not be advertised in the fixed-format LSAs. The OSPFv2 Opaque LSAs are optional and fully backward compatible. Guidelines for Writing an IANA Considerations Section in RFCs Many protocols make use of points of extensibility that use constants to identify various protocol parameters. To ensure that the values in these fields do not have conflicting uses and to promote interoperability, their allocations are often coordinated by a central record keeper. For IETF protocols, that role is filled by the Internet Assigned Numbers Authority (IANA). To make assignments in a given registry prudently, guidance describing the conditions under which new values should be assigned, as well as when and how modifications to existing values can be made, is needed. This document defines a framework for the documentation of these guidelines by specification authors, in order to assure that the provided guidance for the IANA Considerations is clear and addresses the various issues that are likely in the operation of a registry. This is the third edition of this document; it obsoletes RFC 5226. Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. OSPFv3 Link State Advertisement (LSA) Extensibility OSPFv3 requires functional extension beyond what can readily be done with the fixed-format Link State Advertisement (LSA) as described in RFC 5340. Without LSA extension, attributes associated with OSPFv3 links and advertised IPv6 prefixes must be advertised in separate LSAs and correlated to the fixed-format LSAs. This document extends the LSA format by encoding the existing OSPFv3 LSA information in Type-Length-Value (TLV) tuples and allowing advertisement of additional information with additional TLVs. Backward-compatibility mechanisms are also described. This document updates RFC 5340, "OSPF for IPv6", and RFC 5838, "Support of Address Families in OSPFv3", by providing TLV-based encodings for the base OSPFv3 unicast support and OSPFv3 address family support. Advertising Layer 2 Bundle Member Link Attributes in IS-IS There are deployments where the Layer 3 interface on which IS-IS operates is a Layer 2 interface bundle. Existing IS-IS advertisements only support advertising link attributes of the Layer 3 interface. If entities external to IS-IS wish to control traffic flows on the individual physical links that comprise the Layer 2 interface bundle, link attribute information about the bundle members is required. This document introduces the ability for IS-IS to advertise the link attributes of Layer 2 (L2) Bundle Members. IGP Flexible Algorithm IGP protocols historically compute the best paths over the network based on the IGP metric assigned to the links. Many network deployments use RSVP-TE or Segment Routing - Traffic Engineering (SR-TE) to steer traffic over a path that is computed using different metrics or constraints than the shortest IGP path. This document specifies a solution that allows IGPs themselves to compute constraint-based paths over the network. This document also specifies a way of using Segment Routing (SR) Prefix-SIDs and SRv6 locators to steer packets along the constraint-based paths. Advertising Layer 2 Bundle Member Link Attributes in OSPF There are deployments where the Layer 3 (L3) interface on which OSPF operates is a Layer 2 (L2) interface bundle. Existing OSPF advertisements only support advertising link attributes of the L3 interface. If entities external to OSPF wish to control traffic flows on the individual physical links that comprise the L2 interface bundle, link attribute information for the bundle members is required. This document defines the protocol extensions for OSPF to advertise the link attributes of L2 bundle members. The document also specifies the advertisement of these OSPF extensions via the Border Gateway Protocol - Link State (BGP-LS) and thereby updates RFC 9085. IS-IS Application-Specific Link Attributes Existing traffic-engineering-related link attribute advertisements have been defined and are used in RSVP-TE deployments. Since the original RSVP-TE use case was defined, additional applications (e.g., Segment Routing Policy and Loop-Free Alternates) that also make use of the link attribute advertisements have been defined. In cases where multiple applications wish to make use of these link attributes, the current advertisements do not support application-specific values for a given attribute, nor do they support an indication of which applications are using the advertised value for a given link. This document introduces link attribute advertisements that address both of these shortcomings. This document obsoletes RFC 8919. OSPF Application-Specific Link Attributes Existing traffic-engineering-related link attribute advertisements have been defined and are used in RSVP-TE deployments. Since the original RSVP-TE use case was defined, additional applications such as Segment Routing (SR) Policy and Loop-Free Alternates (LFAs) that also make use of the link attribute advertisements have been defined. In cases where multiple applications wish to make use of these link attributes, the current advertisements do not support application-specific values for a given attribute, nor do they support indication of which applications are using the advertised value for a given link. This document introduces link attribute advertisements in OSPFv2 and OSPFv3 that address both of these shortcomings. This document obsoletes RFC 8920. Informative References IS-IS YANG Model Augmentations for Additional Features - Release 1 LabN Consulting, L.L.C. Futurewei Technologies Cisco Systems This document defines YANG data modules augmenting the IETF IS-IS YANG model to provide support for IS-IS Minimum Remaining Lifetime as defined in RFC 7987, and Signaling Maximum SID Depth Using IS-IS as defined in RFC 8491. Work in Progress OSPF YANG Model Augmentations for Additional Features - Release 1 LabN Consulting, LLC Futurewei Technologies This document defines YANG data modules that augment the IETF OSPF YANG model to support various OSPF extensions and features, including Traffic Engineering Extensions to OSPF Version 3 as defined in RFC 5329, OSPF Two-Part Metric as defined in RFC 8042, OSPF Graceful Link Shutdown as defined in RFC 8379, OSPF Link-Local Signaling (LLS) Extensions for Local Interface ID Advertisement as defined in RFC 8510, OSPF MSD as defined in RFC 8476, OSPF Application-Specific Link Attributes as defined in RFC 9492, and OSPF Flexible Algorithm as defined in RFC 9350. Work in Progress A Path Computation Element (PCE)-Based Architecture Constraint-based path computation is a fundamental building block for traffic engineering systems such as Multiprotocol Label Switching (MPLS) and Generalized Multiprotocol Label Switching (GMPLS) networks. Path computation in large, multi-domain, multi-region, or multi-layer networks is complex and may require special computational components and cooperation between the different network domains. This document specifies the architecture for a Path Computation Element (PCE)-based model to address this problem space. This document does not attempt to provide a detailed description of all the architectural components, but rather it describes a set of building blocks for the PCE architecture from which solutions may be constructed. This memo provides information for the Internet community. M-ISIS: Multi Topology (MT) Routing in Intermediate System to Intermediate Systems (IS-ISs) This document describes an optional mechanism within Intermediate System to Intermediate Systems (IS-ISs) used today by many ISPs for IGP routing within their clouds. This document describes how to run, within a single IS-IS domain, a set of independent IP topologies that we call Multi-Topologies (MTs). This MT extension can be used for a variety of purposes, such as an in-band management network "on top" of the original IGP topology, maintaining separate IGP routing domains for isolated multicast or IPv6 islands within the backbone, or forcing a subset of an address space to follow a different topology. [STANDARDS-TRACK] Simplified Extension of Link State PDU (LSP) Space for IS-IS This document describes a simplified method for extending the Link State PDU (LSP) space beyond the 256 LSP limit. This method is intended as a preferred replacement for the method defined in RFC 3786. [STANDARDS-TRACK] A Framework for Loop-Free Convergence A micro-loop is a packet forwarding loop that may occur transiently among two or more routers in a hop-by-hop packet forwarding paradigm. This framework provides a summary of the causes and consequences of micro-loops and enables the reader to form a judgement on whether micro-looping is an issue that needs to be addressed in specific networks. It also provides a survey of the currently proposed mechanisms that may be used to prevent or to suppress the formation of micro-loops when an IP or MPLS network undergoes topology change due to failure, repair, or management action. When sufficiently fast convergence is not available and the topology is susceptible to micro-loops, use of one or more of these mechanisms may be desirable. This document is not an Internet Standards Track specification; it is published for informational purposes. OSPF Traffic Engineering (TE) Metric Extensions In certain networks, such as, but not limited to, financial information networks (e.g., stock market data providers), network performance information (e.g., link propagation delay) is becoming critical to data path selection. This document describes common extensions to RFC 3630 "Traffic Engineering (TE) Extensions to OSPF Version 2" and RFC 5329 "Traffic Engineering Extensions to OSPF Version 3" to enable network performance information to be distributed in a scalable fashion. The information distributed using OSPF TE Metric Extensions can then be used to make path selection decisions based on network performance. Note that this document only covers the mechanisms by which network performance information is distributed. The mechanisms for measuring network performance information or using that information, once distributed, are outside the scope of this document. IS-IS Traffic Engineering (TE) Metric Extensions In certain networks, such as, but not limited to, financial information networks (e.g., stock market data providers), network-performance criteria (e.g., latency) are becoming as critical to data-path selection as other metrics. This document describes extensions to IS-IS Traffic Engineering Extensions (RFC 5305). These extensions provide a way to distribute and collect network-performance information in a scalable fashion. The information distributed using IS-IS TE Metric Extensions can then be used to make path-selection decisions based on network performance. Note that this document only covers the mechanisms with which network-performance information is distributed. The mechanisms for measuring network performance or acting on that information, once distributed, are outside the scope of this document. This document obsoletes RFC 7810. IS-IS Extensions in Support of Inter-Autonomous System (AS) MPLS and GMPLS Traffic Engineering This document describes extensions to the Intermediate System to Intermediate System (IS-IS) protocol to support Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) Traffic Engineering (TE) for multiple Autonomous Systems (ASes). It defines IS-IS extensions for the flooding of TE information about inter-AS links, which can be used to perform inter-AS TE path computation. No support for flooding information from within one AS to another AS is proposed or defined in this document. This document builds on RFC 5316 by adding support for IPv6-only operation. This document obsoletes RFC 5316. Loop avoidance using Segment Routing Cisco Systems Cisco Systems Cisco Systems Orange INSA Lyon Cisco Systems This document presents a mechanism aimed at providing loop avoidance in the case of IGP network convergence event. The solution relies on the temporary use of SR policies ensuring loop-freeness over the post-convergence paths from the converging node to the destination. Work in Progress

Updated List of Rules for Pruning Links in Flex-Algorithm Topology This section lists the entire set of rules to prune links from Flex-Algorithm topology during Flexible Algorithm calculation. It includes the original rules defined in as well as the new additions (rules 6 and 7) described in this document. For all links in the topology:

Check if any exclude Administrative Group rule is part of the Flex-Algorithm Definition. If such exclude rule exists, 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.
Check if any exclude SRLG rule is part of the Flex-Algorithm Definition. If such exclude rule exists, check if the link is 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.
Check if any include-any Administrative Group rule is part of the Flex-Algorithm Definition. If such include-any rule 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.
Check if any include-all Administrative Group rule is part of the Flex-Algorithm Definition. If such include-all rule 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.
If the Flex-Algorithm Definition uses something other than the IGP metric (), and such metric 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.
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.
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.

Acknowledgements Many thanks to , , , , , and for discussions and input.

Contributors Juniper Networks

salih@juniper.net

Authors' Addresses Juniper Networks Inc.

Exora Business Park Bangalore Karnataka 560103 India shraddha@juniper.net

Juniper Networks Inc.

bwilliam@juniper.net

Juniper Networks Inc.

mrajesh@juniper.net

Orange

bruno.decraene@orange.com

Cisco Systems

ppsenak@cisco.com

Juniper Networks Inc.

tony.li@tony.li