rfc9843v1.txt   rfc9843.txt 
skipping to change at line 22 skipping to change at line 22
August 2025 August 2025
IGP Flexible Algorithms: Bandwidth, Delay, Metrics, and Constraints IGP Flexible Algorithms: Bandwidth, Delay, Metrics, and Constraints
Abstract Abstract
Many networks configure the IGP link metric relative to the link Many networks configure the IGP link metric relative to the link
capacity, and high bandwidth traffic gets routed per the link capacity, and high bandwidth traffic gets routed per the link
capacity. Flexible Algorithms provide mechanisms to create capacity. Flexible Algorithms provide mechanisms to create
constraint-based paths in an IGP. This specification documents a constraint-based paths in an IGP. This specification documents a
generic metric type and a set of bandwidth-related constraints to be generic metric-type and a set of bandwidth-related constraints to be
used in Flexible Algorithms. used in Flexible Algorithms.
Status of This Memo Status of This Memo
This is an Internet Standards Track document. This is an Internet Standards Track document.
This document is a product of the Internet Engineering Task Force This document is a product of the Internet Engineering Task Force
(IETF). It represents the consensus of the IETF community. It has (IETF). It represents the consensus of the IETF community. It has
received public review and has been approved for publication by the received public review and has been approved for publication by the
Internet Engineering Steering Group (IESG). Further information on Internet Engineering Steering Group (IESG). Further information on
skipping to change at line 152 skipping to change at line 152
administrative groups, can be used to ensure that traffic avoids administrative groups, can be used to ensure that traffic avoids
particular portions of the network. These strict constraints are particular portions of the network. These strict constraints are
appropriate when there is an absolute requirement to avoid parts of appropriate when there is an absolute requirement to avoid parts of
the topology, even in failure conditions. However, if the the topology, even in failure conditions. However, if the
requirement is less strict, then using a high metric in a portion of requirement is less strict, then using a high metric in a portion of
the topology may be more appropriate. the topology may be more appropriate.
This document defines a family of generic metrics that can advertise This document defines a family of generic metrics that can advertise
various types of administratively assigned metrics. This document various types of administratively assigned metrics. This document
proposes standard metric-types that have specific semantics and proposes standard metric-types that have specific semantics and
require to be standardized. This document also specifies user- require standardization. This document also specifies user-defined
defined metric-types where specifics are not defined so that metric-types where specifics are not defined so that administrators
administrators are free to assign semantics as they see fit. are free to assign semantics as they see fit.
In Section 4, this document specifies a new bandwidth-based metric
type to be used with Flex-Algorithm and other applications.
Section 3 defines additional FAD [RFC9350] constraints that allow the Section 3 defines additional FAD [RFC9350] constraints that allow the
network administrator to preclude the use of low bandwidth links or network administrator to preclude the use of low bandwidth links or
high delay links. high delay links. In Section 4, this document 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 Section 4.1 defines mechanisms to automatically calculate link
metrics based on the parameters defined in the FAD and the advertised metrics based on the parameters defined in the FAD and the advertised
Maximum Link Bandwidth of each link. This is advantageous because Maximum Link Bandwidth of each link. This is advantageous because
administrators can change their criteria for metric assignment administrators can change their criteria for metric assignment
centrally, without individual modification of each link metric centrally, without individual modification of each link metric
throughout the network. The procedures described in this document throughout the network. The procedures described in this document
are intended to assign a metric to a link based on the total link 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 capacity, and they are not intended to update the metric based on
actual traffic flow. Thus, the procedures described in this document actual traffic flow. Thus, the procedures described in this document
skipping to change at line 186 skipping to change at line 186
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in "OPTIONAL" in this document are to be interpreted as described in
BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
2. Generic Metric Advertisement 2. Generic Metric Advertisement
IS-IS [RFC1195] and OSPF [RFC2328] advertise a metric for each link IS-IS [RFC1195] and OSPF [RFC2328] advertise a metric for each link
in their respective link state advertisements. Multiple metric types in their respective link state advertisements. Multiple metric-types
are already supported. Administratively assigned metrics are are already supported. Administratively assigned metrics are
described in the original OSPF and IS-IS specifications. The Traffic described in the original OSPF and IS-IS specifications. The Traffic
Engineering Default Metric is defined in [RFC5305] and [RFC3630], and Engineering Default Metric is defined in [RFC5305] and [RFC3630], and
the Min Unidirectional delay metric is defined in [RFC8570] and the Unidirectional Link Delay is defined in [RFC8570] and [RFC7471].
[RFC7471]. Other metrics, such as jitter, reliability, and fiscal Other metrics, such as jitter, reliability, and fiscal cost may be
cost may be helpful, depending on the traffic class. Rather than helpful, depending on the traffic class. Rather than attempt to
attempt to enumerate all possible metrics of interest, this document enumerate all possible metrics of interest, this document specifies a
specifies a generic mechanism for advertising metrics. generic mechanism for advertising metrics.
Each generic metric advertisement is on a per-link and per-metric- Each generic metric advertisement is on a per-link and per-metric-
type basis. The metric advertisement consists of a metric type field type basis. The metric advertisement consists of a metric-type field
and a value for the metric. The metric type field has been assigned 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 in the "IGP Metric-Type" IANA registry. Metric-types 0-127 are
standard metric types as assigned by IANA. This document further standard metric-types as assigned by IANA. This document further
specifies a user-defined metric type space of metric types 128-255. specifies a user-defined metric-type space of metric-types 128-255.
These are user defined and can be assigned by an operator for local These are user defined and can be assigned by an operator for local
use. use.
Implementations MUST support sending and receiving generic metric Implementations MUST support sending and receiving a Generic Metric
sub-TLV in Application-Specific Link Attributes (ASLA) encodings as sub-TLV in Application-Specific Link Attributes (ASLA) encodings as
well as in the TLV 22/extended link LSA/TE-LSAs. The usage of a well as in TLV 22 and Extended Link Opaque Link State Advertisements
generic metric by an individual application is subject to the same (LSAs) [RFC7684] and TE-LSAs. The usage of a generic metric by an
rules that apply to other link attributes as defined in [RFC3630], individual application is subject to the same rules that apply to
[RFC5305], [RFC9479], [RFC9492], and [RFC9350]. other link attributes as defined in [RFC3630], [RFC5305], [RFC9479],
[RFC9492], and [RFC9350].
2.1. IS-IS Generic Metric Sub-TLV 2.1. IS-IS Generic Metric Sub-TLV
The IS-IS Generic Metric sub-TLV specifies the link metric for a The IS-IS Generic Metric sub-TLV specifies the link metric for a
given metric type. Typically, this metric is assigned by a network given metric-type. Typically, this metric is assigned by a network
administrator. The Generic Metric sub-TLV is advertised in the TLVs/ administrator. The Generic Metric sub-TLV is advertised in the TLVs/
sub-TLVs below: sub-TLVs below:
a. TLV 22 (Extended IS reachability) [RFC5305] a. TLV 22 (Extended IS reachability) [RFC5305]
b. TLV 222 (MT-ISN) [RFC5120] b. TLV 222 (MT-ISN) [RFC5120]
c. TLV 23 (IS Neighbor Attribute) [RFC5311] c. TLV 23 (IS Neighbor Attribute) [RFC5311]
d. TLV 223 (MT IS Neighbor Attribute) [RFC5311] d. TLV 223 (MT IS Neighbor Attribute) [RFC5311]
e. TLV 141 (Inter-AS Reachability Information) [RFC9346] e. TLV 141 (Inter-AS Reachability Information) [RFC9346]
f. sub-TLV 16 (Application-Specific Link Attributes (ASLA)) of TLV f. sub-TLV 16 (Application-Specific Link Attributes (ASLA)) of TLVs
22/222/23/223/141 [RFC9479] 22/222/23/223/141 [RFC9479]
g. TLV 25 (L2 Bundle Member Attributes) [RFC8668]. Marked as "y(s)" g. TLV 25 (L2 Bundle Member Attributes) [RFC8668]. Marked as "y(s)"
(shareable among bundle members). (shareable among bundle members).
The Generic Metric sub-TLV, type 17, is 6 octets in length. The Generic Metric sub-TLV, type 17, is 6 octets in length.
0 1 2 3 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 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at line 260 skipping to change at line 261
An 8-bit field assigned by IANA (17). This value uniquely An 8-bit field assigned by IANA (17). This value uniquely
identifies the Generic Metric TLV. identifies the Generic Metric TLV.
Length (1 octet): Length (1 octet):
An 8-bit field indicating the total length, in octets, of the An 8-bit field indicating the total length, in octets, of the
subsequent fields. For this TLV, the Length is set to 4. subsequent fields. For this TLV, the Length is set to 4.
Metric-Type (1 octet): Metric-Type (1 octet):
An 8-bit field specifying the type of metric. The value is taken An 8-bit field specifying the type of metric. The value is taken
from the "IGP Metric-Type" registry maintained by IANA. The from the "IGP Metric-Type" registry maintained by IANA. The
metric type may be any value that is indicated as allowed in the metric-type may be any value that is indicated as allowed in the
Generic Metric sub-TLV by the "IGP Metric-Type" registry. Generic Metric sub-TLV by the "IGP Metric-Type" registry.
Value (3 octets): Value (3 octets):
A 24-bit unsigned integer representing the metric value. The A 24-bit unsigned integer representing the metric value. The
valid range is from 0 to 16,777,215 (0xFFFFFF). valid range is from 0 to 16,777,215 (0xFFFFFF).
The Generic Metric sub-TLV MAY be advertised multiple times. For a The Generic Metric sub-TLV MAY be advertised multiple times. For a
particular metric type, the Generic Metric sub-TLV MUST be advertised particular metric-type, the Generic Metric sub-TLV MUST be advertised
only once for a link when advertised in TLV 22, 222, 23, 223, and 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 141. When the Generic Metric sub-TLV is advertised in ASLA, each
metric type MUST be advertised only once per-application for a link. metric-type MUST be advertised only once per-application for a link.
If there are multiple Generic Metric sub-TLVs advertised 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) for the same metric-type (and the same application in case of ASLA)
in one or more received Link State Protocol Data Units (LSPDUs), in one or more received Link State Protocol Data Units (LSPDUs),
advertisement in the lowest-numbered fragment MUST be used, and the advertisement in the lowest-numbered fragment MUST be used, and the
subsequent instances MUST be ignored. subsequent instances MUST be ignored.
For a link, if the metric type corresponds to a metric type for which 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 legacy advertisement mechanisms exist (e.g., the IGP Metric, the Min
Unidirectional Link Delay, or the Traffic Engineering Default Unidirectional Link Delay, or the Traffic Engineering Default
Metric), the legacy metric types MUST be utilized from the existing Metric), the legacy metric-types MUST be utilized from the existing
TLV or sub-TLVs. If a Generic Metric advertises a legacy metric, it TLV or sub-TLVs. If a Generic Metric advertises a legacy metric, it
MUST be ignored. MUST be ignored.
A metric value of 0xFFFFFF is considered a maximum link metric, and a A metric value of 0xFFFFFF is considered a maximum link metric, and a
link having this metric value MUST be used during Flex-Algorithm link having this metric value MUST be used during Flex-Algorithm
calculations as a last resort link as described in Section 15.3 of calculations as a last resort link as described in Section 15.3 of
[RFC9350]. A link can be made unusable by Flex-Algorithm by leaving [RFC9350]. A link can be made unusable by Flex-Algorithm by leaving
out Generic Metric advertisement of the particular metric-type that out Generic Metric advertisement of the particular metric-type that
the Flex-Algorithm uses, as described in [RFC9350]. the Flex-Algorithm uses, as described in [RFC9350].
During the router maintenance activity, the Generic Metric for all 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 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- (0xFFFFFF), as it is the maximum usable link metric for the Flex-
Algorithm calculations. Algorithm calculations.
2.2. OSPF Generic Metric Sub-TLV 2.2. OSPF Generic Metric Sub-TLV
The OSPF Generic Metric sub-TLV specifies the link metric for a given The OSPF Generic Metric sub-TLV specifies the link metric for a given
metric type. Typically, this metric is assigned by a network metric-type. Typically, this metric is assigned by a network
administrator. The Generic Metric sub-TLV is advertised in the TLVs administrator. The Generic Metric sub-TLV is advertised in the TLVs
below: below:
a. sub-TLV of TE Link TLV (2) of OSPF TE LSA [RFC3630]. a. sub-TLV of TE Link TLV (type 2) of OSPF TE LSA [RFC3630].
b. sub-TLV of TE Link TLV (2) of OSPFv2 Inter-AS-TE-v2 LSA b. sub-TLV of TE Link TLV (type 2) of OSPFv2 Inter-AS-TE-v2 LSA
[RFC5392]. [RFC5392].
c. sub-TLV of TE Link TLV (2) of OSPFv3 Intra-Area-TE-LSA [RFC5329]. c. sub-TLV of TE Link TLV (type 2) of OSPFv3 Intra-Area-TE-LSA
[RFC5329].
d. sub-TLV of TE Link TLV (2) of OSPFv3 Inter-AS-TE-v3 LSA d. sub-TLV of TE Link TLV (type 2) of OSPFv3 Inter-AS-TE-v3 LSA
[RFC5392]. [RFC5392].
e. sub-TLV of Application-Specific Link Attributes (ASLA) sub-TLV e. sub-TLV of Application-Specific Link Attributes (ASLA) sub-TLV
[RFC9492] of the OSPFv2 Extended Link TLV [RFC7684]. [RFC9492] of the OSPFv2 Extended Link TLV [RFC7684].
f. sub-TLV of Application-Specific Link Attributes (ASLA) sub-TLV f. sub-TLV of Application-Specific Link Attributes (ASLA) sub-TLV
[RFC9492] of the OSPFv3 Router-Link TLV [RFC8362]. [RFC9492] of the OSPFv3 Router-Link TLV [RFC8362].
g. sub-TLV of the OSPFv2 L2 Bundle Member Attributes sub-TLV g. sub-TLV of the OSPFv2 L2 Bundle Member Attributes sub-TLV
[RFC9356]. [RFC9356].
skipping to change at line 354 skipping to change at line 356
A 16-bit field assigned by IANA (25/36/34). This value uniquely A 16-bit field assigned by IANA (25/36/34). This value uniquely
identifies the Generic Metric TLV. identifies the Generic Metric TLV.
Length (2 octets): Length (2 octets):
A 16-bit field indicating the total length, in octets, of the A 16-bit field indicating the total length, in octets, of the
subsequent fields. For this TLV, the Length is set to 8. subsequent fields. For this TLV, the Length is set to 8.
Metric-Type (1 octet): Metric-Type (1 octet):
An 8-bit field specifying the type of metric. The value is taken An 8-bit field specifying the type of metric. The value is taken
from the "IGP Metric-Type" registry maintained by IANA. The from the "IGP Metric-Type" registry maintained by IANA. The
metric type may be any value that is indicated as allowed in the metric-type may be any value that is indicated as allowed in the
Generic Metric sub-TLV by the "IGP Metric-Type" registry. Generic Metric sub-TLV by the "IGP Metric-Type" registry.
Reserved (3 octets): Reserved (3 octets):
Must set to zero by the sender and must be ignored by the Must set to zero by the sender and must be ignored by the
receiver. receiver.
Value (4 octets): Value (4 octets):
A 32-bit unsigned integer representing the metric value. The A 32-bit unsigned integer representing the metric value. The
valid range is from 0 to 4,294,967,295 (0xFFFFFFFF). valid range is from 0 to 4,294,967,295 (0xFFFFFFFF).
The Generic Metric sub-TLV MAY be advertised multiple times. For a The Generic Metric sub-TLV MAY be advertised multiple times. For a
particular metric type, the Generic Metric sub-TLV MUST be advertised particular metric-type, the Generic Metric sub-TLV MUST be advertised
only once for a link when advertised as (a) through (d) above. When 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 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 MUST be advertised only once per application for a link. If there
are multiple Generic Metric sub-TLVs advertised for a link for the 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 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 more received LSAs, advertisement in the lowest-numbered LSA MUST be
used, and the subsequent instances MUST be ignored. used, and the subsequent instances MUST be ignored.
For a link, if the metric type corresponds to a metric type for which 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 legacy advertisement mechanisms exist (e.g., the IGP Metric, the Min
Unidirectional Link Delay, or the Traffic Engineering Default Unidirectional Link Delay, or the Traffic Engineering Default
Metric), the legacy metric types MUST be utilized from the existing Metric), the legacy metric-types MUST be utilized from the existing
TLV or sub-TLVs. If a Generic Metric advertises a legacy metric, it TLV or sub-TLVs. If a Generic Metric advertises a legacy metric, it
MUST be ignored. MUST be ignored.
A metric value of 0xFFFFFFFF is considered a maximum link metric, and A metric value of 0xFFFFFFFF is considered a maximum link metric, and
a link having this metric value MUST be used during Flex-Algorithm a link having this metric value MUST be used during Flex-Algorithm
calculations as a last resort link, as described in Section 15.3 of calculations as a last resort link, as described in Section 15.3 of
[RFC9350]. [RFC9350].
A link can be made unusable by Flex-Algorithm by leaving out Generic A link can be made unusable by Flex-Algorithm by leaving out Generic
Metric advertisement of the particular metric-type that the Flex- Metric advertisement of the particular metric-type that the Flex-
Algorithm uses, as described in [RFC9350]. Algorithm uses, as described in [RFC9350].
During the router maintenance activity, the Generic Metric for all 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 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- (0xFFFFFFFF), as it is the maximum usable link metric for the Flex-
Algorithm calculations. Algorithm calculations.
2.3. Generic Metric Applicability to Flexible Algorithm Multi-Domain/ 2.3. Generic Metric Applicability to Flexible Algorithm Multi-Domain/
Multi-Area Networks Multi-Area Networks
Generic Metric can be used by Flex-Algorithm by specifying the metric Generic Metric can be used by Flex-Algorithm by specifying the
type in the Flexible Algorithm Definitions. When Flex-Algorithm is metric-type in the Flexible Algorithm Definitions. When Flex-
used in a multi-area network, [RFC9350] defines the Flexible Algorithm is used in a multi-area network, [RFC9350] defines the
Algorithm Prefix Metric (FAPM) sub-TLV that carries the Flexible- Flexible Algorithm Prefix Metric (FAPM) sub-TLV that carries the
Algorithm-specific metric. Metrics carried in FAPM will be equal to Flexible-Algorithm-specific metric. Metrics carried in FAPM will be
the metric to reach the prefix for that Flex-Algorithm in its source equal to the metric to reach the prefix for that Flex-Algorithm in
area or domain (source area from the Area Border Router (ABR) its source area or domain (source area from the Area Border Router
perspective). When Flex-Algorithm uses Generic Metric, the same (ABR) perspective). When Flex-Algorithm uses Generic Metric, the
procedures as described in Section 13 of [RFC9350] are used to send same procedures as described in Section 13 of [RFC9350] are used to
and process the FAPM sub-TLV. send and process the FAPM sub-TLV.
3. FAD Constraint Sub-TLVs 3. FAD Constraint Sub-TLVs
Large high throughput flows are referred to as "elephant flows". Large high throughput flows are referred to as "elephant flows".
Directing an elephant flow down a low-bandwidth link might congest Directing an elephant flow down a low-bandwidth link might congest
the link and cause other critical application traffic flowing on the the link and cause other critical application traffic flowing on the
link to drop. Thus, in the context of Flex-Algorithm, it would be 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 useful to be able to constrain the topology to only those links
capable of supporting a minimum amount of bandwidth. capable of supporting a minimum amount of bandwidth.
If the capacity of a link is constant, this can already be achieved If the capacity of a low bandwidth link is constant, constraining the
through the use of administrative groups. However, when a Layer 3 topology to avoid those links can already be achieved through the use
link is actually a collection of Layer 2 links (Link Aggregation of administrative groups. However, when a Layer 3 link is actually a
Group (LAG) / Layer 2 Bundle), the link bandwidth will vary based on collection of Layer 2 links (Link Aggregation Group (LAG) / Layer 2
the set of active constituent links. This could be automated by Bundle), the link bandwidth will vary based on the set of active
having an implementation vary the advertised administrative groups constituent links. This could be automated by having an
based on bandwidth, but this seems unnecessarily complex and implementation vary the advertised administrative groups based on
expressing this requirement as a direct constraint on the topology bandwidth, but this seems unnecessarily complex and expressing this
seems simpler. This is also advantageous if the minimum required requirement as a direct constraint on the topology seems simpler.
bandwidth changes, as this constraint would provide a single This is also advantageous if the minimum required bandwidth changes,
centralized, coordinated point of control. as this constraint would provide a single centralized, coordinated
point of control.
To satisfy this requirement, this document defines an Exclude Minimum To satisfy this requirement, this document defines an Exclude Minimum
Bandwidth constraint. When this constraint is advertised in a FAD, a Bandwidth constraint. When this constraint is advertised in a FAD, a
link will be pruned from the Flex-Algorithm topology if the link's link will be pruned from the Flex-Algorithm topology if the link's
advertised Maximum Link Bandwidth is below the advertised Minimum advertised Maximum Link Bandwidth is below the advertised Minimum
Bandwidth value. Bandwidth value.
Similarly, this document defines an Exclude Maximum Link Delay Similarly, this document defines an Exclude Maximum Link Delay
constraint. Applications, such as High-Frequency Trading are constraint. Applications, such as High-Frequency Trading are
sensitive to link delays and may perform poorly in networks prone to sensitive to link delays and may perform poorly in networks prone to
skipping to change at line 487 skipping to change at line 490
The FAEMB sub-TLV MUST appear once at most in the FAD sub-TLV. If it 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 appears more than once, the IS-IS FAD sub-TLV MUST be ignored by the
receiver. receiver.
The Minimum bandwidth advertised in the FAEMB sub-TLV MUST be The Minimum bandwidth advertised in the FAEMB sub-TLV MUST be
compared with Maximum Link Bandwidth advertised in sub-sub-TLV 9 of compared with Maximum Link Bandwidth advertised in sub-sub-TLV 9 of
the ASLA sub-TLV [RFC9479]. If the L-flag is set in the ASLA sub- the ASLA sub-TLV [RFC9479]. If the L-flag is set in the ASLA sub-
TLV, the Minimum bandwidth advertised in the FAEMB sub-TLV MUST be TLV, the Minimum bandwidth advertised in the FAEMB sub-TLV MUST be
compared with the Maximum Link Bandwidth as advertised in the sub-TLV compared with the Maximum Link Bandwidth as advertised in the sub-TLV
9 of the TLV 22/222/23/223/141 [RFC5305], as defined in Section 4.2 9 of the TLVs 22/222/23/223/141 [RFC5305], as defined in Section 4.2
of [RFC9479]. of [RFC9479].
If the Maximum Link Bandwidth is lower than the Minimum Link If the Maximum Link Bandwidth is lower than the Minimum Link
Bandwidth advertised in the FAEMB sub-TLV, the link MUST be excluded Bandwidth advertised in the FAEMB sub-TLV, the link MUST be excluded
from the Flex-Algorithm topology. If a link does not have the from the Flex-Algorithm topology. If a link does not have the
Maximum Link Bandwidth advertised but the FAD contains this sub-TLV, Maximum Link Bandwidth advertised but the FAD contains this sub-TLV,
then that link MUST NOT be excluded from the topology based on the then that link MUST NOT be excluded from the topology based on the
Minimum Bandwidth constraint. Minimum Bandwidth constraint.
3.1.2. IS-IS Exclude Maximum Delay Sub-TLV 3.1.2. IS-IS Exclude Maximum Delay Sub-TLV
skipping to change at line 534 skipping to change at line 537
The FAEMD sub-TLV MUST appear only once in the FAD sub-TLV. If it 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 appears more than once, the IS-IS FAD sub-TLV MUST be ignored by the
receiver. receiver.
The Maximum link delay advertised in the FAEMD sub-TLV MUST be The Maximum link delay advertised in the FAEMD sub-TLV MUST be
compared with Min Unidirectional Link Delay advertised in sub-sub-TLV compared with Min Unidirectional Link Delay advertised in sub-sub-TLV
34 of the ASLA sub-TLV [RFC9479]. If the L-flag is set in the ASLA 34 of the ASLA sub-TLV [RFC9479]. If the L-flag is set in the ASLA
sub-TLV, the Maximum link delay advertised in the FAEMD sub-TLV MUST sub-TLV, the Maximum link delay advertised in the FAEMD sub-TLV MUST
be compared with Min Unidirectional Link Delay as advertised by the be compared with Min Unidirectional Link Delay as advertised by the
sub-TLV 34 of the TLV 22/222/23/223/141 [RFC8570], as defined in sub-TLV 34 of the TLVs 22/222/23/223/141 [RFC8570], as defined in
Section 4.2 of [RFC9479]. Section 4.2 of [RFC9479].
If the Min Unidirectional Link Delay value is higher than the Maximum 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 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 from the Flex-Algorithm topology. If a link does not have the Min
Unidirectional Link Delay advertised but the FAD contains this sub- Unidirectional Link Delay advertised but the FAD contains this sub-
TLV, then that link MUST NOT be excluded from the topology based on TLV, then that link MUST NOT be excluded from the topology based on
the Maximum Delay constraint. the Maximum Delay constraint.
3.2. OSPF FAD Constraint Sub-TLVs 3.2. OSPF FAD Constraint Sub-TLVs
skipping to change at line 648 skipping to change at line 651
4. Bandwidth Metric Advertisement 4. Bandwidth Metric Advertisement
Historically, IGP implementations have made default metric Historically, IGP implementations have made default metric
assignments based on link bandwidth. This has proven to be useful assignments based on link bandwidth. This has proven to be useful
but has suffered from having different defaults across but has suffered from having different defaults across
implementations and from the rapid growth of link bandwidths. With implementations and from the rapid growth of link bandwidths. With
Flex-Algorithm, the network administrator can define a function that Flex-Algorithm, the network administrator can define a function that
will produce a metric for each link and have each node automatically will produce a metric for each link and have each node automatically
compute each link's metric based on its bandwidth. compute each link's metric based on its bandwidth.
This document defines a standard metric type for this purpose called This document defines a standard metric-type for this purpose called
the "Bandwidth Metric". The Bandwidth Metric MAY be advertised in the "Bandwidth Metric". The Bandwidth Metric MAY be advertised in
the Generic Metric sub-TLV with the metric type set to "Bandwidth 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 Metric". IS-IS and OSPF will advertise this type of metric in their
link advertisements. The Bandwidth Metric is a link attribute and link advertisements. The Bandwidth Metric is a link attribute, and
for the advertisement and processing of this attribute for Flex- it MUST follow Section 12 of [RFC9350] for its advertisement and
Algorithm, MUST follow Section 12 of [RFC9350]. processing during Flex-Algorithm calculation.
Flex-Algorithm uses this metric type by specifying the bandwidth 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 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 an automatic computation of the bandwidth metric based on a link's
advertised bandwidth. An explicit advertisement of a link's advertised bandwidth. An explicit advertisement of a link's
bandwidth metric using the Generic Metric sub-TLV overrides this bandwidth metric using the Generic Metric sub-TLV overrides this
automatic computation. The automatic bandwidth metric calculation automatic computation. The automatic Bandwidth metric calculation
sub-TLVs are advertised in the FAD TLV, and these parameters are sub-TLVs are advertised in the FAD TLV, and these parameters are
applicable to applications such as Flex-Algorithm that make use of applicable to applications such as Flex-Algorithm that make use of
the FAD TLV. the FAD TLV.
4.1. Automatic Metric Calculation 4.1. Automatic Metric Calculation
Networks that are designed to be highly regular and that follow Networks that are designed to be highly regular and that follow
uniform metric assignment may want to simplify their operations by uniform metric assignment may want to simplify their operations by
automatically calculating the bandwidth metric. When a FAD automatically calculating the bandwidth metric. When a FAD
advertises the metric type as Bandwidth Metric and the link does not advertises the metric-type as Bandwidth Metric and the link does not
have the Bandwidth Metric advertised, automatic metric derivation can have the Bandwidth Metric advertised, automatic metric derivation can
be used with additional FAD constraint advertisement as described in be used with additional FAD constraint advertisement as described in
this section. this section.
If a link's bandwidth changes, then the delay in learning about the If a link's bandwidth changes, then the delay in learning about the
change may create the possibility of micro-loops in the topology. change may create the possibility of micro-loops in the topology.
This is no different from the IGP's susceptibility to micro-loops This is no different from the IGP's susceptibility to micro-loops
during a metric change. The micro-loop avoidance procedures during a metric change. The micro-loop avoidance procedures
described in [SR-LOOP-AVOID] or any other mechanism as described in described in [SR-LOOP-AVOID] or any other mechanism as described in
the framework [RFC5715] can be used to avoid micro-loops when the the framework [RFC5715] can be used to avoid micro-loops when the
skipping to change at line 695 skipping to change at line 698
becomes more complex in the case of parallel adjacencies. If there becomes more complex in the case of parallel adjacencies. If there
are parallel adjacencies between systems, then the bandwidth between are parallel adjacencies between systems, then the bandwidth between
the systems is the sum of the bandwidth of the parallel links. This 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 is somewhat more complex to deal with, so there is an optional mode
for computing the aggregate bandwidth. for computing the aggregate bandwidth.
4.1.1. Automatic Metric Calculation Modes 4.1.1. Automatic Metric Calculation Modes
4.1.1.1. Simple Mode 4.1.1.1. Simple Mode
In simple mode, the Maximum Link Bandwidth of a single Layer 3 link 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 is used to derive the metric. This mode is suitable for deployments
that do not use parallel Layer 3 links. In this case, the that do not use parallel Layer 3 links. In this case, the
computation of the metric is straightforward. If a Layer 3 link is 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 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 the bandwidths of the working components and may vary with Layer 2
link failures. link failures.
4.1.1.2. Interface Group Mode 4.1.1.2. Interface Group Mode
The simple mode of metric calculation may not work well when there The Simple Mode of metric calculation may not work well when there
are multiple parallel Layer 3 interfaces between two nodes. Ideally, are multiple parallel Layer 3 interfaces between two nodes. Ideally,
the metric between two systems should be the same given the same the metric between two systems should be the same given the same
bandwidth, whether the bandwidth is provided by parallel Layer 2 bandwidth, whether the bandwidth is provided by parallel Layer 2
links or parallel Layer 3 links. To address this, in Interface Group links or parallel Layer 3 links. To address this, in Interface Group
Mode, nodes MUST compute the aggregate bandwidth of all parallel Mode, nodes MUST compute the aggregate bandwidth of all parallel
adjacencies, MUST derive the metric based on the aggregate bandwidth, adjacencies, MUST derive the metric based on the aggregate bandwidth,
and MUST apply the resulting metric to each of the parallel and MUST apply the resulting metric to each of the parallel
adjacencies. Note that a single elephant flow is normally pinned to adjacencies. Note that a single elephant flow is normally pinned to
a single Layer 3 interface. If the single Layer 3 link bandwidth is a single Layer 3 interface. If the single Layer 3 link bandwidth is
not sufficient for any single elephant flow, the mechanisms to solve not sufficient for any single elephant flow, the mechanisms to solve
skipping to change at line 871 skipping to change at line 874
FADRB sub-TLV MUST NOT appear more than once in an IS-IS FAD sub-TLV. 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 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 by the receiver. The value advertised in the Reference Bandwidth
field MUST be non-zero. If a zero value is advertised in the 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 Reference Bandwidth field in the IS-IS FADRB sub-TLV, the sub-TLV
MUST be ignored. MUST be ignored.
If a Generic Metric sub-TLV with a Bandwidth metric type is If a Generic Metric sub-TLV with a Bandwidth metric type is
advertised for a link, the Flex-Algorithm calculation MUST use the advertised for a link, the Flex-Algorithm calculation MUST use the
advertised Bandwidth Metric and MUST NOT use the automatically advertised Bandwidth Metric and MUST NOT use the automatically
derived metric for that link. In case of Interface Group Mode, if derived metric for that link.
all the parallel links have been advertised with the Bandwidth
Metric, the individual link Bandwidth Metric MUST be used. If only In case of Interface Group Mode, the following rules apply to
some links among the parallel links have the Bandwidth Metric parallel links:
advertisement, the Bandwidth Metric for such links MUST be ignored,
and automatic Metric calculation MUST be used to derive link metric. * 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 If the calculated metric evaluates to zero, a metric of 1 MUST be
used. used.
If the calculated metric evaluates to a number greater than 0xFFFFFF, If the calculated metric evaluates to a number greater than 0xFFFFFF,
it is set to 0xFFFFFF. it is set to 0xFFFFFF.
4.1.3.2. Bandwidth Threshold Sub-TLV 4.1.3.2. Bandwidth Threshold Sub-TLV
This section provides FAD constraint advertisement details for the This section provides FAD constraint advertisement details for the
skipping to change at line 1025 skipping to change at line 1039
A FAD MUST NOT contain both the FADBT sub-TLV and the FADRB sub-TLV. 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 If both of these sub-TLVs are advertised in the same FAD for a
Flexible Algorithm, the FAD MUST be ignored by the receiver. Flexible Algorithm, the FAD MUST be ignored by the receiver.
If a Generic Metric sub-TLV with Bandwidth metric type is advertised If a Generic Metric sub-TLV with Bandwidth metric type is advertised
for a link, the Flex-Algorithm calculation MUST use the Bandwidth for a link, the Flex-Algorithm calculation MUST use the Bandwidth
Metric advertised on the link and MUST NOT use the automatically Metric advertised on the link and MUST NOT use the automatically
derived metric for that link. derived metric for that link.
In case of Interface Group Mode, if all the parallel links have been In case of Interface Group Mode, the following rules apply to
advertised with the Bandwidth Metric, the individual link Bandwidth parallel links:
Metric MUST be used. If only some links among the parallel links
have advertised the Bandwidth Metric, the Bandwidth Metric for such * If all the parallel links have been advertised with the Bandwidth
links MUST be ignored and automatic Metric calculation MUST be used Metric:
to derive the link 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.
4.1.4. OSPF FAD Constraint Sub-TLVs for Automatic Metric Calculation 4.1.4. OSPF FAD Constraint Sub-TLVs for Automatic Metric Calculation
4.1.4.1. Reference Bandwidth Sub-TLV 4.1.4.1. Reference Bandwidth Sub-TLV
The Flexible Algorithm Definition Reference Bandwidth (FADRB) 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: is a sub-TLV of the OSPF FAD TLV. It has the following format:
0 1 2 3 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 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
skipping to change at line 1271 skipping to change at line 1294
If a Generic Metric sub-TLV with Bandwidth metric type is advertised If a Generic Metric sub-TLV with Bandwidth metric type is advertised
for a link, the Flex-Algorithm calculation MUST use the Bandwidth for a link, the Flex-Algorithm calculation MUST use the Bandwidth
Metric advertised on the link and MUST NOT use the automatically Metric advertised on the link and MUST NOT use the automatically
derived metric for that link. derived metric for that link.
Metric Assignment in Interface Group Mode: Metric Assignment in Interface Group Mode:
When a link does not have a configured Bandwidth Metric, the When a link does not have a configured Bandwidth Metric, the
automatically derived metric MUST be used for that link. automatically derived metric MUST be used for that link.
In the context of Interface Group Mode, the following rules apply to In case of Interface Group Mode, the following rules apply to
parallel links: parallel links:
* If all parallel links have advertised the Bandwidth Metric: * If all parallel links have advertised the Bandwidth Metric:
The individual link Bandwidth Metrics MUST be used for each link The individual link Bandwidth Metric MUST be used for each link
during path computation. during path computation.
* If only some of the parallel links have advertised the Bandwidth * If only some of the parallel links have advertised the Bandwidth
Metric: Metric:
- The Bandwidth Metric advertisements for those links MUST be - The Bandwidth Metric advertisements for those links MUST be
ignored. ignored.
- Automatic metric calculation MUST be used to derive the link - Automatic metric calculation MUST be used to derive the link
metrics for all parallel links. metrics for all parallel links.
skipping to change at line 1304 skipping to change at line 1327
This section specifies the rules of deriving the Bandwidth Metric if This section specifies the rules of deriving the Bandwidth Metric if
and only if the winning FAD for the Flex-Algorithm specifies the and only if the winning FAD for the Flex-Algorithm specifies the
metric-type as "Bandwidth Metric". metric-type as "Bandwidth Metric".
1. If the Generic Metric sub-TLV with Bandwidth metric type is 1. If the Generic Metric sub-TLV with Bandwidth metric type is
advertised for the link as described in Section 4, it MUST be advertised for the link as described in Section 4, it MUST be
used during the Flex-Algorithm calculation. used during the Flex-Algorithm calculation.
2. If the Generic Metric sub-TLV with Bandwidth metric type is not 2. If the Generic Metric sub-TLV with Bandwidth metric type is not
advertised for the link and the winning FAD for the Flex- advertised for the link and the winning FAD for the Flex-
Algorithm does not specify the automatic bandwidth metric Algorithm does not specify the automatic Bandwidth metric
calculation (as defined in Section 4.1), the link is treated as calculation (as defined in Section 4.1), the link is treated as
if the Bandwidth Metric is not available for the link. if the Bandwidth Metric is not available for the link.
3. If the Generic Metric sub-TLV with Bandwidth metric type is not 3. If the Generic Metric sub-TLV with Bandwidth metric type is not
advertised for the link and the winning FAD (Section 5.3 of advertised for the link and the winning FAD (Section 5.3 of
[RFC9350]) for the Flex-Algorithm specifies the automatic [RFC9350]) for the Flex-Algorithm specifies the automatic
bandwidth metric calculation (as defined in Section 4.1), the Bandwidth metric calculation (as defined in Section 4.1), the
Bandwidth Metric MUST be automatically calculated per the Bandwidth Metric MUST be automatically calculated per the
procedures defined in Section 4.1. If the Link Bandwidth is not procedures defined in Section 4.1. If the Link Bandwidth is not
advertised for a link, the link MUST be pruned for the Flex- advertised for a link, the link MUST be pruned for the Flex-
Algorithm calculations. Algorithm calculations.
4. In ISIS, for Flex-Algorithm purposes, the Link Bandwidth is 4. In ISIS, for Flex-Algorithm purposes, the Link Bandwidth is
advertised as a sub-sub-TLV 9 of the Flex-Algorithm-specific ASLA 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 sub-TLV. It is also possible to advertise the link bandwidth or
Flex-Algorithm in sub-TLV 9 of TLV 22/222/23/223/141 [RFC5305] 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 together with the L-flag set in the Flex-Algorithm-specific ASLA
advertisement. In the absence of both of these advertisements, advertisement. In the absence of both of these advertisements,
the bandwidth of the link is not available for Flex-Algorithm the bandwidth of the link is not available for Flex-Algorithm
purposes. purposes.
6. Calculation of Flex-Algorithm Paths 6. Calculation of Flex-Algorithm Paths
The following two new additional rules are added to the existing The following two new additional rules are added to the existing
rules in the Flex-Algorithm calculations specified in Section 13 of rules in the Flex-Algorithm calculations specified in Section 13 of
[RFC9350]: [RFC9350]:
 End of changes. 46 change blocks. 
93 lines changed or deleted 116 lines changed or added

This html diff was produced by rfcdiff 1.48.