LSR S. Hegde Internet-Draft W. Britto Intended status: Standards Track R. Shetty Expires: 24 March 2025 Juniper Networks Inc. B. Decraene Orange P. Psenak Cisco Systems T. Li Juniper Networks Inc. 20 September 2024 Flexible Algorithms: Bandwidth, Delay, Metrics and Constraints draft-ietf-lsr-flex-algo-bw-con-15 Abstract Many networks configure the link metric relative to the link capacity. High bandwidth traffic gets routed as per the link capacity. Flexible algorithms provide mechanisms to create constraint based paths in an IGP. This draft documents a generic metric type and set of bandwidth related constraints to be used in Flexible Algorithms. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on 24 March 2025. Hegde, et al. Expires 24 March 2025 [Page 1] Internet-Draft Flex-Algorithm: Bandwidth, Delay, Metric September 2024 Copyright Notice Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Generic Metric Advertisement . . . . . . . . . . . . . . . . 5 2.1. IS-IS Generic Metric Sub-TLV . . . . . . . . . . . . . . 5 2.2. OSPF Generic Metric Sub-TLV . . . . . . . . . . . . . . . 6 2.3. Generic Metric applicability to Flexible Algorithms Multi-domain/Multi-area networks . . . . . . . . . . . . 8 3. FAD constraint Sub-TLVs . . . . . . . . . . . . . . . . . . . 8 3.1. IS-IS FAD constraint Sub-TLVs . . . . . . . . . . . . . . 9 3.1.1. IS-IS Exclude Minimum Bandwidth sub-TLV . . . . . . . 9 3.1.2. IS-IS Exclude Maximum Delay Sub-TLV . . . . . . . . . 10 3.2. OSPF FAD constraint Sub-TLVs . . . . . . . . . . . . . . 11 3.2.1. OSPF Exclude Minimum Bandwidth Sub-TLV . . . . . . . 11 3.2.2. OSPF Exclude Maximum Delay Sub-TLV . . . . . . . . . 12 4. Bandwidth Metric Advertisement . . . . . . . . . . . . . . . 12 4.1. Automatic Metric Calculation . . . . . . . . . . . . . . 13 4.1.1. Automatic Metric Calculation Modes . . . . . . . . . 13 4.1.2. Automatic Metric Calculation Methods . . . . . . . . 15 4.1.3. IS-IS FAD constraint Sub-TLVs for automatic metric calculation . . . . . . . . . . . . . . . . . . . . . 16 4.1.4. OSPF FAD constraint Sub-TLVs for automatic metric calculation . . . . . . . . . . . . . . . . . . . . . 20 5. Bandwidth metric considerations . . . . . . . . . . . . . . . 25 6. Calculation of Flex-Algorithm paths . . . . . . . . . . . . . 25 7. Backward Compatibility . . . . . . . . . . . . . . . . . . . 26 8. Security Considerations . . . . . . . . . . . . . . . . . . . 26 9. Operational Considerations . . . . . . . . . . . . . . . . . 26 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26 10.1. IGP Metric-Type Registry . . . . . . . . . . . . . . . . 26 10.2. IS-IS Sub-Sub-TLVs for Flexible Algorithm Definition Sub-TLV . . . . . . . . . . . . . . . . . . . . . . . . 27 10.3. OSPF Sub-TLVs for Flexible Algorithm Definition Sub-TLV . . . . . . . . . . . . . . . . . . . . . . . . 28 Hegde, et al. Expires 24 March 2025 [Page 2] Internet-Draft Flex-Algorithm: Bandwidth, Delay, Metric September 2024 10.4. IS-IS Sub-TLVs for TLVs Advertising Neighbor Information . . . . . . . . . . . . . . . . . . . . . . 28 10.5. Sub-sub-TLV Codepoints for Application-Specific Link Attributes . . . . . . . . . . . . . . . . . . . . . . . 28 10.6. OSPFv2 Extended Link TLV Sub-TLVs . . . . . . . . . . . 28 10.7. Types for Sub-TLVs of TE Link TLV (Value 2) . . . . . . 29 10.8. OSPFv3 Extended-LSA Sub-TLVs . . . . . . . . . . . . . . 29 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 29 12. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 29 13. APPENDIX . . . . . . . . . . . . . . . . . . . . . . . . . . 29 13.1. Updated list of rules for pruning links in Flex-algorithm topology . . . . . . . . . . . . . . . . . . . . . . . . 29 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 30 14.1. Normative References . . . . . . . . . . . . . . . . . . 30 14.2. Informative References . . . . . . . . . . . . . . . . . 32 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 33 1. Introduction High bandwidth traffic such as residential Internet traffic and machine-to-machine elephant flows benefit from using high capacity links. Accordingly, many network operators define a link's metric relative to its capacity to help direct traffic to higher bandwidth links, but this is no guarantee that lower bandwidth links will be avoided, especially in failure scenarios. To ensure that elephant flows are only placed on high capacity links, it would be useful to explicitly exclude the high bandwidth traffic from utilizing links below a certain capacity. A Flex-Algorithm [RFC9350] is defined as a set of parameters consisting of calculation-type, metric-type, and a set of constraints to allow operators to have more control over the network path computation. In this document, we define further extensions to Flex-Algorithm that will allow operators additional control over their traffic flows, especially with respect to bandwidth constraints. Historically, IGPs have done path computation by minimizing the sum of the link metrics along the path from source to destination. While the metric has been administratively defined, implementations have defaulted to a metric that is inversely proportional to link bandwidth. This has driven traffic to higher bandwidth links and has required manual metric manipulation to achieve the desired loading of the network. Over time, with the addition of different traffic types, the need for alternate types of metrics has evolved. Flex-Algorithm already supports using the minimum link delay and the administratively assigned traffic-engineering metrics in path computation. However, it is clear that additional metrics may be of interest in different Hegde, et al. Expires 24 March 2025 [Page 3] Internet-Draft Flex-Algorithm: Bandwidth, Delay, Metric September 2024 situations. A network operator may seek to minimize their operational costs and thus may want a metric that reflects the actual fiscal costs of using a link. Other traffic may require low jitter, leading to an entirely different set of metrics. With Flex- Algorithm, all of these different metrics, and more, could be used concurrently on the same network. In some circumstances, path computation constraints, such as administrative groups, can be used to ensure that traffic avoids particular portions of the network. These strict constraints are appropriate when there is an absolute requirement to avoid parts of the topology, even in failure conditions. If, however, the requirement is less strict, then using a high metric in a portion of the topology may be more appropriate. This document defines a family of generic metrics that can advertise various types of administratively assigned metrics. This document proposes standard metric-types which have specific semantics and require to be standardized. This document also proposes user defined metric-types where specifics are not defined, so that administrators are free to assign semantics as they see fit. In Section 4, this document specifies a new bandwidth based metric type to be used with Flex-Algorithm and other applications. Section 3 defines additional Flexible Algorithm Definition (FAD) 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 metrics based on the parameters defined in the FAD and the advertised Maximum Link Bandwidth of each link. This is advantageous because administrators can change their criteria for metric assignment centrally, without individual modification of each link metric throughout the network. The procedures described in this document are intended to assign a metric to a link based on the total link capacity and they are not intended to update the metric based on actual traffic flow. Thus, the procedures described in this document are not a replacement to the capability of a PCE which has a dynamic view of the network and provides real-time bandwidth management or a distributed bandwidth management protocol. Hegde, et al. Expires 24 March 2025 [Page 4] Internet-Draft Flex-Algorithm: Bandwidth, Delay, Metric September 2024 2. Generic Metric Advertisement IS-IS and OSPF advertise a metric for each link in their respective link state advertisements. Multiple metric types are already supported. Administratively assigned metrics are described in the original OSPF and IS-IS specifications. The Traffic Engineering Default Metric is defined in [RFC5305] and [RFC3630] and the Min Unidirectional delay metric is defined in [RFC8570] and [RFC7471]. Other metrics, such as jitter, reliability, and fiscal cost may be helpful, depending on the traffic class. Rather than attempt to enumerate all possible metrics of interest, this document specifies a generic mechanism for advertising metrics. Each generic metric advertisement is on a per-link and per-metric type basis. The metric advertisement consists of a metric type field and a value for the metric. The metric type field is assigned by the "IGP metric type" IANA registry. Metric types 0-127 are standard metric types as assigned by IANA. This document further specifies a user-defined metric type space of metric types 128-255. These are user defined and can be assigned by an operator for local use. Implementations MUST support sending and receiving generic metric sub-TLV in ASLA encodings as well as in the TLV 22/extended link LSA/ TE-LSAs. The usage of a generic metric by an individual application is subject to the same rules that apply to other link attributes as defined in [RFC3630], [RFC5305], [RFC9479], [RFC9492] and [RFC9350]. 2.1. IS-IS Generic Metric Sub-TLV The IS-IS Generic Metric sub-TLV specifies the link metric for a given metric type. Typically, this metric is assigned by a network administrator. The Generic Metric sub-TLV is advertised in the TLVs/ sub-TLVs below: a. TLV-22 (Extended IS reachability) [RFC5305] b. TLV-222 (MT-ISN) [RFC5120] c. TLV-23 (IS Neighbor Attribute) [RFC5311] d. TLV-223 (MT IS Neighbor Attribute) [RFC5311] e. TLV-141 (inter-AS reachability information) [RFC9346] f. sub-TLV 16 (Application-Specific Link Attributes (ASLA)) of TLV 22/222/23/223/141 [RFC9479] Hegde, et al. Expires 24 March 2025 [Page 5] Internet-Draft Flex-Algorithm: Bandwidth, Delay, Metric September 2024 g. TLV 25 (L2 Bundle Member Attributes) [RFC8668] Marked as "y(s)" (shareable among bundle members) 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | metric-type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Value | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type : TBD1 (To be assigned by IANA) Length: 4 octets Metric-type: A value from the IGP metric-type registry Value : Metric value range (0 - 16,777,215) Figure 1: IS-IS Generic Metric Sub-TLV The Generic Metric sub-TLV MAY be advertised multiple times. For a particular metric type, the Generic Metric sub-TLV MUST be advertised only once for a link when advertised in TLV 22, 222, 23, 223 and 141. When Generic metric sub-TLV is advertised in ASLA, each metric type MUST be advertised only once per-application for a link. If there are multiple Generic Metric sub-TLVs advertised for a link for the same metric type (and same application in case of ASLA) in one or more received LSPDUs, advertisement in the lowest numbered fragment MUST be used and the subsequent instances MUST be ignored. If the metric type indicates a standard metric type for which there are other advertisement mechanisms (e.g., the IGP metric, the Min Unidirectional Link Delay, or the Traffic Engineering Default Metric), the Generic Metric advertisement MUST be ignored. A metric value of 0xFFFFFF is considered as maximum link metric and a link having this metric value MUST be used during Flex-algorithm calculations as a last resort link as described in sec 15.3 of [RFC9350]. A link can be made unusable by Flex-algorithm by leaving out Generic metric advertisement of the particular metric-type that the Flex-algorithm uses as described in [RFC9350]. 2.2. OSPF Generic Metric Sub-TLV The OSPF Generic Metric sub-TLV specifies the link metric for a given metric type. Typically, this metric is assigned by a network administrator. The Generic Metric sub-TLV is advertised in the TLVs below: Hegde, et al. Expires 24 March 2025 [Page 6] Internet-Draft Flex-Algorithm: Bandwidth, Delay, Metric September 2024 a. sub-TLV of TE Link TLV (2) of OSPF TE LSA [RFC3630]. b. sub-TLV of TE Link TLV (2) of OSPFv2 Inter-AS-TE-v2 LSA [RFC5392]. c. sub-TLV of TE Link TLV (2) of OSPFv3 Intra-Area-TE-LSA [RFC5329]. d. sub-TLV of TE Link TLV (2) of OSPFv3 Inter-AS-TE-v3 LSA [RFC5392]. e. sub-TLV of Application-Specific Link Attributes (ASLA) sub-TLV [RFC9492] of the OSPFv2 Extended Link TLV [RFC7684]. f. sub-TLV of Application-Specific Link Attributes (ASLA) sub-TLV [RFC9492] of the OSPFv3 Router-Link TLV [RFC8362]. g. sub-TLV of the OSPFv2 L2 Bundle Member Attributes sub-TLV [RFC9356]. h. sub-sub-TLV of the OSPFv3 L2 Bundle Member Attributes sub-TLV [RFC9356]. The Generic Metric sub-TLV is TLV type TBD2 (IANA), and is eight octets in length. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | metric-type | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Value | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type : TBD2 (To be assigned by IANA) Length: 8 octets Metric-type = A value from the IGP metric type registry Value : Metric value (0- 4,294,967,295) Figure 2: OSPF Generic Metric Sub-TLV The Generic Metric sub-TLV MAY be advertised multiple times. For a particular metric type, the Generic Metric sub-TLV MUST be advertised only once for a link when advertised as (a) through (d) above. When Hegde, et al. Expires 24 March 2025 [Page 7] Internet-Draft Flex-Algorithm: Bandwidth, Delay, Metric September 2024 Generic Metric sub-TLV is advertised as sub-sub-TLV of ASLA, it MUST be advertised only once per-application for a link. If there are multiple Generic Metric sub-TLVs advertised for a link for the same metric type (and same application in case of ASLA) in one or more received LSAs, advertisement in the lowest numbered LSA MUST be used and the subsequent instances MUST be ignored. If the metric type indicates a standard metric type for which there are other advertisement mechanisms (e.g., the IGP metric, the Min Unidirectional Link Delay, or the Traffic Engineering Default Metric), the Generic Metric advertisement MUST be ignored. A metric value of 0xFFFFFFFF is considered as maximum link metric and a link having this metric value MUST be used during Flex-algorithm calculations as a last resort link as described in sec 15.3 of [RFC9350]. A link can be made unusable by Flex-algorithm by leaving out Generic metric advertisement of the particular metric-type that the Flex- algorithm uses as described in [RFC9350]. 2.3. Generic Metric applicability to Flexible Algorithms Multi-domain/ Multi-area networks Generic Metric can be used by Flex-Algorithms by specifying the metric type in the Flexible Algorithm Definitions. When Flex- Algorithms is used in a multi-area network, [RFC9350] defines the Flexible Algorithm Prefix Metric (FAPM) sub-TLV that carries the Flexible-Algorithm-specific metric. Metrics carried in FAPM will be equal to the metric to reach the prefix for that Flex-Algorithm in its source area or domain. When Flex-Algorithm uses Generic metric, the same procedures as described in section 13 of [RFC9350] are used to send and process FAPM sub-TLV. 3. FAD constraint Sub-TLVs In networks that carry elephant flows, directing an elephant flow down a low-bandwidth link would be catastrophic. Thus, in the context of Flex-Algorithm, it would be useful to be able to constrain the topology to only those links capable of supporting a minimum amount of bandwidth. If the capacity of a link is constant, this can already be achived through the use of administrative groups. However, when a layer-3 link is actually a collection of layer-2 links (LAG/layer-2 Bundle), the link bandwidth will vary based on the set of active constituent links. This could be automated by having an implementation vary the advertised administrative groups based on bandwidth, but this seems Hegde, et al. Expires 24 March 2025 [Page 8] Internet-Draft Flex-Algorithm: Bandwidth, Delay, Metric September 2024 unnecessarily complex and expressing this requirement as a direct constraint on the topology seems simpler. This is also advantageous if the minimum required bandwidth changes, as this constraint would provide a single centralized, coordinated point of control. To satify this requirement, this document defines an Exclude Minimum Bandwidth constraint. When this constraint is advertised in a FAD, a link will be pruned from the Flex-Algorithm topology if the link's advertised Maximum Link Bandwidth is below the advertised Minimum Bandwidth value. Similarly, this document defines an Exclude Maximum Link Delay constraint. Delay is an important consideration in High Frequency Trading applications, networks with transparent L2 link recovery, or in satellite networks, where link delay may fluctuate. Mechanisms already exist to measure the link delay dynamically and advertise it in the IGP. Networks that employ dynamic link-delay measurement, may want to exclude links that have a delay over a given threshold. 3.1. IS-IS FAD constraint Sub-TLVs 3.1.1. IS-IS Exclude Minimum Bandwidth sub-TLV IS-IS Flex-Algorithm Exclude Minimum Bandwidth sub-TLV (FAEMB) is a sub-TLV of the IS-IS FAD sub-TLV. It has the following format: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Min Bandwidth | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ where: Type: TBD3 Length: 4 octets. Min Bandwidth: The link bandwidth is encoded in IEEE floating point format (32 bits). The units are 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 appears more than once, the IS-IS FAD sub-TLV MUST be ignored by the receiver. Hegde, et al. Expires 24 March 2025 [Page 9] Internet-Draft Flex-Algorithm: Bandwidth, Delay, Metric September 2024 The Minimum bandwidth advertised in FAEMB sub-TLV MUST be compared with Maximum Link Bandwidth advertised in sub-sub-TLV 9 of ASLA sub- TLV [RFC9479]. If L-Flag is set in the ASLA sub-TLV, the Minimum bandwidth advertised in FAEMB sub-TLV MUST be compared with Maximum Link Bandwidth as advertised in the sub-TLV 9 of the TLV 22/222/23/223/141 [RFC5305] as defined in [RFC9479] Section 4.2. If the Maximum Link Bandwidth is lower than the Minimum link bandwidth advertised in FAEMB sub-TLV, the link MUST be excluded from the Flex-Algorithm topology. If a link does not have the Maximum Link Bandwidth advertised but the FAD contains this sub-TLV, then that link MUST NOT be excluded from the topology based on the Minimum Bandwidth constraint. 3.1.2. IS-IS Exclude Maximum Delay Sub-TLV IS-IS Flex-Algorithm Exclude Maximum Delay sub-TLV (FAEMD) is a sub- TLV of the IS-IS FAD sub-TLV. It has the following format. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Max Link Delay | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ where: Type: TBD4 Length: 3 octets Max link delay: 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 appears more than once, the IS-IS FAD sub-TLV MUST be ignored by the receiver. The Maximum link delay advertised in FAEMD sub-TLV MUST be compared with Min Unidirectional Link Delay advertised in sub-sub-TLV 34 of ASLA sub-TLV [RFC9479]. If the L-Flag is set in the ASLA sub-TLV, the Maximum link delay advertised in FAEMD sub-TLV MUST be compared with Min Unidirectional Link Delay as advertised by the sub-TLV 34 of the TLV 22/222/23/223/141 [RFC8570] as defined in [RFC9479] Section 4.2. Hegde, et al. Expires 24 March 2025 [Page 10] Internet-Draft Flex-Algorithm: Bandwidth, Delay, Metric September 2024 If the Min Unidirectional Link Delay value is higher than the Maximum link delay advertised in FAEMD sub-TLV, the link MUST be excluded from the Flex-Algorithm topology. If a link does not have the Min Unidirectional Link Delay advertised but the FAD contains this sub- TLV, then that link MUST NOT be excluded from the topology based on the Maximum Delay constraint. 3.2. OSPF FAD constraint Sub-TLVs 3.2.1. OSPF Exclude Minimum Bandwidth Sub-TLV OSPF Flex-Algorithm Exclude Minimum Bandwidth sub-TLV (FAEMB) is a sub-TLV of the OSPF FAD TLV. It has the following format: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Min Bandwidth | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ where: Type: TBD5 Length: 4 octets. Min Bandwidth: The link bandwidth is encoded in IEEE floating point format (32 bits). The units are bytes-per-second. Figure 5: OSPF FAEMB Sub-TLV The FAEMB sub-TLV MUST only appear once in the FAD sub-TLV. If it appears more than once, the OSPF FAD TLV MUST be ignored by the receiver. The Maximum Link Bandwidth as advertised in the Extended Link TLV in the Extended Link Opaque LSA in OSPFv2 [RFC7684] or as a sub-TLV of the Router-Link TLV of the E-Router-LSA Router-Link TLV in OSPFv3 [RFC8362] MUST be compared against the Minimum bandwidth advertised in FAEMB sub-TLV. If the link bandwidth is lower than the Minimum bandwidth advertised in FAEMB sub-TLV, the link MUST be excluded from the Flex-Algorithm topology. If a link does not have the Maximum Link Bandwidth advertised but the FAD contains this sub- TLV, then that link MUST be included in the topology and proceed to apply further pruning rules for the link. Hegde, et al. Expires 24 March 2025 [Page 11] Internet-Draft Flex-Algorithm: Bandwidth, Delay, Metric September 2024 3.2.2. OSPF Exclude Maximum Delay Sub-TLV The OSPF Flex-Algorithm Exclude Maximum Delay sub-TLV (FAEMD) is a sub-TLV of the OSPF FAD TLV. It has the following format. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | RESERVED | Max Delay | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ where: Type: TBD6 Length: 4 octets Max link delay: 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 appears more than once, the OSPF FAD TLV MUST be ignored by the receiver. The Min Delay value advertised via the Min/Max Unidirectional Link Delay of ASLA sub-TLV [RFC9492], MUST be compared against the Maximum delay advertised in the FAEMD sub-TLV. If the Min Unidirectional Link Delay is higher than the Maximum delay advertised in the FAEMD sub-TLV, the link MUST be excluded from the Flex-Algorithm topology. If the Min/Max Unidirectional Link Delay is not aadvertised for a link but the FAD contains this sub-TLV,then then that link MUST NOT be excluded from the topology based on the Maximum Delay constraint. 4. Bandwidth Metric Advertisement Historically, IGP implementations have made default metric assignments based on link bandwidth. This has proven to be useful, but has suffered from having different defaults across implementations and from the rapid growth of link bandwidths. With Flex-Algorithm, the network administrator can define a function that will produce a metric for each link and have each node automatically compute each link's metric based its bandwidth. This document defines a standard metric type for this purpose called the "Bandwidth Metric". The Bandwidth Metric MAY be advertised in the Generic Metric sub-TLV with the metric type set to "Bandwidth Metric". IS-IS and OSPF will advertise this type of metric in their Hegde, et al. Expires 24 March 2025 [Page 12] Internet-Draft Flex-Algorithm: Bandwidth, Delay, Metric September 2024 link advertisements. Bandwidth metric is a link attribute and for the advertisement and processing of this attribute for Flex- algorithm, MUST follow the the section 12 of [RFC9350] Flex-Algorithm uses this metric type by specifying the bandwidth metric as the metric type in a FAD TLV. A FAD TLV may also specify an automatic computation of the bandwidth metric based on a link's advertised bandwidth. An explicit advertisement of a link's bandwidth metric using the Generic Metric sub-TLV overrides this automatic computation. The automatic bandwidth metric calculation sub-TLVs are advertised in the FAD TLV and these parameters are applicable to applications such as Flex-algorithm that make use of the FAD TLV. 4.1. Automatic Metric Calculation Networks which are designed to be highly regular and follow uniform metric assignment may want to simplify their operations by automatically calculating the bandwidth metric. When a FAD advertises the metric type as Bandwidth Metric and the link does not have the Bandwidth Metric advertised, automatic metric derivation can be used with additional FAD constraint advertisement as described in this section. If a link's bandwidth changes, then the delay in learning about the change may create the possibility of micro-loops in the topology. This is no different from the IGP's susceptibility to micro-loops during a metric change. The micro-loop avoidance procedures described in [I-D.bashandy-rtgwg-segment-routing-uloop] or any other mechanism as described in the framework [RFC5715] can be used to avoid micro-loops when the automatic metric calculation is deployed. Computing the metric between adjacent systems based on bandwidth becomes more complex in the case of parallel adjacencies. If there are parallel adjacencies between systems, then the bandwidth between the systems is the sum of the bandwidth of the parallel links. This is somewhat more complex to deal with, so there is an optional mode for computing the aggregate bandwidth. 4.1.1. Automatic Metric Calculation Modes Hegde, et al. Expires 24 March 2025 [Page 13] Internet-Draft Flex-Algorithm: Bandwidth, Delay, Metric September 2024 4.1.1.1. Simple Mode In simple mode, the Maximum Link Bandwidth of a single layer-3 link is used to derive the metric. This mode is suitable for deployments that do not use parallel layer-3 links. In this case, the computation of the metric is straightforward. If a layer-3 link is composed of a layer-2 bundle, then the link bandwidth is the sum of the bandwidths of the working components and may vary with layer-2 link failures. 4.1.1.2. Interface Group Mode The simple mode of metric calculation may not work well when there are multiple parallel layer-3 interfaces between two nodes. Ideally, the metric between two systems should be the same given the same bandwidth, whether the bandwidth is provided by parallel layer-2 links or parallel layer-3 links. To address this, in Interface Group Mode, nodes MUST compute the aggregate bandwidth of all parallel adjacencies, MUST derive the metric based on the aggregate bandwidth, and MUST apply the resulting metric to each of the parallel adjacencies. Note that a single elephant flow is normally pinned to a single layer-3 interface. If the single layer-3 link bandwidth is not sufficient for any single elephant flow, the mechanisms to solve this issue are outside the scope of this document. A------B====C====F====D | | ------E------- Figure 7: Parallel interfaces For exmple, in the above diagram, there are two parallel links 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 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 lower. Since the bandwidth is higher on the B->C->F->D path, the metric for that path should be lower than the B->E->D path to attract the traffic on B->C->F->D path. Interface Group Mode should be preferred in cases where there are parallel layer-3 links. In the interface group mode, every node MUST identify the set of parallel links between a pair of nodes based on IGP link advertisements and MUST consider cumulative bandwidth of the parallel links while arriving at the metric of each link. Hegde, et al. Expires 24 March 2025 [Page 14] Internet-Draft Flex-Algorithm: Bandwidth, Delay, Metric September 2024 The parallel layer-3 links between two nodes may not have the same bandwidth. In such cases the method described in interface group mode will result in same metric being used for all the parallel links which may cause undesired load-balancing on the links. In such cases, a device may locally apply load-balancing factor relative to the link bandwidth on the ECMP nexthops. 4.1.2. Automatic Metric Calculation Methods In automatic metric calculation for simple and interface group mode, Maximum Link Bandwidth of the links is used to derive the metric. There are two types of automatic metric derivation methods. 1. Reference bandwidth method 2. Bandwidth thresholds method 4.1.2.1. Reference Bandwidth method In many networks, the metric is inversely proportional to the link bandwidth. The administrator or implementation selects a reference bandwdith and the metric is derived by dividing the reference bandwidth by the advertised Maximum Link Bandwidth. Advertising the reference bandwidth in the FAD constraints allows the metric computation to be done on every node for each link. The metric is computed using reference bandwidth and the advertised link bandwidth. Centralized control of this reference bandwidth simplifies management in the case that the reference bandwidth changes. In order to ensure that small bandwidth changes do not change the link metric, it is useful to define the granularity of the bandwidth that is of interest. The link bandwidth will be truncated to this granularity before deriving the metric. For example, reference bandwidth = 1000G Granularity = 20G The derived metric is 10 for link bandwidth in the range 100G to 119G Hegde, et al. Expires 24 March 2025 [Page 15] Internet-Draft Flex-Algorithm: Bandwidth, Delay, Metric September 2024 4.1.2.2. Bandwidth Thresholds method The reference bandwidth approach described above provides a uniform metric value for a range of link bandwidths. In certain cases there may be a need to define non-proportional metric values for the varying ranges of link bandwidth. For example, bandwidths from 10G to 30G are assigned metric value 100, bandwidth from 30G to 70G get a metric value of 50, and bandwidths greater than 70G have a metric of 10. In order to support this, a staircase mapping based on bandwidth thresholds is supported in the FAD. This advertisement contains a set of threshold values and associated metrics. 4.1.3. IS-IS FAD constraint Sub-TLVs for automatic metric calculation 4.1.3.1. Reference Bandwidth Sub-TLV This section provides FAD constraint advertisement details for the reference bandwidth method of metric calculation as described in Section 4.1.2.1. The Flexible Algorithm Definition Reference Bandwidth sub-TLV (FADRB sub-TLV) is a sub-TLV of the IS-IS FAD sub- TLV. It has the following format: Hegde, et al. Expires 24 March 2025 [Page 16] Internet-Draft Flex-Algorithm: Bandwidth, Delay, Metric September 2024 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Flags | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reference Bandwidth | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Granularity Bandwidth | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ where: Type: TBD7 Length: 9 octets. Reference Bandwidth: Bandwidth encoded in IEEE floating point format (32 bits). The units are bytes-per-second. Granularity Bandwidth: Bandwidth encoded in IEEE floating point format (32 bits). The units are bytes-per-second. Flags: 0 1 2 3 4 5 6 7 +-+-+-+-+-+-+-+-+ |G| | +-+-+-+-+-+-+-+-+ G-flag: When set, Interface Group Mode MUST be used to derive total link bandwidth. When granularity_bw is less than or equal to Total_link_bandwidth Metric calculation: (Reference_bandwidth) / (Total_link_bandwidth - (Modulus of(Total_link_bandwidth, granularity_bw))) When granularity_bw is greater than Total_link_bandwidth Metric calculation: Reference_bandwidth / Total_link_bandwidth Figure 8: IS-IS FADRB Sub-TLV Hegde, et al. Expires 24 March 2025 [Page 17] Internet-Draft Flex-Algorithm: Bandwidth, Delay, Metric September 2024 The Granularity Bandwidth value ensures that the metric does not change when there is a small change in the link bandwidth. The IS-IS FADRB sub-TLV MUST NOT appear more than once in an IS-IS FAD sub-TLV. If it appears more than once, the IS-IS FAD sub-TLV MUST be ignored by the receiver. The value advertised in the Reference Bandwidth field MUST be non-zero. If a zero value is advertised in the Reference Bandwidth Field in the IS-IS FADRB sub-TLV, the sub-TLV MUST be ignored. If a Generic Metric sub-TLV with Bandwidth metric type is advertised for a link, the Flex-Algorithm calculation MUST use the advertised Bandwidth Metric, and MUST NOT use the automatically derived metric for that link. In case of Interface Group Mode, 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 the Bandwidth Metric advertisement, the Bandwidth Metric for such links MUST be ignored and automatic Metric calculation MUST be used to derive link metric. If the calculated metric evaluates to zero, a metric of 1 MUST be used. If the calculated metric evaluates to a number greater than 0xFFFFFF, it is set to 0xFFFFFF. 4.1.3.2. Bandwidth Thresholds Sub-TLV This section provides FAD constraint advertisement details for the Bandwidth Thresholds method of metric calculation as described in 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- TLV. It has the following format: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Flags | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Bandwidth Threshold 1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Threshold Metric 1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Bandwidth Threshold 2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Threshold Metric 2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Bandwidth Threshold 3 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ..... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Hegde, et al. Expires 24 March 2025 [Page 18] Internet-Draft Flex-Algorithm: Bandwidth, Delay, Metric September 2024 | Threshold Metric N-1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Bandwidth Threshold N | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Threshold Metric N | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ where: Type: TBD8 Length: 1 + n*7 octets. Here n is equal to number of Threshold Metrics specified. n MUST be greater than or equal to 1. Flags: 0 1 2 3 4 5 6 7 +-+-+-+-+-+-+-+-+ |G| | | | +-+-+-+-+-+-+-+-+ G-flag: when set, interface group Mode MUST be used to derive total link bandwidth. Staircase bandwidth threshold and associated metric values. Bandwidth Threshold 1: Minimum Link Bandwidth is encoded in in IEEE floating point format (32 bits). The units are bytes-per-second. Threshold Metric 1 : Metric value range (1 - 4,261,412,864) Bandwidth Threshold n: Maximum Link Bandwidth is encoded in IEEE floating point format (32 bits). The units are bytes-per-second. Threshold Metric n : Metric value range (1 - 4,261,412,864) Figure 9: IS-IS FADBT Sub-TLV When G-flag is set, the cumulative bandwidth of the parallel links is computed as described in section Section 4.1.1.2. If G-flag is not set, the advertised Maximum Link Bandwidth is used. When the computed link bandwidth is less than Bandwidth Threshold 1, the MAX_METRIC value of 4,261,412,864 MUST be assigned as the Bandwidth Metric on the link during the Flex-Algorithm SPF calculation. Hegde, et al. Expires 24 March 2025 [Page 19] Internet-Draft Flex-Algorithm: Bandwidth, Delay, Metric September 2024 When the computed link bandwidth is greater than or equal to Bandwidth Threshold 1 and less than Bandwidth Threshold 2, Threshold Metric 1 MUST be assigned as the Bandwidth Metric on the link during the Flex-Algorithm SPF calculation. Similarly, when the computed link bandwidth is greater than or equal to Bandwidth Threshold 2 and less than Bandwidth Threshold 3, Threshold Metric 2 MUST be assigned as the Bandwidth Metric on the link during the Flex-Algorithm SPF calculation. In general, when the computed link bandwidth is greater than or equal to Bandwidth Threshold X AND less than Bandwidth Threshold X+1, Threshold Metric X MUST be assigned as the Bandwidth Metric on the link during the Flex-Algorithm SPF calculation. Finally, when the computed link bandwidth is greater than or equal to Bandwidth Threshold N, then Threshold Metric N MUST be assigned as the Bandwidth Metric on the link during Flex-Algorithm SPF calculation. The IS-IS FADBT sub-TLV MUST NOT appear more than once in an IS-IS FAD sub-TLV. If it appears more than once, the IS-IS FAD sub-TLV MUST MUST stop participating in such flex-algorithm. A FAD MUST NOT contain both the FADBT sub-TLV and the FADRB sub-TLV. If both these sub-TLVs are advertised in the same FAD for a Flexible Algorithm, the FAD MUST be ignored by the receiver. If a Generic Metric sub-TLV with Bandwidth metric type is advertised for a link, the Flex-Algorithm calculation MUST use the Bandwidth Metric advertised on the link, and MUST NOT use the automatically derived metric for that link. In case of Interface Group Mode, 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 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 4.1.4.1. Reference Bandwidth Sub-TLV The Flexible Algorithm Definition Reference Bandwidth sub-TLV (FADRB sub-TLV) is a sub-TLV of the OSPF FAD TLV. It has the following format: Hegde, et al. Expires 24 March 2025 [Page 20] Internet-Draft Flex-Algorithm: Bandwidth, Delay, Metric September 2024 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Flags | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reference Bandwidth | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Granularity Bandwidth | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ where: Type: TBD9 Length: 14 octets. Reference Bandwidth: Bandwidth encoded in 32 bits in IEEE floating point format. The units are in bytes per second. Granularity Bandwidth: Bandwidth encoded in 32 bits in IEEE floating point format. The units are in bytes per second. Flags: 0 1 2 3 4 5 6 7 +-+-+-+-+-+-+-+-+ |G| | | | +-+-+-+-+-+-+-+-+ G-flag: When set, Interface Group Mode MUST be used to derive total link bandwidth. When granularity_bw is less than or equal to Total_link_bandwidth Metric calculation: (Reference_bandwidth) / (Total_link_bandwidth - (Modulus of(Total_link_bandwidth, granularity_bw))) When granularity_bw is greater than Total_link_bandwidth Metric calculation: Reference_bandwidth/ Total_link_bandwidth Hegde, et al. Expires 24 March 2025 [Page 21] Internet-Draft Flex-Algorithm: Bandwidth, Delay, Metric September 2024 Figure 10: OSPF FADRB Sub-TLV The Granularity Bandwidth value is used to ensure that the metric does not change when there is a small change in the link bandwidth. The OSPF FADRB sub-TLV MUST NOT appear more than once in an OSPF FAD TLV. If it appears more than once, the OSPF FAD TLV MUST be ignored by the receiver.The value advertised in the Reference Bandwidth field MUST be non-zero. If a zero value is advertised in the Reference Bandwidth Field in the OSPF FADRB sub-TLV, the sub-TLV MUST be ignored. If a Generic Metric sub-TLV with Bandwidth metric type is advertised for a link, the Flex-Algorithm calculation MUST use the advertised Bandwidth Metric on the link, and MUST NOT use the automatically derived metric for that link.In case of Interface Group Mode, 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 the Bandwidth Metric advertisement, the Bandwidth Metric for such links MUST be ignored and automatic Metric calculation MUST be used to derive link metric. If the calculated metric evaluates to zero, a metric of 1 MUST be used. If the calculated metric evaluates to a number greater than 0xFFFFFFFF, it is set to 0xFFFFFFFF. 4.1.4.2. Bandwidth Threshold Sub-TLV The Flexible Algorithm Definition Bandwidth Thresholds sub-TLV (FADBT sub-TLV) is a sub-TLV of the OSPF FAD TLV. It has the following format: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Flags | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Bandwidth Threshold 1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Threshold Metric 1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Bandwidth Threshold 2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Threshold Metric 2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Bandwidth Threshold 3 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Hegde, et al. Expires 24 March 2025 [Page 22] Internet-Draft Flex-Algorithm: Bandwidth, Delay, Metric September 2024 ..... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Threshold Metric N-1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Bandwidth Threshold N | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Threshold Metric N | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ where: Type: TBD10 Length: 2 + N*8 octets. Here n is equal to number of Threshold Metrics specified. N MUST be greater than or equal to 1. Flags: 0 1 2 3 4 5 6 7 +-+-+-+-+-+-+-+-+ |G| | +-+-+-+-+-+-+-+-+ G-flag: when set, interface group Mode MUST be used to derive total link bandwidth. Staircase bandwidth threshold and associated metric values. Bandwidth Threshold 1: Minimum Link Bandwidth is encoded in IEEE floating point format (32 bits). The units are bytes per second. Threshold Metric 1 : Metric value range (1 - 4,294,967,296) Bandwidth Threshold N: Maximum Link Bandwidth is encoded in IEEE floating point format (32 bits). The units are bytes per second. Threshold Metric N : Metric value range (1 - 4,294,967,296) Figure 11: OSPF FADBT Sub-TLV When G-flag is set, the cumulative bandwidth of the parallel links is computed as described in section Section 4.1.1.2. If G-flag is not set, the advertised Maximum Link Bandwidth is used. Hegde, et al. Expires 24 March 2025 [Page 23] Internet-Draft Flex-Algorithm: Bandwidth, Delay, Metric September 2024 When the computed link bandwidth is less than Bandwidth Threshold 1 , the MAX_METRIC value of 4,294,967,296 MUST be assigned as the Bandwidth Metric on the link during the Flex-Algorithm SPF calculation. When the computed link bandwidth is greater than or equal to Bandwidth Threshold 1 and less than Bandwidth Threshold 2, Threshold Metric 1 MUST be assigned as the Bandwidth Metric on the link during the Flex-Algorithm SPF calculation. Similarly, when the computed link bandwidth is greater than or equal to Bandwidth Threshold 2 and less than Bandwidth Threshold 3, Threshold Metric 2 MUST be assigned as the Bandwidth Metric on the link during the Flex-Algorithm SPF calculation. In general, when the computed link bandwidth is greater than or equal to Bandwidth Threshold X AND less than Bandwidth Threshold X+1, Threshold Metric X MUST be assigned as the Bandwidth Metric on the link during the Flex-Algorithm SPF calculation. Finally, when the computed link bandwidth is greater than or equal to Bandwidth Threshold N, then Threshold Metric N MUST be assigned as the Bandwidth Metric on the link during the Flex-Algorithm SPF calculation. The IS-IS FADBT sub-TLV MUST NOT appear more than once in an IS-IS FAD sub-TLV. If it appears more than once, the IS-IS FAD sub-TLV MUST stop participating in such flex-algorithm. A FAD MUST NOT contain both the FADBT sub-TLV and the FADRB sub-TLV. If both these sub-TLVs are advertised in the same FAD for a Flexible Algorithm, the FAD MUST be ignored by the receiver. If a Generic Metric sub-TLV with Bandwidth metric type is advertised for a link, the Flex-Algorithm calculation MUST use the Bandwidth Metric advertised on the link, and MUST NOT use the automatically derived metric for that link. In case of Interface Group Mode, 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 the Bandwidth Metric advertisement, the Bandwidth Metric for such links MUST be ignored and automatic Metric calculation MUST be used to derive link metric. Hegde, et al. Expires 24 March 2025 [Page 24] Internet-Draft Flex-Algorithm: Bandwidth, Delay, Metric September 2024 5. Bandwidth metric considerations This section specifies the rules of deriving the Bandwidth Metric if and only if the winning FAD for the Flex-Algorithm specifies the metric-type as "Bandwidth Metric". 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 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 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 not advertised for the link and the winning FAD for the Flex- Algorithm specifies the automatic bandwidth metric calculation (as defined in Section 4.1), the Bandwidth Metric metric MUST be automatically calculated as per the procedures defined in Section 4.1. If the Link Bandwidth is not advertised for a link, the link MUST be pruned for the Flex-Algorithm calculations. 4.In ISIS the Link Bandwidth for Flex-Algorithm purposes 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 TLV 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. 6. Calculation of Flex-Algorithm paths Two new additional rules are added to the existing rules in the Flex- Algorithm calculations specified in sec 13 of [RFC9350]. 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. Hegde, et al. Expires 24 March 2025 [Page 25] Internet-Draft Flex-Algorithm: Bandwidth, Delay, Metric September 2024 7. Check if any exclude FAEMD rule is part of the Flex-Algorithm definition. If such exclude rule exists and the link has Min Unidirectional link delay advertised, check if the link delay satisfies the FAEMD rule. If the link does not satisfy the FAEMD rule, the link MUST be pruned from the Flex-Algorithm computation. 7. Backward Compatibility This extension brings no new backward-compatibility issues. This document defines new FAD constraints in Section 3 Section 4.1.3 and Section 4.1.4. As described in [RFC9350], any node that does not understand sub-TLVs in a FAD TLV, stops participation in the corresponding Flex-Algorithm. The new extensions can be deployed among the nodes that are upgraded to understand the new extensions without affecting the nodes that are not upgraded. This document also defines a new metric advertisement as described in Section 2. As per Sec 13 of [RFC9350], the links that do not advertise the metric-type specified by the selected FAD, the link is pruned from Flex-Algorithm calculations. The new metric-types and the Flex- Algorithms using new metric-types can be deployed in the network without affecting existing deployment. 8. Security Considerations This document inherits security considerations from [RFC9350]. 9. Operational Considerations Operational consideration defined in [RFC9350] generally apply to the extensions defined in this document as well. This document defines metric-type range for user defined metrics. When user defined metrics are used in an inter-area or inter-level network, all the domains should assign same meaning to the particular metric-type. 10. IANA Considerations 10.1. IGP Metric-Type Registry IGP Metric-type Registry is updated to include another column specifying whether the pariticular metric-type is allowed in the generic-metric sub-TLV or not. Hegde, et al. Expires 24 March 2025 [Page 26] Internet-Draft Flex-Algorithm: Bandwidth, Delay, Metric September 2024 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 Figure 12: IANA IGP Metric-Type Registry 10.2. IS-IS Sub-Sub-TLVs for Flexible Algorithm Definition Sub-TLV 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: 9(TBD8) Description: IS-IS Threshold Metric Sub-TLV Reference: This document Section 4.1.3.2 Hegde, et al. Expires 24 March 2025 [Page 27] Internet-Draft Flex-Algorithm: Bandwidth, Delay, Metric September 2024 10.3. OSPF Sub-TLVs for Flexible Algorithm Definition Sub-TLV 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: 9 (TBD10) Description: OSPF Threshold Metric Sub-TLV Reference: This document Section 4.1.4.2 10.4. IS-IS Sub-TLVs for TLVs Advertising Neighbor Information 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 Type: 17 (TBD1) Description: Generic metric Reference: This document Section 2.1 10.6. OSPFv2 Extended Link TLV Sub-TLVs Type: 25(TBD2) Hegde, et al. Expires 24 March 2025 [Page 28] Internet-Draft Flex-Algorithm: Bandwidth, Delay, Metric September 2024 Description: Generic metric Reference: This document Section 2.2 L2BM set to Y 10.7. Types for Sub-TLVs of TE Link TLV (Value 2) Type: 36 (TBD2) Description: Generic metric Reference: This document Section 2.2 10.8. OSPFv3 Extended-LSA Sub-TLVs Type: 34 (TBD2) 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. Hegde, et al. Expires 24 March 2025 [Page 29] Internet-Draft Flex-Algorithm: Bandwidth, Delay, Metric September 2024 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 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. 14. References 14.1. Normative References Hegde, et al. Expires 24 March 2025 [Page 30] Internet-Draft Flex-Algorithm: Bandwidth, Delay, Metric September 2024 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering (TE) Extensions to OSPF Version 2", RFC 3630, DOI 10.17487/RFC3630, September 2003, . [RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic Engineering", RFC 5305, DOI 10.17487/RFC5305, October 2008, . [RFC5329] Ishiguro, K., Manral, V., Davey, A., and A. Lindem, Ed., "Traffic Engineering Extensions to OSPF Version 3", RFC 5329, DOI 10.17487/RFC5329, September 2008, . [RFC5392] Chen, M., Zhang, R., and X. Duan, "OSPF Extensions in Support of Inter-Autonomous System (AS) MPLS and GMPLS Traffic Engineering", RFC 5392, DOI 10.17487/RFC5392, January 2009, . [RFC7684] Psenak, P., Gredler, H., Shakir, R., Henderickx, W., Tantsura, J., and A. Lindem, "OSPFv2 Prefix/Link Attribute Advertisement", RFC 7684, DOI 10.17487/RFC7684, November 2015, . [RFC8362] Lindem, A., Roy, A., Goethals, D., Reddy Vallem, V., and F. Baker, "OSPFv3 Link State Advertisement (LSA) Extensibility", RFC 8362, DOI 10.17487/RFC8362, April 2018, . [RFC8668] Ginsberg, L., Ed., Bashandy, A., Filsfils, C., Nanduri, M., and E. Aries, "Advertising Layer 2 Bundle Member Link Attributes in IS-IS", RFC 8668, DOI 10.17487/RFC8668, December 2019, . [RFC9350] Psenak, P., Ed., Hegde, S., Filsfils, C., Talaulikar, K., and A. Gulko, "IGP Flexible Algorithm", RFC 9350, DOI 10.17487/RFC9350, February 2023, . [RFC9356] Talaulikar, K., Ed. and P. Psenak, "Advertising Layer 2 Bundle Member Link Attributes in OSPF", RFC 9356, DOI 10.17487/RFC9356, January 2023, . Hegde, et al. Expires 24 March 2025 [Page 31] Internet-Draft Flex-Algorithm: Bandwidth, Delay, Metric September 2024 [RFC9479] Ginsberg, L., Psenak, P., Previdi, S., Henderickx, W., and J. Drake, "IS-IS Application-Specific Link Attributes", RFC 9479, DOI 10.17487/RFC9479, October 2023, . [RFC9492] Psenak, P., Ed., Ginsberg, L., Henderickx, W., Tantsura, J., and J. Drake, "OSPF Application-Specific Link Attributes", RFC 9492, DOI 10.17487/RFC9492, October 2023, . 14.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, . [RFC5120] Przygienda, T., Shen, N., and N. Sheth, "M-ISIS: Multi Topology (MT) Routing in Intermediate System to Intermediate Systems (IS-ISs)", RFC 5120, DOI 10.17487/RFC5120, February 2008, . [RFC5311] McPherson, D., Ed., Ginsberg, L., Previdi, S., and M. Shand, "Simplified Extension of Link State PDU (LSP) Space for IS-IS", RFC 5311, DOI 10.17487/RFC5311, February 2009, . [RFC5715] Shand, M. and S. Bryant, "A Framework for Loop-Free Convergence", RFC 5715, DOI 10.17487/RFC5715, January 2010, . [RFC7471] Giacalone, S., Ward, D., Drake, J., Atlas, A., and S. Previdi, "OSPF Traffic Engineering (TE) Metric Extensions", RFC 7471, DOI 10.17487/RFC7471, March 2015, . [RFC8570] Ginsberg, L., Ed., Previdi, S., Ed., Giacalone, S., Ward, D., Drake, J., and Q. Wu, "IS-IS Traffic Engineering (TE) Metric Extensions", RFC 8570, DOI 10.17487/RFC8570, March 2019, . Hegde, et al. Expires 24 March 2025 [Page 32] Internet-Draft Flex-Algorithm: Bandwidth, Delay, Metric September 2024 [RFC9346] Chen, M., Ginsberg, L., Previdi, S., and D. Xiaodong, "IS- IS Extensions in Support of Inter-Autonomous System (AS) MPLS and GMPLS Traffic Engineering", RFC 9346, DOI 10.17487/RFC9346, February 2023, . Authors' Addresses Shraddha Hegde Juniper Networks Inc. Exora Business Park Bangalore 560103 KA India Email: shraddha@juniper.net William Britto A J Juniper Networks Inc. Email: bwilliam@juniper.net Rajesh Shetty Juniper Networks Inc. Email: mrajesh@juniper.net Bruno Decraene Orange Email: bruno.decraene@orange.com Peter Psenak Cisco Systems Email: ppsenak@cisco.com Tony Li Juniper Networks Inc. Email: tony.li@tony.li Hegde, et al. Expires 24 March 2025 [Page 33]