<?xmlversion="1.0"?>version='1.0' encoding='UTF-8'?> <!DOCTYPE rfcSYSTEM "rfc2629.dtd"[ <!ENTITYRFC2119 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">nbsp " "> <!ENTITYRFC5305 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5305.xml">zwsp "​"> <!ENTITYRFC7684 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.7684.xml">nbhy "‑"> <!ENTITYRFC5311 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5311.xml"> <!ENTITY RFC9346 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.9346.xml"> <!ENTITY RFC5120 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5120.xml"> <!ENTITY RFC8570 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.8570.xml"> <!ENTITY RFC7471 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.7471.xml"> <!ENTITY RFC3630 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3630.xml"> <!ENTITY RFC9479 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.9479.xml"> <!ENTITY RFC9492 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.9492.xml"> <!ENTITY RFC8362 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.8362.xml"> <!ENTITY RFC9350 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.9350.xml"> <!ENTITY RFC5715 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5715.xml"> <!ENTITY RFC9356 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.9356.xml"> <!ENTITY RFC5392 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5392.xml"> <!ENTITY RFC5329 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5329.xml"> <!ENTITY RFC8668 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.8668.xml"> <!ENTITY RFC8174 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.8174.xml"> <!ENTITY RFC4655 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4655.xml"> <!ENTITY RFC1195 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.1195.xml"> <!ENTITY RFC2328 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2328.xml">wj "⁠"> ]><?rfc toc="yes"?> <?rfc tocompact="yes"?> <?rfc tocdepth="3"?> <?rfc tocindent="yes"?> <?rfc symrefs="yes"?> <?rfc sortrefs="yes"?> <?rfc comments="yes"?> <?rfc inline="yes"?> <?rfc compact="yes"?> <?rfc subcompact="no"?><rfc xmlns:xi="http://www.w3.org/2001/XInclude" category="std" docName="draft-ietf-lsr-flex-algo-bw-con-22"ipr="trust200902">number="9843" consensus="true" ipr="trust200902" obsoletes="" updates="" submissionType="IETF" xml:lang="en" tocInclude="true" tocDepth="3" symRefs="true" sortRefs="true" version="3"> <front> <title abbrev="IGPFlex-Algorithm:Flex-Algorithms: Bandwidth, Delay,Metric"> IGPand Metrics">IGP Flexible Algorithms: Bandwidth, Delay,MetricsMetrics, and Constraints</title> <seriesInfo name="RFC" value="9843"/> <author initials="S." surname="Hegde" fullname="Shraddha Hegde"> <organization>Juniper Networks Inc.</organization> <address> <postal> <street>Exora Business Park</street> <city>Bangalore</city><region>KA</region><region>Karnataka</region> <code>560103</code> <country>India</country> </postal> <email>shraddha@juniper.net</email> </address> </author> <!--[rfced] We removed "A J" from William Britto's name to match use in RFC 9502. If that is not desired, please let us know. --> <author initials="W." surname="Britto" fullname="WilliamBritto A J">Britto"> <organization>Juniper Networks Inc.</organization> <address><postal> <street></street> <city></city> <region></region> <code></code> <country></country> </postal><email>bwilliam@juniper.net</email> </address> </author> <author initials="R." surname="Shetty" fullname="Rajesh Shetty"> <organization>Juniper Networks Inc.</organization> <address><postal> <street></street> <city></city> <region></region> <code></code> <country></country> </postal><email>mrajesh@juniper.net</email> </address> </author> <author initials="B." surname="Decraene" fullname="Bruno Decraene"> <organization>Orange</organization> <address><postal> <street></street> <city></city> <region></region> <code></code> <country></country> </postal><email>bruno.decraene@orange.com</email> </address> </author> <author initials="P." surname="Psenak" fullname="Peter Psenak"> <organization>Cisco Systems</organization> <address><postal> <street></street> <city></city> <region></region> <code></code> <country></country> </postal><email>ppsenak@cisco.com</email> </address> </author> <author initials="T." surname="Li" fullname="Tony Li"> <organization>Juniper Networks Inc.</organization> <address><postal> <street></street> <city></city> <region></region> <code></code> <country></country> </postal><email>tony.li@tony.li</email> </address> </author> <dateyear="2025"/> <area>Routing</area> <workgroup>LSR</workgroup>year="2025" month="August"/> <area>RTG</area> <workgroup>lsr</workgroup> <keyword>AS</keyword> <keyword>IGP</keyword> <abstract> <t> Many networks configure the IGP link metric relative to the linkcapacity. Highcapacity, and high bandwidth traffic gets routedasper the link capacity. Flexiblealgorithms <xref target ='RFC9350'/>provideAlgorithms provide mechanisms to createconstraint basedconstraint-based paths in an IGP. Thisdraftspecification documents a generic metric type and a set ofbandwidth relatedbandwidth-related constraints to be used in Flexible Algorithms. </t> </abstract><note title="Requirements Language"> <t> 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, <xref target ='RFC2119'/>, <xref target ='RFC8174'/> when, and only when, they appear in all capitals, as shown here. </t> </note></front> <middle> <sectiontitle="Introduction" anchor='sec_introduction'>anchor="sec_introduction" numbered="true" toc="default"> <name>Introduction</name> <t> High bandwidth traffic such as residential Internet traffic and machine-to-machine elephant flows benefit from using high capacity links. Accordingly, many network operators define a link's metric relative to its capacity to help direct traffic to higher bandwidth links, but this is no guarantee that lower bandwidth links will be avoided, especially in failure scenarios. To ensure that elephant flows are only placed on high capacity links, it would be useful to explicitly exclude the high throughput traffic from utilizing links below a certain capacity. Flex-Algorithm <xreftarget ='RFC9350'/>target="RFC9350" format="default"/> provides a mechanism to create constrained paths by defining a set of parameters consisting of calculation-type, metric-type, and a set of constraints. In this document, we define further extensions toFlex-Algorithmthe Flexible Algorithm Definition (FAD) that will allow operators additional control over their traffic flows, especially with respect to bandwidth constraints. </t> <t>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.</t> <t>Over time, with the addition of different traffic types, the need for alternate types of metrics has evolved. Flex-Algorithm already supports using the minimum link delay and the administratively assigned traffic-engineering metrics in path computation. However, it is clear that additional metrics may be of interest in different situations. A network operator may seek to minimize their operational costs and thus may want a metric that reflects the actual fiscal costs of using a link. Other traffic may require low jitter, leading to an entirely different set of metrics. With Flex-Algorithm, all of these different metrics, and more, could be used concurrently on the same network.</t> <t>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,However, if the requirement is less strict, then using a high metric in a portion of the topology may be more appropriate. </t> <t>This document defines a family of generic metrics that can advertise various types of administratively assigned metrics. <!--[rfced] How may we clarify "and require to be standardized"? Please let us know if option A or option B captures in the intended meaning. In addition, as this document is being published as a Standards-Track RFC, please consider whether "proposes" is accurate. Perhaps "introduces" would work? Original: This document proposes standard metric-types which have specific semantics and require to be standardized. Perhaps A: This document proposes standard metric-types that have specific semantics and require standardization. Perhaps B: This document proposes standard metric-types that have specific semantics and requirements for standardization. --> This document proposes standard metric-types that have specific semantics and require to be standardized. This document also specifiesuser defineduser-defined metric-types where specifics are notdefined,defined so that administrators are free to assign semantics as they see fit.</t><t>In <xref target ='sec_bw_metric'/>,<!--[rfced] Should the section references be in order for ease of reading as shown below? Original: In Section 4, this document specifies a new bandwidth based metric type to be used with Flex-Algorithm and other applications.<xref target ='sec_fad_con'/>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... Perhaps: Section 3 defines additional FAD [RFC9350] constraints that allow the network administrator to preclude the use of low bandwidth links or high delay links. In Section 4, this document specifies a new bandwidth-based metric type to be used with Flex-Algorithm and other applications. Section 4.1 defines... --> <t>In <xreftarget ='RFC9350'/>target="sec_bw_metric" format="default"/>, this document specifies a new bandwidth-based metric type to be used with Flex-Algorithm and other applications. <xref target="sec_fad_con" format="default"/> defines additional FAD <xref target="RFC9350" format="default"/> constraints that allow the network administrator to preclude the use of low bandwidth links or high delay links.</t> <t> <xreftarget ='sec_auto_metric'/>target="sec_auto_metric" format="default"/> 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 linkcapacitycapacity, 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 <xreftarget ='RFC4655'/>target="RFC4655" format="default"/>, which has a dynamic view of the network and provides real-time bandwidth management or a distributed bandwidth management protocol.</t> <section anchor="req_lang" numbered="true" toc="default"> <name>Requirements Language</name> <t> The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>", "<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to be interpreted as described in BCP 14 <xref target="RFC2119"/> <xref target="RFC8174"/> when, and only when, they appear in all capitals, as shown here. </t> </section> </section> <sectiontitle="Genericanchor="sec_generic_metric" numbered="true" toc="default"> <name>Generic MetricAdvertisement" anchor='sec_generic_metric'>Advertisement</name> <t> IS-IS <xreftarget ='RFC1195'/>andtarget="RFC1195" format="default"/> and OSPF <xreftarget ='RFC2328'/>target="RFC2328" format="default"/> 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. <!--[rfced] Should "Min Unidirectional delay metric" be "Unidirectional Link Delay" or "Min/Max Unidirectional Link Delay" per RFCs 8570 and 7471? Original: The Traffic Engineering Default Metric is defined in [RFC5305] and [RFC3630] and the Min Unidirectional delay metric is defined in [RFC8570] and [RFC7471]. Perhaps: The Traffic Engineering Default Metric is defined in [RFC5305] and [RFC3630], and the Min/Max Unidirectional Link Delay is defined in [RFC8570] and [RFC7471]. --> The Traffic Engineering Default Metric is defined in <xreftarget ='RFC5305'/>target="RFC5305" format="default"/> and <xreftarget ='RFC3630'/>target="RFC3630" format="default"/>, and the Min Unidirectional delay metric is defined in <xreftarget ='RFC8570'/>target="RFC8570" format="default"/> and <xreftarget ='RFC7471'/>.target="RFC7471" format="default"/>. 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. </t> <t> Each generic metric advertisement is on a per-link andper-metric typeper-metric-type basis. The metric advertisement consists of a metric type field and a value for the metric. The metric type fieldishas been assignedbyin 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. </t><t>Implementations<!--[rfced] We find "TLV 22/extended link LSA/TE-LSAs" hard to read. How may we reword this for clarity and to also include the expansion of "LSA"? Also, should "generic metric sub-TLV" be singular and uppercase for consistency as shown below? Original: Implementations MUST support sending and receiving generic metric sub-TLV in Application Specific Link Attributes (ASLA)encodings as well as in the TLV 22/extended link LSA/TE-LSAs. Perhaps: Implementations MUST support sending and receiving a Generic Metric sub-TLV in Application-Specific Link Attributes (ASLA) encodings as well as in TLV 22 and extended Link State Advertisements (LSAs) and TE-LSAs. --> <t>Implementations <bcp14>MUST</bcp14> support sending and receiving generic metric 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 generic metric by an individual application is subject to the same rules that apply to other link attributes as defined in <xreftarget ='RFC3630'/>,target="RFC3630" format="default"/>, <xreftarget ='RFC5305'/>,target="RFC5305" format="default"/>, <xreftarget ='RFC9479'/>,target="RFC9479" format="default"/>, <xreftarget ='RFC9492'/>target="RFC9492" format="default"/>, and <xreftarget ='RFC9350'/>.</t>target="RFC9350" format="default"/>.</t> <sectiontitle="IS-ISanchor="sec_isis_gen_metric" numbered="true" toc="default"> <name>IS-IS Generic MetricSub-TLV" anchor='sec_isis_gen_metric'>Sub-TLV</name> <t>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:</t><t><list> <t>a. TLV-22<ol spacing="normal" type="a"> <li>TLV 22 (Extended IS reachability) <xreftarget ='RFC5305'/></t> <t>b. TLV-222target="RFC5305" format="default"/></li> <li>TLV 222 (MT-ISN) <xreftarget ='RFC5120'/></t> <t>c. TLV-23target="RFC5120" format="default"/></li> <li>TLV 23 (IS Neighbor Attribute) <xreftarget ='RFC5311'/></t> <t>d. TLV-223target="RFC5311" format="default"/></li> <li>TLV 223 (MT IS Neighbor Attribute) <xreftarget ='RFC5311'/> </t> <t>e. TLV-141 (inter-AS reachability information) <xref target ='RFC9346'/></t> <t>f.target="RFC5311" format="default"/></li> <li>TLV 141 (Inter-AS Reachability Information) <xref target="RFC9346" format="default"/></li> <!--[rfced] When referring to "TLV 22/222/23/223/141" (or "TLV 22/23/141/222/223" if updated), should "TLV" be plural (e.g., "TLVs 22/222/23/223/141")? We note that the plural form is used in the "Sub-TLVs for TLVs 22, 23, 141, 222, and 223" registry. Original: f. sub-TLV 16 (Application-Specific Link Attributes (ASLA)) of TLV 22/222/23/223/141<xref target ='RFC9479'/></t> <t>g.[RFC9479] g. TLV 25 (L2 Bundle Member Attributes) [RFC8668] Marked as "y(s)" (shareable among bundle members) ... One example in the running text (see the document for more instances). Original: 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. --> <li>sub-TLV 16 (Application-Specific Link Attributes (ASLA)) of TLV 22/222/23/223/141 <xref target="RFC9479" format="default"/></li> <li>TLV 25 (L2 Bundle Member Attributes) <xreftarget ='RFC8668'/>target="RFC8668" format="default"/>. Marked as "y(s)" (shareable among bundlemembers)</t> </list></t>members).</li> </ol> <t>The Generic Metric sub-TLV, typeTBD1 (IANA), and17, issix6 octets in length. </t> <figureanchor="isis_gen_metric_sub_tlv" title="IS-ISanchor="isis_gen_metric_sub_tlv"> <name>IS-IS Generic MetricSub-TLV"> <artwork>Sub-TLV</name> <artwork name="" type="" align="left" alt=""><![CDATA[ 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]]></artwork> </figure> <t> where: </t> <dl spacing="normal" newline="true"> <dt>Type (1octet): Anoctet):</dt> <dd>An 8-bit field assigned by IANA(To Be Determined as TBD1).(17). This value uniquely identifies the Generic MetricTLV. LengthTLV.</dd> <dt>Length (1octet): Anoctet):</dt> <dd>An 8-bit field indicating the total length, in octets, of the subsequent fields. For this TLV, the Length is set to4. Metric-Type4.</dd> <dt>Metric-Type (1octet): Anoctet):</dt> <dd>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 valuewhichthat is indicated as allowed in thegeneric metricGeneric Metric sub-TLV by theIGP Metric-Type Registry. Value"IGP Metric-Type" registry.</dd> <dt>Value (3octets): Aoctets):</dt> <dd>A 24-bit unsigned integer representing the metric value. The valid range is from 0 to 16,777,215(0xFFFFFF). </artwork> </figure> </t>(0xFFFFFF).</dd> </dl> <t> The Generic Metric sub-TLVMAY<bcp14>MAY</bcp14> be advertised multiple times. For a particular metric type, the Generic Metric sub-TLVMUST<bcp14>MUST</bcp14> be advertised only once for a link when advertised in TLV 22, 222, 23,223223, and 141. When the GenericmetricMetric sub-TLV is advertised in ASLA, each metric typeMUST<bcp14>MUST</bcp14> be advertised only once per-application for a link. If there are multiple Generic Metric sub-TLVs advertised for a link for the same metric type (and the same application in case of ASLA) in one or more receivedLSPDUs,Link State Protocol Data Units (LSPDUs), advertisement in thelowest numberedlowest-numbered fragmentMUST<bcp14>MUST</bcp14> beusedused, and the subsequent instancesMUST<bcp14>MUST</bcp14> be ignored. </t> <t>For a link, if the metric type corresponds to a metric type for which legacy advertisement mechanisms exist (e.g., the IGPmetric,Metric, theMinimumMin Unidirectional Link Delay, or the Traffic Engineering Default Metric), the legacy metric typesMUST<bcp14>MUST</bcp14> be utilized from the existing TLV or sub-TLVs. If a Generic Metric advertises a legacy metric, itMUST<bcp14>MUST</bcp14> be ignored..</t> <t>A metric value of 0xFFFFFF is consideredasa maximum linkmetricmetric, and a link having this metric valueMUST<bcp14>MUST</bcp14> be used duringFlex-algorithmFlex-Algorithm calculations as a last resort link as described insec 15.3 of<xreftarget ='RFC9350'/>.section="15.3" target="RFC9350" format="default"/>. A link can be made unusable byFlex-algorithmFlex-Algorithm by leaving out GenericmetricMetric advertisement of the particular metric-type that theFlex-algorithm usesFlex-Algorithm uses, as described in <xreftarget ='RFC9350'/>.target="RFC9350" format="default"/>. </t> <t> During the router maintenance activity, the Generic Metric for all the links on the nodeMAY<bcp14>MAY</bcp14> be set to a maximum value of 16,777,215 (0xFFFFFF), as it is the maximum usable link metric for theFlex-algorithmFlex-Algorithm calculations.</t> </section> <sectiontitle="OSPFanchor="sec_ospf_gen_metric" numbered="true" toc="default"> <name>OSPF Generic MetricSub-TLV" anchor='sec_ospf_gen_metric'>Sub-TLV</name> <t> 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:</t><t><list> <t>a.<ol type="a" spacing="normal"> <!--[rfced] Would it be correct to update "2" to "type 2" as shown below for clarity? Original: a. sub-TLV of TE Link TLV (2) of OSPF TE LSA<xref target ='RFC3630'/>.</t> <t>b.[RFC3630]. b. sub-TLV of TE Link TLV (2) of OSPFv2 Inter-AS-TE-v2 LSA<xref target ='RFC5392'/>.</t> <t>c.[RFC5392]. c. sub-TLV of TE Link TLV (2) of OSPFv3 Intra-Area-TE-LSA<xref target ='RFC5329'/>.</t> <t>d.[RFC5329]. d. sub-TLV of TE Link TLV (2) of OSPFv3 Inter-AS-TE-v3 LSA<xref target ='RFC5392'/>.</t> <t>e.[RFC5392]. Perhaps: a. sub-TLV of TE Link TLV (type 2) of OSPF TE LSA [RFC3630]. b. sub-TLV of TE Link TLV (type 2) of OSPFv2 Inter-AS-TE-v2 LSA [RFC5392]. c. sub-TLV of TE Link TLV (type 2) of OSPFv3 Intra-Area-TE-LSA [RFC5329]. d. sub-TLV of TE Link TLV (type 2) of OSPFv3 Inter-AS-TE-v3 LSA [RFC5392]. --> <li>sub-TLV of TE Link TLV (2) of OSPF TE LSA <xref target="RFC3630" format="default"/>.</li> <li>sub-TLV of TE Link TLV (2) of OSPFv2 Inter-AS-TE-v2 LSA <xref target="RFC5392" format="default"/>.</li> <li>sub-TLV of TE Link TLV (2) of OSPFv3 Intra-Area-TE-LSA <xref target="RFC5329" format="default"/>.</li> <li>sub-TLV of TE Link TLV (2) of OSPFv3 Inter-AS-TE-v3 LSA <xref target="RFC5392" format="default"/>.</li> <li>sub-TLV of Application-Specific Link Attributes (ASLA) sub-TLV <xreftarget ='RFC9492'/>target="RFC9492" format="default"/> of the OSPFv2 Extended Link TLV <xreftarget ='RFC7684'/>.</t> <t>f. sub-TLVtarget="RFC7684" format="default"/>.</li> <li>sub-TLV of Application-Specific Link Attributes (ASLA) sub-TLV <xreftarget ='RFC9492'/>target="RFC9492" format="default"/> of the OSPFv3 Router-Link TLV <xreftarget ='RFC8362'/>.</t> <t>g. sub-TLVtarget="RFC8362" format="default"/>.</li> <li>sub-TLV of the OSPFv2 L2 Bundle Member Attributes sub-TLV <xreftarget ='RFC9356'/>.</t> <t>h. sub-TLVtarget="RFC9356" format="default"/>.</li> <li>sub-TLV of the OSPFv3 L2 Bundle Member Attributes sub-TLV <xreftarget ='RFC9356'/>.</t> </list></t>target="RFC9356" format="default"/>.</li> </ol> <t>The Generic Metric sub-TLV,type TBD21/TBD22/TB23 (IANA), andtypes 25/36/34, is eight octets in length. </t> <figureanchor="ospf_gen_metric_sub_tlv" title="OSPFanchor="ospf_gen_metric_sub_tlv"> <name>OSPF Generic MetricSub-TLV "> <artwork>Sub-TLV</name> <artwork name="" type="" align="left" alt=""><![CDATA[ 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | metric-type | Reserved (MBZ) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Value | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Type]]></artwork> </figure> <t> where: </t> <dl spacing="normal" newline="true"> <dt>Type (2octets): Aoctets):</dt> <dd>A 16-bit field assigned by IANA(To Be Determined as TBD21/TBD22/TBD23).(25/36/34). This value uniquely identifies the Generic MetricTLV. LengthTLV.</dd> <dt>Length (2octets): Aoctets):</dt> <dd>A 16-bit field indicating the total length, in octets, of the subsequent fields. For this TLV, the Length is set to8. Metric-Type8.</dd> <dt>Metric-Type (1octet): Anoctet):</dt> <dd>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 valuewhichthat is indicated as allowed in thegeneric metricGeneric Metric sub-TLV by theIGP Metric-Type Registry. Reserved"IGP Metric-Type" registry.</dd> <dt>Reserved (3octets): Mustoctets):</dt> <dd>Must set to zero by the sender and must be ignored byreceiver. Valuethe receiver.</dd> <dt>Value (4octets): Aoctets):</dt> <dd>A 32-bit unsigned integer representing the metric value. The valid range is from 0 to4,294,967,295(0xFFFFFFFF). </artwork> </figure>4,294,967,295 (0xFFFFFFFF).</dd> </dl> <t>The Generic Metric sub-TLVMAY<bcp14>MAY</bcp14> be advertised multiple times. For a particular metric type, the Generic Metric sub-TLVMUST<bcp14>MUST</bcp14> be advertised only once for a link when advertised as (a) through (d) above. When the Generic Metric sub-TLV is advertised as a sub-TLV of ASLA, itMUST<bcp14>MUST</bcp14> be advertised only onceper-applicationper application for a link. If there are multiple Generic Metric sub-TLVs advertised for a link for the same metric type (and the same application in case of ASLA) in one or more received LSAs, advertisement in thelowest numberedlowest-numbered LSAMUST<bcp14>MUST</bcp14> beusedused, and the subsequent instancesMUST<bcp14>MUST</bcp14> be ignored.</t> <t>For a link, if the metric type corresponds to a metric type for which legacy advertisement mechanisms exist (e.g., the IGPmetric,Metric, theMinimumMin Unidirectional Link Delay, or the Traffic Engineering Default Metric), the legacy metric typesMUST<bcp14>MUST</bcp14> be utilized from the existing TLV or sub-TLVs. If a Generic Metric advertises a legacy metric, itMUST<bcp14>MUST</bcp14> be ignored. </t> <t>A metric value of 0xFFFFFFFF is consideredasa maximum linkmetricmetric, and a link having this metric valueMUST<bcp14>MUST</bcp14> be used duringFlex-algorithmFlex-Algorithm calculations as a last resortlinklink, as described insec 15.3 of<xreftarget ='RFC9350'/>.</t> </t>section="15.3" target="RFC9350" format="default"/>.</t> <t>A link can be made unusable byFlex-algorithmFlex-Algorithm by leaving out GenericmetricMetric advertisement of the particular metric-type that theFlex-algorithm usesFlex-Algorithm uses, as described in <xreftarget ='RFC9350'/>.</t>target="RFC9350" format="default"/>.</t> <t> During the router maintenance activity, the Generic Metric for all the links on the nodeMAY<bcp14>MAY</bcp14> be set to a maximum value of 4,294,967,295((0xFFFFFFFF),(0xFFFFFFFF), as it is the maximum usable link metric for theFlex-algorithmFlex-Algorithm calculations.</t> </section> <sectiontitle="Genericanchor="sec_multi_area" numbered="true" toc="default"> <name>Generic MetricapplicabilityApplicability to FlexibleAlgorithms Multi-domain/Multi-area networks " anchor='sec_multi_area'>Algorithm Multi-Domain/Multi-Area Networks</name> <t>Generic Metric can be used byFlex-AlgorithmsFlex-Algorithm by specifying the metric type in the Flexible Algorithm Definitions. WhenFlex-AlgorithmsFlex-Algorithm is used in a multi-area network, <xreftarget ='RFC9350'/>target="RFC9350" format="default"/> defines the Flexible Algorithm Prefix Metric (FAPM) sub-TLV that carries the Flexible-Algorithm-specific metric. Metrics carried in FAPM will be equal to the metric to reach the prefix for that Flex-Algorithm in its source area or domain (source area from theABRArea Border Router (ABR) perspective). When Flex-Algorithm uses Genericmetric,Metric, the same procedures as described insection 13 of<xreftarget ='RFC9350'/>target="RFC9350" sectionFormat="of" section="13"/> are used to send and process the FAPM sub-TLV.</t> </section> </section> <sectiontitle=" FAD constraint Sub-TLVs" anchor='sec_fad_con'>anchor="sec_fad_con" numbered="true" toc="default"> <name>FAD Constraint Sub-TLVs</name> <t> Large high throughput flows are referred to as "elephant flows". Directing an elephant flow down a low-bandwidth link might congest the link and cause other critical application traffic flowing on the link to drop. Thus, in the context of Flex-Algorithm, it would be useful to be able to constrain the topology to only those links capable of supporting a minimum amount of bandwidth.</t> <!--[rfced] Please clarify what "this" refers to in the following sentence. Original: If the capacity of a link is constant, this can already be achieved through the use of administrative groups. --> <t>If the capacity of a link is constant, this can already be achieved through the use of administrative groups. However, when alayer-3Layer 3 link is actually a collection oflayer-2Layer 2 links(LAG/layer-2(Link Aggregation Group (LAG) / Layer 2 Bundle), the link bandwidth will vary based on the set of active constituent links. This could be automated by having an implementation vary the advertised administrative groups based on bandwidth, but this seems unnecessarily complex and expressing this requirement as a direct constraint on the topology seems simpler. This is also advantageous if the minimum required bandwidth changes, as this constraint would provide a single centralized, coordinated point of control.</t> <t>To satisfy this requirement, this document defines an Exclude Minimum Bandwidth constraint. When this constraint is advertised in a FAD, a link will be pruned from the Flex-Algorithm topology if the link's advertised Maximum Link Bandwidth is below the advertised Minimum Bandwidth value.</t> <t>Similarly, this document defines an Exclude Maximum Link Delay constraint. Applications, such as High-Frequency Trading are sensitive to link delays and may perform poorly in networks prone to delay variability, such as those with transparent Layer 2 link recovery mechanisms or satellitelinks.".links. Mechanisms already exist to measure the link delay dynamically and advertise it in the IGP. Networks that employ dynamic link-delay measurement, may want to exclude links that have a delay over a given threshold.</t> <sectiontitle="IS-IS FAD constraint Sub-TLVs" anchor='sec_isis'> <section title="IS-ISanchor="sec_isis" numbered="true" toc="default"> <name>IS-IS FAD Constraint Sub-TLVs</name> <section anchor="sec_isis_bw_exclusion" numbered="true" toc="default"> <name>IS-IS Exclude Minimum Bandwidthsub-TLV" anchor='sec_isis_bw_exclusion'>Sub-TLV</name> <t> IS-IS Flex-Algorithm Exclude Minimum Bandwidthsub-TLV(FAEMB) sub-TLV is a sub-TLV of the IS-IS FAD sub-TLV. It has the following format: </t> <figureanchor="isis_faemb_sub_tlv" title="IS-ISanchor="isis_faemb_sub_tlv"> <name>IS-IS FAEMBSub-TLV"> <artwork>Sub-TLV</name> <artwork name="" type="" align="left" alt=""><![CDATA[ 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]]></artwork> </figure> <t>where:</t> <dl spacing="normal" newline="true"> <dt>Type (1octet): Anoctet):</dt> <dd>An 8-bit field assigned by IANA(To Be Determined as TBD3).(6). This value uniquely identifies the FAEMBsub-TLV. Lengthsub-TLV.</dd> <dt>Length (1octet): Anoctet):</dt> <dd>An 8-bit field indicating the total length, in octets, of the subsequent fields. For this sub-TLV, the Length is set to4. Min4.</dd> <dt>Min Bandwidth (4octets): Aoctets):</dt> <dd>A 32-bit field specifying the link bandwidth encoded in IEEE floating point format (32bits)[IEEE754-2019].bits) <xref target="IEEE754-2019"/>. The units arebytes-per-second. </artwork> </figure> </t>bytes per second.</dd> </dl> <t>The FAEMB sub-TLVMUST<bcp14>MUST</bcp14> appear once at mostoncein the FAD sub-TLV. If it appears more than once, the IS-IS FAD sub-TLVMUST<bcp14>MUST</bcp14> be ignored by the receiver. </t> <t>The Minimum bandwidth advertised in the FAEMB sub-TLVMUST<bcp14>MUST</bcp14> be compared with Maximum Link Bandwidth advertised in sub-sub-TLV 9 of the ASLA sub-TLV <xreftarget ='RFC9479'/>.target="RFC9479" format="default"/>. IfL-Flagthe L-flag is set in the ASLA sub-TLV, the Minimum bandwidth advertised in the FAEMB sub-TLVMUST<bcp14>MUST</bcp14> be compared with the Maximum Link Bandwidth as advertised in the sub-TLV 9 of the TLV 22/222/23/223/141 <xreftarget ='RFC5305'/>target="RFC5305" format="default"/>, as defined in <xreftarget ='RFC9479'/> Section 4.2.target="RFC9479" sectionFormat="of" section="4.2"/>. </t> <t>If the Maximum Link Bandwidth is lower than the Minimumlink bandwidthLink Bandwidth advertised in the FAEMB sub-TLV, the linkMUST<bcp14>MUST</bcp14> 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 linkMUST NOT<bcp14>MUST NOT</bcp14> be excluded from the topology based on the Minimum Bandwidth constraint. </t> </section> <sectiontitle="IS-ISanchor="sec_isis_delay_exclusion" numbered="true" toc="default"> <name>IS-IS Exclude Maximum DelaySub-TLV" anchor='sec_isis_delay_exclusion'>Sub-TLV</name> <t> IS-IS Flex-Algorithm Exclude Maximum Delaysub-TLV(FAEMD) sub-TLV is a sub-TLV of the IS-IS FAD sub-TLV. It has the followingformat.format: </t> <figureanchor="isis_faemd_sub_tlv" title="IS-ISanchor="isis_faemd_sub_tlv"> <name>IS-IS FAEMDSub-TLV"> <artwork>Sub-TLV</name> <artwork name="" type="" align="left" alt=""><![CDATA[ 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]]></artwork> </figure> <t>where:</t> <dl spacing="normal" newline="true"> <dt>Type (1octet): Anoctet):</dt> <dd>An 8-bit field assigned by IANA(To Be Determined as TBD4).(7). This value uniquely identifies the FAEMDsub-TLV. Lengthsub-TLV.</dd> <dt>Length (1octet): Anoctet):</dt> <dd>An 8-bit field indicating the total length, in octets, of the subsequent fields. For this sub-TLV, the Length is set to3. Max link delay3.</dd> <dt>Max Link Delay (3octets): Aoctets):</dt> <dd>A 24-bit field specifying the Maximum link delay inmicroseconds. </artwork> </figure> </t>microseconds.</dd> </dl> <t>The FAEMD sub-TLVMUST<bcp14>MUST</bcp14> appear only once in the FAD sub-TLV. If it appears more than once, the IS-IS FAD sub-TLVMUST<bcp14>MUST</bcp14> be ignored by the receiver.</t> <t>The Maximum link delay advertised in the FAEMD sub-TLVMUST<bcp14>MUST</bcp14> be compared with Min Unidirectional Link Delay advertised in sub-sub-TLV 34 of the ASLA sub-TLV <xreftarget ='RFC9479'/>.target="RFC9479" format="default"/>. If theL-FlagL-flag is set in the ASLA sub-TLV, the Maximum link delay advertised in the FAEMD sub-TLVMUST<bcp14>MUST</bcp14> be compared with Min Unidirectional Link Delay as advertised by the sub-TLV 34 of the TLV 22/222/23/223/141 <xreftarget ='RFC8570'/>target="RFC8570" format="default"/>, as defined in <xreftarget ='RFC9479'/> Section 4.2.target="RFC9479" sectionFormat="of" section="4.2"/>. </t> <t>If the Min Unidirectional Link Delay value is higher than the Maximum link delay advertised in the FAEMD sub-TLV, the linkMUST<bcp14>MUST</bcp14> 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 linkMUST NOT<bcp14>MUST NOT</bcp14> be excluded from the topology based on the Maximum Delay constraint. </t> </section> </section> <sectiontitle="OSPF FAD constraint Sub-TLVs" anchor='sec_ospf'> <section title="OSPFanchor="sec_ospf" numbered="true" toc="default"> <name>OSPF FAD Constraint Sub-TLVs</name> <section anchor="sec_ospf_bw_exclusion" numbered="true" toc="default"> <name>OSPF Exclude Minimum BandwidthSub-TLV" anchor='sec_ospf_bw_exclusion'>Sub-TLV</name> <t> OSPF Flex-Algorithm Exclude Minimum Bandwidthsub-TLV(FAEMB) sub-TLV is a sub-TLV of the OSPF FAD TLV. It has the following format: </t> <figureanchor="ospf_faemb_sub_tlv" title="OSPFanchor="ospf_faemb_sub_tlv"> <name>OSPF FAEMBSub-TLV"> <artwork>Sub-TLV</name> <artwork name="" type="" align="left" alt=""><![CDATA[ 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]]></artwork> </figure> <t>where:</t> <dl spacing="normal" newline="true"> <dt>Type (2octets): Aoctets):</dt> <dd>A 16-bit field assigned by IANA(To Be Determined as TBD5).(6). This value uniquely identifies the OSPF FAEMBsub-TLV. Lengthsub-TLV.</dd> <dt>Length (2octets): Aoctets):</dt> <dd>A 16-bit field indicating the total length, in octets, of the subsequent fields. For this sub-TLV, the Length is set to4. Min4.</dd> <dt>Min Bandwidth (4octets): Aoctets):</dt> <dd>A 32-bit field specifying the link bandwidth encoded in IEEE floating point format (32bits)[IEEE754-2019].bits)<xref target="IEEE754-2019"/>. The units arebytes-per-second. </artwork> </figure> </t>bytes per second.</dd> </dl> <t>The FAEMB sub-TLVMUST<bcp14>MUST</bcp14> only appear once in the FAD sub-TLV. If it appears more than once, the OSPF FAD TLVMUST<bcp14>MUST</bcp14> be ignored by the receiver.</t> <t>The Maximum Link Bandwidth as advertised in the Extended Link TLV in the Extended Link Opaque LSA in OSPFv2 <xreftarget ='RFC7684'/>target="RFC7684" format="default"/> or as a sub-TLV of the Router-Link TLV of the E-Router-LSA Router-Link TLV in OSPFv3 <xreftarget ='RFC8362'/> MUSTtarget="RFC8362" format="default"/> <bcp14>MUST</bcp14> be compared against the Minimum bandwidth advertised in the FAEMB sub-TLV. If the link bandwidth is lower than the Minimum bandwidth advertised in the FAEMB sub-TLV, the linkMUST<bcp14>MUST</bcp14> be excluded from the Flex-Algorithm topology. </t> <t>If a link does not have the Maximum Link Bandwidth advertised but the FAD contains this sub-TLV, then that linkMUST<bcp14>MUST</bcp14> be included in the topology and proceed to apply further pruning rules for the link. </t> </section> <sectiontitle="OSPFanchor="sec_ospf_delay_exclusion" numbered="true" toc="default"> <name>OSPF Exclude Maximum DelaySub-TLV" anchor='sec_ospf_delay_exclusion'>Sub-TLV</name> <t> The OSPF Flex-Algorithm Exclude Maximum Delaysub-TLV(FAEMD) sub-TLV is a sub-TLV of the OSPF FAD TLV. It has the following format. </t> <figureanchor="ospf_faemd_sub_tlv" title="OSPFanchor="ospf_faemd_sub_tlv"> <name>OSPF FAEMDSub-TLV"> <artwork>Sub-TLV</name> <artwork name="" type="" align="left" alt=""><![CDATA[ 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 | MaxlinkLink Delay | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+where: Type]]></artwork> </figure> <t>where:</t> <dl spacing="normal" newline="true"> <dt>Type (2octets): Aoctets):</dt> <dd>A 16-bit field assigned by IANA(To Be Determined as TBD6).(7). This value uniquely identifies the OSPF FAEMDsub-TLV. Lengthsub-TLV.</dd> <dt>Length (2octets): Aoctets):</dt> <dd>A 16-bit field indicating the total length, in octets, of the subsequent fields. For this sub-TLV, the Length is set to4. Reserved4.</dd> <dt>Reserved (1octet): Mustoctet):</dt> <dd>Must be set to zero by the sender and must be ignored byreceiver. Max link delaythe receiver.</dd> <dt>Max Link Delay (3octets): Aoctets):</dt> <dd>A 24-bit field specifying the Maximum link delay inmicroseconds. </artwork> </figure> </t>microseconds.</dd> </dl> <t> The FAEMD sub-TLVMUST<bcp14>MUST</bcp14> only appear once in the OSPF FAD TLV. If it appears more than once, the OSPF FAD TLVMUST<bcp14>MUST</bcp14> be ignored by the receiver. </t> <t>The Min Delay value advertised via the Min/Max Unidirectional Link Delay of the ASLA sub-TLV <xreftarget ='RFC9492'/>, MUSTtarget="RFC9492" format="default"/> <bcp14>MUST</bcp14> 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 linkMUST<bcp14>MUST</bcp14> be excluded from the Flex-Algorithm topology. If the Min/Max Unidirectional Link Delay is not advertised for a link but the FAD contains thissub-TLV,thensub-TLV, then that linkMUST NOT<bcp14>MUST NOT</bcp14> be excluded from the topology based on the Maximum Delay constraint. </t> </section> </section> </section> <sectiontitle="Bandwidthanchor="sec_bw_metric" numbered="true" toc="default"> <name>Bandwidth MetricAdvertisement" anchor='sec_bw_metric'>Advertisement</name> <t> Historically, IGP implementations have made default metric assignments based on link bandwidth. This has proven to beuseful,useful but has suffered from having different defaults across implementations and from the rapid growth of link bandwidths. With Flex-Algorithm, the network administrator can define a function that will produce a metric for each link and have each node automatically compute each link's metric based on its bandwidth.</t> <t>This document defines a standard metric type for this purpose called the "Bandwidth Metric". The Bandwidth MetricMAY<bcp14>MAY</bcp14> be advertised in the Generic Metric sub-TLV with the metric type set to "Bandwidth Metric". IS-IS and OSPF will advertise this type of metric in their link advertisements. <!--[rfced] May we update this sentence for clarity as shown below? Original: Bandwidth metric is a link attribute and for the advertisement and processing of this attribute for Flex-algorithm, MUST follow the section 12 of [RFC9350]. Perhaps: The Bandwidth Metric is a link attribute, and it MUST follow Section 12 of [RFC9350] for its advertisement and processing during Flex-Algorithm calculation. --> The Bandwidth Metric is a link attribute and for the advertisement and processing of this attribute for Flex-Algorithm, <bcp14>MUST</bcp14> follow <xreftarget ='RFC9350'/></t>target="RFC9350" sectionFormat="of" section="12"/>.</t> <t> 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 FADTLVTLV, and these parameters are applicable to applications such asFlex-algorithmFlex-Algorithm that make use of the FAD TLV. </t> <sectiontitle="Automaticanchor="sec_auto_metric" numbered="true" toc="default"> <name>Automatic MetricCalculation" anchor='sec_auto_metric'>Calculation</name> <t> Networkswhichthat are designed to be highly regular and that follow uniform metric assignment may want to simplify their operations by automatically calculating the bandwidth metric. When a FAD advertises the metric type as Bandwidth Metric and the link does not have the Bandwidth Metric advertised, automatic metric derivation can be used with additional FAD constraint advertisement as described in this section. </t> <t> 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 <xreftarget ='I-D.bashandy-rtgwg-segment-routing-uloop'/>target="I-D.bashandy-rtgwg-segment-routing-uloop" format="default"/> or any other mechanism as described in the framework <xreftarget ='RFC5715'/>target="RFC5715" format="default"/> can be used to avoid micro-loops when the automatic metric calculation is deployed.</t> <t> 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.</t> <sectiontitle="Automaticanchor="sec_auto_metric_mode" numbered="true" toc="default"> <name>Automatic Metric CalculationModes" anchor='sec_auto_metric_mode'>Modes</name> <sectiontitle="Simple Mode" anchor='sec_simple'>anchor="sec_simple" numbered="true" toc="default"> <name>Simple Mode</name> <t> In simple mode, the Maximum Link Bandwidth of a singlelayer-3Layer 3 link is used to derive the metric. This mode is suitable for deployments that do not use parallellayer-3Layer 3 links. In this case, the computation of the metric is straightforward. If alayer-3Layer 3 link is composed of alayer-2Layer 2 bundle, then the link bandwidth is the sum of the bandwidths of the working components and may vary withlayer-2Layer 2 link failures. </t> </section> <sectiontitle="Interfaceanchor="sec_intf_grp" numbered="true" toc="default"> <name>Interface GroupMode" anchor='sec_intf_grp'>Mode</name> <t> The simple mode of metric calculation may not work well when there are multiple parallellayer-3Layer 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 parallellayer-2Layer 2 links or parallellayer-3Layer 3 links. To address this, in Interface Group Mode, nodesMUST<bcp14>MUST</bcp14> compute the aggregate bandwidth of all parallel adjacencies,MUST<bcp14>MUST</bcp14> derive the metric based on the aggregate bandwidth, andMUST<bcp14>MUST</bcp14> apply the resulting metric to each of the parallel adjacencies. Note that a single elephant flow is normally pinned to a singlelayer-3Layer 3 interface. If the singlelayer-3Layer 3 link bandwidth is not sufficient for any single elephant flow, the mechanisms to solve this issue are outside the scope of this document. </t> <figureanchor="interface_grp" title="Parallel interfaces"> <artwork>anchor="interface_grp"> <name>Parallel Interfaces</name> <artwork name="" type="" align="left" alt=""><![CDATA[ A------B====C====F====D | | ------E-------</artwork>]]></artwork> </figure> <t> For example, in the above diagram, there are two parallel links betweenB->C, C->F, F->D.B->C, C->F, F->D. Let us assume the link bandwidth is uniform10Gbps10 Gbps on all links. When bandwidth is used to derive the metric for the links, the metric for each link will be the same. Traffic from B to D will be forwardedB->E->Das B->E->D because the metric will be lower. Since the bandwidth is higher on theB->C->F->DB->C->F->D path, the metric for that path should be lower than theB->E->DB->E->D path to attract the traffic onB->C->F->Dthe B->C->F->D path. Interface Group Mode should be preferred in cases where there are parallellayer-3Layer 3 links. </t> <t> In theinterface group mode,Interface Group Mode, every nodeMUST<bcp14>MUST</bcp14> identify the set of parallel links between a pair of nodes based on IGP link advertisements andMUST<bcp14>MUST</bcp14> consider cumulative bandwidth of the parallel links while arriving at the metric of each link. </t> <t>The parallellayer-3Layer 3 links between two nodes may not have the same bandwidth. In suchcasescases, the method described ininterface group modeInterface Group Mode will result in the same metric being used for all the parallellinkslinks, which may cause undesiredload-balancingload balancing on the links. In such cases, a device may locally apply a load-balancing factor relative to the link bandwidth on the ECMPnexthops.next hops. The load-balancing mechanisms are outside the scope of this document.</t> </section> </section> <sectiontitle="Automaticanchor="sec_auto_metric_methods" numbered="true" toc="default"> <name>Automatic Metric CalculationMethods" anchor='sec_auto_metric_methods'>Methods</name> <t> In automatic metric calculation for simple andinterface group mode,Interface Group Mode, Maximum Link Bandwidth of the links is used to derive the metric. There are two types of automatic metric derivation methods.</t><t> <list> <t> 1. Reference<ol type="1" spacing="normal"> <li>Reference bandwidthmethod</t> <t> 2. Bandwidthmethod</li> <li>Bandwidth thresholdsmethod </t> </list> </t>method</li> </ol> <sectiontitle="Referenceanchor="sec_ref_bw_method" numbered="true" toc="default"> <name>Reference Bandwidthmethod" anchor='sec_ref_bw_method'>Method</name> <t>In many networks, the metric is inversely proportional to the link bandwidth. The administrator or implementation selects a reference bandwidth and the metric is derived by dividing the reference bandwidth by the advertised Maximum Link Bandwidth. Advertising the reference bandwidth in the FAD constraints allows the metric computation to be done on every node for each link. The metric is computed using reference bandwidth and the advertised link bandwidth. Centralized control of this reference bandwidth simplifies management in the casethatwhere 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. </t><t> For<t>For example,</t><t><list> <t>reference<t indent="3">reference bandwidth = 1000G </t><t>Granularity<t indent="3">Granularity = 20G </t><t>The<t indent="3">The derived metric is 10 for link bandwidth in the range 100G to 119G </t></list></t></section> <sectiontitle="Bandwidthanchor="sec_bw_threshold_method" numbered="true" toc="default"> <name>Bandwidth Thresholdsmethod" anchor='sec_bw_threshold_method'>Method</name> <t> The reference bandwidth approach described above provides a uniform metric value for a range of link bandwidths. In certaincasescases, 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 70Ggetare assigned a metric value of 50, and bandwidths greater than 70G have a metric of 10. In order to support this, a staircase mapping based on bandwidth thresholds is supported in the FAD. This advertisement contains a set of threshold values and associated metrics. </t> </section> </section> <sectiontitle="IS-ISanchor="sec_auto_isis" numbered="true" toc="default"> <name>IS-IS FADconstraintConstraint Sub-TLVs forautomatic metric calculation" anchor='sec_auto_isis'>Automatic Metric Calculation</name> <sectiontitle="Referenceanchor="sec_isis_auto_ref_bw" numbered="true" toc="default"> <name>Reference BandwidthSub-TLV" anchor='sec_isis_auto_ref_bw'>Sub-TLV</name> <t> This section provides FAD constraint advertisement details for the reference bandwidth method of metriccalculationcalculation, as described in <xreftarget ='sec_ref_bw_method'/>.target="sec_ref_bw_method" format="default"/>. The Flexible Algorithm Definition Reference Bandwidth (FADRB) sub-TLV(FADRB sub-TLV)is a sub-TLV of the IS-IS FAD sub-TLV. It has the following format: </t> <figureanchor="isis_fadrb_sub_tlv" title="IS-ISanchor="isis_fadrb_sub_tlv"> <name>IS-IS FADRBSub-TLV"> <artwork>Sub-TLV</name> <artwork name="" type="" align="left" alt=""><![CDATA[ 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]]></artwork> </figure> <t>where:</t> <dl spacing="normal" newline="true"> <dt>Type (1octet): Anoctet):</dt> <dd>An 8-bit field assigned by IANA(To Be Determined as TBD7).(8). This value uniquely identifies the IS-IS FADRBsub-TLV. Lengthsub-TLV.</dd> <dt>Length (1octet): Anoctet):</dt> <dd>An 8-bit field indicating the total length, in octets, of the subsequent fields. For this sub-TLV, the Length is set to9. Flags9.</dd> <dt>Flags (1octet): Anoctet):</dt> <dd><t>An 8-bit field containingflags.flags.</t> <artwork name="" type="" align="left" alt=""><![CDATA[ 0 1 2 3 4 5 6 7 +-+-+-+-+-+-+-+-+ |G| | +-+-+-+-+-+-+-+-+G-flag: When]]></artwork></dd> <dt>G-flag:</dt> <dd>When set, Interface Group ModeMUST<bcp14>MUST</bcp14> be used to derive total link bandwidth. Unassigned bitsMUST<bcp14>MUST</bcp14> be set tozero. Referencezero.</dd> <dt>Reference Bandwidth (4octets): Aoctets):</dt> <dd>A 32-bit field with Bandwidth encoded in IEEE floating point format[IEEE754-2019].<xref target="IEEE754-2019"/>. The units arebytes-per-second. Granularitybytes per second.</dd> <dt>Granularity Bandwidth (4octets): Aoctets):</dt> <dd>A 32-bit field with Bandwidth encoded in IEEE floating point format[IEEE754-2019].<xref target="IEEE754-2019"/>. The units arebytes-per-second. Whenbytes per second.</dd> </dl> <t>When granularity_bw is less than or equal toTotal_link_bandwidth Metric calculation: (Reference_bandwidth)Total_link_bandwidth, then:</t> <dl spacing="normal" newline="false"> <dt>Metric calculation:</dt><dd>(Reference_bandwidth) / (Total_link_bandwidth - (Modulus of(Total_link_bandwidth,granularity_bw))) Whengranularity_bw)))</dd> </dl> <t>When granularity_bw is greater thanTotal_link_bandwidth Metric calculation: Reference_bandwidthTotal_link_bandwidth, then:</t> <dl spacing="normal" newline="false"> <dt>Metric calculation:</dt><dd>Reference_bandwidth /Total_link_bandwidth TheTotal_link_bandwidth</dd> </dl> <t>The division used here is integer division. Modulus of operation is defined as a remainder value when two numbers aredivided. </artwork> </figure> </t>divided.</t> <t> 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-TLVMUST NOT<bcp14>MUST NOT</bcp14> appear more than once in an IS-IS FAD sub-TLV. If it appears more than once, the IS-IS FAD sub-TLVMUST<bcp14>MUST</bcp14> be ignored by the receiver. The value advertised in the Reference Bandwidth fieldMUST<bcp14>MUST</bcp14> be non-zero. If a zero value is advertised in the Reference BandwidthFieldfield in the IS-IS FADRB sub-TLV, the sub-TLVMUST<bcp14>MUST</bcp14> be ignored.</t> <t>If a Generic Metric sub-TLV with a Bandwidth metric type is advertised for a link, the Flex-Algorithm calculationMUST<bcp14>MUST</bcp14> use the advertised BandwidthMetric,Metric andMUST NOT<bcp14>MUST NOT</bcp14> 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,Thethe individual link Bandwidth MetricMUST<bcp14>MUST</bcp14> be used. If only some links among the parallel links have the Bandwidth Metric advertisement, the Bandwidth Metric for such linksMUST<bcp14>MUST</bcp14> beignoredignored, and automatic Metric calculationMUST<bcp14>MUST</bcp14> be used to derive link metric. </t> <t>If the calculated metric evaluates to zero, a metric of 1MUST<bcp14>MUST</bcp14> be used.</t> <t> If the calculated metric evaluates to a number greater than 0xFFFFFF, it is set to 0xFFFFFF.</t> </section> <sectiontitle="Bandwidth Thresholds Sub-TLV" anchor='sec_isis_threshold_metric'>anchor="sec_isis_threshold_metric" numbered="true" toc="default"> <name>Bandwidth Threshold Sub-TLV</name> <t> This section provides FAD constraint advertisement details for the Bandwidth Thresholds method of metric calculation as described in <xreftarget ='sec_bw_threshold_method'/>.target="sec_bw_threshold_method" format="default"/>. The Flexible Algorithm Definition Bandwidth Threshold (FADBT) sub-TLV(FADBT sub-TLV)is a sub-TLV of the IS-IS FAD sub-TLV. It has the following format: </t> <figureanchor="isis_fadbt_sub_tlv" title="IS-ISanchor="isis_fadbt_sub_tlv"> <name>IS-IS FADBTSub-TLV"> <artwork>Sub-TLV</name> <artwork name="" type="" align="left" alt=""><![CDATA[ 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Flags | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Bandwidth Threshold 1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Threshold Metric 1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Bandwidth Threshold 2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Threshold Metric 2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Bandwidth Threshold 3 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ..... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Threshold Metric N-1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Bandwidth Threshold N | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Threshold Metric N | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+where: Type]]></artwork> </figure> <t>where:</t> <dl spacing="normal" newline="true"> <dt>Type (1octet):octet):</dt> <dd> An 8-bit field assigned by IANA(To Be Determined as TBD8).(9). This value uniquely identifies the IS-IS FADBTsub-TLV. Lengthsub-TLV.</dd> <dt>Length (1octet): Anoctet):</dt> <dd>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 nHere, N is equal to the number of Threshold Metrics specified. nMUST<bcp14>MUST</bcp14> be greater than or equal to1 Flags1.</dd> <dt>Flags (1octet):octet):</dt> <dd><artwork name="" type="" align="left" alt=""><![CDATA[ 0 1 2 3 4 5 6 7 +-+-+-+-+-+-+-+-+ |G| | | | +-+-+-+-+-+-+-+-+G-flag: when]]></artwork> <dl spacing="normal" newline="false"> <dt>G-flag:</dt><dd>When set,interface groupInterface Group ModeMUST<bcp14>MUST</bcp14> be used to derive total linkbandwidth. Unassigned bits MUSTbandwidth.</dd> <dt>Unassigned bits</dt><dd> <bcp14>MUST</bcp14> be set tozero.zero.</dd> </dl> </dd> </dl> <!--[rfced] We updated this text to make it a complete sentence. There are two instances in the document. Please let us know if this is not correct. Original: Staircase bandwidth threshold and associated metric values.BandwidthCurrent: Following is the staircase bandwidth threshold and associated metric values. --> <t>Following is the staircase bandwidth threshold and associated metric values.</t> <dl spacing="normal" newline="true"> <dt>Bandwidth Threshold 1 (4octets): Minimumoctets):</dt> <dd>Minimum Link Bandwidth is encoded ininIEEE floating point format (32bits)[IEEE754-2019].bits)<xref target="IEEE754-2019"/>. The units arebytes-per-second. Thresholdbytes per second.</dd> <dt>Threshold Metric 1 (3octets): Metricoctets):</dt> <dd>Metric value range (1 - 16,777,215(0xFFFFFF)) Bandwidth(0xFFFFFF))</dd> <dt>Bandwidth Threshold n (4octets): Maximumoctets):</dt> <dd>Maximum Link Bandwidth is encoded in IEEE floating point format (32bits)[IEEE754-2019].bits)<xref target="IEEE754-2019"/>. The units arebytes-per-second. Thresholdbytes per second.</dd> <dt>Threshold Metric n (3octest) : Metricoctets):</dt> <dd>Metric value range (1 - 16,777,215(0xFFFFFF)) </artwork> </figure> </t>(0xFFFFFF))</dd> </dl> <t>When the G-flag is set, the cumulative bandwidth of the parallel links is computed as described in <xreftarget ='sec_intf_grp'/>.target="sec_intf_grp" format="default"/>. If the G-flag is not set, the advertised Maximum Link Bandwidth is used.</t><t>Assignment<t>The assignment of the Bandwidth MetricBasedbased onComputed Link Bandwidth:</t>computed link bandwidth is described below.</t> <t>The Bandwidth Metric for a link during the Flex-Algorithm Shortest Path First (SPF) calculationMUST<bcp14>MUST</bcp14> be assigned according to the following rules:</t><t> <list> <t>1. When<ol type="1" spacing="normal"> <li><t>When the computed link bandwidth is less than Bandwidth Threshold1: <ul> <li> The1:</t> <t>The Bandwidth MetricMUST<bcp14>MUST</bcp14> be set to the maximum metric value of4,261,412,864.</li> </ul> </t> <t>2. When4,261,412,864.</t> </li> <li><t>When the computed link bandwidth is greater than or equal to Bandwidth Threshold 1 and less than Bandwidth Threshold2: <ul> <li> The2:</t> <t>The Bandwidth MetricMUST<bcp14>MUST</bcp14> be set to Threshold Metric1.</li> </ul> </t> <t>3. When1.</t> </li> <li><t>When the computed link bandwidth is greater than or equal to Bandwidth Threshold 2 and less than Bandwidth Threshold3: <ul> <li> The3:</t> <t>The Bandwidth MetricMUST<bcp14>MUST</bcp14> be set to Threshold Metric2.</li> </ul> </t> <t>4. In2.</t> </li> <li><t>In general, for all integer values of X such that 1 ≤ X <N: <ul> <li> WhenN:</t> <t>When the computed link bandwidth is greater than or equal to Bandwidth Threshold X and less than Bandwidth ThresholdX+1:</li> <li> TheX+1:</t> <t>The Bandwidth MetricMUST<bcp14>MUST</bcp14> be set to Threshold MetricX.</li> </ul> </t> <t>5. WhenX.</t> </li> <li><t>When the computed link bandwidth is greater than or equal to Bandwidth ThresholdN: <ul> <li> TheN:</t> <t>The Bandwidth MetricMUST<bcp14>MUST</bcp14> be set to Threshold MetricN.</li> </ul> </t> </list> </t> <t>Notes: <list> <t>TheN.</t> </li> </ol> <t>Notes:</t> <ul spacing="normal"> <li>The termBandwidth"Bandwidth ThresholdXX" refers to a predefined threshold value corresponding to the indexX.</t> <t>TheX.</li> <li>The termThreshold"Threshold MetricXX" refers to the metric value associated with Bandwidth ThresholdX.</t> <t>NX.</li> <li>N represents the total number of bandwidth thresholds defined in thesystem.</t> </list> </t>system.</li> </ul> <t>ImplementationsMUST<bcp14>MUST</bcp14> ensure that these rules are consistently applied to maintain interoperability and optimal path computation within the network.</t> <t>The IS-IS FADBT sub-TLVMUST NOT<bcp14>MUST NOT</bcp14> appear more than once in an IS-IS FAD sub-TLV. If it appears more than once, the IS-IS FAD sub-TLVMUST<bcp14>MUST</bcp14> be ignored by the receiver.</t> <t>A FADMUST NOT<bcp14>MUST NOT</bcp14> contain both the FADBT sub-TLV and the FADRB sub-TLV. If both of these sub-TLVs are advertised in the same FAD for a Flexible Algorithm, the FADMUST<bcp14>MUST</bcp14> be ignored by the receiver.</t> <t>If a Generic Metric sub-TLV with Bandwidth metric type is advertised for a link, the Flex-Algorithm calculationMUST<bcp14>MUST</bcp14> use the Bandwidth Metric advertised on thelink,link andMUST NOT<bcp14>MUST NOT</bcp14> use the automatically derived metric for that link.</t><t>In<!--[rfced] We note similar text in Sections 4.1.3.1, 4.1.3.2, and 4.1.4.2. Should any of this text be in paragraph form or bulleted form for consistency? Original Section 4.1.3.1: 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. Section 4.1.3.2: 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. Section 4.1.4.2: In the context of Interface Group Mode, the following rules apply to parallel links: * If all parallel links have advertised the Bandwidth Metric: The individual link Bandwidth Metrics MUST be used for each link during path computation. * If only some of the parallel links have advertised the Bandwidth Metric: - The Bandwidth Metric advertisements for those links MUST be ignored. - Automatic metric calculation MUST be used to derive the link metrics for all parallel links. --> <t>In case of Interface Group Mode, if all the parallel links have been advertised with the Bandwidth Metric, the individual link Bandwidth Metric <bcp14>MUST</bcp14> be used. If only some links among the parallel links have advertised the Bandwidth Metric, the Bandwidth Metric for such links <bcp14>MUST</bcp14> be ignored and automatic Metric calculation <bcp14>MUST</bcp14> be used to derive the link metric.</t> </section> </section> <sectiontitle="OSPFanchor="sec_auto_ospf" numbered="true" toc="default"> <name>OSPF FADconstraintConstraint Sub-TLVs forautomatic metric calculation" anchor='sec_auto_ospf'>Automatic Metric Calculation</name> <sectiontitle="Referenceanchor="sec_ospf_auto_ref_bw" numbered="true" toc="default"> <name>Reference BandwidthSub-TLV" anchor='sec_ospf_auto_ref_bw'>Sub-TLV</name> <t> The Flexible Algorithm Definition Reference Bandwidth (FADRB) sub-TLV(FADRB sub-TLV)is a sub-TLV of the OSPF FAD TLV. It has the following format: </t> <figureanchor="ospf_fadrb_sub_tlv" title="OSPFanchor="ospf_fadrb_sub_tlv"> <name>OSPF FADRBSub-TLV"> <artwork>Sub-TLV</name> <artwork name="" type="" align="left" alt=""><![CDATA[ 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]]></artwork> </figure> <t>where:</t> <dl spacing="normal" newline="true"> <dt>Type (2octets): Aoctets):</dt> <dd>A 16-bit field assigned by IANA(To Be Determined as TBD9).(8). This value uniquely identifies the OSPF FADRBsub-TLV. Lengthsub-TLV.</dd> <dt>Length (2octets): Aoctets):</dt> <dd>A 16-bit field indicating the total length, in octets, of the subsequent fields. For this sub-TLV, Length is set to14. Flags14.</dd> <dt>Flags (1octet):octet):</dt> <dd><artwork name="" type="" align="left" alt=""><![CDATA[ 0 1 2 3 4 5 6 7 +-+-+-+-+-+-+-+-+ |G| | | | +-+-+-+-+-+-+-+-+G-flag: When]]></artwork> <dl spacing="normal" newline="false"> <dt>G-flag:</dt><dd>When set, Interface Group ModeMUST<bcp14>MUST</bcp14> be used to derive total linkbandwidth. Unassigned bits MUSTbandwidth.</dd> <dt>Unassigned bits</dt><dd> <bcp14>MUST</bcp14> be set tozero. Referencezero.</dd> </dl></dd> <dt>Reference Bandwidth (4octets): Bandwidthoctets):</dt> <dd>Bandwidth encoded in 32 bits in IEEE floating point format[IEEE754-2019].<xref target="IEEE754-2019"/>. The units are in bytes persecond. Granularitysecond.</dd> <dt>Granularity Bandwidth (4octets): Bandwidthoctets):</dt> <dd>Bandwidth encoded in 32 bits in IEEE floating point format[IEEE754-2019].<xref target="IEEE754-2019"/>. The units are in bytes persecond. Whensecond.</dd> </dl> <t>When granularity_bw is less than or equal toTotal_link_bandwidth Metric calculation: (Reference_bandwidth)Total_link_bandwidth, then:</t> <dl spacing="normal" newline="true"> <dt>Metric calculation:</dt><dd>(Reference_bandwidth) / (Total_link_bandwidth - (Modulus of(Total_link_bandwidth,granularity_bw))) Whengranularity_bw)))</dd> </dl> <t>When granularity_bw is greater thanTotal_link_bandwidth Metric calculation: Reference_bandwidth/ Total_link_bandwidth TheTotal_link_bandwidth, then:</t> <dl spacing="normal" newline="true"> <dt>Metric calculation:</dt><dd>Reference_bandwidth/ Total_link_bandwidth</dd> </dl> <t>The division used here is integerdivision. Modulusdivision.</t> <t>Modulus of operation is defined as a remainder value when two numbers aredivided. </artwork> </figure> Thedivided.</t> <t>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-TLVMUST NOT<bcp14>MUST NOT</bcp14> appear more than once in an OSPF FAD TLV. If it appears more than once, the OSPF FAD TLVMUST<bcp14>MUST</bcp14> be ignored by thereceiver.Thereceiver. The value advertised in the Reference Bandwidth fieldMUST<bcp14>MUST</bcp14> be non-zero. If a zero value is advertised in the Reference BandwidthFieldfield in the OSPF FADRB sub-TLV, the sub-TLVMUST<bcp14>MUST</bcp14> be ignored. If a Generic Metric sub-TLV with Bandwidth metric type is advertised for a link, the Flex-Algorithm calculationMUST<bcp14>MUST</bcp14> use the advertised Bandwidth Metric on thelink,link andMUST NOT<bcp14>MUST NOT</bcp14> use the automatically derived metric for that link. In the case of Interface Group Mode, the following procedures apply:<list></t> <ul spacing="normal"> <li> <t> When all parallel links have advertised the Bandwidth Metric: The individual link Bandwidth MetricMUST<bcp14>MUST</bcp14> be used for each link.</t> </li> <li> <t> When only a subset of the parallel links have advertised the Bandwidth Metric: The Bandwidth Metric advertisements for those linksMUST<bcp14>MUST</bcp14> be ignored. In this scenario, automatic metric calculationMUST<bcp14>MUST</bcp14> be used to derive the link metrics for all parallel links.</t></list> </t></li> </ul> <t>If the calculated metric evaluates to zero, a metric of 1MUST<bcp14>MUST</bcp14> be used.</t> <t> If the calculated metric evaluates to a number greater than 0xFFFFFFFF, it is set to 0xFFFFFFFF.</t> </section> <sectiontitle="Bandwidthanchor="sec_ospf_threshold_metric" numbered="true" toc="default"> <name>Bandwidth ThresholdSub-TLV" anchor='sec_ospf_threshold_metric'>Sub-TLV</name> <t> The Flexible Algorithm Definition BandwidthThresholdsThreshold (FADBT) sub-TLV(FADBT sub-TLV)is a sub-TLV of the OSPF FAD TLV. It has the following format: </t> <figureanchor="ospf_fadbt_sub_tlv" title="OSPFanchor="ospf_fadbt_sub_tlv"> <name>OSPF FADBTSub-TLV"> <artwork>Sub-TLV</name> <artwork name="" type="" align="left" alt=""><![CDATA[ 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Flags | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Bandwidth Threshold 1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Threshold Metric 1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Bandwidth Threshold 2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Threshold Metric 2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Bandwidth Threshold 3 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ..... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Threshold Metric N-1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Bandwidth Threshold N | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Threshold Metric N | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+where: Type]]></artwork> </figure> <t>where:</t> <dl spacing="normal" newline="true"> <dt>Type (2octets): Aoctets):</dt> <dd>A 16-bit field assigned by IANA(To Be Determined as TBD10).(9). This value uniquely identifies the OSPF FADBTsub-TLV. Lengthsub-TLV.</dd> <dt>Length (2octets): Aoctets):</dt> <dd>A 16-bit field indicating the total length, in octets, of the subsequent fields. For this sub-TLV, Length is set to 2 + N*8 octets.HereHere, N is equal to the number of Threshold Metrics specified. NMUST<bcp14>MUST</bcp14> be greater than or equal to1. Flags1.</dd> <dt>Flags (1octet):octet):</dt> <dd> <artwork name="" type="" align="left" alt=""><![CDATA[ 0 1 2 3 4 5 6 7 +-+-+-+-+-+-+-+-+ |G| | +-+-+-+-+-+-+-+-+G-flag: when]]></artwork> <dl spacing="normal" newline="false"> <dt>G-flag:</dt><dd>When set,interface groupInterface Group ModeMUST<bcp14>MUST</bcp14> be used to derive total linkbandwidth. Unassigned bits MUSTbandwidth.</dd> <dt>Unassigned bits</dt><dd><bcp14>MUST</bcp14> be set tozero. Staircasezero.</dd> </dl> </dd> </dl> <t>Following is the staircase bandwidth threshold and associated metricvalues. Bandwidthvalues.</t> <dl spacing="normal" newline="true"> <dt>Bandwidth Threshold 1 (4octets): Minimumoctets):</dt> <dd>Minimum Link Bandwidth is encoded in IEEE floating point format (32bits)[IEEE754-2019].bits)<xref target="IEEE754-2019"/>. The units are bytes persecond. Thresholdsecond.</dd> <dt>Threshold Metric 1 (4octets): Metricoctets):</dt> <dd>Metric value range (1 - 4,294,967,296(0xFFFFFFFF)) Bandwidth(0xFFFFFFFF))</dd> <dt>Bandwidth Threshold N (4 octets):Maximum</dt> <dd>Maximum Link Bandwidth is encoded in IEEE floating point format (32bits)[IEEE754-2019].bits)<xref target="IEEE754-2019"/>. The units are bytes persecond. Thresholdsecond.</dd> <dt>Threshold Metric N (4octets): Metricoctets):</dt> <dd>Metric value range (1 - 4,294,967,296(0xFFFFFFFF)) </artwork> </figure> </t>(0xFFFFFFFF))</dd> </dl> <t>When the G-flag is set, the cumulative bandwidth of the parallel links is computed as described in <xreftarget ='sec_intf_grp'/>.target="sec_intf_grp" format="default"/>. If the G-flag is not set, the advertised Maximum Link Bandwidth is used.</t><t>Assignment<t>The assignment of the Bandwidth MetricBasedbased onComputed Link Bandwidth:</t> <t>Thecomputed link bandwidth is described below.</t> <t>During the Flex-Algorithm SPF calculation, the Bandwidth Metric for a linkduring the Flex-Algorithm Shortest Path First (SPF) calculation MUST<bcp14>MUST</bcp14> be assigned according to the following rules:</t><t> <list> <t>1. When<ol type="1" spacing="normal"> <li><t>When the computed link bandwidth is less than Bandwidth Threshold1: <ul> <li>The1:</t> <t>The Bandwidth MetricMUST<bcp14>MUST</bcp14> be set to the maximum metric value of4,294,967,296.</li> </ul> </t> <t>2. When4,294,967,296.</t></li> <li><t>When the computed link bandwidth is greater than or equal to Bandwidth Threshold 1 and less than Bandwidth Threshold2: <ul> <li>The2:</t> <t>The Bandwidth MetricMUST<bcp14>MUST</bcp14> be set to Threshold Metric1.</li> </ul> </t> <t>3. When1.</t> </li> <li><t>When the computed link bandwidth is greater than or equal to Bandwidth Threshold 2 and less than Bandwidth Threshold3: <ul> <li> The3:</t> <t>The Bandwidth MetricMUST<bcp14>MUST</bcp14> be set to Threshold Metric2.</li> </ul> </t> <t>4. In2.</t></li> <li><t>In general, for all integer values of X where 1 ≤X <N: <ul> <li>WhenN:</t> <t>When the computed link bandwidth is greater than or equal to Bandwidth Threshold X and less than Bandwidth ThresholdX+1:</li> <li>TheX+1:</t> <t>The Bandwidth MetricMUST<bcp14>MUST</bcp14> be set to Threshold MetricX.</li> </ul> </t> <t>5. WhenX.</t></li> <li><t>When the computed link bandwidth is greater than or equal to Bandwidth ThresholdN: <ul> <li>TheN:</t> <t>The Bandwidth MetricMUST<bcp14>MUST</bcp14> be set to Threshold MetricN.</li> </ul> </t> </list> </t> <t>Notes: <list>N.</t></li> </ol> <t>Notes:</t> <ul spacing="normal"> <li> <t>Bandwidth Threshold X refers to the predefined bandwidth threshold corresponding to index X.</t> </li> <li> <t>Threshold Metric X is the metric value associated with Bandwidth Threshold X.</t> </li> <li> <t>N represents the total number of bandwidth thresholds defined in the system.</t></list> </t></li> </ul> <t>ImplementationsMUST<bcp14>MUST</bcp14> consistently apply these rules to ensure accurate path computations and maintain interoperability within the network.</t> <t>The OSPF FADBT sub-TLVMUST NOT<bcp14>MUST NOT</bcp14> appear more than once in an OSPF FAD sub-TLV. If it appears more than once, the OSPF FADMUSTsub-TLV <bcp14>MUST</bcp14> be ignored by the receiver.</t> <t>A FADMUST NOT<bcp14>MUST NOT</bcp14> 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 FADMUST<bcp14>MUST</bcp14> be ignored by the receiver.</t> <t>If a Generic Metric sub-TLV with Bandwidth metric type is advertised for a link, the Flex-Algorithm calculationMUST<bcp14>MUST</bcp14> use the Bandwidth Metric advertised on thelink,link andMUST NOT<bcp14>MUST NOT</bcp14> use the automatically derived metric for that link.</t> <t> Metric Assignment in Interface Group Mode:</t> <t>When a link does not have a configured Bandwidth Metric, the automatically derived metricMUST<bcp14>MUST</bcp14> be used for that link.</t> <t>In the context of Interface Group Mode, the following rules apply to parallel links:</t><t> <list> <t> If<ul spacing="normal"> <li> <t>If all parallel links have advertised the BandwidthMetric: <ul> <li>TheMetric:</t> <t>The individual link Bandwidth MetricsMUST<bcp14>MUST</bcp14> be used for each link during pathcomputation.</li> </ul> </t>computation.</t> </li> <li> <t>If only some of the parallel links have advertised the BandwidthMetric:Metric:</t> <ul> <li>The Bandwidth Metric advertisements for those linksMUST<bcp14>MUST</bcp14> be ignored.</li> <li>Automatic metric calculationMUST<bcp14>MUST</bcp14> be used to derive the link metrics for all parallel links.</li> </ul></t> </list> </t></li> </ul> <t>This approach ensures consistent metric calculation and avoids discrepancies caused by partial Bandwidth Metric advertisements among parallel links.</t> </section> </section> </section> </section> <sectiontitle='Bandwidth metric considerations' anchor='sec-metric'>anchor="sec-metric" numbered="true" toc="default"> <name>Bandwidth Metric Considerations</name> <t> 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".<list> <t>1. If</t> <ol type="1" spacing="normal"> <li>If the Generic Metric sub-TLV with Bandwidth metric type is advertised for the link as described in <xreftarget ='sec_bw_metric'/>,target="sec_bw_metric" format="default"/>, itMUST<bcp14>MUST</bcp14> be used during the Flex-Algorithmcalculation.</t> <t>2. Ifcalculation.</li> <li>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 <xreftarget ='sec_auto_metric'/> ),target="sec_auto_metric" format="default"/>), the link is treated as if the Bandwidth Metric is not available for thelink.</t> <t>3. Iflink.</li> <li>If the Generic Metric sub-TLV with Bandwidth metric type is not advertised for the link and the winning FAD(sec 5.3 <xref target ='RFC9350'/>(<xref section="5.3" target="RFC9350" format="default"/>) for the Flex-Algorithm specifies the automatic bandwidth metric calculation (as defined in <xreftarget ='sec_auto_metric'/>),target="sec_auto_metric" format="default"/>), the Bandwidth Metricmetric MUST<bcp14>MUST</bcp14> be automatically calculatedasper the procedures defined in <xreftarget ='sec_auto_metric'/>.target="sec_auto_metric" format="default"/>. If the Link Bandwidth is not advertised for a link, the linkMUST<bcp14>MUST</bcp14> be pruned for the Flex-Algorithmcalculations.</t> <t>4.In ISIScalculations.</li> <li>In ISIS, for Flex-Algorithm purposes, the Link Bandwidthfor Flex-Algorithm purposesis advertised as a sub-sub-TLV 9 of theFlex-algorithm specificFlex-Algorithm-specific ASLA sub-TLV. It is also possible to advertise the link bandwidth orFlex-Algorithm,Flex-Algorithm in sub-TLV 9 of TLV 22/222/23/223/141[RFC5305],<xref target="RFC5305"/> together with theL-FlagL-flag set in theFlex-Algorithm specificFlex-Algorithm-specific ASLA advertisement. In the absence of both of these advertisements, the bandwidth of the link is not available for Flex-Algorithmpurposes.</t> </list> </t>purposes.</li> </ol> </section><section title='Calculation<!-- This section sounds like this it updates RFC 9350. Please confirm that an Updates tag is not needed on this document. Original: 6. Calculation of Flex-Algorithmpaths' anchor='sec-calc'> <t>paths Two new additional rules are added to the existing rules in theFlex-AlgorithmFlex- Algorithm calculations specified in Section 13 of<xref target ='RFC9350'/>.</t> <t> <list> <t>6.[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-Algorithmcomputation.</t> <t>7.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-Algorithmcomputation.</t> </list> </t>computation. --> <section anchor="sec-calc" numbered="true" toc="default"> <name>Calculation of Flex-Algorithm Paths</name> <t>The following two new additional rules are added to the existing rules in the Flex-Algorithm calculations specified in <xref target="RFC9350" sectionFormat="of" section="13"/>:</t> <blockquote> <ol spacing="normal" start="6"> <li>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 <bcp14>MUST</bcp14> be pruned from the Flex-Algorithm computation.</li> <li>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 <bcp14>MUST</bcp14> be pruned from the Flex-Algorithm computation.</li> </ol> </blockquote> </section> <sectionanchor='backward_compatibility' title='Backward Compatibility'>anchor="backward_compatibility" numbered="true" toc="default"> <name>Backward Compatibility</name> <t> This extension brings no new backward-compatibility issues. This document defines new FAD constraints in Sections <xreftarget ='sec_fad_con'/>target="sec_fad_con" format="counter"/>, <xreftarget ='sec_auto_isis'/>target="sec_auto_isis" format="counter"/>, and <xreftarget ='sec_auto_ospf'/>.target="sec_auto_ospf" format="counter"/>. As described in <xreftarget ='RFC9350'/>,target="RFC9350" format="default"/>, any node that does not understand sub-TLVs in a FADTLV,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 <xreftarget ='sec_generic_metric'/>.target="sec_generic_metric" format="default"/>. As perSection 13 of<xreftarget ='RFC9350'/>,target="RFC9350" sectionFormat="of" section="13"/>, when the linksthatdo not advertise the metric-type specified by the selected FAD, the link is pruned from Flex-Algorithm calculations. The new metric-types andtheFlex-Algorithms using the new metric-types can be deployed in the network without affecting existing deployment. </t> </section> <sectiontitle='Security Considerations' anchor='sec-con'>anchor="sec-con" numbered="true" toc="default"> <name>Security Considerations</name> <t>This document inherits security considerations from <xreftarget ='RFC9350'/>.</t>target="RFC9350" format="default"/>.</t> </section> <sectiontitle='Operational Considerations' anchor='sec-ops'>anchor="sec-ops" numbered="true" toc="default"> <name>Operational Considerations</name> <t>Operationalconsiderationconsiderations defined in <xreftarget ='RFC9350'/>target="RFC9350" format="default"/> generally apply to the extensions defined in this document as well. This document defines a metric-type range foruser defineduser-defined metrics. When user-defined metrics are used in an inter-area or inter-level network, all the domains should assign same meaning to the particular metric-type. The YANG data models for Flex-Algorithm extensions are defined in documents <xreftarget ='I-D.ietf-lsr-ospf-yang-augmentation-v1'/>target="I-D.ietf-lsr-ospf-yang-augmentation-v1" format="default"/> and <xreftarget ='I-D.ietf-lsr-isis-yang-augmentation-v1'/></t>target="I-D.ietf-lsr-isis-yang-augmentation-v1" format="default"/>.</t> <t>Before the router goes into maintenance activity, the traffic needs to be diverted away from the router. This is achieved by setting the overload bit or setting link metrics on the router to a high value. In case of Generic Metric, the link metrics can be set to a Maximum usable metric for OSPF andISIS.IS-IS. The traffic will be diverted away from the router to a shorter available path. If there are no alternate paths available, traffic will stay on the router as the links are not removed fromFlex-algorithmthe Flex-Algorithm calculation when they are set to a maximum metricasper <xreftarget ='RFC9350'/>target="RFC9350" format="default"/>. </t> </section> <section anchor="IANA"title="IANA Considerations"> <section anchor='igp_metric_type' title='IGPnumbered="true" toc="default"> <name>IANA Considerations</name> <section anchor="igp_metric_type" numbered="true" toc="default"> <name>IGP Metric-TypeRegistry'> <t>IGP Metric-type Registry isRegistry</name> <t>The "IGP Metric-Type" registry has been updated to include another column specifying whether the particular metric-type is allowed in thegeneric-metric sub-TLV or not.Generic Metric sub-TLV. The range 128-255 isbeingredefinedinby this document as a user-definedrangerange, and this range does notstandards action.require Standards Action <xref target="RFC8126"/>. </t><t> <figure anchor="iana_metric_type" title="IANA IGP<table anchor="iana_metric_type"> <name>IGP Metric-TypeRegistry"> <artwork> Type Description Reference Allowed in generic-metric ---------------------------------------------------------------- 0 IGP Metric [RFC9350] No Section 5.1 1 MinRegistry</name> <thead> <tr> <th>Type</th> <th>Description</th> <th>Reference</th> <th>Allowed in Generic-Metric</th> </tr> </thead> <tbody> <tr> <td>0</td> <td>IGP Metric</td> <td><xref target="RFC9350" sectionFormat="of" section="5.1"/></td> <td>No</td> </tr> <tr> <td>1</td> <td>Min Unidirectional[RFC9350] NoLink Delay as definedSection 5.1in[RFC8570, Section 4.2],and [RFC7471, Section 4.2] 2 Traffic<xref target="RFC8570" sectionFormat="comma" section="4.2"/> and <xref target="RFC7471" sectionFormat="comma" section="4.2"/></td> <td><xref target="RFC9350" sectionFormat="of" section="5.1"/></td> <td>No</td> </tr> <tr> <td>2</td> <td>Traffic Engineering Default[RFC9350] NoMetric as defined inSection 5.1 [RFC5305,Section 3.7],<xref target="RFC5305" sectionFormat="comma" section="3.7"/> and[RFC3630, Section 2.5.5] 3(TBA) BandwidthTraffic Engineering Metricthis document yes 128-255(TBA) Useras definedmetric this document yes </artwork> </figure> </t> </section> <section anchor='isis_fad' title='IS-ISin <xref target="RFC3630" sectionFormat="comma" section="2.5.5"/></td> <td><xref target="RFC9350" sectionFormat="of" section="5.1"/></td> <td>No</td> </tr> <tr> <td>3</td> <td>Bandwidth Metric</td> <td>RFC 9843</td> <td>Yes</td> </tr> <tr> <td>128-255</td> <td>Reserved for User-Defined Metric</td> <td>RFC 9843</td> <td>Yes</td> </tr> </tbody> </table> </section> <section anchor="isis_fad" numbered="true" toc="default"> <name>IS-IS Sub-Sub-TLVs for Flexible Algorithm DefinitionSub-TLV'> <t>IS-ISSub-TLV</name> <t>The "IS-IS Sub-Sub-TLVs for Flexible Algorithm DefinitionSub-TLVSub-TLV" registry is part of the“IS-IS"IS-IS TLVCodepoints”Codepoints" registry group.</t><t> Type: 6(TBD3)</t> <t> Description: IS-IS<dl spacing="compact" newline="false"> <dt>Type:</dt><dd>6</dd> <dt>Description:</dt><dd>IS-IS Exclude MinimumBandwidth Sub-TLV </t> <t>Reference: This document <xref target ='sec_isis_bw_exclusion'/></t> <t> Type: 7 (TBD4)</t> <t> Description: IS-ISBandwidth</dd> <dt>Reference:</dt><dd>RFC 9843, <xref target="sec_isis_bw_exclusion" format="default"/></dd> </dl> <dl spacing="compact" newline="false"> <dt>Type:</dt><dd>7</dd> <dt>Description:</dt><dd>IS-IS Exclude MaximumDelay Sub-TLV </t> <t>Reference: This document <xref target ='sec_isis_delay_exclusion'/></t> <t> Type: 8 (TBD7)</t> <t> Description: IS-ISDelay</dd> <dt>Reference:</dt><dd>RFC 9843, <xref target="sec_isis_delay_exclusion" format="default"/></dd> </dl> <dl spacing="compact" newline="false"> <dt>Type:</dt><dd>8</dd> <dt>Description:</dt><dd>IS-IS ReferenceBandwidth Sub-TLV </t> <t>Reference: This document <xref target ='sec_isis_auto_ref_bw'/></t> <t> Type: 9(TBD8)</t> <t> Description: IS-IS Threshold Metric Sub-TLV </t> <t>Reference: This document <xref target ='sec_isis_threshold_metric'/></t> </section> <section anchor='ospf_fad' title='OSPFBandwidth</dd> <dt>Reference:</dt><dd>RFC 9843, <xref target="sec_isis_auto_ref_bw" format="default"/></dd> </dl> <dl spacing="compact" newline="false"> <dt>Type:</dt><dd>9</dd> <dt>Description:</dt><dd>IS-IS Bandwidth Threshold</dd> <dt>Reference:</dt><dd>RFC 9843, <xref target="sec_isis_threshold_metric" format="default"/></dd> </dl> </section> <section anchor="ospf_fad" numbered="true" toc="default"> <name>OSPF Sub-TLVs for Flexible Algorithm DefinitionSub-TLV'> <t>OSPFSub-TLV</name> <t>The "OSPF Flexible Algorithm Definition TLVSub-TLVsSub-TLVs" registry is part of the“Open"Open Shortest Path First (OSPF)Parameters”Parameters" registry group.</t><t> Type:6 (TBD5)</t> <t> Description: OSPF<dl spacing="compact" newline="false"> <dt>Bit Number:</dt><dd>6</dd> <dt>Description:</dt><dd>OSPF Exclude MinimumBandwidth Sub-TLV </t> <t>Reference: This document <xref target ='sec_ospf_bw_exclusion'/></t> <t> Type: 7(TBD6)</t> <t> Description: OSPFBandwidth</dd> <dt>Reference:</dt><dd>RFC 9843, <xref target="sec_ospf_bw_exclusion" format="default"/></dd> </dl> <dl spacing="compact" newline="false"> <dt>Bit Number:</dt><dd>7</dd> <dt>Description:</dt><dd>OSPF Exclude MaximumDelay Sub-TLV </t> <t>Reference: This document <xref target ='sec_ospf_delay_exclusion'/></t> <t> Type: 8(TBD9)</t> <t> Description: OSPFDelay</dd> <dt>Reference:</dt><dd>RFC 9843, <xref target="sec_ospf_delay_exclusion" format="default"/></dd> </dl> <dl spacing="compact" newline="false"> <dt>Bit Number:</dt><dd>8</dd> <dt>Description:</dt><dd>OSPF ReferenceBandwidth Sub-TLV </t> <t>Reference: This document <xref target ='sec_ospf_auto_ref_bw'/></t> <t> Type: 9 (TBD10)</t> <t> Description: OSPF Threshold Metric Sub-TLV </t> <t>Reference: This document <xref target ='sec_ospf_threshold_metric'/></t> </section> <section anchor='isis_gen_metric' title='IS-ISBandwidth</dd> <dt>Reference:</dt><dd>RFC 9843, <xref target="sec_ospf_auto_ref_bw" format="default"/></dd> </dl> <dl spacing="compact" newline="false"> <dt>Bit Number:</dt><dd>9</dd> <dt>Description:</dt><dd>OSPF Bandwidth Threshold</dd> <dt>Reference:</dt><dd>RFC 9843, <xref target="sec_ospf_threshold_metric" format="default"/></dd> </dl> </section> <section anchor="isis_gen_metric" numbered="true" toc="default"> <name>IS-IS Sub-TLVs for TLVs Advertising NeighborInformation'> <t>IS-ISInformation</name> <t>The "IS-IS Sub-TLVs for TLVs Advertising NeighborInformationInformation" registry is part of the“IS-IS"IS-IS TLVCodepoints”Codepoints" registrygroup</t> <t> Type:17 (TBD1)</t> <t> Description: Generic metric </t> <t>Reference: This document <xref target ='sec_isis_gen_metric'/></t> <t> TLV 22,23,25, 141, 222 and 223group.</t> <dl spacing="compact" newline="false"> <dt>Type:</dt><dd>17</dd> <dt>Description:</dt><dd>Generic Metric</dd> <dt>TLVs set toY</t>"Y":</dt><dd>22, 23, 25, 141, 222, and 223</dd> <dt>Reference:</dt><dd>RFC 9843, <xref target="sec_isis_gen_metric" format="default"/></dd> </dl> </section> <sectionanchor='isis_gen_metric_te_app' title='Sub-sub-TLVanchor="isis_gen_metric_te_app" numbered="true" toc="default"> <name>Sub-Sub-TLV Codepoints for Application-Specific LinkAttributes'> <t>IS-IS Sub-sub-TLVAttributes</name> <t>The "IS-IS Sub-Sub-TLV Codepoints for Application-Specific LinkAttributesAttributes" registry is part of the“IS-IS"IS-IS TLVCodepoints”Codepoints" registrygroup</t> <t> Type: 17 (TBD1)</t> <t> Description: Generic metric </t> <t>Reference: This document <xref target ='sec_isis_gen_metric'/></t> </section> <section anchor='ospf_gen_metric' title='OSPFv2group.</t> <dl spacing="compact" newline="false"> <dt>Type:</dt><dd>17</dd> <dt>Description:</dt><dd>Generic Metric</dd> <dt>Reference:</dt><dd>RFC 9843, <xref target="sec_isis_gen_metric" format="default"/></dd> </dl> </section> <section anchor="ospf_gen_metric" numbered="true" toc="default"> <name>OSPFv2 Extended Link TLVSub-TLVs'> <t> OSPFv2Sub-TLVs</name> <t>The "OSPFv2 Extended Link TLVSub-TLVsSub-TLVs" registry is part of the“Open"Open Shortest Path First v2 (OSPFv2)Parameters”Parameters" registrygroup</t> <t> Type: 25(TBD21)</t> <t> Description: Generic metric </t> <t>Reference: This document <xref target ='sec_ospf_gen_metric'/></t> <t> L2BM set to Y</t> </section> <section anchor='ospf_gen_metric_te_lsa' title='Typesgroup.</t> <dl spacing="compact" newline="false"> <dt>Value:</dt><dd>25</dd> <dt>Description:</dt><dd>Generic Metric</dd> <dt>L2BM:</dt><dd>Y</dd> <dt>Reference:</dt><dd>RFC 9843, <xref target="sec_ospf_gen_metric" format="default"/></dd> </dl> </section> <section anchor="ospf_gen_metric_te_lsa" numbered="true" toc="default"> <name>Types for Sub-TLVs of TE Link TLV (Value2)'> <t> Types2)</name> <t>The "Types forSub-TLVssub-TLVs of TE Link TLV (Value2)2)" registry is part of the“Open"Open Shortest Path First (OSPF) Traffic EngineeringTLVs”TLVs" registrygroup</t> <t> Type: 36 (TBD22)</t> <t> Description: Generic metric </t> <t> Reference: This document <xref target ='sec_ospf_gen_metric'/></t> </section> <section anchor='ospfv3_gen_metric_te_lsa' title='OSPFv3group.</t> <dl spacing="compact" newline="false"> <dt>Value:</dt><dd>36</dd> <dt>Description:</dt><dd>Generic Metric</dd> <dt>Reference:</dt><dd>RFC 9843, <xref target="sec_ospf_gen_metric" format="default"/></dd> </dl> </section> <section anchor="ospfv3_gen_metric_te_lsa" numbered="true" toc="default"> <name>OSPFv3 Extended-LSASub-TLVs'>Sub-TLVs</name> <t>OSPFv3The "OSPFv3 Extended-LSASub-TLVsSub-TLVs" registry is part of the“Open"Open Shortest Path First v3 (OSPFv3)Parameters”Parameters" registrygroup</t> <t> Type: 34 (TBD23)</t> <t> Description: Generic metric </t> <t> Reference: This document <xref target ='sec_ospf_gen_metric'/></t> <t> L2BM set to Y</t>group.</t> <dl spacing="compact" newline="false"> <dt>Value:</dt><dd>34</dd> <dt>Description:</dt><dd>Generic Metric</dd> <dt>L2BM:</dt><dd>Y</dd> <dt>Reference:</dt><dd>RFC 9843, <xref target="sec_ospf_gen_metric" format="default"/></dd> </dl> </section> </section><section title='Acknowledgements' anchor='ack'> <t>Many thanks to Chris Bowers, Krzysztof Szarcowitz, Julian Lucek, Ram Santhanakrishnan, Ketan Talaulikar and Acee Lindem</middle> <back> <displayreference target="I-D.bashandy-rtgwg-segment-routing-uloop" to="SR-LOOP-AVOID"/> <displayreference target="I-D.ietf-lsr-isis-yang-augmentation-v1" to="ISIS-AUGMENTATION"/> <displayreference target="I-D.ietf-lsr-ospf-yang-augmentation-v1" to="OSPF-AUGMENTATION"/> <references> <name>References</name> <references> <name>Normative References</name> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5305.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3630.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7684.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9479.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9492.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8362.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9350.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9356.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5392.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5329.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8668.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.1195.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2328.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8126.xml"/> <reference anchor="IEEE754-2019" target=""> <front> <title>IEEE Standard fordiscussions and inputs.</t> </section> <section title='Contributors'> <t>1. Salih K A</t> <t>Juniper Networks</t> <t>salih@juniper.net</t> </section> <section title='APPENDIX' anchor='app'>Floating-Point Arithmetic</title> <author> <organization>IEEE</organization> </author> <date day="22" month="July" year="2019"/> </front> <seriesInfo name="IEEE Std" value="754-2019"/> <seriesInfo name="DOI" value="10.1109/ieeestd.2019.8766229"/> </reference> </references> <references> <name>Informative References</name> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8570.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7471.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5311.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9346.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5120.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5715.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4655.xml"/> <!-- [I-D.ietf-lsr-ospf-yang-augmentation-v1] draft-ietf-lsr-ospf-yang-augmentation-v1-16 IESG State: I-D Exists as of 07/29/25. --> <xi:include href="https://bib.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-lsr-ospf-yang-augmentation-v1.xml"/> <!-- [I-D.ietf-lsr-isis-yang-augmentation-v1] draft-ietf-lsr-isis-yang-augmentation-v1-09 IESG State: I-D Exists as of 07/29/25. --> <xi:include href="https://bib.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-lsr-isis-yang-augmentation-v1.xml"/> <!-- [I-D.bashandy-rtgwg-segment-routing-uloop] draft-bashandy-rtgwg-segment-routing-uloop-17 IESG State: Expired as of 07/29/25. --> <xi:include href="https://bib.ietf.org/public/rfc/bibxml3/reference.I-D.bashandy-rtgwg-segment-routing-uloop.xml"/> </references> </references> <sectiontitle='Updated listanchor="rules" numbered="true" toc="default"> <name>Updated List ofrulesRules forpruning linksPruning Links inFlex-algorithm topology ' anchor='rules'>Flex-Algorithm Topology</name> <t>This section lists the entire set of rules to prune links from Flex-Algorithm topology duringFlexible-algorithmFlexible Algorithm calculation. It includes the original rules defined inSection 13 of<xreftarget ='RFC9350'/>target="RFC9350" sectionFormat="of" section="13"/> as well as the new additionsproposed(rules 6 and 7) described in thisdocument. <list>document.</t> <t>For all links in the topology:</t><t>1. Check<ol type="1" spacing="normal"> <li>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 linkMUST<bcp14>MUST</bcp14> be pruned from thecomputation.</t> <t>2. Checkcomputation.</li> <li>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 isa lsoalso part of the SRLG exclude rule. If the link is part of such SRLG, the linkMUST<bcp14>MUST</bcp14> be pruned from thecomputation.</t> <t>3. Checkcomputation.</li> <li>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 linkMUST<bcp14>MUST</bcp14> be pruned from thecomputation.</t> <t>4. Checkcomputation.</li> <li>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 linkMUST<bcp14>MUST</bcp14> be pruned from thecomputation.</t> <t>5. Ifcomputation.</li> <li>If the Flex-Algorithm Definition uses something other than the IGP metric(Section 5 of <xref target ='RFC9350'/>),(<xref target="RFC9350" sectionFormat="of" section="5"/>), and such metric is not advertised for the particular link in a topology for which the computation is done, such linkMUST<bcp14>MUST</bcp14> be pruned from the computation. A metric of value 0MUST NOT<bcp14>MUST NOT</bcp14> be assumed in such acase.</t> <t>6. Checkcase.</li> <li>Check if any exclude FAEMB rule is part of the Flex-Algorithmdefinition.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 linkMUST<bcp14>MUST</bcp14> be pruned from the Flex-Algorithmcomputation.</t> <t>7. Checkcomputation.</li> <li>Check if any exclude FAEMD rule is part of the Flex-Algorithmdefinition.Definition. If such exclude rule exists and the link has Min Unidirectionallink delayLink Delay advertised, check if the link delay satisfies the FAEMD rule. If the link does not satisfy the FAEMD rule, the linkMUST<bcp14>MUST</bcp14> be pruned from the Flex-Algorithmcomputation.</t> </list> </t>computation.</li> </ol> </section> <section anchor="ack" numbered="false" toc="default"> <name>Acknowledgements</name> <t>Many thanks to <contact fullname="Chris Bowers"/>, <contact fullname="Krzysztof Szarcowitz"/>, <contact fullname="Julian Lucek"/>, <contact fullname="Ram Santhanakrishnan"/>, <contact fullname="Ketan Talaulikar"/>, and <contact fullname="Acee Lindem"/> for discussions and input.</t> </section> <section numbered="false" toc="default"> <name>Contributors</name> <contact fullname="Salih K.A."> <organization>Juniper Networks</organization> <address> <email>salih@juniper.net</email> </address> </contact> </section></middle> <back> <references title='Normative References'> &RFC2119; &RFC8174; &RFC5305; &RFC3630; &RFC7684; &RFC9479; &RFC9492; &RFC8362; &RFC9350; &RFC9356; &RFC5392; &RFC5329; &RFC8668; &RFC1195; &RFC2328; <reference anchor="IEEE754"> <front> <title>IEEE Standard<!-- [rfced] Please review whether any of the notes in this document should be in the <aside> element. It is defined as "a container forFloating-Point Arithmetic</title> <author> <organization>Institutecontent that is semantically less important or tangential to the content that surrounds it" (https://authors.ietf.org/en/rfcxml-vocabulary#aside). --> <!-- [rfced] Terminology a) Throughout the text, the following terminology appears to be used inconsistently. Please review these occurrences and let us know if/how they may be made consistent. Bandwidth metric type vs. bandwidth metric calculation (Should "bandwidth metric calculation" be "Bandwidth metric calculation" to match "Bandwidth metric type"?) metric-type vs. metric type Minimum Bandwidth value vs. Minimum bandwidth advertised (Are these terms different or should "bandwidth" be uppercase for consistency?) Maximum Delay constraint vs. Maximum delay advertised (Are these terms different or should "delay" be uppercase for consistency? Min Delay value (used once in this document) Is this the intended term or should it perhaps be "Minimum Delay value" or "Min Unidirectional Link Delay value"? b) We updated the document to reflect the forms on the right for consistency. Please let us know ofElectricalany objections. Bandwidth metric -> Bandwidth Metric bytes-per-second -> bytes per second Flex-algorithm -> Flex-Algorithm (per RFC 9350) Flex-Algorithm definition -> Flex Algorithm Definition (per RFC 9350) Flexible Algorithm Definition Bandwidth Thresholds -> Flexible Algorithm Definition Bandwidth Threshold (singular) Generic metric -> Generic Metric (for consistency andElectronics Engineers</organization> </author> <date day="22" month="July" year="2019"/> </front> <seriesInfo name="IEEE" value="754-2019"/> <seriesInfo name="DOI" value="10.1109/ieeestd.2019.8766229"/> <format target="https://ieeexplore.ieee.org/document/8766220" type="HTML"/> </reference> </references> <references title='Informative References'> &RFC8570; &RFC7471; &RFC5311; &RFC9346; &RFC5120; &RFC5715; &RFC4655; <?rfc include="reference.I-D.ietf-lsr-ospf-yang-augmentation-v1"?> <?rfc include="reference.I-D.ietf-lsr-isis-yang-augmentation-v1"?> <?rfc include="reference.I-D.bashandy-rtgwg-segment-routing-uloop"?> </references>per IANA) IGP metric -> IGP Metric (per RFC 9350 and IANA) ISIS -> IS-IS interface group mode -> Interface Group Mode L-Flag -> L-flag (per RFC 9350) layer-2 -> Layer 2 layer-3 -> Layer 3 Max link delay -> Max Link Delay Min Unidirectional link delay and Minimum Unidirectional Link Delay -> Min Unidirectional Link Delay (per RFC 9350) Minimum link bandwidth -> Minimum Link Bandwidth nexthops -> next hops Reference Bandwidth Field -> Reference Bandwidth field c) Should "simple mode" be made uppercase to match "Interface Group Mode" since they are both listed as automatic metric calculation modes? --> <!-- [rfced] Abbreviations a) FYI - We have added expansions for the following abbreviations per Section 3.6 of RFC 7322 ("RFC Style Guide"). Please review each expansion in the document carefully to ensure correctness. Area Border Router (ABR) Link Aggregation Group (LAG) Link State Advertisement (LSA) Link State Protocol Data Unit (LSPDU) b) We made the following change to follow use in RFC 9350. Please let us know of any objections. Flex-Algorithm Definition (FAD) -> Flexible Algorithm Definition (FAD) --> <!-- [rfced] Please review the "Inclusive Language" portion of the online Style Guide <https://www.rfc-editor.org/styleguide/part2/#inclusive_language> and let us know if any changes are needed. Updates of this nature typically result in more precise language, which is helpful for readers. Note that our script did not flag any words in particular, but this should still be reviewed as a best practice. --> </back> </rfc>