rfc9843.original   rfc9843.txt 
LSR S. Hegde Internet Engineering Task Force (IETF) S. Hegde
Internet-Draft W. Britto Request for Comments: 9843 W. Britto
Intended status: Standards Track R. Shetty Updates: 9350 R. Shetty
Expires: 17 August 2025 Juniper Networks Inc. Category: Standards Track Juniper Networks Inc.
B. Decraene ISSN: 2070-1721 B. Decraene
Orange Orange
P. Psenak P. Psenak
Cisco Systems Cisco Systems
T. Li T. Li
Juniper Networks Inc. Juniper Networks Inc.
13 February 2025 September 2025
IGP Flexible Algorithms: Bandwidth, Delay, Metrics and Constraints IGP Flexible Algorithms: Bandwidth, Delay, Metrics, and Constraints
draft-ietf-lsr-flex-algo-bw-con-22
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. High bandwidth traffic gets routed as per the link capacity, and high bandwidth traffic gets routed per the link
capacity. Flexible algorithms [RFC9350]provide mechanisms to create capacity. Flexible Algorithms provide mechanisms to create
constraint based paths in an IGP. This draft documents a generic constraint-based paths in an IGP. This specification documents a
metric type and set of bandwidth related constraints to be used in generic metric-type and a set of bandwidth-related constraints to be
Flexible Algorithms. used in Flexible Algorithms.
Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", This document updates RFC 9350.
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP
14, [RFC2119], [RFC8174] when, and only when, they appear in all
capitals, as shown here.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This is an Internet Standards Track document.
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering This document is a product of the Internet Engineering Task Force
Task Force (IETF). Note that other groups may also distribute (IETF). It represents the consensus of the IETF community. It has
working documents as Internet-Drafts. The list of current Internet- received public review and has been approved for publication by the
Drafts is at https://datatracker.ietf.org/drafts/current/. Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 7841.
Internet-Drafts are draft documents valid for a maximum of six months Information about the current status of this document, any errata,
and may be updated, replaced, or obsoleted by other documents at any and how to provide feedback on it may be obtained at
time. It is inappropriate to use Internet-Drafts as reference https://www.rfc-editor.org/info/rfc9843.
material or to cite them other than as "work in progress."
This Internet-Draft will expire on 17 August 2025.
Copyright Notice Copyright Notice
Copyright (c) 2025 IETF Trust and the persons identified as the Copyright (c) 2025 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/ Provisions Relating to IETF Documents
license-info) in effect on the date of publication of this document. (https://trustee.ietf.org/license-info) in effect on the date of
Please review these documents carefully, as they describe your rights publication of this document. Please review these documents
and restrictions with respect to this document. Code Components carefully, as they describe your rights and restrictions with respect
extracted from this document must include Revised BSD License text as to this document. Code Components extracted from this document must
described in Section 4.e of the Trust Legal Provisions and are include Revised BSD License text as described in Section 4.e of the
provided without warranty as described in the Revised BSD License. Trust Legal Provisions and are provided without warranty as described
in the Revised BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction
2. Generic Metric Advertisement . . . . . . . . . . . . . . . . 5 1.1. Requirements Language
2.1. IS-IS Generic Metric Sub-TLV . . . . . . . . . . . . . . 5 2. Generic Metric Advertisement
2.2. OSPF Generic Metric Sub-TLV . . . . . . . . . . . . . . . 7 2.1. IS-IS Generic Metric Sub-TLV
2.3. Generic Metric applicability to Flexible Algorithms 2.2. OSPF Generic Metric Sub-TLV
Multi-domain/Multi-area networks . . . . . . . . . . . . 9 2.3. Generic Metric Applicability to Flexible Algorithm
3. FAD constraint Sub-TLVs . . . . . . . . . . . . . . . . . . . 10 Multi-Domain/Multi-Area Networks
3.1. IS-IS FAD constraint Sub-TLVs . . . . . . . . . . . . . . 10 3. FAD Constraint Sub-TLVs
3.1.1. IS-IS Exclude Minimum Bandwidth sub-TLV . . . . . . . 10 3.1. IS-IS FAD Constraint Sub-TLVs
3.1.2. IS-IS Exclude Maximum Delay Sub-TLV . . . . . . . . . 11 3.1.1. IS-IS Exclude Minimum Bandwidth Sub-TLV
3.2. OSPF FAD constraint Sub-TLVs . . . . . . . . . . . . . . 12 3.1.2. IS-IS Exclude Maximum Delay Sub-TLV
3.2.1. OSPF Exclude Minimum Bandwidth Sub-TLV . . . . . . . 13 3.2. OSPF FAD Constraint Sub-TLVs
3.2.2. OSPF Exclude Maximum Delay Sub-TLV . . . . . . . . . 14 3.2.1. OSPF Exclude Minimum Bandwidth Sub-TLV
4. Bandwidth Metric Advertisement . . . . . . . . . . . . . . . 15 3.2.2. OSPF Exclude Maximum Delay Sub-TLV
4.1. Automatic Metric Calculation . . . . . . . . . . . . . . 15 4. Bandwidth Metric Advertisement
4.1.1. Automatic Metric Calculation Modes . . . . . . . . . 16 4.1. Automatic Metric Calculation
4.1.2. Automatic Metric Calculation Methods . . . . . . . . 17 4.1.1. Automatic Metric Calculation Modes
4.1.3. IS-IS FAD constraint Sub-TLVs for automatic metric 4.1.2. Automatic Metric Calculation Methods
calculation . . . . . . . . . . . . . . . . . . . . . 18 4.1.3. IS-IS FAD Constraint Sub-TLVs for Automatic Metric
4.1.4. OSPF FAD constraint Sub-TLVs for automatic metric Calculation
calculation . . . . . . . . . . . . . . . . . . . . . 23 4.1.4. OSPF FAD Constraint Sub-TLVs for Automatic Metric
5. Bandwidth metric considerations . . . . . . . . . . . . . . . 29 Calculation
6. Calculation of Flex-Algorithm paths . . . . . . . . . . . . . 29 5. Bandwidth Metric Considerations
7. Backward Compatibility . . . . . . . . . . . . . . . . . . . 30 6. Calculation of Flex-Algorithm Paths
8. Security Considerations . . . . . . . . . . . . . . . . . . . 30 7. Backward Compatibility
9. Operational Considerations . . . . . . . . . . . . . . . . . 30 8. Security Considerations
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 31 9. Operational Considerations
10.1. IGP Metric-Type Registry . . . . . . . . . . . . . . . . 31 10. IANA Considerations
10.1. IGP Metric-Type Registry
10.2. IS-IS Sub-Sub-TLVs for Flexible Algorithm Definition 10.2. IS-IS Sub-Sub-TLVs for Flexible Algorithm Definition
Sub-TLV . . . . . . . . . . . . . . . . . . . . . . . . 31 Sub-TLV
10.3. OSPF Sub-TLVs for Flexible Algorithm Definition Sub-TLV
10.3. OSPF Sub-TLVs for Flexible Algorithm Definition 10.4. IS-IS Sub-TLVs for TLVs Advertising Neighbor Information
Sub-TLV . . . . . . . . . . . . . . . . . . . . . . . . 32 10.5. Sub-Sub-TLV Codepoints for Application-Specific Link
10.4. IS-IS Sub-TLVs for TLVs Advertising Neighbor Attributes
Information . . . . . . . . . . . . . . . . . . . . . . 33 10.6. OSPFv2 Extended Link TLV Sub-TLVs
10.5. Sub-sub-TLV Codepoints for Application-Specific Link 10.7. Types for Sub-TLVs of TE Link TLV (Value 2)
Attributes . . . . . . . . . . . . . . . . . . . . . . . 33 10.8. OSPFv3 Extended-LSA Sub-TLVs
10.6. OSPFv2 Extended Link TLV Sub-TLVs . . . . . . . . . . . 33 11. References
10.7. Types for Sub-TLVs of TE Link TLV (Value 2) . . . . . . 33 11.1. Normative References
10.8. OSPFv3 Extended-LSA Sub-TLVs . . . . . . . . . . . . . . 34 11.2. Informative References
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 34 Appendix A. Updated List of Rules for Pruning Links in
12. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 34 Flex-Algorithm Topology
13. APPENDIX . . . . . . . . . . . . . . . . . . . . . . . . . . 34 Acknowledgements
13.1. Updated list of rules for pruning links in Flex-algorithm Contributors
topology . . . . . . . . . . . . . . . . . . . . . . . . 34 Authors' Addresses
14. References . . . . . . . . . . . . . . . . . . . . . . . . . 35
14.1. Normative References . . . . . . . . . . . . . . . . . . 35
14.2. Informative References . . . . . . . . . . . . . . . . . 37
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 38
1. Introduction 1. Introduction
High bandwidth traffic such as residential Internet traffic and High bandwidth traffic such as residential Internet traffic and
machine-to-machine elephant flows benefit from using high capacity machine-to-machine elephant flows benefit from using high capacity
links. Accordingly, many network operators define a link's metric links. Accordingly, many network operators define a link's metric
relative to its capacity to help direct traffic to higher bandwidth relative to its capacity to help direct traffic to higher bandwidth
links, but this is no guarantee that lower bandwidth links will be links, but this is no guarantee that lower bandwidth links will be
avoided, especially in failure scenarios. To ensure that elephant avoided, especially in failure scenarios. To ensure that elephant
flows are only placed on high capacity links, it would be useful to flows are only placed on high capacity links, it would be useful to
explicitly exclude the high throughput traffic from utilizing links explicitly exclude the high throughput traffic from utilizing links
below a certain capacity. Flex-Algorithm [RFC9350] provides a below a certain capacity. Flex-Algorithm [RFC9350] provides a
mechanism to create constrained paths by defining a set of parameters mechanism to create constrained paths by defining a set of parameters
consisting of calculation-type, metric-type, and a set of consisting of calculation-type, metric-type, and a set of
constraints. In this document, we define further extensions to Flex- constraints. In this document, we define further extensions to the
Algorithm Definition (FAD) that will allow operators additional Flexible Algorithm Definition (FAD) that will allow operators
control over their traffic flows, especially with respect to additional control over their traffic flows, especially with respect
bandwidth constraints. to bandwidth constraints.
Historically, IGPs have done path computation by minimizing the sum Historically, IGPs have done path computation by minimizing the sum
of the link metrics along the path from source to destination. While of the link metrics along the path from source to destination. While
the metric has been administratively defined, implementations have the metric has been administratively defined, implementations have
defaulted to a metric that is inversely proportional to link defaulted to a metric that is inversely proportional to link
bandwidth. This has driven traffic to higher bandwidth links and has bandwidth. This has driven traffic to higher bandwidth links and has
required manual metric manipulation to achieve the desired loading of required manual metric manipulation to achieve the desired loading of
the network. the network.
Over time, with the addition of different traffic types, the need for Over time, with the addition of different traffic types, the need for
skipping to change at page 4, line 17 skipping to change at line 147
operational costs and thus may want a metric that reflects the actual operational costs and thus may want a metric that reflects the actual
fiscal costs of using a link. Other traffic may require low jitter, fiscal costs of using a link. Other traffic may require low jitter,
leading to an entirely different set of metrics. With Flex- leading to an entirely different set of metrics. With Flex-
Algorithm, all of these different metrics, and more, could be used Algorithm, all of these different metrics, and more, could be used
concurrently on the same network. concurrently on the same network.
In some circumstances, path computation constraints, such as In some circumstances, path computation constraints, such as
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. If, however, 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 which have specific semantics and introduces 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 Section 3 defines additional FAD [RFC9350] constraints that allow the
network administrator to preclude the use of low bandwidth links or
high delay links. Section 4 specifies a new bandwidth-based metric-
type to be used with Flex-Algorithm and other applications. type to be used with Flex-Algorithm and other applications.
Section 3 defines additional Flexible Algorithm Definition (FAD)
[RFC9350] constraints that allow the network administrator to
preclude the use of low bandwidth links or high delay links.
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
are not a replacement to the capability of a PCE [RFC4655] which has are not a replacement to the capability of a PCE [RFC4655], which has
a dynamic view of the network and provides real-time bandwidth a dynamic view of the network and provides real-time bandwidth
management or a distributed bandwidth management protocol. management or a distributed bandwidth management protocol.
1.1. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in
BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
2. Generic Metric Advertisement 2. Generic Metric Advertisement
IS-IS [RFC1195]and OSPF [RFC2328] advertise a metric for each link in IS-IS [RFC1195] and OSPF [RFC2328] advertise a metric for each link
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 is assigned by the and a value for the metric. The metric-type field has been assigned
"IGP Metric-Type" IANA registry. Metric types 0-127 are standard in the "IGP Metric-Type" IANA registry. Metric-types 0-127 are
metric types as assigned by IANA. This document further specifies a standard metric-types as assigned by IANA. This document further
user-defined metric type space of metric types 128-255. These are specifies a user-defined metric-type space of metric-types 128-255.
user defined and can be assigned by an operator for local use. They can be assigned by an operator for local 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)" (shareable among bundle members)
The Generic Metric sub-TLV, type TBD1 (IANA), and is six octets in g. TLV 25 (L2 Bundle Member Attributes) [RFC8668]. Marked as "y(s)"
length. (shareable among bundle members).
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | metric-type | | Type | Length | metric-type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value | | Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type (1 octet): Figure 1: IS-IS Generic Metric Sub-TLV
An 8-bit field assigned by IANA (To Be Determined as TBD1).
This value uniquely identifies the Generic Metric TLV.
Length (1 octet): where:
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): Type (1 octet):
An 8-bit field specifying the type of metric. An 8-bit field assigned by IANA (17). This value uniquely
The value is taken from the "IGP Metric-Type" identifies the Generic Metric TLV.
registry maintained by IANA. The metric type may
be any value which is indicated as allowed
in the generic metric sub-TLV by the
IGP Metric-Type Registry.
Value (3 octets): Length (1 octet):
A 24-bit unsigned integer representing the metric value. An 8-bit field indicating the total length, in octets, of the
The valid range is from 0 to 16,777,215 (0xFFFFFF). subsequent fields. For this TLV, the Length is set to 4.
Figure 1: IS-IS Generic Metric Sub-TLV 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 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 141. only once for a link when advertised in TLVs 22, 222, 23, 223, and
When Generic metric sub-TLV is advertised in ASLA, each metric type 141. When the Generic Metric sub-TLV is advertised in ASLA, each
MUST be advertised only once per-application for a link. If there metric-type MUST be advertised only once per-application for a link.
are multiple Generic Metric sub-TLVs advertised for a link for the If there are multiple Generic Metric sub-TLVs advertised for a link
same metric type (and same application in case of ASLA) in one or for the same metric-type (and the same application in case of ASLA)
more received LSPDUs, advertisement in the lowest numbered fragment in one or more received Link State Protocol Data Units (LSPDUs),
MUST be used and the subsequent instances MUST be ignored. 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 For a link, if the metric-type corresponds to a metric-type for which
legacy advertisement mechanisms exist (e.g., the IGP metric, the legacy advertisement mechanisms exist (e.g., the IGP Metric, the Min
Minimum 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 as 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 sec 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 c. sub-TLV of TE Link TLV (type 2) of OSPFv3 Intra-Area-TE-LSA
[RFC5329]. [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].
h. sub-TLV of the OSPFv3 L2 Bundle Member Attributes sub-TLV h. sub-TLV of the OSPFv3 L2 Bundle Member Attributes sub-TLV
[RFC9356]. [RFC9356].
The Generic Metric sub-TLV, type TBD21/TBD22/TB23 (IANA), and is The Generic Metric sub-TLV, types 25/36/34, is 8 octets in length.
eight 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | | Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| metric-type | Reserved (MBZ) | | metric-type | Reserved (MBZ) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value | | Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type (2 octets): Figure 2: OSPF Generic Metric Sub-TLV
A 16-bit field assigned by IANA (To Be Determined as TBD21/TBD22/TBD23).
This value uniquely identifies the Generic Metric TLV.
Length (2 octets): where:
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): Type (2 octets):
An 8-bit field specifying the type of metric. A 16-bit field assigned by IANA (25/36/34). This value uniquely
The value is taken from the "IGP Metric-Type" identifies the Generic Metric TLV.
registry maintained by IANA. The metric type
may be any value which is indicated as allowed
in the generic metric sub-TLV by the
IGP Metric-Type Registry.
Reserved (3 octets): Length (2 octets):
Must set to zero by sender and A 16-bit field indicating the total length, in octets, of the
must be ignored by receiver. subsequent fields. For this TLV, the Length is set to 8.
Value (4 octets): Metric-Type (1 octet):
A 32-bit unsigned integer representing the metric value. An 8-bit field specifying the type of metric. The value is taken
The valid range is from 0 to 4,294,967,295(0xFFFFFFFF). 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.
Figure 2: OSPF Generic Metric Sub-TLV Reserved (3 octets):
MUST set to zero by the sender and MUST be ignored by the
receiver.
Value (4 octets):
A 32-bit unsigned integer 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 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
Generic Metric sub-TLV is advertised as sub-TLV of ASLA, it MUST be the Generic Metric sub-TLV is advertised as a sub-TLV of ASLA, it
advertised only once per-application for a link. If there are MUST be advertised only once per application for a link. If there
multiple Generic Metric sub-TLVs advertised for a link for the same are multiple Generic Metric sub-TLVs advertised for a link for the
metric type (and same application in case of ASLA) in one or more same metric-type (and the same application in case of ASLA) in one or
received LSAs, advertisement in the lowest numbered LSA MUST be used more received LSAs, advertisement in the lowest-numbered LSA MUST be
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 legacy advertisement mechanisms exist (e.g., the IGP Metric, the Min
Minimum 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 as 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 sec 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 Algorithms 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-Algorithms by specifying the Generic Metric can be used by Flex-Algorithm by specifying the
metric type in the Flexible Algorithm Definitions. When Flex- metric-type in the Flexible Algorithm Definitions. When Flex-
Algorithms is used in a multi-area network, [RFC9350] defines the Algorithm is used in a multi-area network, [RFC9350] defines the
Flexible Algorithm Prefix Metric (FAPM) sub-TLV that carries the Flexible Algorithm Prefix Metric (FAPM) sub-TLV that carries the
Flexible-Algorithm-specific metric. Metrics carried in FAPM will be Flexible-Algorithm-specific metric. Metrics carried in FAPM will be
equal to the metric to reach the prefix for that Flex-Algorithm in equal to the metric to reach the prefix for that Flex-Algorithm in
its source area or domain (source area from the ABR perspective). its source area or domain (source area from the Area Border Router
When Flex-Algorithm uses Generic metric, the same procedures as (ABR) perspective). When Flex-Algorithm uses Generic Metric, the
described in section 13 of [RFC9350] are used to send and process same procedures as described in Section 13 of [RFC9350] are used to
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 (LAG/layer-2 Bundle), of administrative groups. However, when a Layer 3 link is actually a
the link bandwidth will vary based on the set of active constituent collection of Layer 2 links (Link Aggregation Group (LAG) / Layer 2
links. This could be automated by having an implementation vary the Bundle), the link bandwidth will vary based on the set of active
advertised administrative groups based on bandwidth, but this seems constituent links. This could be automated by having an
unnecessarily complex and expressing this requirement as a direct implementation vary the advertised administrative groups based on
constraint on the topology seems simpler. This is also advantageous bandwidth, but this seems unnecessarily complex and expressing this
if the minimum required bandwidth changes, as this constraint would requirement as a direct constraint on the topology seems simpler.
provide a single centralized, coordinated point of control. 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 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 value is below the FAD advertised
Bandwidth value. minimum 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
delay variability, such as those with transparent Layer 2 link delay variability, such as those with transparent Layer 2 link
recovery mechanisms or satellite links.". Mechanisms already exist recovery mechanisms or satellite links. Mechanisms already exist to
to measure the link delay dynamically and advertise it in the IGP. measure the link delay dynamically and advertise it in the IGP.
Networks that employ dynamic link-delay measurement, may want to Networks that employ dynamic link-delay measurement, may want to
exclude links that have a delay over a given threshold. exclude links that have a delay over a given threshold.
3.1. IS-IS FAD constraint Sub-TLVs 3.1. IS-IS FAD Constraint Sub-TLVs
3.1.1. IS-IS Exclude Minimum Bandwidth sub-TLV 3.1.1. IS-IS Exclude Minimum Bandwidth Sub-TLV
IS-IS Flex-Algorithm Exclude Minimum Bandwidth sub-TLV (FAEMB) is a 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: sub-TLV of the IS-IS FAD sub-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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | | Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Min Bandwidth | | Min Bandwidth |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: IS-IS FAEMB Sub-TLV
where: where:
Type (1 octet): Type (1 octet):
An 8-bit field assigned by IANA (To Be Determined as TBD3). An 8-bit field assigned by IANA (6). This value uniquely
This value uniquely identifies the FAEMB sub-TLV. identifies the FAEMB sub-TLV.
Length (1 octet): Length (1 octet):
An 8-bit field indicating the total length, in octets, An 8-bit field indicating the total length, in octets, of the
of the subsequent fields. For this sub-TLV, the Length is set to 4. subsequent fields. For this sub-TLV, the Length is set to 4.
Min Bandwidth (4 octets): Min Bandwidth (4 octets):
A 32-bit field specifying the link bandwidth encoded in IEEE A 32-bit field specifying the link bandwidth encoded in IEEE
floating point format (32 bits)[IEEE754-2019]. floating point format (32 bits) [IEEE754-2019]. The units are
The units are bytes-per-second. bytes per second.
Figure 3: IS-IS FAEMB Sub-TLV
The FAEMB sub-TLV MUST appear at most once 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 FAEMB sub-TLV MUST be compared The minimum bandwidth value advertised in the FAEMB sub-TLV MUST be
with Maximum Link Bandwidth advertised in sub-sub-TLV 9 of ASLA sub- compared with maximum link bandwidth value advertised in sub-sub-TLV
TLV [RFC9479]. If L-Flag is set in the ASLA sub-TLV, the Minimum 9 of the ASLA sub-TLV [RFC9479]. If the L-flag is set in the ASLA
bandwidth advertised in FAEMB sub-TLV MUST be compared with Maximum sub-TLV, the minimum bandwidth value advertised in the FAEMB sub-TLV
Link Bandwidth as advertised in the sub-TLV 9 of the TLV MUST be compared with the maximum link bandwidth value as advertised
22/222/23/223/141 [RFC5305] as defined in [RFC9479] Section 4.2. in the sub-TLV 9 of the TLVs 22/222/23/223/141 [RFC5305], as defined
in Section 4.2 of [RFC9479].
If the Maximum Link Bandwidth is lower than the Minimum link If the maximum link bandwidth value is lower than the minimum link
bandwidth advertised in FAEMB sub-TLV, the link MUST be excluded from bandwidth value advertised in the FAEMB sub-TLV, the link MUST be
the Flex-Algorithm topology. If a link does not have the Maximum excluded from the Flex-Algorithm topology. If a link does not have
Link Bandwidth advertised but the FAD contains this sub-TLV, then the Maximum Link Bandwidth advertised but the FAD contains the FAEMB
that link MUST NOT be excluded from the topology based on the Minimum sub-TLV, then that link MUST NOT be excluded from the topology based
Bandwidth constraint. on the Minimum Bandwidth constraint.
3.1.2. IS-IS Exclude Maximum Delay Sub-TLV 3.1.2. IS-IS Exclude Maximum Delay Sub-TLV
IS-IS Flex-Algorithm Exclude Maximum Delay sub-TLV (FAEMD) is a sub- 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. TLV of the IS-IS FAD sub-TLV. It has the following format:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Max Link Delay |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: 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: where:
Type (1 octet): Type (1 octet):
An 8-bit field assigned by IANA (To Be Determined as TBD4). An 8-bit field assigned by IANA (7). This value uniquely
This value uniquely identifies the FAEMD sub-TLV. identifies the FAEMD sub-TLV.
Length (1 octet): Length (1 octet):
An 8-bit field indicating the total length, in octets, An 8-bit field indicating the total length, in octets, of the
of the subsequent fields. For this sub-TLV, the Length is set to 3. subsequent fields. For this sub-TLV, the Length is set to 3.
Max link delay (3 octets): Max Link Delay (3 octets):
A 24-bit field specifying the Maximum link delay in microseconds. A 24-bit field specifying the Maximum link delay in microseconds.
Figure 4: IS-IS FAEMD Sub-TLV
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 FAEMD sub-TLV MUST be compared The maximum link delay value advertised in the FAEMD sub-TLV MUST be
with Min Unidirectional Link Delay advertised in sub-sub-TLV 34 of compared with Min Unidirectional Link Delay advertised in sub-sub-TLV
ASLA sub-TLV [RFC9479]. If the L-Flag is set in the ASLA sub-TLV, 34 of the ASLA sub-TLV [RFC9479]. If the L-flag is set in the ASLA
the Maximum link delay advertised in FAEMD sub-TLV MUST be compared sub-TLV, the maximum link delay value advertised in the FAEMD sub-TLV
with Min Unidirectional Link Delay as advertised by the sub-TLV 34 of MUST be compared with Min Unidirectional Link Delay as advertised by
the TLV 22/222/23/223/141 [RFC8570] as defined in [RFC9479] the sub-TLV 34 of the TLVs 22/222/23/223/141 [RFC8570], as defined in
Section 4.2. 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 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 the FAEMD
TLV, then that link MUST NOT be excluded from the topology based on sub-TLV, then that link MUST NOT be excluded from the topology based
the Maximum Delay constraint. on the Maximum Delay constraint.
3.2. OSPF FAD Constraint Sub-TLVs
3.2. OSPF FAD constraint Sub-TLVs
3.2.1. OSPF Exclude Minimum Bandwidth Sub-TLV 3.2.1. OSPF Exclude Minimum Bandwidth Sub-TLV
OSPF Flex-Algorithm Exclude Minimum Bandwidth sub-TLV (FAEMB) is a OSPF Flex-Algorithm Exclude Minimum Bandwidth (FAEMB) sub-TLV is a
sub-TLV of the OSPF FAD TLV. It has the following format: 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | | Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Min Bandwidth | | Min Bandwidth |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
where:
Type (2 octets): Figure 5: OSPF FAEMB Sub-TLV
A 16-bit field assigned by IANA (To Be Determined as TBD5).
This value uniquely identifies the OSPF FAEMB sub-TLV.
Length (2 octets): where:
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): Type (2 octets):
A 32-bit field specifying the link bandwidth encoded in A 16-bit field assigned by IANA (6). This value uniquely
IEEE floating point format (32 bits)[IEEE754-2019]. identifies the OSPF FAEMB sub-TLV.
The units are bytes-per-second.
Figure 5: 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)[IEEE754-2019]. The units are
bytes per second.
The FAEMB sub-TLV MUST only appear once in the FAD sub-TLV. If it 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 appears more than once, the OSPF FAD TLV MUST be ignored by the
receiver. receiver.
The Maximum Link Bandwidth as advertised in the Extended Link TLV in The Maximum Link Bandwidth as advertised in the Extended Link TLV in
the Extended Link Opaque LSA in OSPFv2 [RFC7684] or as a sub-TLV of the Extended Link Opaque LSA in OSPFv2 [RFC7684] or as a sub-TLV of
the Router-Link TLV of the E-Router-LSA Router-Link TLV in OSPFv3 the Router-Link TLV of the E-Router-LSA Router-Link TLV in OSPFv3
[RFC8362] MUST be compared against the Minimum bandwidth advertised [RFC8362] MUST be compared against the Minimum Bandwidth advertised
in FAEMB sub-TLV. If the link bandwidth is lower than the Minimum in the FAEMB sub-TLV. If the link bandwidth value is lower than the
bandwidth advertised in FAEMB sub-TLV, the link MUST be excluded from Minimum Bandwidth advertised in the FAEMB sub-TLV, the link MUST be
the Flex-Algorithm topology. excluded from the Flex-Algorithm topology.
If a link does not have the Maximum Link Bandwidth advertised but the If a link does not have the Maximum Link Bandwidth advertised but the
FAD contains this sub-TLV, then that link MUST be included in the FAD contains the FAEMB sub-TLV, then that link MUST be included in
topology and proceed to apply further pruning rules for the link. the topology and proceed to apply further pruning rules for the link.
3.2.2. OSPF Exclude Maximum Delay Sub-TLV 3.2.2. OSPF Exclude Maximum Delay Sub-TLV
The OSPF Flex-Algorithm Exclude Maximum Delay sub-TLV (FAEMD) is a The OSPF Flex-Algorithm Exclude Maximum Delay (FAEMD) sub-TLV is a
sub-TLV of the OSPF FAD TLV. It has the following format. 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | | Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RESERVED | Max link Delay | | RESERVED | Max Link Delay |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6: OSPF FAEMD Sub-TLV
where: where:
Type (2 octets): Type (2 octets):
A 16-bit field assigned by IANA (To Be Determined as TBD6). A 16-bit field assigned by IANA (7). This value uniquely
This value uniquely identifies the OSPF FAEMD sub-TLV. identifies the OSPF FAEMD sub-TLV.
Length (2 octets): Length (2 octets):
A 16-bit field indicating the total length, in octets, A 16-bit field indicating the total length, in octets, of the
of the subsequent fields. For this sub-TLV, the Length is set to 4. subsequent fields. For this sub-TLV, the Length is set to 4.
Reserved (1 octet): Reserved (1 octet):
Must set to zero by sender and MUST be set to zero by the sender and MUST be ignored by the
must be ignored by receiver. receiver.
Max link delay (3 octets): Max Link Delay (3 octets):
A 24-bit field specifying the Maximum link delay in microseconds. A 24-bit field specifying the Maximum link delay in microseconds.
Figure 6: OSPF FAEMD Sub-TLV
The FAEMD sub-TLV MUST only appear once in the OSPF FAD TLV. If it 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 appears more than once, the OSPF FAD TLV MUST be ignored by the
receiver. receiver.
The Min Delay value advertised via the Min/Max Unidirectional Link The Min Delay value advertised via the Min/Max Unidirectional Link
Delay of ASLA sub-TLV [RFC9492], MUST be compared against the Maximum Delay of the ASLA sub-TLV [RFC9492] MUST be compared against the
delay advertised in the FAEMD sub-TLV. If the Min Unidirectional Maximum Delay advertised in the FAEMD sub-TLV. If the Min
Link Delay is higher than the Maximum delay advertised in the FAEMD Unidirectional Link Delay is higher than the Maximum Delay advertised
sub-TLV, the link MUST be excluded from the Flex-Algorithm topology. in the FAEMD sub-TLV, the link MUST be excluded from the Flex-
If the Min/Max Unidirectional Link Delay is not advertised for a link Algorithm topology. If the Min/Max Unidirectional Link Delay is not
but the FAD contains this sub-TLV,then then that link MUST NOT be advertised for a link but the FAD contains this sub-TLV, then that
excluded from the topology based on the Maximum Delay constraint. link MUST NOT be excluded from the topology based on the Maximum
Delay constraint.
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. Bandwidth metric is a link attribute and for link advertisements. The Bandwidth Metric is a link attribute, and
the advertisement and processing of this attribute for Flex- it MUST follow Section 12 of [RFC9350] for its advertisement and
algorithm, MUST follow the 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 which are designed to be highly regular and follow uniform Networks that are designed to be highly regular and that follow
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 [I-D.bashandy-rtgwg-segment-routing-uloop] or any other described in [SR-LOOP-AVOID] or any other mechanism as described in
mechanism as described in the framework [RFC5715] can be used to the framework [RFC5715] can be used to avoid micro-loops when the
avoid micro-loops when the automatic metric calculation is deployed. automatic metric calculation is deployed.
Computing the metric between adjacent systems based on bandwidth Computing the metric between adjacent systems based on bandwidth
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
this issue are outside the scope of this document. this issue are outside the scope of this document.
A------B====C====F====D A------B====C====F====D
| | | |
------E------- ------E-------
Figure 7: Parallel interfaces Figure 7: Parallel Interfaces
For example, in the above diagram, there are two parallel links 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 between B->C, C->F, F->D. Let us assume the link bandwidth is
uniform 10Gbps on all links. When bandwidth is used to derive the 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. metric for the links, the metric for each link will be the same.
Traffic from B to D will be forwarded B->E->D as the metric will be Traffic from B to D will be forwarded as B->E->D because the metric
lower. Since the bandwidth is higher on the B->C->F->D path, the will be lower. Since the bandwidth is higher on the B->C->F->D path,
metric for that path should be lower than the B->E->D path to attract the metric for that path should be lower than the B->E->D path to
the traffic on B->C->F->D path. Interface Group Mode should be attract the traffic on the B->C->F->D path. Interface Group Mode
preferred in cases where there are parallel layer-3 links. should be preferred in cases where there are parallel Layer 3 links.
In the interface group mode, every node MUST identify the set of In the Interface Group Mode, every node MUST identify the set of
parallel links between a pair of nodes based on IGP link parallel links between a pair of nodes based on IGP link
advertisements and MUST consider cumulative bandwidth of the parallel advertisements and MUST consider cumulative bandwidth of the parallel
links while arriving at the metric of each link. links while arriving at the metric of each link.
The parallel layer-3 links between two nodes may not have the same The parallel Layer 3 links between two nodes may not have the same
bandwidth. In such cases the method described in interface group bandwidth. In such cases, the method described in Interface Group
mode will result in same metric being used for all the parallel links Mode will result in the same metric being used for all the parallel
which may cause undesired load-balancing on the links. In such links, which may cause undesired load balancing on the links. In
cases, a device may locally apply load-balancing factor relative to such cases, a device may locally apply a load-balancing factor
the link bandwidth on the ECMP nexthops. The load-balancing relative to the link bandwidth on the ECMP next hops. The load-
mechanisms are outside the scope of this document. balancing mechanisms are outside the scope of this document.
4.1.2. Automatic Metric Calculation Methods 4.1.2. Automatic Metric Calculation Methods
In automatic metric calculation for simple and interface group mode, In automatic metric calculation for simple and Interface Group Mode,
Maximum Link Bandwidth of the links is used to derive the metric. Maximum Link Bandwidth of the links is used to derive the metric.
There are two types of automatic metric derivation methods. There are two types of automatic metric derivation methods.
1. Reference bandwidth method 1. Reference bandwidth method
2. Bandwidth thresholds method 2. Bandwidth thresholds method
4.1.2.1. Reference Bandwidth method 4.1.2.1. Reference Bandwidth Method
In many networks, the metric is inversely proportional to the link In many networks, the metric is inversely proportional to the link
bandwidth. The administrator or implementation selects a reference bandwidth. The administrator or implementation selects a reference
bandwidth and the metric is derived by dividing the reference bandwidth and the metric is derived by dividing the reference
bandwidth by the advertised Maximum Link Bandwidth. Advertising the bandwidth by the advertised Maximum Link Bandwidth. Advertising the
reference bandwidth in the FAD constraints allows the metric reference bandwidth in the FAD constraints allows the metric
computation to be done on every node for each link. The metric is computation to be done on every node for each link. The metric is
computed using reference bandwidth and the advertised link bandwidth. computed using reference bandwidth and the advertised link bandwidth.
Centralized control of this reference bandwidth simplifies management Centralized control of this reference bandwidth simplifies management
in the case that the reference bandwidth changes. In order to ensure in the case where the reference bandwidth changes. In order to
that small bandwidth changes do not change the link metric, it is ensure that small bandwidth changes do not change the link metric, it
useful to define the granularity of the bandwidth that is of is useful to define the granularity of the bandwidth that is of
interest. The link bandwidth will be truncated to this granularity interest. The link bandwidth will be truncated to this granularity
before deriving the metric. before deriving the metric.
For example, For example,
reference bandwidth = 1000G reference bandwidth = 1000G
Granularity = 20G Granularity = 20G
The derived metric is 10 for link bandwidth in the range 100G to The derived metric is 10 for link bandwidth in the range 100G to
119G 119G
4.1.2.2. Bandwidth Thresholds method 4.1.2.2. Bandwidth Thresholds Method
The reference bandwidth approach described above provides a uniform The reference bandwidth approach described above provides a uniform
metric value for a range of link bandwidths. In certain cases there metric value for a range of link bandwidths. In certain cases, there
may be a need to define non-proportional metric values for the may be a need to define non-proportional metric values for the
varying ranges of link bandwidth. For example, bandwidths from 10G varying ranges of link bandwidth. For example, bandwidths from 10G
to 30G are assigned metric value 100, bandwidth from 30G to 70G get a to 30G are assigned metric value 100, bandwidth from 30G to 70G are
metric value of 50, and bandwidths greater than 70G have a metric of assigned a metric value of 50, and bandwidths greater than 70G have a
10. In order to support this, a staircase mapping based on bandwidth metric of 10. In order to support this, a staircase mapping based on
thresholds is supported in the FAD. This advertisement contains a bandwidth thresholds is supported in the FAD. This advertisement
set of threshold values and associated metrics. contains a set of threshold values and associated metrics.
4.1.3. IS-IS FAD constraint Sub-TLVs for automatic metric calculation 4.1.3. IS-IS FAD Constraint Sub-TLVs for Automatic Metric Calculation
4.1.3.1. Reference Bandwidth Sub-TLV 4.1.3.1. Reference Bandwidth Sub-TLV
This section provides FAD constraint advertisement details for the This section provides FAD constraint advertisement details for the
reference bandwidth method of metric calculation as described in reference bandwidth method of metric calculation, as described in
Section 4.1.2.1. The Flexible Algorithm Definition Reference Section 4.1.2.1. The Flexible Algorithm Definition Reference
Bandwidth sub-TLV (FADRB sub-TLV) is a sub-TLV of the IS-IS FAD sub- Bandwidth (FADRB) sub-TLV is a sub-TLV of the IS-IS FAD sub-TLV. It
TLV. It has the following format: 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Flags | | Type | Length | Flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reference Bandwidth | | Reference Bandwidth |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Granularity Bandwidth | | Granularity Bandwidth |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 8: IS-IS FADRB Sub-TLV
where: where:
Type (1 octet): Type (1 octet):
An 8-bit field assigned by IANA (To Be Determined as TBD7). An 8-bit field assigned by IANA (8). This value uniquely
This value uniquely identifies the IS-IS FADRB sub-TLV. identifies the IS-IS FADRB sub-TLV.
Length (1 octet): Length (1 octet):
An 8-bit field indicating the total length, in octets, An 8-bit field indicating the total length, in octets, of the
of the subsequent fields. For this sub-TLV, the Length is set to 9. subsequent fields. For this sub-TLV, the Length is set to 9.
Flags (1 octet): Flags (1 octet):
An 8-bit field containing flags. An 8-bit field containing flags.
0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
|G| | |G| |
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
G-flag: When set, Interface Group Mode MUST be used to G-flag:
derive total link bandwidth. When set, Interface Group Mode MUST be used to derive total link
Unassigned bits MUST be set to zero. bandwidth. Unassigned bits MUST be set to zero and MUST be
ignored by the receiver.
Reference Bandwidth (4 octets): Reference Bandwidth (4 octets):
A 32-bit field with Bandwidth encoded in A 32-bit field with Bandwidth encoded in IEEE floating point
IEEE floating point format [IEEE754-2019]. format [IEEE754-2019]. The units are bytes per second.
The units are bytes-per-second.
Granularity Bandwidth (4 octets): Granularity Bandwidth (4 octets):
A 32-bit field with Bandwidth encoded in A 32-bit field with Bandwidth encoded in IEEE floating point
IEEE floating point format [IEEE754-2019]. format [IEEE754-2019]. The units are bytes per second.
The units are bytes-per-second.
When granularity_bw is less than or equal to Total_link_bandwidth When granularity_bw is less than or equal to Total_link_bandwidth,
then:
Metric calculation: (Reference_bandwidth) / Metric calculation: (Reference_bandwidth) / (Total_link_bandwidth -
(Total_link_bandwidth - (Modulus of(Total_link_bandwidth, granularity_bw)))
(Modulus of(Total_link_bandwidth,
granularity_bw)))
When granularity_bw is greater than Total_link_bandwidth When granularity_bw is greater than Total_link_bandwidth, then:
Metric calculation: Reference_bandwidth /
Total_link_bandwidth
The division used here is integer division. Metric calculation: Reference_bandwidth / Total_link_bandwidth
Modulus of operation is defined as a remainder
value when two numbers are divided.
Figure 8: IS-IS FADRB Sub-TLV 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 The Granularity Bandwidth value ensures that the metric does not
change when there is a small change in the link bandwidth. The IS-IS 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. 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 Bandwidth metric type is advertised If a Generic Metric sub-TLV with a Bandwidth metric-type is
for a link, the Flex-Algorithm calculation MUST use the advertised advertised for a link, the Flex-Algorithm calculation MUST use the
Bandwidth Metric, and MUST NOT use the automatically derived metric advertised Bandwidth Metric and MUST NOT use the automatically
for that link. In case of Interface Group Mode, if all the parallel derived metric for that link.
links have been advertised with the Bandwidth Metric, The individual
link Bandwidth Metric MUST be used. If only some links among the In case of Interface Group Mode, the following rules apply to
parallel links have the Bandwidth Metric advertisement, the Bandwidth parallel links:
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 Thresholds 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
Bandwidth Thresholds method of metric calculation as described in Bandwidth Thresholds method of metric calculation as described in
Section 4.1.2.2. The Flexible Algorithm Definition Bandwidth Section 4.1.2.2. The Flexible Algorithm Definition Bandwidth
Threshold sub-TLV (FADBT sub-TLV) is a sub-TLV of the IS-IS FAD sub- Threshold (FADBT) sub-TLV is a sub-TLV of the IS-IS FAD sub-TLV. It
TLV. It has the following format: 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Flags | | Type | Length | Flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Bandwidth Threshold 1 | | Bandwidth Threshold 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Threshold Metric 1 | | Threshold Metric 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 21, line 13 skipping to change at line 928
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
..... .....
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Threshold Metric N-1 | | Threshold Metric N-1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Bandwidth Threshold N | | Bandwidth Threshold N |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Threshold Metric N | | Threshold Metric N |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
where: Figure 9: IS-IS FADBT Sub-TLV
Type (1 octet):
An 8-bit field assigned by IANA (To Be Determined as TBD8).
This value uniquely identifies the IS-IS FADBT sub-TLV.
Length (1 octet): where:
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 number of Threshold Metrics specified.
n MUST be greater than or equal to 1
Flags (1 octet): Type (1 octet):
An 8-bit field assigned by IANA (9). This value uniquely
identifies the IS-IS FADBT sub-TLV.
0 1 2 3 4 5 6 7 Length (1 octet):
+-+-+-+-+-+-+-+-+ An 8-bit field indicating the total length, in octets, of the
|G| | | | 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.
G-flag: when set, interface group Mode MUST be used to derive Flags (1 octet):
total link bandwidth. 0 1 2 3 4 5 6 7
Unassigned bits MUST be set to zero. +-+-+-+-+-+-+-+-+
|G| | | |
+-+-+-+-+-+-+-+-+
Staircase bandwidth threshold and associated metric values. 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.
Bandwidth Threshold 1 (4 octets): Following is the staircase bandwidth threshold and associated metric
Minimum Link Bandwidth is encoded in in values.
IEEE floating point format (32 bits)[IEEE754-2019].
The units are bytes-per-second.
Threshold Metric 1 (3 octets): Bandwidth Threshold 1 (4 octets):
Metric value range (1 - 16,777,215 (0xFFFFFF)) Minimum Link Bandwidth is encoded in IEEE floating point format
(32 bits)[IEEE754-2019]. The units are bytes per second.
Bandwidth Threshold n (4 octets): Threshold Metric 1 (3 octets):
Maximum Link Bandwidth is encoded in Metric value range (1 - 16,777,215 (0xFFFFFF))
IEEE floating point format (32 bits)[IEEE754-2019].
The units are bytes-per-second.
Threshold Metric n (3 octest) : Bandwidth Threshold N (4 octets):
Metric value range (1 - 16,777,215 (0xFFFFFF)) Maximum Link Bandwidth is encoded in IEEE floating point format
(32 bits)[IEEE754-2019]. The units are bytes per second.
Figure 9: IS-IS FADBT Sub-TLV Threshold Metric N (3 octets):
Metric value range (1 - 16,777,215 (0xFFFFFF))
When G-flag is set, the cumulative bandwidth of the parallel links is When the G-flag is set, the cumulative bandwidth of the parallel
computed as described in Section 4.1.1.2. If G-flag is not set, the links is computed as described in Section 4.1.1.2. If the G-flag is
advertised Maximum Link Bandwidth is used. not set, the advertised Maximum Link Bandwidth is used.
Assignment of Bandwidth Metric Based on Computed Link Bandwidth: 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 The Bandwidth Metric for a link during the Flex-Algorithm Shortest
Path First (SPF) calculation MUST be assigned according to the Path First (SPF) calculation MUST be assigned according to the
following rules: following rules:
1. When the computed link bandwidth is less than Bandwidth 1. When the computed link bandwidth is less than Bandwidth Threshold
Threshold 1: 1:
- The Bandwidth Metric MUST be set to the maximum metric value of The Bandwidth Metric MUST be set to the maximum metric value of
4,261,412,864. 4,261,412,864.
2. When the computed link bandwidth is greater than or equal to 2. When the computed link bandwidth is greater than or equal to
Bandwidth Threshold 1 and less than Bandwidth Threshold 2: Bandwidth Threshold 1 and less than Bandwidth Threshold 2:
- The Bandwidth Metric MUST be set to Threshold Metric 1. The Bandwidth Metric MUST be set to Threshold Metric 1.
3. When the computed link bandwidth is greater than or equal to 3. When the computed link bandwidth is greater than or equal to
Bandwidth Threshold 2 and less than Bandwidth Threshold 3: Bandwidth Threshold 2 and less than Bandwidth Threshold 3:
- The Bandwidth Metric MUST be set to Threshold Metric 2. The Bandwidth Metric MUST be set to Threshold Metric 2.
4. In general, for all integer values of X such that 1 ≤ X < N: 4. In general, for all integer values of X such that 1 ≤ X < N:
- When the computed link bandwidth is greater than or equal to When the computed link bandwidth is greater than or equal to
Bandwidth Threshold X and less than Bandwidth Threshold X+1: Bandwidth Threshold X and less than Bandwidth Threshold X+1:
- The Bandwidth Metric MUST be set to Threshold Metric X. The Bandwidth Metric MUST be set to Threshold Metric X.
5. When the computed link bandwidth is greater than or equal to 5. When the computed link bandwidth is greater than or equal to
Bandwidth Threshold N: Bandwidth Threshold N:
- The Bandwidth Metric MUST be set to Threshold Metric N. The Bandwidth Metric MUST be set to Threshold Metric N.
Notes: Notes:
The term Bandwidth Threshold X refers to a predefined threshold * The term "Bandwidth Threshold X" refers to a predefined threshold
value corresponding to the index X. value corresponding to the index X.
The term Threshold Metric X refers to the metric value associated * The term "Threshold Metric X" refers to the metric value
with Bandwidth Threshold X. associated with Bandwidth Threshold X.
N represents the total number of bandwidth thresholds defined in * N represents the total number of bandwidth thresholds defined in
the system. the system.
Implementations MUST ensure that these rules are consistently applied Implementations MUST ensure that these rules are consistently applied
to maintain interoperability and optimal path computation within the to maintain interoperability and optimal path computation within the
network. network.
The IS-IS FADBT sub-TLV MUST NOT appear more than once in an IS-IS 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 FAD sub-TLV. If it appears more than once, the IS-IS FAD sub-TLV
MUST be ignored by the receiver. MUST be ignored by the receiver.
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 these sub-TLVs are advertised in the same FAD for a Flexible If both of these sub-TLVs are advertised in the same FAD for a
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 the Bandwidth Metric advertisement, the Bandwidth Metric for
such links MUST be ignored and automatic Metric calculation MUST be
used to derive link metric.
4.1.4. OSPF FAD constraint Sub-TLVs for automatic metric calculation * 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.
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 sub-TLV (FADRB The Flexible Algorithm Definition Reference Bandwidth (FADRB) sub-TLV
sub-TLV) is a sub-TLV of the OSPF FAD TLV. It has the following is a sub-TLV of the OSPF FAD TLV. It has the following format:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | | Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags | Reserved | | Flags | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reference Bandwidth | | Reference Bandwidth |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Granularity Bandwidth | | Granularity Bandwidth |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
where: Figure 10: OSPF FADRB Sub-TLV
Type (2 octets): where:
A 16-bit field assigned by IANA (To Be Determined as TBD9).
This value uniquely identifies the OSPF FADRB sub-TLV.
Length (2 octets): Type (2 octets):
A 16-bit field indicating the total length, in octets, A 16-bit field assigned by IANA (8). This value uniquely
of the subsequent fields. For this sub-TLV, Length is set to 14. identifies the OSPF FADRB sub-TLV.
Flags (1 octet): 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.
0 1 2 3 4 5 6 7 Flags (1 octet):
+-+-+-+-+-+-+-+-+ 0 1 2 3 4 5 6 7
|G| | | | +-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+ |G| | | |
+-+-+-+-+-+-+-+-+
G-flag: When set, Interface Group Mode MUST be used G-flag: When set, Interface Group Mode MUST be used to derive
to derive total link bandwidth. total link bandwidth. Unassigned bits MUST be set to zero and
Unassigned bits MUST be set to zero. MUST be ignored by the receiver.
Reference Bandwidth (4 octets): Reference Bandwidth (4 octets):
Bandwidth encoded in 32 bits in Bandwidth encoded in 32 bits in IEEE floating point format
IEEE floating point format [IEEE754-2019]. [IEEE754-2019]. The units are in bytes per second.
The units are in bytes per second.
Granularity Bandwidth (4 octets):
Bandwidth encoded in 32 bits in
IEEE floating point format [IEEE754-2019].
The units are in bytes per second.
When granularity_bw is less than or equal to Total_link_bandwidth Granularity Bandwidth (4 octets):
Bandwidth encoded in 32 bits in IEEE floating point format
[IEEE754-2019]. The units are in bytes per second.
Metric calculation: (Reference_bandwidth) / When granularity_bw is less than or equal to Total_link_bandwidth,
(Total_link_bandwidth - then:
(Modulus of(Total_link_bandwidth,
granularity_bw)))
When granularity_bw is greater than Total_link_bandwidth Metric calculation:
(Reference_bandwidth) / (Total_link_bandwidth - (Modulus
of(Total_link_bandwidth, granularity_bw)))
Metric calculation: Reference_bandwidth/ When granularity_bw is greater than Total_link_bandwidth, then:
Total_link_bandwidth
The division used here is integer division. Metric calculation:
Reference_bandwidth/ Total_link_bandwidth
Modulus of operation is defined as a remainder The division used here is integer division.
value when two numbers are divided.
Figure 10: OSPF FADRB Sub-TLV 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 The Granularity Bandwidth value is used to ensure that the metric
does not change when there is a small change in the link bandwidth. 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 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 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 by the receiver. The value advertised in the Reference Bandwidth
MUST be non-zero. If a zero value is advertised in the Reference field MUST be non-zero. If a zero value is advertised in the
Bandwidth Field in the OSPF FADRB sub-TLV, the sub-TLV MUST be Reference Bandwidth field in the OSPF FADRB sub-TLV, the sub-TLV MUST
ignored. If a Generic Metric sub-TLV with Bandwidth metric type is be ignored. If a Generic Metric sub-TLV with Bandwidth metric-type
advertised for a link, the Flex-Algorithm calculation MUST use the is advertised for a link, the Flex-Algorithm calculation MUST use the
advertised Bandwidth Metric on the link, and MUST NOT use the advertised Bandwidth Metric on the link and MUST NOT use the
automatically derived metric for that link. In the case of Interface automatically derived metric for that link. In the case of Interface
Group Mode, the following procedures apply: Group Mode, the following procedures apply:
When all parallel links have advertised the Bandwidth Metric: The * When all parallel links have advertised the Bandwidth Metric: The
individual link Bandwidth Metric MUST be used for each link. individual link Bandwidth Metric MUST be used for each link.
When only a subset of the parallel links have advertised the * When only a subset of the parallel links have advertised the
Bandwidth Metric: The Bandwidth Metric advertisements for those Bandwidth Metric: The Bandwidth Metric advertisements for those
links MUST be ignored. In this scenario, automatic metric links MUST be ignored. In this scenario, automatic metric
calculation MUST be used to derive the link metrics for all calculation MUST be used to derive the link metrics for all
parallel links. parallel links.
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 If the calculated metric evaluates to a number greater than
0xFFFFFFFF, it is set to 0xFFFFFFFF. 0xFFFFFFFF, it is set to 0xFFFFFFFF.
4.1.4.2. Bandwidth Threshold Sub-TLV 4.1.4.2. Bandwidth Threshold Sub-TLV
The Flexible Algorithm Definition Bandwidth Thresholds sub-TLV (FADBT The Flexible Algorithm Definition Bandwidth Threshold (FADBT) sub-TLV
sub-TLV) is a sub-TLV of the OSPF FAD TLV. It has the following is a sub-TLV of the OSPF FAD TLV. It has the following format:
format:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags | 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: 0 1 2 3
Type (2 octets): 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
A 16-bit field assigned by IANA (To Be Determined as TBD10). +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
This value uniquely identifies the OSPF FADBT sub-TLV. | 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Length (2 octets): Figure 11: OSPF FADBT Sub-TLV
A 16-bit field indicating the total length, in octets,
of the subsequent fields. For this sub-TLV, Length is set
2 + N*8 octets. Here N is equal to number of
Threshold Metrics specified. N MUST be greater than or equal to 1.
Flags (1 octet): where:
0 1 2 3 4 5 6 7 Type (2 octets):
+-+-+-+-+-+-+-+-+ A 16-bit field assigned by IANA (9). This value uniquely
|G| | identifies the OSPF FADBT sub-TLV.
+-+-+-+-+-+-+-+-+
G-flag: when set, interface group Mode MUST be used to Length (2 octets):
derive total link bandwidth. A 16-bit field indicating the total length, in octets, of the
Unassigned bits MUST be set to zero. 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.
Staircase bandwidth threshold and associated metric values. Flags (1 octet):
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
|G| |
+-+-+-+-+-+-+-+-+
Bandwidth Threshold 1 (4 octets): G-flag: When set, Interface Group Mode MUST be used to derive
Minimum Link Bandwidth is encoded total link bandwidth. Unassigned bits MUST be set to zero and
in IEEE floating point format (32 bits)[IEEE754-2019]. MUST be ignored by the receiver.
The units are bytes per second.
Threshold Metric 1 (4 octets): Following is the staircase bandwidth threshold and associated metric
values.
Metric value range (1 - 4,294,967,296 (0xFFFFFFFF)) Bandwidth Threshold 1 (4 octets):
Minimum Link Bandwidth is encoded in IEEE floating point format
(32 bits)[IEEE754-2019]. The units are bytes per second.
Bandwidth Threshold N (4 octets): Threshold Metric 1 (4 octets):
Maximum Link Bandwidth is encoded Metric value range (1 - 4,294,967,296 (0xFFFFFFFF))
in IEEE floating point format (32 bits)[IEEE754-2019].
The units are bytes per second.
Threshold Metric N (4 octets): Bandwidth Threshold N (4 octets):
Metric value range (1 - 4,294,967,296 (0xFFFFFFFF)) Maximum Link Bandwidth is encoded in IEEE floating point format
(32 bits)[IEEE754-2019]. The units are bytes per second.
Figure 11: OSPF FADBT Sub-TLV Threshold Metric N (4 octets):
Metric value range (1 - 4,294,967,296 (0xFFFFFFFF))
When G-flag is set, the cumulative bandwidth of the parallel links is When the G-flag is set, the cumulative bandwidth of the parallel
computed as described in Section 4.1.1.2. If G-flag is not set, the links is computed as described in Section 4.1.1.2. If the G-flag is
advertised Maximum Link Bandwidth is used. not set, the advertised Maximum Link Bandwidth is used.
Assignment of Bandwidth Metric Based on Computed Link Bandwidth: 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 During the Flex-Algorithm SPF calculation, the Bandwidth Metric for a
Path First (SPF) calculation MUST be assigned according to the link MUST be assigned according to the following rules:
following rules:
1. When the computed link bandwidth is less than Bandwidth 1. When the computed link bandwidth is less than Bandwidth Threshold
Threshold 1: 1:
- The Bandwidth Metric MUST be set to the maximum metric value of The Bandwidth Metric MUST be set to the maximum metric value of
4,294,967,296. 4,294,967,296.
2. When the computed link bandwidth is greater than or equal to 2. When the computed link bandwidth is greater than or equal to
Bandwidth Threshold 1 and less than Bandwidth Threshold 2: Bandwidth Threshold 1 and less than Bandwidth Threshold 2:
- The Bandwidth Metric MUST be set to Threshold Metric 1. The Bandwidth Metric MUST be set to Threshold Metric 1.
3. When the computed link bandwidth is greater than or equal to 3. When the computed link bandwidth is greater than or equal to
Bandwidth Threshold 2 and less than Bandwidth Threshold 3: Bandwidth Threshold 2 and less than Bandwidth Threshold 3:
- The Bandwidth Metric MUST be set to Threshold Metric 2. The Bandwidth Metric MUST be set to Threshold Metric 2.
4. In general, for all integer values of X where 1 ≤X < N: 4. In general, for all integer values of X where 1 ≤X < N:
- When the computed link bandwidth is greater than or equal to When the computed link bandwidth is greater than or equal to
Bandwidth Threshold X and less than Bandwidth Threshold X+1: Bandwidth Threshold X and less than Bandwidth Threshold X+1:
- The Bandwidth Metric MUST be set to Threshold Metric X. The Bandwidth Metric MUST be set to Threshold Metric X.
5. When the computed link bandwidth is greater than or equal to 5. When the computed link bandwidth is greater than or equal to
Bandwidth Threshold N: Bandwidth Threshold N:
- The Bandwidth Metric MUST be set to Threshold Metric N. The Bandwidth Metric MUST be set to Threshold Metric N.
Notes: Notes:
Bandwidth Threshold X refers to the predefined bandwidth threshold * Bandwidth Threshold X refers to the predefined bandwidth threshold
corresponding to index X. corresponding to index X.
Threshold Metric X is the metric value associated with Bandwidth * Threshold Metric X is the metric value associated with Bandwidth
Threshold X. Threshold X.
N represents the total number of bandwidth thresholds defined in * N represents the total number of bandwidth thresholds defined in
the system. the system.
Implementations MUST consistently apply these rules to ensure Implementations MUST consistently apply these rules to ensure
accurate path computations and maintain interoperability within the accurate path computations and maintain interoperability within the
network. network.
The OSPF FADBT sub-TLV MUST NOT appear more than once in an OSPF FAD 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 MUST be ignored sub-TLV. If it appears more than once, the OSPF FAD sub-TLV MUST be
by the receiver. ignored by the receiver.
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 these sub-TLVs are advertised in the same FAD for a Flexible If both these sub-TLVs are advertised in the same FAD for a Flexible
Algorithm, the FAD MUST be ignored by the receiver. 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.
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 The individual link Bandwidth Metric MUST be used for each link
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.
This approach ensures consistent metric calculation and avoids This approach ensures consistent metric calculation and avoids
discrepancies caused by partial Bandwidth Metric advertisements among discrepancies caused by partial Bandwidth Metric advertisements among
parallel links. parallel links.
5. Bandwidth metric considerations 5. Bandwidth Metric Considerations
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 used advertised for the link as described in Section 4, it MUST be
during the Flex-Algorithm calculation. used during the Flex-Algorithm calculation.
2. If the Generic Metric sub-TLV with Bandwidth metric type is
not advertised for the link and the winning FAD for the Flex-
Algorithm does not specify the automatic bandwidth metric
calculation (as defined in Section 4.1 ), the link is treated as
if the Bandwidth Metric is not available for the link.
3. If the Generic Metric sub-TLV with Bandwidth metric type is 2. If the Generic Metric sub-TLV with Bandwidth metric-type is not
not advertised for the link and the winning FAD (sec 5.3 [RFC9350] advertised for the link and the winning FAD for the Flex-
for the Flex-Algorithm specifies the automatic bandwidth metric Algorithm does not specify the automatic Bandwidth metric
calculation (as defined in Section 4.1), the Bandwidth Metric calculation (as defined in Section 4.1), the link is treated as
metric MUST be automatically calculated as per the procedures if the Bandwidth Metric is not available for the link.
defined in Section 4.1. If the Link Bandwidth is not advertised
for a link, the link MUST be pruned for the Flex-Algorithm
calculations.
4.In ISIS the Link Bandwidth for Flex-Algorithm purposes is 3. If the Generic Metric sub-TLV with Bandwidth metric-type is not
advertised as a sub-sub-TLV 9 of the Flex-algorithm specific ASLA advertised for the link and the winning FAD (Section 5.3 of
sub-TLV. It is also possible to advertise the link bandwidth or [RFC9350]) for the Flex-Algorithm specifies the automatic
Flex-Algorithm, in sub-TLV 9 of TLV 22/222/23/223/141 [RFC5305], Bandwidth metric calculation (as defined in Section 4.1), the
together with the L-Flag set in the Flex-Algorithm specific ASLA Bandwidth Metric MUST be automatically calculated per the
advertisement. In the absence of both of these advertisements, procedures defined in Section 4.1. If the Link Bandwidth is not
the bandwidth of the link is not available for Flex-Algorithm advertised for a link, the link MUST be pruned for the Flex-
purposes. Algorithm calculations.
6. Calculation of Flex-Algorithm paths 4. In IS-IS, for Flex-Algorithm purposes, the Link Bandwidth is
advertised as a sub-sub-TLV 9 of the Flex-Algorithm-specific ASLA
sub-TLV. It is also possible to advertise the link bandwidth or
Flex-Algorithm in sub-TLV 9 of TLVs 22/222/23/223/141 [RFC5305]
together with the L-flag set in the Flex-Algorithm-specific ASLA
advertisement. In the absence of both of these advertisements,
the bandwidth of the link is not available for Flex-Algorithm
purposes.
Two new additional rules are added to the existing rules in the Flex- 6. Calculation of Flex-Algorithm Paths
Algorithm calculations specified in Section 13 of [RFC9350].
6. Check if any exclude FAEMB rule is part of the Flex-Algorithm The following two new additional rules are added to the existing
definition. If such exclude rule exists and the link has Maximum rules in the Flex-Algorithm calculations specified in Section 13 of
Link Bandwidth advertised, check if the link bandwidth satisfies [RFC9350]:
the FAEMB rule. If the link does not satisfy the FAEMB rule, the
link MUST be pruned from the Flex-Algorithm computation.
7. Check if any exclude FAEMD rule is part of the Flex-Algorithm | 6. Check if any exclude FAEMB rule is part of the Flex-Algorithm
definition. If such exclude rule exists and the link has Min | definition. If such exclude rule exists and the link has
Unidirectional link delay advertised, check if the link delay | Maximum Link Bandwidth advertised, check if the link bandwidth
satisfies the FAEMD rule. If the link does not satisfy the FAEMD | satisfies the FAEMB rule. If the link does not satisfy the
rule, the link MUST be pruned from the Flex-Algorithm computation. | FAEMB rule, the link MUST be pruned from the Flex-Algorithm
| computation.
|
| 7. Check if any exclude FAEMD rule is part of the Flex-Algorithm
| definition. If such exclude rule exists and the link has Min
| Unidirectional link delay advertised, check if the link delay
| satisfies the FAEMD rule. If the link does not satisfy the
| FAEMD rule, the link MUST be pruned from the Flex-Algorithm
| computation.
7. Backward Compatibility 7. Backward Compatibility
This extension brings no new backward-compatibility issues. This This extension brings no new backward-compatibility issues. This
document defines new FAD constraints in Section 3 Section 4.1.3 and document defines new FAD constraints in Sections 3, 4.1.3, and 4.1.4.
Section 4.1.4. As described in [RFC9350], any node that does not As described in [RFC9350], any node that does not understand sub-TLVs
understand sub-TLVs in a FAD TLV, stops participation in the in a FAD TLV stops participation in the corresponding Flex-Algorithm.
corresponding Flex-Algorithm. The new extensions can be deployed The new extensions can be deployed among the nodes that are upgraded
among the nodes that are upgraded to understand the new extensions to understand the new extensions without affecting the nodes that are
without affecting the nodes that are not upgraded. This document not upgraded. This document also defines a new metric advertisement
also defines a new metric advertisement as described in Section 2. as described in Section 2. As per Section 13 of [RFC9350], when the
As per Section 13 of [RFC9350], the links that do not advertise the links do not advertise the metric-type specified by the selected FAD,
metric-type specified by the selected FAD, the link is pruned from the link is pruned from Flex-Algorithm calculations. The new metric-
Flex-Algorithm calculations. The new metric-types and the Flex- types and Flex-Algorithms using the new metric-types can be deployed
Algorithms using new metric-types can be deployed in the network in the network without affecting existing deployment.
without affecting existing deployment.
8. Security Considerations 8. Security Considerations
This document inherits security considerations from [RFC9350]. This document inherits security considerations from [RFC9350].
9. Operational Considerations 9. Operational Considerations
Operational consideration defined in [RFC9350] generally apply to the Operational considerations defined in [RFC9350] generally apply to
extensions defined in this document as well. This document defines the extensions defined in this document as well. This document
metric-type range for user defined metrics. When user-defined defines a metric-type range for user-defined metrics. When user-
metrics are used in an inter-area or inter-level network, all the defined metrics are used in an inter-area or inter-level network, all
domains should assign same meaning to the particular metric-type. the domains should assign same meaning to the particular metric-type.
The YANG data models for Flex-Algorithm extensions are defined in The YANG data models for Flex-Algorithm extensions are defined in
documents [I-D.ietf-lsr-ospf-yang-augmentation-v1] and documents [OSPF-AUGMENTATION] and [ISIS-AUGMENTATION].
[I-D.ietf-lsr-isis-yang-augmentation-v1]
Before the router goes into maintenance activity, the traffic needs Before the router goes into maintenance activity, the traffic needs
to be diverted away from the router. This is achieved by setting the 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. 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 Maximum In case of Generic Metric, the link metrics can be set to a Maximum
usable metric for OSPF and ISIS. The traffic will be diverted away 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 from the router to a shorter available path. If there are no
alternate paths available, traffic will stay on the router as the alternate paths available, traffic will stay on the router as the
links are not removed from Flex-algorithm calculation when they are links are not removed from the Flex-Algorithm calculation when they
set to maximum metric as per [RFC9350] are set to a maximum metric per [RFC9350].
10. IANA Considerations 10. IANA Considerations
10.1. IGP Metric-Type Registry 10.1. IGP Metric-Type Registry
IGP Metric-type Registry is updated to include another column The "IGP Metric-Type" registry has been updated to include another
specifying whether the particular metric-type is allowed in the column specifying whether the particular metric-type is allowed in
generic-metric sub-TLV or not. The range 128-255 is being redefined the Generic Metric sub-TLV. The range 128-255 is redefined by this
in this document as user-defined range and this range does not document as a user-defined range, and this range does not require
standards action. Standards Action [RFC8126].
Type Description Reference Allowed in
generic-metric
----------------------------------------------------------------
0 IGP Metric [RFC9350] No
Section 5.1
1 Min Unidirectional [RFC9350] No
Link Delay as defined Section 5.1
in [RFC8570,
Section 4.2],and
[RFC7471, Section 4.2]
2 Traffic Engineering Default [RFC9350] No
Metric as defined in Section 5.1
[RFC5305,Section 3.7],
and [RFC3630, Section 2.5.5]
3(TBA) Bandwidth Metric this document yes
128-255(TBA) User defined metric this document yes +=========+===========================+===========+================+
| Type | Description | Reference | Allowed in |
| | | | Generic-Metric |
+=========+===========================+===========+================+
| 0 | IGP Metric | Section | No |
| | | 5.1 of | |
| | | [RFC9350] | |
+---------+---------------------------+-----------+----------------+
| 1 | Min Unidirectional Link | Section | No |
| | Delay as defined in | 5.1 of | |
| | [RFC8570], Section 4.2 | [RFC9350] | |
| | and [RFC7471], | | |
| | Section 4.2 | | |
+---------+---------------------------+-----------+----------------+
| 2 | Traffic Engineering | Section | No |
| | Default Metric as defined | 5.1 of | |
| | in [RFC5305], Section 3.7 | [RFC9350] | |
| | and Traffic Engineering | | |
| | Metric as defined in | | |
| | [RFC3630], Section 2.5.5 | | |
+---------+---------------------------+-----------+----------------+
| 3 | Bandwidth Metric | RFC 9843 | Yes |
+---------+---------------------------+-----------+----------------+
| 128-255 | Reserved for User-Defined | RFC 9843 | Yes |
| | Metric | | |
+---------+---------------------------+-----------+----------------+
Figure 12: IANA IGP Metric-Type Registry Table 1: IGP Metric-Type Registry
10.2. IS-IS Sub-Sub-TLVs for Flexible Algorithm Definition Sub-TLV 10.2. IS-IS Sub-Sub-TLVs for Flexible Algorithm Definition Sub-TLV
IS-IS Sub-Sub-TLVs for Flexible Algorithm Definition Sub-TLV is part The "IS-IS Sub-Sub-TLVs for Flexible Algorithm Definition Sub-TLV"
of the “IS-IS TLV Codepoints” registry group. registry is part of the "IS-IS TLV Codepoints" registry group.
Type: 6(TBD3)
Description: IS-IS Exclude Minimum Bandwidth Sub-TLV
Reference: This document Section 3.1.1
Type: 7 (TBD4)
Description: IS-IS Exclude Maximum Delay Sub-TLV
Reference: This document Section 3.1.2
Type: 8 (TBD7)
Description: IS-IS Reference Bandwidth Sub-TLV
Reference: This document Section 4.1.3.1 Type: 6
Description: IS-IS Exclude Minimum Bandwidth
Reference: RFC 9843, Section 3.1.1
Type: 9(TBD8) Type: 7
Description: IS-IS Exclude Maximum Delay
Reference: RFC 9843, Section 3.1.2
Description: IS-IS Threshold Metric Sub-TLV Type: 8
Description: IS-IS Reference Bandwidth
Reference: RFC 9843, Section 4.1.3.1
Reference: This document Section 4.1.3.2 Type: 9
Description: IS-IS Bandwidth Threshold
Reference: RFC 9843, Section 4.1.3.2
10.3. OSPF Sub-TLVs for Flexible Algorithm Definition Sub-TLV 10.3. OSPF Sub-TLVs for Flexible Algorithm Definition Sub-TLV
OSPF Flexible Algorithm Definition TLV Sub-TLVs registry is part of The "OSPF Flexible Algorithm Definition TLV Sub-TLVs" registry is
the “Open Shortest Path First (OSPF) Parameters” registry group. part of the "Open Shortest Path First (OSPF) Parameters" registry
group.
Type:6 (TBD5)
Description: OSPF Exclude Minimum Bandwidth Sub-TLV
Reference: This document Section 3.2.1
Type: 7(TBD6)
Description: OSPF Exclude Maximum Delay Sub-TLV
Reference: This document Section 3.2.2
Type: 8(TBD9)
Description: OSPF Reference Bandwidth Sub-TLV
Reference: This document Section 4.1.4.1 Type: 6
Description: OSPF Exclude Minimum Bandwidth
Reference: RFC 9843, Section 3.2.1
Type: 9 (TBD10) Type: 7
Description: OSPF Exclude Maximum Delay
Reference: RFC 9843, Section 3.2.2
Description: OSPF Threshold Metric Sub-TLV Type: 8
Description: OSPF Reference Bandwidth
Reference: RFC 9843, Section 4.1.4.1
Reference: This document Section 4.1.4.2 Type: 9
Description: OSPF Bandwidth Threshold
Reference: RFC 9843, Section 4.1.4.2
10.4. IS-IS Sub-TLVs for TLVs Advertising Neighbor Information 10.4. IS-IS Sub-TLVs for TLVs Advertising Neighbor Information
IS-IS Sub-TLVs for TLVs Advertising Neighbor Information registry is The "IS-IS Sub-TLVs for TLVs Advertising Neighbor Information"
part of the “IS-IS TLV Codepoints” registry group registry is part of the "IS-IS TLV Codepoints" registry group.
Type:17 (TBD1)
Description: Generic metric
Reference: This document Section 2.1
TLV 22,23,25, 141, 222 and 223 set to Y
10.5. Sub-sub-TLV Codepoints for Application-Specific Link Attributes
IS-IS Sub-sub-TLV Codepoints for Application-Specific Link Attributes Type: 17
registry is part of the “IS-IS TLV Codepoints” registry group Description: Generic Metric
TLVs set to "Y": 22, 23, 25, 141, 222, and 223
Reference: RFC 9843, Section 2.1
Type: 17 (TBD1) 10.5. Sub-Sub-TLV Codepoints for Application-Specific Link Attributes
Description: Generic metric The "IS-IS Sub-Sub-TLV Codepoints for Application-Specific Link
Attributes" registry is part of the "IS-IS TLV Codepoints" registry
group.
Reference: This document Section 2.1 Type: 17
Description: Generic Metric
Reference: RFC 9843, Section 2.1
10.6. OSPFv2 Extended Link TLV Sub-TLVs 10.6. OSPFv2 Extended Link TLV Sub-TLVs
OSPFv2 Extended Link TLV Sub-TLVs registry is part of the “Open The "OSPFv2 Extended Link TLV Sub-TLVs" registry is part of the "Open
Shortest Path First v2 (OSPFv2) Parameters” registry group Shortest Path First v2 (OSPFv2) Parameters" registry group.
Type: 25(TBD21)
Description: Generic metric
Reference: This document Section 2.2
L2BM set to Y Value: 25
Description: Generic Metric
L2BM: Y
Reference: RFC 9843, Section 2.2
10.7. Types for Sub-TLVs of TE Link TLV (Value 2) 10.7. Types for Sub-TLVs of TE Link TLV (Value 2)
Types for Sub-TLVs of TE Link TLV (Value 2) registry is part of the The "Types for sub-TLVs of TE Link TLV (Value 2)" registry is part of
“Open Shortest Path First (OSPF) Traffic Engineering TLVs” registry the "Open Shortest Path First (OSPF) Traffic Engineering TLVs"
group registry group.
Type: 36 (TBD22)
Description: Generic metric
Reference: This document Section 2.2 Value: 36
Description: Generic Metric
Reference: RFC 9843, Section 2.2
10.8. OSPFv3 Extended-LSA Sub-TLVs 10.8. OSPFv3 Extended-LSA Sub-TLVs
OSPFv3 Extended-LSA Sub-TLVs is part of the “Open Shortest Path First The "OSPFv3 Extended-LSA Sub-TLVs" registry is part of the "Open
v3 (OSPFv3) Parameters” registry group Shortest Path First v3 (OSPFv3) Parameters" registry group.
Type: 34 (TBD23)
Description: Generic metric
Reference: This document Section 2.2
L2BM set to Y
11. Acknowledgements
Many thanks to Chris Bowers, Krzysztof Szarcowitz, Julian Lucek, Ram
Santhanakrishnan, Ketan Talaulikar and Acee Lindem for discussions
and inputs.
12. Contributors
1. Salih K A
Juniper Networks
salih@juniper.net
13. APPENDIX
13.1. 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 Section 13 of [RFC9350] as
well as new additions proposed in this document.
For all links in the topology:
1. 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.
2. 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 a lso part of the SRLG exclude rule. If
the link is part of such SRLG, the link MUST be pruned from the
computation.
3. Check if any include-any Administrative 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.
4. 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.
5. If the Flex-Algorithm Definition uses something other than the
IGP metric (Section 5 of [RFC9350]), 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.
6. Check if any exclude FAEMB rule is part of the Flex-Algorithm
definition. If such exclude rule exists and the link has Maximum
Link Bandwidth advertised, check if the link bandwidth satisfies
the FAEMB rule. If the link does not satisfy the FAEMB rule, the
link MUST be pruned from the Flex-Algorithm computation.
7. Check if any exclude FAEMD rule is part of the Flex-Algorithm Value: 34
definition. If such exclude rule exists and the link has Min Description: Generic Metric
Unidirectional link delay advertised, check if the link delay L2BM: Y
satisfies the FAEMD rule. If the link does not satisfy the FAEMD Reference: RFC 9843, Section 2.2
rule, the link MUST be pruned from the Flex-Algorithm computation.
14. References 11. References
14.1. Normative References 11.1. Normative References
[IEEE754] Institute of Electrical and Electronics Engineers, "IEEE [IEEE754-2019]
Standard for Floating-Point Arithmetic", IEEE 754-2019, IEEE, "IEEE Standard for Floating-Point Arithmetic", IEEE
DOI 10.1109/ieeestd.2019.8766229, 22 July 2019, Std 754-2019, DOI 10.1109/ieeestd.2019.8766229, 22 July
<https://ieeexplore.ieee.org/document/8766220>. 2019, <https://doi.org/10.1109/ieeestd.2019.8766229>.
[RFC1195] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and [RFC1195] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and
dual environments", RFC 1195, DOI 10.17487/RFC1195, dual environments", RFC 1195, DOI 10.17487/RFC1195,
December 1990, <https://www.rfc-editor.org/info/rfc1195>. December 1990, <https://www.rfc-editor.org/info/rfc1195>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
skipping to change at page 36, line 42 skipping to change at line 1581
[RFC5392] Chen, M., Zhang, R., and X. Duan, "OSPF Extensions in [RFC5392] Chen, M., Zhang, R., and X. Duan, "OSPF Extensions in
Support of Inter-Autonomous System (AS) MPLS and GMPLS Support of Inter-Autonomous System (AS) MPLS and GMPLS
Traffic Engineering", RFC 5392, DOI 10.17487/RFC5392, Traffic Engineering", RFC 5392, DOI 10.17487/RFC5392,
January 2009, <https://www.rfc-editor.org/info/rfc5392>. January 2009, <https://www.rfc-editor.org/info/rfc5392>.
[RFC7684] Psenak, P., Gredler, H., Shakir, R., Henderickx, W., [RFC7684] Psenak, P., Gredler, H., Shakir, R., Henderickx, W.,
Tantsura, J., and A. Lindem, "OSPFv2 Prefix/Link Attribute Tantsura, J., and A. Lindem, "OSPFv2 Prefix/Link Attribute
Advertisement", RFC 7684, DOI 10.17487/RFC7684, November Advertisement", RFC 7684, DOI 10.17487/RFC7684, November
2015, <https://www.rfc-editor.org/info/rfc7684>. 2015, <https://www.rfc-editor.org/info/rfc7684>.
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
Writing an IANA Considerations Section in RFCs", BCP 26,
RFC 8126, DOI 10.17487/RFC8126, June 2017,
<https://www.rfc-editor.org/info/rfc8126>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>. May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8362] Lindem, A., Roy, A., Goethals, D., Reddy Vallem, V., and [RFC8362] Lindem, A., Roy, A., Goethals, D., Reddy Vallem, V., and
F. Baker, "OSPFv3 Link State Advertisement (LSA) F. Baker, "OSPFv3 Link State Advertisement (LSA)
Extensibility", RFC 8362, DOI 10.17487/RFC8362, April Extensibility", RFC 8362, DOI 10.17487/RFC8362, April
2018, <https://www.rfc-editor.org/info/rfc8362>. 2018, <https://www.rfc-editor.org/info/rfc8362>.
[RFC8668] Ginsberg, L., Ed., Bashandy, A., Filsfils, C., Nanduri, [RFC8668] Ginsberg, L., Ed., Bashandy, A., Filsfils, C., Nanduri,
skipping to change at page 37, line 30 skipping to change at line 1620
[RFC9479] Ginsberg, L., Psenak, P., Previdi, S., Henderickx, W., and [RFC9479] Ginsberg, L., Psenak, P., Previdi, S., Henderickx, W., and
J. Drake, "IS-IS Application-Specific Link Attributes", J. Drake, "IS-IS Application-Specific Link Attributes",
RFC 9479, DOI 10.17487/RFC9479, October 2023, RFC 9479, DOI 10.17487/RFC9479, October 2023,
<https://www.rfc-editor.org/info/rfc9479>. <https://www.rfc-editor.org/info/rfc9479>.
[RFC9492] Psenak, P., Ed., Ginsberg, L., Henderickx, W., Tantsura, [RFC9492] Psenak, P., Ed., Ginsberg, L., Henderickx, W., Tantsura,
J., and J. Drake, "OSPF Application-Specific Link J., and J. Drake, "OSPF Application-Specific Link
Attributes", RFC 9492, DOI 10.17487/RFC9492, October 2023, Attributes", RFC 9492, DOI 10.17487/RFC9492, October 2023,
<https://www.rfc-editor.org/info/rfc9492>. <https://www.rfc-editor.org/info/rfc9492>.
14.2. Informative References 11.2. Informative References
[I-D.bashandy-rtgwg-segment-routing-uloop]
Bashandy, A., Filsfils, C., Litkowski, S., Decraene, B.,
Francois, P., and P. Psenak, "Loop avoidance using Segment
Routing", Work in Progress, Internet-Draft, draft-
bashandy-rtgwg-segment-routing-uloop-17, 29 June 2024,
<https://datatracker.ietf.org/doc/html/draft-bashandy-
rtgwg-segment-routing-uloop-17>.
[I-D.ietf-lsr-isis-yang-augmentation-v1] [ISIS-AUGMENTATION]
Lindem, A., Qu, Y., and S. Litkowski, "IS-IS YANG Model Lindem, A., Qu, Y., and S. Litkowski, "IS-IS YANG Model
Augmentations for Additional Features - Version 1", Work Augmentations for Additional Features - Release 1", Work
in Progress, Internet-Draft, draft-ietf-lsr-isis-yang- in Progress, Internet-Draft, draft-ietf-lsr-isis-yang-
augmentation-v1-08, 2 September 2024, augmentation-v1-10, 6 July 2025,
<https://datatracker.ietf.org/doc/html/draft-ietf-lsr- <https://datatracker.ietf.org/doc/html/draft-ietf-lsr-
isis-yang-augmentation-v1-08>. isis-yang-augmentation-v1-10>.
[I-D.ietf-lsr-ospf-yang-augmentation-v1] [OSPF-AUGMENTATION]
Lindem, A. and Y. Qu, "OSPF YANG Model Augmentations for Lindem, A. and Y. Qu, "OSPF YANG Model Augmentations for
Additional Features - Version 1", Work in Progress, Additional Features - Release 1", Work in Progress,
Internet-Draft, draft-ietf-lsr-ospf-yang-augmentation- Internet-Draft, draft-ietf-lsr-ospf-yang-augmentation-
v1-14, 27 December 2024, v1-17, 6 July 2025,
<https://datatracker.ietf.org/doc/html/draft-ietf-lsr- <https://datatracker.ietf.org/doc/html/draft-ietf-lsr-
ospf-yang-augmentation-v1-14>. ospf-yang-augmentation-v1-17>.
[RFC4655] Farrel, A., Vasseur, J.-P., and J. Ash, "A Path [RFC4655] Farrel, A., Vasseur, J.-P., and J. Ash, "A Path
Computation Element (PCE)-Based Architecture", RFC 4655, Computation Element (PCE)-Based Architecture", RFC 4655,
DOI 10.17487/RFC4655, August 2006, DOI 10.17487/RFC4655, August 2006,
<https://www.rfc-editor.org/info/rfc4655>. <https://www.rfc-editor.org/info/rfc4655>.
[RFC5120] Przygienda, T., Shen, N., and N. Sheth, "M-ISIS: Multi [RFC5120] Przygienda, T., Shen, N., and N. Sheth, "M-ISIS: Multi
Topology (MT) Routing in Intermediate System to Topology (MT) Routing in Intermediate System to
Intermediate Systems (IS-ISs)", RFC 5120, Intermediate Systems (IS-ISs)", RFC 5120,
DOI 10.17487/RFC5120, February 2008, DOI 10.17487/RFC5120, February 2008,
skipping to change at page 38, line 49 skipping to change at line 1674
D., Drake, J., and Q. Wu, "IS-IS Traffic Engineering (TE) D., Drake, J., and Q. Wu, "IS-IS Traffic Engineering (TE)
Metric Extensions", RFC 8570, DOI 10.17487/RFC8570, March Metric Extensions", RFC 8570, DOI 10.17487/RFC8570, March
2019, <https://www.rfc-editor.org/info/rfc8570>. 2019, <https://www.rfc-editor.org/info/rfc8570>.
[RFC9346] Chen, M., Ginsberg, L., Previdi, S., and D. Xiaodong, "IS- [RFC9346] Chen, M., Ginsberg, L., Previdi, S., and D. Xiaodong, "IS-
IS Extensions in Support of Inter-Autonomous System (AS) IS Extensions in Support of Inter-Autonomous System (AS)
MPLS and GMPLS Traffic Engineering", RFC 9346, MPLS and GMPLS Traffic Engineering", RFC 9346,
DOI 10.17487/RFC9346, February 2023, DOI 10.17487/RFC9346, February 2023,
<https://www.rfc-editor.org/info/rfc9346>. <https://www.rfc-editor.org/info/rfc9346>.
[SR-LOOP-AVOID]
Bashandy, A., Filsfils, C., Litkowski, S., Decraene, B.,
Francois, P., and P. Psenak, "Loop avoidance using Segment
Routing", Work in Progress, Internet-Draft, draft-
bashandy-rtgwg-segment-routing-uloop-17, 29 June 2024,
<https://datatracker.ietf.org/doc/html/draft-bashandy-
rtgwg-segment-routing-uloop-17>.
Appendix A. Updated List of Rules for Pruning Links in Flex-Algorithm
Topology
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 Section 13 of [RFC9350] as
well as the new additions (rules 6 and 7) described in this document.
For all links in the topology:
1. 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.
2. 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.
3. 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.
4. 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.
5. If the Flex-Algorithm Definition uses something other than the
IGP metric (Section 5 of [RFC9350]), 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.
6. Check if any exclude FAEMB rule is part of the Flex-Algorithm
Definition. If such exclude rule exists and the link has Maximum
Link Bandwidth advertised, check if the link bandwidth satisfies
the FAEMB rule. If the link does not satisfy the FAEMB rule, the
link MUST be pruned from the Flex-Algorithm computation.
7. Check if any exclude FAEMD rule is part of the Flex-Algorithm
Definition. If such exclude rule exists and the link has Min
Unidirectional Link Delay advertised, check if the link delay
satisfies the FAEMD rule. If the link does not satisfy the FAEMD
rule, the link MUST be pruned from the Flex-Algorithm
computation.
Acknowledgements
Many thanks to Chris Bowers, Krzysztof Szarcowitz, Julian Lucek, Ram
Santhanakrishnan, Ketan Talaulikar, and Acee Lindem for discussions
and input.
Contributors
Salih K.A.
Juniper Networks
Email: salih@juniper.net
Authors' Addresses Authors' Addresses
Shraddha Hegde Shraddha Hegde
Juniper Networks Inc. Juniper Networks Inc.
Exora Business Park Exora Business Park
Bangalore 560103 Bangalore 560103
KA Karnataka
India India
Email: shraddha@juniper.net Email: shraddha@juniper.net
William Britto A J William Britto
Juniper Networks Inc. Juniper Networks Inc.
Email: bwilliam@juniper.net Email: bwilliam@juniper.net
Rajesh Shetty Rajesh Shetty
Juniper Networks Inc. Juniper Networks Inc.
Email: mrajesh@juniper.net Email: mrajesh@juniper.net
Bruno Decraene Bruno Decraene
Orange Orange
Email: bruno.decraene@orange.com Email: bruno.decraene@orange.com
 End of changes. 297 change blocks. 
982 lines changed or deleted 981 lines changed or added

This html diff was produced by rfcdiff 1.48.