rfc9843xml2.original.xml   rfc9843.xml 
<?xml version="1.0"?> <?xml version='1.0' encoding='UTF-8'?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY RFC2119 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.
RFC.2119.xml">
<!ENTITY RFC5305 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.
RFC.5305.xml">
<!ENTITY RFC7684 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.
RFC.7684.xml">
<!ENTITY RFC5311 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">
]>
<?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 category="std" docName="draft-ietf-lsr-flex-algo-bw-con-22" ipr="trust20090
2">
<front>
<title abbrev="IGP Flex-Algorithm: Bandwidth, Delay, Metric">
IGP Flexible Algorithms: Bandwidth, Delay, Metrics and Constraints</title>
<author initials="S." surname="Hegde" fullname="Shraddha Hegde"> <!DOCTYPE rfc [
<organization>Juniper Networks Inc.</organization> <!ENTITY nbsp "&#160;">
<address> <!ENTITY zwsp "&#8203;">
<postal> <!ENTITY nbhy "&#8209;">
<street>Exora Business Park</street> <!ENTITY wj "&#8288;">
<city>Bangalore</city> ]>
<region>KA</region>
<code>560103</code>
<country>India</country>
</postal>
<email>shraddha@juniper.net</email>
</address>
</author>
<author initials="W." surname="Britto" fullname="William Britto A J">
<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"> <rfc xmlns:xi="http://www.w3.org/2001/XInclude" category="std" docName="draft-ie
<organization>Juniper Networks Inc.</organization> tf-lsr-flex-algo-bw-con-22" number="9843" consensus="true" ipr="trust200902" obs
<address> oletes="" updates="" submissionType="IETF" xml:lang="en" tocInclude="true" tocDe
<postal> pth="3" symRefs="true" sortRefs="true" version="3">
<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"> <front>
<organization>Orange</organization> <title abbrev="IGP Flex-Algorithms: Bandwidth, Delay, and Metrics">IGP Flexi
<address> ble
<postal> Algorithms: Bandwidth, Delay, Metrics, and Constraints</title>
<street></street> <seriesInfo name="RFC" value="9843"/>
<city></city> <author initials="S." surname="Hegde" fullname="Shraddha Hegde">
<region></region> <organization>Juniper Networks Inc.</organization>
<code></code> <address>
<country></country> <postal>
</postal> <street>Exora Business Park</street>
<email>bruno.decraene@orange.com</email> <city>Bangalore</city>
</address> <region>Karnataka</region>
</author> <code>560103</code>
<country>India</country>
</postal>
<email>shraddha@juniper.net</email>
</address>
</author>
<author initials="P." surname="Psenak" fullname="Peter Psenak"> <!--[rfced] We removed "A J" from William Britto's name to match use
<organization>Cisco Systems</organization> in RFC 9502. If that is not desired, please let us know.
<address> -->
<postal> <author initials="W." surname="Britto" fullname="William Britto">
<street></street> <organization>Juniper Networks Inc.</organization>
<city></city> <address>
<region></region> <email>bwilliam@juniper.net</email>
<code></code> </address>
<country></country> </author>
</postal> <author initials="R." surname="Shetty" fullname="Rajesh Shetty">
<email>ppsenak@cisco.com</email> <organization>Juniper Networks Inc.</organization>
</address> <address>
</author> <email>mrajesh@juniper.net</email>
</address>
</author>
<author initials="B." surname="Decraene" fullname="Bruno Decraene">
<organization>Orange</organization>
<address>
<email>bruno.decraene@orange.com</email>
</address>
</author>
<author initials="P." surname="Psenak" fullname="Peter Psenak">
<organization>Cisco Systems</organization>
<address>
<email>ppsenak@cisco.com</email>
</address>
</author>
<author initials="T." surname="Li" fullname="Tony Li">
<organization>Juniper Networks Inc.</organization>
<address>
<email>tony.li@tony.li</email>
</address>
</author>
<date year="2025" month="August"/>
<author initials="T." surname="Li" fullname="Tony Li"> <area>RTG</area>
<organization>Juniper Networks Inc.</organization> <workgroup>lsr</workgroup>
<address>
<postal>
<street></street>
<city></city>
<region></region>
<code></code>
<country></country>
</postal>
<email>tony.li@tony.li</email>
</address>
</author>
<date year="2025"/> <keyword>AS</keyword>
<area>Routing</area> <keyword>IGP</keyword>
<workgroup>LSR</workgroup>
<keyword>AS</keyword>
<keyword>IGP</keyword>
<abstract> <abstract>
<t> <t>
Many networks configure the IGP link metric relative to the link capacity. Many networks configure the IGP link metric relative to the link capacity, a
High bandwidth traffic gets routed as per the link capacity. Flexible nd high
algorithms <xref target ='RFC9350'/>provide mechanisms to bandwidth traffic gets routed per the link capacity. Flexible
create constraint based paths in an IGP. Algorithms provide mechanisms to create constraint-based paths in an IGP.
This draft documents a generic metric type and This specification documents a generic metric type and a
set of bandwidth related constraints to be used in Flexible Algorithms. set of bandwidth-related constraints to be used in Flexible Algorithms.
</t> </t>
</abstract>
</abstract> </front>
<middle>
<note title="Requirements Language"> <section anchor="sec_introduction" numbered="true" toc="default">
<t> The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", <name>Introduction</name>
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and <t> High bandwidth traffic such as residential Internet traffic 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>
<section title="Introduction" anchor='sec_introduction'>
<t> High bandwidth traffic such as residential Internet traffic and
machine-to-machine elephant flows benefit from using high capacity machine-to-machine elephant flows benefit from using high capacity
links. Accordingly, many network operators define a link's metric links. Accordingly, many network operators define a link's metric
relative to its capacity to help direct traffic to higher bandwidth relative to its capacity to help direct traffic to higher bandwidth
links, but this is no guarantee that lower bandwidth links will be links, but this is no guarantee that lower bandwidth links will be
avoided, especially in failure scenarios. To ensure that elephant avoided, especially in failure scenarios. To ensure that elephant
flows are only placed on high capacity links, it would be useful to flows are only placed on high capacity links, it would be useful to
explicitly exclude the high throughput traffic from utilizing links explicitly exclude the high throughput traffic from utilizing links
below a certain capacity. Flex-Algorithm <xref target ='RFC9350'/> below a certain capacity. Flex-Algorithm <xref target="RFC9350" format="defau lt"/>
provides a mechanism to create constrained paths by defining provides a mechanism to create constrained paths by defining
a set of parameters consisting of a set of parameters consisting of
calculation-type, metric-type, and a set of constraints. In calculation-type, metric-type, and a set of constraints. In
this document, we define further extensions to Flex-Algorithm Definition (FAD ) that this document, we define further extensions to the Flexible Algorithm Definit ion (FAD) that
will allow operators additional control over their traffic flows, will allow operators additional control over their traffic flows,
especially with respect to bandwidth constraints. </t> especially with respect to bandwidth constraints. </t>
<t>Historically, IGPs have done path computation by minimizing the
<t>Historically, IGPs have done path computation by minimizing the
sum of the link metrics along the path from source to sum of the link metrics along the path from source to
destination. While the metric has been administratively defined, destination. While the metric has been administratively defined,
implementations have defaulted to a metric that is inversely implementations have defaulted to a metric that is inversely
proportional to link bandwidth. This has driven traffic to higher proportional to link bandwidth. This has driven traffic to higher
bandwidth links and has required manual metric manipulation to bandwidth links and has required manual metric manipulation to
achieve the desired loading of the network.</t> achieve the desired loading of the network.</t>
<t>Over time, with the addition of different traffic types, the need
<t>Over time, with the addition of different traffic types, the need
for alternate types of metrics has evolved. Flex-Algorithm for alternate types of metrics has evolved. Flex-Algorithm
already supports using the minimum link delay and the already supports using the minimum link delay and the
administratively assigned traffic-engineering metrics in path administratively assigned traffic-engineering metrics in path
computation. However, it is clear that additional metrics may be of computation. However, it is clear that additional metrics may be of
interest in different situations. A network operator may seek to interest in different situations. A network operator may seek to
minimize their operational costs and thus may want a metric that minimize their operational costs and thus may want a metric that
reflects the actual fiscal costs of using a link. Other traffic reflects the actual fiscal costs of using a link. Other traffic
may require low jitter, leading to an entirely different set of may require low jitter, leading to an entirely different set of
metrics. With Flex-Algorithm, all of these different metrics, and metrics. With Flex-Algorithm, all of these different metrics, and
more, could be used concurrently on the same network.</t> more, could be used concurrently on the same network.</t>
<t>In some circumstances, path computation constraints, such as
<t>In some circumstances, path computation constraints, such as
administrative groups, can be used to ensure that traffic avoids administrative groups, can be used to ensure that traffic avoids
particular portions of the network. These strict constraints are particular portions of the network. These strict constraints are
appropriate when there is an absolute requirement to avoid parts of appropriate when there is an absolute requirement to avoid parts of
the topology, even in failure conditions. If, however, the the topology, even in failure conditions. However, if the
requirement is less strict, then using a high metric in a portion requirement is less strict, then using a high metric in a portion
of the topology may be more appropriate. </t> 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.
<t>This document defines a family of generic metrics that can advertise <!--[rfced] How may we clarify "and require to be standardized"? Please
various types of administratively assigned metrics. This document proposes let us know if option A or option B captures in the intended
standard metric-types which have specific semantics and require meaning.
In addition, as this document is being published as a Standards-Track RFC, pleas
e 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. to be standardized.
This document also specifies user defined metric-types where specifics are This document also specifies user-defined metric-types where specifics are
not defined, so that administrators are free to assign semantics as not defined so that administrators are free to assign semantics as
they see fit.</t> they see fit.</t>
<t>In <xref target ='sec_bw_metric'/>, this document specifies a
new bandwidth based 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. type to be used with Flex-Algorithm and other applications.
<xref target ='sec_fad_con'/> defines additional Section 3 defines additional Flexible Algorithm Definition (FAD)
Flexible Algorithm Definition (FAD) <xref target ='RFC9350'/> [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 <xref target="sec_bw_metric" format="default"/>, this document speci
fies 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 t
arget="RFC9350" format="default"/>
constraints that allow the network constraints that allow the network
administrator to preclude the use of low bandwidth links or high administrator to preclude the use of low bandwidth links or high
delay links.</t> delay links.</t>
<t> <xref target ='sec_auto_metric'/> <t> <xref target="sec_auto_metric" format="default"/>
defines mechanisms to automatically calculate link metrics based on defines mechanisms to automatically calculate link metrics based on
the parameters defined in the FAD and the advertised Maximum Link Bandwidth the parameters defined in the FAD and the advertised Maximum Link Bandwidth
of each link. This is advantageous because administrators can change their of each link. This is advantageous because administrators can change their
criteria for metric assignment centrally, without individual criteria for metric assignment centrally, without individual
modification of each link metric throughout the network. The procedures 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 described in this document are intended to assign a metric to a link based on
the total link capacity and they are not intended to update the metric based the total link capacity, and they are not intended to update the metric based
on actual traffic flow. Thus, the procedures described in this document are n ot a on actual traffic flow. Thus, the procedures described in this document are n ot a
replacement to the capability of a PCE <xref target ='RFC4655'/> which has a dynamic view of replacement to the capability of a PCE <xref target="RFC4655" format="defaul t"/>, which has a dynamic view of
the network and provides real-time bandwidth management or a distributed band width the network and provides real-time bandwidth management or a distributed band width
management protocol.</t> 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>REQU
IRED</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&nbsp;14 <xref target="RFC2119"/> <xref target="RFC8174"/>
when, and only when, they appear in all capitals, as shown here.
</t>
</section>
</section> </section>
<section title="Generic Metric Advertisement" <section anchor="sec_generic_metric" numbered="true" toc="default">
anchor='sec_generic_metric'> <name>Generic Metric Advertisement</name>
<t> IS-IS <xref target ='RFC1195'/>and OSPF <xref target ='RFC2328'/> advertise <t> IS-IS <xref target="RFC1195" format="default"/> and OSPF <xref target=
"RFC2328" format="default"/> advertise
a metric for each link in their respective a metric for each link in their respective
link state advertisements. Multiple metric types are already supported. link state advertisements. Multiple metric types are already supported.
Administratively assigned metrics are described in the original OSPF Administratively assigned metrics are described in the original OSPF
and IS-IS specifications. The Traffic Engineering Default Metric and IS-IS specifications.
is defined in <xref target ='RFC5305'/> and <xref target ='RFC3630'/>
<!--[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 <xref target="RFC5305" format="default"/> and <xref target="RFC363
0" format="default"/>,
and the Min Unidirectional delay metric is defined in and the Min Unidirectional delay metric is defined in
<xref target ='RFC8570'/> and <xref target ='RFC7471'/>. <xref target="RFC8570" format="default"/> and <xref target="RFC7471" format="def ault"/>.
Other metrics, such as jitter, reliability, and fiscal cost may be Other metrics, such as jitter, reliability, and fiscal cost may be
helpful, depending on the traffic class. Rather than attempt to helpful, depending on the traffic class. Rather than attempt to
enumerate all possible metrics of interest, this document specifies enumerate all possible metrics of interest, this document specifies
a generic mechanism for advertising metrics. </t> a generic mechanism for advertising metrics. </t>
<t>
Each generic metric advertisement is on a per-link and per-metric <t>
type basis. The metric advertisement consists of a metric type Each generic metric advertisement is on a per-link and per-metric-type
field and a value for the metric. The metric type field is basis. The metric advertisement consists of a metric type
assigned by the "IGP Metric-Type" IANA registry. Metric types field and a value for the metric. The metric type field has been
assigned in the "IGP Metric-Type" IANA registry. Metric types
0-127 are standard metric types as assigned by IANA. This document 0-127 are standard metric types as assigned by IANA. This document
further specifies a user-defined metric type space of metric types further specifies a user-defined metric type space of metric types
128-255. These are user defined and can be assigned by an operator 128-255. These are user defined and can be assigned by an operator
for local use. for local use.
</t> </t>
<t>Implementations MUST support sending and receiving generic metric
sub-TLV in Application Specific Link Attributes (ASLA)encodings as <!--[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 gener
ic metric
sub-TLV in Application-Specific Link Attributes (ASLA) encodings as
well as in the TLV 22/extended link LSA/TE-LSAs. 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 sa me The usage of a generic metric by an individual application is subject to the sa me
rules that apply to other link attributes as defined in <xref target ='RFC3630' rules that apply to other link attributes as defined in <xref target="RFC3630"
/>, format="default"/>,
<xref target ='RFC5305'/>, <xref target ='RFC9479'/>, <xref target="RFC5305" format="default"/>, <xref target="RFC9479" format="defau
<xref target ='RFC9492'/> and <xref target ='RFC9350'/>.</t> lt"/>,
<xref target="RFC9492" format="default"/>, and <xref target="RFC9350" format="d
<section title="IS-IS Generic Metric Sub-TLV" efault"/>.</t>
anchor='sec_isis_gen_metric'> <section anchor="sec_isis_gen_metric" numbered="true" toc="default">
<t>The IS-IS Generic Metric sub-TLV specifies the link metric for a given <name>IS-IS Generic Metric Sub-TLV</name>
<t>The IS-IS Generic Metric sub-TLV specifies the link metric for a give
n
metric type. Typically, this metric is assigned by a metric type. Typically, this metric is assigned by a
network administrator. network administrator.
The Generic Metric sub-TLV is advertised in the TLVs/sub-TLVs below:</t> The Generic Metric sub-TLV is advertised in the TLVs/sub-TLVs below:</t>
<ol spacing="normal" type="a">
<li>TLV 22 (Extended IS reachability) <xref target="RFC5305"
format="default"/></li>
<li>TLV 222 (MT-ISN) <xref target="RFC5120" format="default"/></li>
<li>TLV 23 (IS Neighbor Attribute) <xref target="RFC5311"
format="default"/></li>
<li>TLV 223 (MT IS Neighbor Attribute) <xref target="RFC5311"
format="default"/></li>
<li>TLV 141 (Inter-AS Reachability Information) <xref
target="RFC9346" format="default"/></li>
<t><list> <!--[rfced] When referring to "TLV 22/222/23/223/141" (or "TLV 22/23/141/222/223
<t>a. TLV-22 (Extended IS reachability) <xref target ='RFC5305'/></t> "
if updated), should "TLV" be plural (e.g., "TLVs 22/222/23/223/141")?
<t>b. TLV-222 (MT-ISN) <xref target ='RFC5120'/></t> We note that the plural form is used in the "Sub-TLVs for TLVs 22, 23, 141,
222, and 223" registry.
<t>c. TLV-23 (IS Neighbor Attribute) <xref target ='RFC5311'/></t>
<t>d. TLV-223 (MT IS Neighbor Attribute) <xref target ='RFC5311'/> </t> Original:
f. sub-TLV 16 (Application-Specific Link Attributes (ASLA)) of TLV
22/222/23/223/141 [RFC9479]
<t>e. TLV-141 (inter-AS reachability information) <xref target ='RFC9346'/ g. TLV 25 (L2 Bundle Member Attributes) [RFC8668] Marked as "y(s)"
></t> (shareable among bundle members)
<t>f. sub-TLV 16 (Application-Specific Link Attributes (ASLA)) of ...
TLV 22/222/23/223/141 <xref target ='RFC9479'/></t> One example in the running text (see the document for more instances).
<t>g. TLV 25 (L2 Bundle Member Attributes) <xref target ='RFC8668'/> Original:
Marked as "y(s)" (shareable among bundle members)</t> 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.
-->
</list></t> <li>sub-TLV 16 (Application-Specific Link Attributes (ASLA)) of TLV
<t>The Generic Metric sub-TLV, type TBD1 (IANA), and is six 22/222/23/223/141 <xref target="RFC9479" format="default"/></li>
octets in length. <li>TLV 25 (L2 Bundle Member Attributes) <xref target="RFC8668"
<figure anchor="isis_gen_metric_sub_tlv" format="default"/>. Marked as "y(s)" (shareable among bundle
title="IS-IS Generic Metric Sub-TLV"> members).</li>
<artwork> </ol>
<t>The Generic Metric sub-TLV, type 17, is 6 octets in length.
</t>
<figure anchor="isis_gen_metric_sub_tlv">
<name>IS-IS Generic Metric Sub-TLV</name>
<artwork name="" type="" align="left" alt=""><![CDATA[
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | metric-type | | Type | Length | metric-type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value | | Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
Type (1 octet): </figure>
An 8-bit field assigned by IANA (To Be Determined as TBD1). <t>
This value uniquely identifies the Generic Metric TLV. where:
Length (1 octet):
An 8-bit field indicating the total length, in octets,
of the subsequent fields. For this TLV, the Length is set to 4.
Metric-Type (1 octet):
An 8-bit field specifying the type of metric.
The value is taken from the "IGP Metric-Type"
registry maintained by IANA. The metric type may
be any value which is indicated as allowed
in the generic metric sub-TLV by the
IGP Metric-Type Registry.
Value (3 octets):
A 24-bit unsigned integer representing the metric value.
The valid range is from 0 to 16,777,215 (0xFFFFFF).
</artwork>
</figure>
</t> </t>
<t>
The Generic Metric sub-TLV MAY be advertised multiple times. <dl spacing="normal" newline="true">
<dt>Type (1 octet):</dt>
<dd>An 8-bit field assigned by IANA (17). This value
uniquely identifies the Generic Metric TLV.</dd>
<dt>Length (1 octet):</dt>
<dd>An 8-bit field indicating the total length, in octets, of the subsequent
fields. For this TLV, the Length is set to 4.</dd>
<dt>Metric-Type (1 octet):</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 value that is indicated as allowed in the Generic Metric sub-TLV by the
"IGP Metric-Type" registry.</dd>
<dt>Value (3 octets):</dt>
<dd>A 24-bit unsigned integer representing the metric value. The valid
range is from 0 to 16,777,215 (0xFFFFFF).</dd>
</dl>
<t>
The Generic Metric sub-TLV <bcp14>MAY</bcp14> be advertised multiple times.
For a particular metric type, For a particular metric type,
the Generic Metric sub-TLV MUST be advertised only once for a link the Generic Metric sub-TLV <bcp14>MUST</bcp14> be advertised only once for a
when advertised in TLV 22, 222, 23, 223 and 141. link
When Generic metric sub-TLV is advertised in ASLA, when advertised in TLV 22, 222, 23, 223, and 141.
each metric type MUST be advertised only once per-application for a link. When the Generic Metric sub-TLV is advertised in ASLA,
each metric type <bcp14>MUST</bcp14> be advertised only once per-application
for a link.
If there are multiple Generic Metric sub-TLVs advertised for a link If there are multiple Generic Metric sub-TLVs advertised for a link
for the same metric type (and same application in case of ASLA) for the same metric type (and the same application in case of ASLA)
in one or more received LSPDUs, advertisement in the lowest numbered fragmen in one or more received Link State Protocol Data Units (LSPDUs), advertiseme
t nt in the lowest-numbered fragment
MUST be used and the subsequent instances MUST be ignored. <bcp14>MUST</bcp14> be used, and the subsequent instances <bcp14>MUST</bcp14
</t> > be ignored.
<t>For a link, if the metric type corresponds to a metric type for </t>
which legacy advertisement mechanisms exist (e.g., the IGP metric, <t>For a link, if the metric type corresponds to a metric type for
the Minimum Unidirectional Link Delay, or the which legacy advertisement mechanisms exist (e.g., the IGP Metric,
Traffic Engineering Default Metric), the legacy metric types MUST the Min Unidirectional Link Delay, or the
Traffic Engineering Default Metric), the legacy metric types <bcp14>MUST</bc
p14>
be utilized from the existing TLV or sub-TLVs. If a Generic Metric be utilized from the existing TLV or sub-TLVs. If a Generic Metric
advertises a legacy metric, it MUST be ignored. advertises a legacy metric, it <bcp14>MUST</bcp14> be ignored.
. </t>
</t> <t>A metric value of
<t>A metric value of 0xFFFFFF is considered a maximum link metric, and a link having
0xFFFFFF is considered as maximum link metric and a link having this metric value <bcp14>MUST</bcp14> be used during Flex-Algorithm calculati
this metric value MUST be used during Flex-algorithm calculations ons
as a last resort link as described in sec 15.3 of <xref target ='RFC9350'/>. as a last resort link as described in <xref section="15.3" target="RFC9350" f
A link can be made unusable by Flex-algorithm by leaving out Generic metric ormat="default"/>.
advertisement of the particular metric-type that the Flex-algorithm A link can be made unusable by Flex-Algorithm by leaving out Generic Metric
uses as described in <xref target ='RFC9350'/>. advertisement of the particular metric-type that the Flex-Algorithm
</t> uses, as described in <xref target="RFC9350" format="default"/>.
</t>
<t> During the router maintenance activity, the Generic Metric for <t> During the router maintenance activity, the Generic Metric for
all the links on the node MAY be set to a maximum value of all the links on the node <bcp14>MAY</bcp14> be set to a maximum value of
16,777,215 (0xFFFFFF), as it is the maximum usable link metric for the 16,777,215 (0xFFFFFF), as it is the maximum usable link metric for the
Flex-algorithm calculations.</t> Flex-Algorithm calculations.</t>
</section> </section>
<section anchor="sec_ospf_gen_metric" numbered="true" toc="default">
<section title="OSPF Generic Metric Sub-TLV" <name>OSPF Generic Metric Sub-TLV</name>
anchor='sec_ospf_gen_metric'> <t>
<t>
The OSPF Generic Metric sub-TLV specifies the link metric for a given The OSPF Generic Metric sub-TLV specifies the link metric for a given
metric type. Typically, this metric is assigned by a metric type. Typically, this metric is assigned by a
network administrator. network administrator.
The Generic Metric sub-TLV is advertised in the TLVs below:</t> The Generic Metric sub-TLV is advertised in the TLVs below:</t>
<ol type="a" spacing="normal">
<t><list> <!--[rfced] Would it be correct to update "2" to "type 2" as shown
<t>a. sub-TLV of TE Link TLV (2) of OSPF TE LSA <xref target ='RFC3630' below for clarity?
/>.</t>
<t>b. sub-TLV of TE Link TLV (2) of OSPFv2 Inter-AS-TE-v2 LSA <xref tar
get ='RFC5392'/>.</t>
<t>c. sub-TLV of TE Link TLV (2) of OSPFv3 Intra-Area-TE-LSA <xref targ
et ='RFC5329'/>.</t>
<t>d. sub-TLV of TE Link TLV (2) of OSPFv3 Inter-AS-TE-v3 LSA <xref tar
get ='RFC5392'/>.</t>
<t>e. sub-TLV of Application-Specific Link Attributes (ASLA) sub-TLV <x
ref target ='RFC9492'/>
of the OSPFv2 Extended Link TLV <xref target ='RFC7684'/>.</t>
<t>f. sub-TLV of Application-Specific Link Attributes (ASLA) sub-TLV <x
ref target ='RFC9492'/>
of the OSPFv3 Router-Link TLV <xref target ='RFC8362'/>.</t>
<t>g. sub-TLV of the OSPFv2 L2 Bundle Member Attributes sub-TLV <xref targ
et ='RFC9356'/>.</t>
<t>h. sub-TLV of the OSPFv3 L2 Bundle Member Attributes sub-TLV <xref targ
et ='RFC9356'/>.</t>
</list></t> Original:
a. sub-TLV of TE Link TLV (2) of OSPF TE LSA [RFC3630].
<t>The Generic Metric sub-TLV, type TBD21/TBD22/TB23 (IANA), and is eight b. sub-TLV of TE Link TLV (2) of OSPFv2 Inter-AS-TE-v2 LSA
[RFC5392].
c. sub-TLV of TE Link TLV (2) of OSPFv3 Intra-Area-TE-LSA [RFC5329].
d. sub-TLV of TE Link TLV (2) of OSPFv3 Inter-AS-TE-v3 LSA
[RFC5392].
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" f
ormat="default"/>.</li>
<li>sub-TLV of TE Link TLV (2) of OSPFv2 Inter-AS-TE-v2 LSA <xref targ
et="RFC5392" format="default"/>.</li>
<li>sub-TLV of TE Link TLV (2) of OSPFv3 Intra-Area-TE-LSA <xref targe
t="RFC5329" format="default"/>.</li>
<li>sub-TLV of TE Link TLV (2) of OSPFv3 Inter-AS-TE-v3 LSA <xref targ
et="RFC5392" format="default"/>.</li>
<li>sub-TLV of Application-Specific Link Attributes (ASLA) sub-TLV <xr
ef target="RFC9492" format="default"/>
of the OSPFv2 Extended Link TLV <xref target="RFC7684" format="defau
lt"/>.</li>
<li>sub-TLV of Application-Specific Link Attributes (ASLA) sub-TLV <xr
ef target="RFC9492" format="default"/>
of the OSPFv3 Router-Link TLV <xref target="RFC8362" format="default
"/>.</li>
<li>sub-TLV of the OSPFv2 L2 Bundle Member Attributes sub-TLV <xref ta
rget="RFC9356" format="default"/>.</li>
<li>sub-TLV of the OSPFv3 L2 Bundle Member Attributes sub-TLV <xref ta
rget="RFC9356" format="default"/>.</li>
</ol>
<t>The Generic Metric sub-TLV, types 25/36/34, is eight
octets in length. octets in length.
<figure anchor="ospf_gen_metric_sub_tlv" </t>
title="OSPF Generic Metric Sub-TLV "> <figure anchor="ospf_gen_metric_sub_tlv">
<artwork> <name>OSPF Generic Metric Sub-TLV</name>
<artwork name="" type="" align="left" alt=""><![CDATA[
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | | Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| metric-type | Reserved (MBZ) | | metric-type | Reserved (MBZ) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value | | Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
</figure>
Type (2 octets): <t>
A 16-bit field assigned by IANA (To Be Determined as TBD21/TBD22/TBD23). where:
This value uniquely identifies the Generic Metric TLV. </t>
<dl spacing="normal" newline="true">
Length (2 octets): <dt>Type (2 octets):</dt>
A 16-bit field indicating the total length, in octets, <dd>A 16-bit field assigned by IANA (25/36/34).
of the subsequent fields. For this TLV, the Length is set to 8. This value uniquely identifies the Generic Metric TLV.</dd>
<dt>Length (2 octets):</dt>
Metric-Type (1 octet): <dd>A 16-bit field indicating the total length, in octets, of the subsequent
An 8-bit field specifying the type of metric. fields. For this TLV, the Length is set to 8.</dd>
The value is taken from the "IGP Metric-Type" <dt>Metric-Type (1 octet):</dt>
registry maintained by IANA. The metric type <dd>An 8-bit field specifying the type of metric. The value is taken from
may be any value which is indicated as allowed the "IGP Metric-Type" registry maintained by IANA. The metric type may be
in the generic metric sub-TLV by the any value that is indicated as allowed in the Generic Metric sub-TLV by the
IGP Metric-Type Registry. "IGP Metric-Type" registry.</dd>
<dt>Reserved (3 octets):</dt>
Reserved (3 octets): <dd>Must set to zero by the sender and must be ignored by the receiver.</dd>
Must set to zero by sender and <dt>Value (4 octets):</dt>
must be ignored by receiver. <dd>A 32-bit unsigned integer representing the metric value.
The valid
Value (4 octets): range is from 0 to 4,294,967,295 (0xFFFFFFFF).</dd>
A 32-bit unsigned integer representing the metric value. </dl>
The valid range is from 0 to 4,294,967,295(0xFFFFFFFF).
</artwork> <t>The Generic Metric sub-TLV <bcp14>MAY</bcp14> be advertised multiple times.
</figure> For a particular metric type, the Generic Metric sub-TLV <bcp14>MUST</bcp14>
<t>The Generic Metric sub-TLV MAY be advertised multiple times. be advertised only once for a link when advertised as (a) through (d) above.
For a particular metric type, the Generic Metric sub-TLV MUST be When the Generic Metric sub-TLV is advertised as a sub-TLV of ASLA, it
advertised only once for a link when advertised as (a) through (d) above. <bcp14>MUST</bcp14> be advertised only once per application for a link. If
When Generic Metric sub-TLV is advertised as sub-TLV of there are multiple Generic Metric sub-TLVs advertised for a link for the same
ASLA, it MUST be advertised only once per-application for a link. metric type (and the same application in case of ASLA) in one or more received
If there are multiple Generic Metric sub-TLVs advertised for LSAs, advertisement in the lowest-numbered LSA <bcp14>MUST</bcp14> be used, and
a link for the same metric type (and same application in case of ASLA) the subsequent instances <bcp14>MUST</bcp14> be ignored.</t>
in one or more received LSAs, advertisement in the lowest numbered <t>For a link, if the metric type corresponds to a metric type for
LSA MUST be used and the subsequent instances MUST be ignored.</t> which legacy advertisement mechanisms exist (e.g., the IGP Metric,
<t>For a link, if the metric type corresponds to a metric type for the Min Unidirectional Link Delay, or the Traffic Engineering
which legacy advertisement mechanisms exist (e.g., the IGP metric, Default Metric), the legacy metric types <bcp14>MUST</bcp14> be utilized
the Minimum Unidirectional Link Delay, or the Traffic Engineering from
Default Metric), the legacy metric types MUST be utilized from
the existing TLV or sub-TLVs. If a Generic Metric advertises a the existing TLV or sub-TLVs. If a Generic Metric advertises a
legacy metric, it MUST be ignored. legacy metric, it <bcp14>MUST</bcp14> be ignored.
</t> </t>
<t>A metric value of <t>A metric value of
0xFFFFFFFF is considered as maximum link metric and a link having 0xFFFFFFFF is considered a maximum link metric, and a link having
this metric value MUST be used during Flex-algorithm calculations this metric value <bcp14>MUST</bcp14> be used during Flex-Algorithm calculati
as a last resort link as described in sec 15.3 of <xref target ='RFC9350'/>.< ons
/t> as a last resort link, as described in <xref section="15.3" target="RFC9350"
</t> format="default"/>.</t>
<t>A link can be made unusable by Flex-algorithm by leaving out Generic m <t>A link can be made unusable by Flex-Algorithm by leaving out Generic
etric Metric
advertisement of the particular metric-type that the Flex-algorithm advertisement of the particular metric-type that the Flex-Algorithm
uses as described in <xref target ='RFC9350'/>.</t> uses, as described in <xref target="RFC9350" format="default"/>.</t>
<t> During the router maintenance activity, the Generic Metric for
all the links on the node MAY be set to a maximum value of
4,294,967,295 ((0xFFFFFFFF), as it is the maximum usable link metric for the
Flex-algorithm calculations.</t>
</section>
<section <t> During the router maintenance activity, the Generic Metric for
title="Generic Metric applicability to Flexible Algorithms Multi-domain/Multi-ar all the links on the node <bcp14>MAY</bcp14> be set to a maximum value of
ea networks " 4,294,967,295 (0xFFFFFFFF), as it is the maximum usable link metric for the
anchor='sec_multi_area'> Flex-Algorithm calculations.</t>
<t>Generic Metric can be used by Flex-Algorithms </section>
<section anchor="sec_multi_area" numbered="true" toc="default">
<name>Generic Metric Applicability to Flexible Algorithm Multi-Domain/Mu
lti-Area Networks</name>
<t>Generic Metric can be used by Flex-Algorithm
by specifying the metric type in the by specifying the metric type in the
Flexible Algorithm Definitions. When Flex-Algorithms is used in a multi-area net Flexible Algorithm Definitions. When Flex-Algorithm is used in a multi-area netw
work, ork,
<xref target ='RFC9350'/> defines the Flexible Algorithm Prefix Metric (FAPM) <xref target="RFC9350" format="default"/> defines the Flexible Algorithm Prefix
Metric (FAPM)
sub-TLV that carries sub-TLV that carries
the Flexible-Algorithm-specific metric. Metrics carried in FAPM will be equal 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 to the metric to reach the prefix for that Flex-Algorithm in its
source area or domain (source area from the ABR perspective). When Flex-Algorith source area or domain (source area from the Area Border Router (ABR) perspective
m uses ). When Flex-Algorithm uses
Generic metric, the same procedures as described in section 13 of Generic Metric, the same procedures as described in
<xref target ='RFC9350'/> <xref target="RFC9350" sectionFormat="of" section="13"/>
are used to send and process FAPM sub-TLV.</t> are used to send and process the FAPM sub-TLV.</t>
</section> </section>
</section> </section>
<section anchor="sec_fad_con" numbered="true" toc="default">
<section title=" FAD constraint Sub-TLVs" anchor='sec_fad_con'> <name>FAD Constraint Sub-TLVs</name>
<t>
<t>
Large high throughput flows are referred to as "elephant flows". Large high throughput flows are referred to as "elephant flows".
Directing an elephant flow Directing an elephant flow
down a low-bandwidth link might congest the link and cause other down a low-bandwidth link might congest the link and cause other
critical application traffic flowing on the link to drop. Thus, in the critical application traffic flowing on the link to drop. Thus, in the
context of Flex-Algorithm, it would be useful to be able to context of Flex-Algorithm, it would be useful to be able to
constrain the topology to only those links capable of supporting a constrain the topology to only those links capable of supporting a
minimum amount of bandwidth.</t> minimum amount of bandwidth.</t>
<t>If the capacity of a link is constant, this can already be achieved <!--[rfced] Please clarify what "this" refers to in the following sentence.
through the use of administrative groups. However, when a layer-3
link is actually a collection of layer-2 links (LAG/layer-2 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 a Layer 3
link is actually a collection of Layer 2 links (Link Aggregation Group (LAG)
/ Layer 2
Bundle), the link bandwidth will vary based on the set of active Bundle), the link bandwidth will vary based on the set of active
constituent links. This could be automated by having an constituent links. This could be automated by having an
implementation vary the advertised administrative groups based on implementation vary the advertised administrative groups based on
bandwidth, but this seems unnecessarily complex and expressing this bandwidth, but this seems unnecessarily complex and expressing this
requirement as a direct constraint on the topology seems requirement as a direct constraint on the topology seems
simpler. This is also advantageous if the minimum required simpler. This is also advantageous if the minimum required
bandwidth changes, as this constraint would provide a single bandwidth changes, as this constraint would provide a single
centralized, coordinated point of control.</t> centralized, coordinated point of control.</t>
<t>To satisfy this requirement, this document defines an
<t>To satisfy this requirement, this document defines an
Exclude Minimum Bandwidth Exclude Minimum Bandwidth
constraint. When this constraint is advertised in a FAD, constraint. When this constraint is advertised in a FAD,
a link will be pruned from the Flex-Algorithm topology if the a link will be pruned from the Flex-Algorithm topology if the
link's advertised Maximum Link Bandwidth is below the advertised link's advertised Maximum Link Bandwidth is below the advertised
Minimum Bandwidth value.</t> Minimum Bandwidth value.</t>
<t>Similarly, this document defines an Exclude Maximum Link Delay
<t>Similarly, this document defines an Exclude Maximum Link Delay
constraint. Applications, such as High-Frequency Trading are sensitive constraint. Applications, such as High-Frequency Trading are sensitive
to link delays and may perform poorly in networks prone to delay to link delays and may perform poorly in networks prone to delay
variability, such as those with transparent Layer 2 link variability, such as those with transparent Layer 2 link
recovery mechanisms or satellite links.". recovery mechanisms or satellite links.
Mechanisms already exist to measure the link delay dynamically and Mechanisms already exist to measure the link delay dynamically and
advertise it in the IGP. Networks that employ dynamic link-delay advertise it in the IGP. Networks that employ dynamic link-delay
measurement, may want to exclude links that have a delay over a measurement, may want to exclude links that have a delay over a
given threshold.</t> given threshold.</t>
<section anchor="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 Bandwidth Sub-TLV</name>
<t>
<section title="IS-IS FAD constraint Sub-TLVs" anchor='sec_isis'> IS-IS Flex-Algorithm Exclude Minimum Bandwidth (FAEMB) sub-TLV is a
<section title="IS-IS Exclude Minimum Bandwidth sub-TLV" anchor='sec_isis_bw_exc
lusion'>
<t>
IS-IS Flex-Algorithm Exclude Minimum Bandwidth sub-TLV (FAEMB) is a
sub-TLV of the IS-IS FAD sub-TLV. It has the following format: sub-TLV of the IS-IS FAD sub-TLV. It has the following format:
<figure anchor="isis_faemb_sub_tlv" title="IS-IS FAEMB Sub-TLV"> </t>
<artwork> <figure anchor="isis_faemb_sub_tlv">
<name>IS-IS FAEMB Sub-TLV</name>
<artwork name="" type="" align="left" alt=""><![CDATA[
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | | Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Min Bandwidth | | Min Bandwidth |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
where: ]]></artwork>
</figure>
Type (1 octet):
An 8-bit field assigned by IANA (To Be Determined as TBD3).
This value uniquely identifies the FAEMB sub-TLV.
Length (1 octet):
An 8-bit field indicating the total length, in octets,
of the subsequent fields. For this sub-TLV, the Length is set to 4.
Min Bandwidth (4 octets): <t>where:</t>
A 32-bit field specifying the link bandwidth encoded in IEEE <dl spacing="normal" newline="true">
floating point format (32 bits)[IEEE754-2019]. <dt>Type (1 octet):</dt>
The units are bytes-per-second. <dd>An 8-bit field assigned by IANA (6). This value
uniquely identifies the FAEMB sub-TLV.</dd>
<dt>Length (1 octet):</dt>
<dd>An 8-bit field indicating the total length, in octets, of the subsequent
fields. For this sub-TLV, the Length is set to 4.</dd>
<dt>Min Bandwidth (4 octets):</dt>
<dd>A 32-bit field specifying the link bandwidth encoded in IEEE floating
point format (32 bits) <xref target="IEEE754-2019"/>. The units are bytes per
second.</dd>
</dl>
</artwork> <t>The FAEMB sub-TLV <bcp14>MUST</bcp14> appear once at most in the FA
</figure> D sub-TLV.
</t> If it appears more than once, the IS-IS FAD sub-TLV <bcp14>MUST</bcp14> be
<t>The FAEMB sub-TLV MUST appear at most once in the FAD sub-TLV.
If it appears more than once, the IS-IS FAD sub-TLV MUST be
ignored by the receiver. </t> ignored by the receiver. </t>
<t>The Minimum bandwidth advertised in the FAEMB sub-TLV <bcp14>MUST</
<t>The Minimum bandwidth advertised in FAEMB sub-TLV MUST be compared with bcp14> be compared with
Maximum Link Bandwidth advertised in sub-sub-TLV 9 of ASLA sub-TLV <xref targ Maximum Link Bandwidth advertised in sub-sub-TLV 9 of the ASLA sub-TLV <xref
et ='RFC9479'/>. target="RFC9479" format="default"/>.
If L-Flag is set in the ASLA sub-TLV, the Minimum bandwidth advertised in FAE If the L-flag is set in the ASLA sub-TLV, the Minimum bandwidth advertised in
MB the FAEMB
sub-TLV MUST be compared with Maximum Link Bandwidth as sub-TLV <bcp14>MUST</bcp14> be compared with the Maximum Link Bandwidth as
advertised in the sub-TLV 9 of the TLV advertised in the sub-TLV 9 of the TLV
22/222/23/223/141 <xref target ='RFC5305'/> as defined in <xref target ='RFC9 22/222/23/223/141 <xref target="RFC5305" format="default"/>, as defined in <x
479'/> ref target="RFC9479" sectionFormat="of" section="4.2"/>. </t>
Section 4.2. </t> <t>If the Maximum Link Bandwidth is lower than the Minimum
Link Bandwidth advertised in the FAEMB sub-TLV,
<t>If the Maximum Link Bandwidth is lower than the Minimum the link <bcp14>MUST</bcp14> be excluded from the Flex-Algorithm topology.
link bandwidth advertised in FAEMB sub-TLV,
the link MUST be excluded from the Flex-Algorithm topology.
If a link does not have the Maximum Link Bandwidth advertised but the If a link does not have the Maximum Link Bandwidth advertised but the
FAD contains this sub-TLV, then that link FAD contains this sub-TLV, then that link
MUST NOT be excluded from the topology based on the Minimum <bcp14>MUST NOT</bcp14> be excluded from the topology based on the Minimum
Bandwidth constraint. Bandwidth constraint.
</t> </t>
</section> </section>
<section title="IS-IS Exclude Maximum Delay Sub-TLV" <section anchor="sec_isis_delay_exclusion" numbered="true" toc="default"
anchor='sec_isis_delay_exclusion'> >
<t> <name>IS-IS Exclude Maximum Delay Sub-TLV</name>
<t>
IS-IS Flex-Algorithm Exclude Maximum Delay sub-TLV (FAEMD) is a IS-IS Flex-Algorithm Exclude Maximum Delay (FAEMD) sub-TLV is a
sub-TLV of the IS-IS FAD sub-TLV. It has the following format. sub-TLV of the IS-IS FAD sub-TLV. It has the following format:
<figure anchor="isis_faemd_sub_tlv" title="IS-IS FAEMD Sub-TLV"> </t>
<artwork> <figure anchor="isis_faemd_sub_tlv">
<name>IS-IS FAEMD Sub-TLV</name>
<artwork name="" type="" align="left" alt=""><![CDATA[
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | | Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Max Link Delay | | Max Link Delay |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
where: ]]></artwork>
</figure>
Type (1 octet): <t>where:</t>
An 8-bit field assigned by IANA (To Be Determined as TBD4). <dl spacing="normal" newline="true">
This value uniquely identifies the FAEMD sub-TLV. <dt>Type (1 octet):</dt>
<dd>An 8-bit field assigned by IANA (7). This value
Length (1 octet): uniquely identifies the FAEMD sub-TLV.</dd>
An 8-bit field indicating the total length, in octets, <dt>Length (1 octet):</dt>
of the subsequent fields. For this sub-TLV, the Length is set to 3. <dd>An 8-bit field indicating the total length, in octets, of the subsequent
fields. For this sub-TLV, the Length is set to 3.</dd>
Max link delay (3 octets): <dt>Max Link Delay (3 octets):</dt>
A 24-bit field specifying the Maximum link delay in microseconds. <dd>A 24-bit field specifying the Maximum link delay in microseconds.</dd>
</dl>
</artwork>
</figure>
</t>
<t>The FAEMD sub-TLV MUST appear only once in the FAD sub-TLV.
If it appears more than once, the IS-IS FAD sub-TLV MUST be
ignored by the receiver.</t>
<t>The Maximum link delay advertised in FAEMD sub-TLV MUST be compared with <t>The FAEMD sub-TLV <bcp14>MUST</bcp14> appear only once in the FAD sub-TLV.
Min Unidirectional Link Delay advertised in sub-sub-TLV 34 of ASLA sub-TLV <x If it appears more than once, the IS-IS FAD sub-TLV <bcp14>MUST</bcp14> be
ref target ='RFC9479'/>. ignored by the receiver.</t>
If the L-Flag is set in the ASLA sub-TLV, the Maximum link delay advertised i <t>The Maximum link delay advertised in the FAEMD sub-TLV <bcp14>MUST<
n FAEMD /bcp14> be compared with
sub-TLV MUST be compared with Min Unidirectional Link Delay as Min Unidirectional Link Delay advertised in sub-sub-TLV 34 of the ASLA sub-TL
V <xref target="RFC9479" format="default"/>.
If the L-flag is set in the ASLA sub-TLV, the Maximum link delay advertised i
n the FAEMD
sub-TLV <bcp14>MUST</bcp14> be compared with Min Unidirectional Link Delay as
advertised by the sub-TLV 34 of the TLV advertised by the sub-TLV 34 of the TLV
22/222/23/223/141 <xref target ='RFC8570'/> as defined in <xref target ='RFC9 22/222/23/223/141 <xref target="RFC8570" format="default"/>, as defined in <x
479'/> ref target="RFC9479" sectionFormat="of" section="4.2"/>. </t>
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 link <bcp14>MUST</bcp
<t>If the Min Unidirectional Link Delay value is higher than the 14> be
Maximum link delay advertised in FAEMD sub-TLV, the link MUST be
excluded from the Flex-Algorithm topology. excluded from the Flex-Algorithm topology.
If a link does not have the Min Unidirectional Link Delay advertised but If a link does not have the Min Unidirectional Link Delay advertised but
the FAD contains this sub-TLV, then that link MUST NOT be the FAD contains this sub-TLV, then that link <bcp14>MUST NOT</bcp14> be
excluded from the topology based on the Maximum Delay constraint. excluded from the topology based on the Maximum Delay constraint.
</t> </t>
</section> </section>
</section> </section>
<section anchor="sec_ospf" numbered="true" toc="default">
<section title="OSPF FAD constraint Sub-TLVs" anchor='sec_ospf'> <name>OSPF FAD Constraint Sub-TLVs</name>
<section anchor="sec_ospf_bw_exclusion" numbered="true" toc="default">
<section title="OSPF Exclude Minimum Bandwidth Sub-TLV" <name>OSPF Exclude Minimum Bandwidth Sub-TLV</name>
anchor='sec_ospf_bw_exclusion'> <t>
<t>
OSPF Flex-Algorithm Exclude Minimum Bandwidth sub-TLV (FAEMB) is a OSPF Flex-Algorithm Exclude Minimum Bandwidth (FAEMB) sub-TLV is a
sub-TLV of the OSPF FAD TLV. It has the following format: sub-TLV of the OSPF FAD TLV. It has the following format:
<figure anchor="ospf_faemb_sub_tlv" title="OSPF FAEMB Sub-TLV"> </t>
<artwork> <figure anchor="ospf_faemb_sub_tlv">
<name>OSPF FAEMB Sub-TLV</name>
<artwork name="" type="" align="left" alt=""><![CDATA[
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | | Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Min Bandwidth | | Min Bandwidth |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
where: ]]></artwork>
</figure>
Type (2 octets): <t>where:</t>
A 16-bit field assigned by IANA (To Be Determined as TBD5). <dl spacing="normal" newline="true">
This value uniquely identifies the OSPF FAEMB sub-TLV. <dt>Type (2 octets):</dt>
<dd>A 16-bit field assigned by IANA (6). This value
Length (2 octets): uniquely identifies the OSPF FAEMB sub-TLV.</dd>
A 16-bit field indicating the total length, in octets, <dt>Length (2 octets):</dt>
of the subsequent fields. For this sub-TLV, the Length is set to 4. <dd>A 16-bit field indicating the total length, in octets, of the subsequent
fields. For this sub-TLV, the Length is set to 4.</dd>
Min Bandwidth (4 octets): <dt>Min Bandwidth (4 octets):</dt>
A 32-bit field specifying the link bandwidth encoded in <dd>A 32-bit field specifying the link bandwidth encoded in IEEE floating
IEEE floating point format (32 bits)[IEEE754-2019]. point format (32 bits)<xref target="IEEE754-2019"/>. The units are bytes per
The units are bytes-per-second. second.</dd>
</dl>
</artwork> <t>The FAEMB sub-TLV <bcp14>MUST</bcp14> only appear once in the FAD s
</figure> ub-TLV.
</t> If it appears more than once, the OSPF FAD TLV <bcp14>MUST</bcp14> be
<t>The FAEMB sub-TLV MUST only appear once in the FAD sub-TLV.
If it appears more than once, the OSPF FAD TLV MUST be
ignored by the receiver.</t> ignored by the receiver.</t>
<t>The Maximum Link Bandwidth as advertised in the Extended Link TLV
<t>The Maximum Link Bandwidth as advertised in the Extended Link TLV in the Extended Link Opaque LSA in OSPFv2 <xref target="RFC7684" format="defa
in the Extended Link Opaque LSA in OSPFv2 <xref target ='RFC7684'/> ult"/>
or as a sub-TLV or as a sub-TLV
of the Router-Link TLV of the E-Router-LSA Router-Link TLV in of the Router-Link TLV of the E-Router-LSA Router-Link TLV in
OSPFv3 <xref target ='RFC8362'/> MUST be compared against OSPFv3 <xref target="RFC8362" format="default"/> <bcp14>MUST</bcp14> be comp
the Minimum bandwidth advertised in FAEMB sub-TLV. ared against
the Minimum bandwidth advertised in the FAEMB sub-TLV.
If the link bandwidth is lower than the Minimum bandwidth If the link bandwidth is lower than the Minimum bandwidth
advertised in FAEMB sub-TLV, the link MUST be excluded advertised in the FAEMB sub-TLV, the link <bcp14>MUST</bcp14> be excluded
from the Flex-Algorithm topology. from the Flex-Algorithm topology.
</t> </t>
<t>If a link does not have the Maximum Link Bandwidth advertised <t>If a link does not have the Maximum Link Bandwidth advertised
but the FAD contains this sub-TLV, then that link MUST be included in the but the FAD contains this sub-TLV, then that link <bcp14>MUST</bcp14> be incl
uded in the
topology and proceed to apply further pruning rules for the link. topology and proceed to apply further pruning rules for the link.
</t> </t>
</section> </section>
<section title="OSPF Exclude Maximum Delay Sub-TLV" <section anchor="sec_ospf_delay_exclusion" numbered="true" toc="default"
anchor='sec_ospf_delay_exclusion'> >
<t> <name>OSPF Exclude Maximum Delay Sub-TLV</name>
<t>
The OSPF Flex-Algorithm Exclude Maximum Delay sub-TLV (FAEMD) is a The OSPF Flex-Algorithm Exclude Maximum Delay (FAEMD) sub-TLV is a
sub-TLV of the OSPF FAD TLV. It has the following format. sub-TLV of the OSPF FAD TLV. It has the following format.
<figure anchor="ospf_faemd_sub_tlv" title="OSPF FAEMD Sub-TLV"> </t>
<artwork> <figure anchor="ospf_faemd_sub_tlv">
<name>OSPF FAEMD Sub-TLV</name>
<artwork name="" type="" align="left" alt=""><![CDATA[
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | | Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RESERVED | Max link Delay | | RESERVED | Max Link Delay |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
where: ]]></artwork>
</figure>
Type (2 octets):
A 16-bit field assigned by IANA (To Be Determined as TBD6).
This value uniquely identifies the OSPF FAEMD sub-TLV.
Length (2 octets):
A 16-bit field indicating the total length, in octets,
of the subsequent fields. For this sub-TLV, the Length is set to 4.
Reserved (1 octet):
Must set to zero by sender and
must be ignored by receiver.
Max link delay (3 octets): <t>where:</t>
A 24-bit field specifying the Maximum link delay in microseconds. <dl spacing="normal" newline="true">
<dt>Type (2 octets):</dt>
<dd>A 16-bit field assigned by IANA (7). This value
uniquely identifies the OSPF FAEMD sub-TLV.</dd>
<dt>Length (2 octets):</dt>
<dd>A 16-bit field indicating the total length, in octets, of the subsequent
fields. For this sub-TLV, the Length is set to 4.</dd>
<dt>Reserved (1 octet):</dt>
<dd>Must be set to zero by the sender and must be ignored by the receiver.</dd
>
<dt>Max Link Delay (3 octets):</dt>
<dd>A 24-bit field specifying the Maximum link delay in microseconds.</dd>
</dl>
</artwork> <t> The FAEMD sub-TLV <bcp14>MUST</bcp14> only appear once in the OSPF
</figure> FAD TLV.
</t> If it appears more than once, the OSPF FAD TLV <bcp14>MUST</bcp14> be
<t> The FAEMD sub-TLV MUST only appear once in the OSPF FAD TLV.
If it appears more than once, the OSPF FAD TLV MUST be
ignored by the receiver. ignored by the receiver.
</t> </t>
<t>The Min Delay value advertised via the Min/Max Unidirectional Link Delay
of ASLA sub-TLV <xref target ='RFC9492'/>, MUST be compared against the Maxi <t>The Min Delay value advertised via the Min/Max Unidirectional Link
mum delay Delay
of the ASLA sub-TLV <xref target="RFC9492" format="default"/> <bcp14>MUST</b
cp14> be compared against the Maximum delay
advertised in the FAEMD sub-TLV. If the Min Unidirectional Link Delay is hig her advertised in the FAEMD sub-TLV. If the Min Unidirectional Link Delay is hig her
than the Maximum delay advertised in the FAEMD sub-TLV, the link MUST be than the Maximum delay advertised in the FAEMD sub-TLV, the link <bcp14>MUST </bcp14> be
excluded from the Flex-Algorithm topology. If the excluded from the Flex-Algorithm topology. If the
Min/Max Unidirectional Link Delay is not advertised for a link but Min/Max Unidirectional Link Delay is not advertised for a link but
the FAD contains this sub-TLV,then then that link MUST NOT be the FAD contains this sub-TLV, then that link <bcp14>MUST NOT</bcp14> be
excluded from the topology based on the Maximum Delay constraint. excluded from the topology based on the Maximum Delay constraint.
</t> </t>
</section> </section>
</section> </section>
</section> </section>
<section title="Bandwidth Metric Advertisement" <section anchor="sec_bw_metric" numbered="true" toc="default">
anchor='sec_bw_metric'> <name>Bandwidth Metric Advertisement</name>
<t>
<t>
Historically, IGP implementations have made default metric Historically, IGP implementations have made default metric
assignments based on link bandwidth. This has proven to be useful, assignments based on link bandwidth. This has proven to be useful
but has suffered from having different defaults across but has suffered from having different defaults across
implementations and from the rapid growth of link bandwidths. With implementations and from the rapid growth of link bandwidths. With
Flex-Algorithm, the network administrator can define a function Flex-Algorithm, the network administrator can define a function
that will produce a metric for each link and have each node that will produce a metric for each link and have each node
automatically compute each link's metric based on its bandwidth.</t> automatically compute each link's metric based on its bandwidth.</t>
<t>This document defines a standard metric type for this purpose
<t>This document defines a standard metric type for this purpose called the "Bandwidth Metric". The Bandwidth Metric <bcp14>MAY</bcp14> be
called the "Bandwidth Metric". The Bandwidth Metric MAY be
advertised in the Generic Metric sub-TLV with the metric type set advertised in the Generic Metric sub-TLV with the metric type set
to "Bandwidth Metric". IS-IS and OSPF will advertise this type to "Bandwidth Metric". IS-IS and OSPF will advertise this type
of metric in their link advertisements. Bandwidth metric is a link of metric in their link advertisements.
attribute and for the advertisement and processing of this attribute for
Flex-algorithm, MUST follow the section 12 of
<xref target ='RFC9350'/></t>
<t> Flex-Algorithm uses this <!--[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 <xref target="RFC9350" sectionFormat="of"
section="12"/>.</t>
<t> Flex-Algorithm uses this
metric type by specifying the bandwidth metric as the metric type metric type by specifying the bandwidth metric as the metric type
in a FAD TLV. A FAD TLV may also specify an automatic computation 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 of the bandwidth metric based on a link's advertised bandwidth. An
explicit advertisement of a link's bandwidth metric using the explicit advertisement of a link's bandwidth metric using the
Generic Metric sub-TLV overrides this automatic computation. Generic Metric sub-TLV overrides this automatic computation.
The automatic bandwidth metric calculation sub-TLVs are advertised The automatic bandwidth metric calculation sub-TLVs are advertised
in the FAD TLV and these parameters are applicable to applications in the FAD TLV, and these parameters are applicable to applications
such as Flex-algorithm that make use of the FAD TLV. such as Flex-Algorithm that make use of the FAD TLV.
</t> </t>
<section anchor="sec_auto_metric" numbered="true" toc="default">
<section title="Automatic Metric Calculation" anchor='sec_auto_metric'> <name>Automatic Metric Calculation</name>
<t> Networks that are designed to be highly regular and that follow unif
<t> Networks which are designed to be highly regular and follow uniform orm
metric assignment may want to simplify their operations by metric assignment may want to simplify their operations by
automatically calculating the bandwidth metric. When automatically calculating the bandwidth metric. When
a FAD advertises the metric type as Bandwidth Metric and the link does a FAD advertises the metric type as Bandwidth Metric and the link does
not have the Bandwidth Metric advertised, automatic metric derivation not have the Bandwidth Metric advertised, automatic metric derivation
can be used with additional FAD constraint advertisement as can be used with additional FAD constraint advertisement as
described in this section. </t> described in this section. </t>
<t> If a link's bandwidth changes, then the delay in learning about the
<t> If a link's bandwidth changes, then the delay in learning about the
change may create the possibility of micro-loops in the change may create the possibility of micro-loops in the
topology. This is no different from the IGP's susceptibility to topology. This is no different from the IGP's susceptibility to
micro-loops during a metric change. The micro-loop avoidance micro-loops during a metric change. The micro-loop avoidance
procedures described in <xref target ='I-D.bashandy-rtgwg-segment-routing-ulo procedures described in <xref target="I-D.bashandy-rtgwg-segment-routing-uloo
op'/> p" format="default"/>
or any other mechanism as described in the framework <xref target ='RFC5715'/ or any other mechanism as described in the framework <xref target="RFC5715" f
> ormat="default"/>
can be used to avoid micro-loops when the automatic metric can be used to avoid micro-loops when the automatic metric
calculation is deployed.</t> calculation is deployed.</t>
<t> Computing the metric between adjacent systems based on bandwidth
<t> Computing the metric between adjacent systems based on bandwidth
becomes more complex in the case of parallel adjacencies. If there becomes more complex in the case of parallel adjacencies. If there
are parallel adjacencies between systems, then the bandwidth are parallel adjacencies between systems, then the bandwidth
between the systems is the sum of the bandwidth of the parallel 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 links. This is somewhat more complex to deal with, so there is an
optional mode for computing the aggregate bandwidth.</t> optional mode for computing the aggregate bandwidth.</t>
<section anchor="sec_auto_metric_mode" numbered="true" toc="default">
<section title="Automatic Metric Calculation Modes" <name>Automatic Metric Calculation Modes</name>
anchor='sec_auto_metric_mode'> <section anchor="sec_simple" numbered="true" toc="default">
<name>Simple Mode</name>
<section title="Simple Mode" anchor='sec_simple'> <t> In simple mode, the Maximum Link Bandwidth of a single Layer 3 l
<t> In simple mode, the Maximum Link Bandwidth of a single layer-3 link ink
is used to derive the metric. This mode is suitable for is used to derive the metric. This mode is suitable for
deployments that do not use parallel layer-3 links. In this case, deployments that do not use parallel Layer 3 links. In this case,
the computation of the metric is straightforward. the computation of the metric is straightforward.
If a layer-3 link is composed of a layer-2 bundle, then the link If a Layer 3 link is composed of a Layer 2 bundle, then the link
bandwidth is the sum of the bandwidths of the working components bandwidth is the sum of the bandwidths of the working components
and may vary with layer-2 link failures. </t> and may vary with Layer 2 link failures. </t>
</section>
</section> <section anchor="sec_intf_grp" numbered="true" toc="default">
<name>Interface Group Mode</name>
<section title="Interface Group Mode" anchor='sec_intf_grp'> <t> The simple mode of metric calculation may not work well when the
<t> The simple mode of metric calculation may not work well when there re
are multiple parallel layer-3 interfaces between two nodes. are multiple parallel Layer 3 interfaces between two nodes.
Ideally, the metric between two systems should be the same given Ideally, the metric between two systems should be the same given
the same bandwidth, whether the bandwidth is provided by parallel the same bandwidth, whether the bandwidth is provided by parallel
layer-2 links or parallel layer-3 links. To address this, in Layer 2 links or parallel Layer 3 links. To address this, in
Interface Group Mode, nodes MUST compute the aggregate bandwidth of Interface Group Mode, nodes <bcp14>MUST</bcp14> compute the aggregate bandwid
all parallel adjacencies, MUST derive the metric based on the th of
aggregate bandwidth, and MUST apply the resulting metric to each of all parallel adjacencies, <bcp14>MUST</bcp14> derive the metric based on the
aggregate bandwidth, and <bcp14>MUST</bcp14> apply the resulting metric to ea
ch of
the parallel adjacencies. Note that a single elephant flow is normally the parallel adjacencies. Note that a single elephant flow is normally
pinned to a single layer-3 interface. If the single layer-3 link pinned to a single Layer 3 interface. If the single Layer 3 link
bandwidth is not sufficient for any single elephant flow, the mechanisms bandwidth is not sufficient for any single elephant flow, the mechanisms
to solve this issue are outside the scope of this document. to solve this issue are outside the scope of this document.
<figure anchor="interface_grp" title="Parallel interfaces"> </t>
<artwork> <figure anchor="interface_grp">
<name>Parallel Interfaces</name>
<artwork name="" type="" align="left" alt=""><![CDATA[
A------B====C====F====D A------B====C====F====D
| | | |
------E------- ------E-------
</artwork> ]]></artwork>
</figure> </figure>
<t>
For example, in the above diagram, there are two parallel links For example, in the above diagram, there are two parallel links
between B->C, C->F, F->D. Let us assume the link bandwidth is between B-&gt;C, C-&gt;F, F-&gt;D. Let us assume the link bandwidth is
uniform 10Gbps on all links. When bandwidth is used to derive the metric uniform 10 Gbps on all links. When bandwidth is used to derive the metric
for the links, the metric for each link will be for the links, the metric for each link will be
the same. Traffic from B to D will be forwarded B->E->D as the same. Traffic from B to D will be forwarded as B-&gt;E-&gt;D because
the metric will be lower. Since the the metric will be lower. Since the
bandwidth is higher on the B->C->F->D path, the metric for that bandwidth is higher on the B-&gt;C-&gt;F-&gt;D path, the metric for that
path should be lower than the B->E->D path to attract the traffic on path should be lower than the B-&gt;E-&gt;D path to attract the traffic on
B->C->F->D path. Interface the B-&gt;C-&gt;F-&gt;D path. Interface
Group Mode should be preferred in cases where there are parallel layer-3 Group Mode should be preferred in cases where there are parallel Layer 3
links. links.
</t> </t>
<t> <t>
In the interface group mode, every node MUST In the Interface Group Mode, every node <bcp14>MUST</bcp14>
identify the set of parallel links between a pair identify the set of parallel links between a pair
of nodes based on IGP link advertisements of nodes based on IGP link advertisements
and MUST consider cumulative bandwidth of the and <bcp14>MUST</bcp14> consider cumulative bandwidth of the
parallel links while arriving at the metric of each link. </t> parallel links while arriving at the metric of each link. </t>
<t>The parallel layer-3 links between two nodes may not have the <t>The parallel Layer 3 links between two nodes may not have the
same bandwidth. In such cases the method described in interface group same bandwidth. In such cases, the method described in Interface Group
mode will Mode will
result in same metric being used for all the parallel links which may result in the same metric being used for all the parallel links, which
cause may cause
undesired load-balancing on the links. In such cases, a device may loc undesired load balancing on the links. In such cases, a device may loc
ally ally
apply load-balancing factor relative to the link bandwidth on the ECMP apply a load-balancing factor relative to the link bandwidth on the EC
nexthops. MP next hops.
The load-balancing mechanisms are outside the scope of this document.< /t> The load-balancing mechanisms are outside the scope of this document.< /t>
</section> </section>
</section> </section>
<section anchor="sec_auto_metric_methods" numbered="true" toc="default">
<section title="Automatic Metric Calculation Methods" <name>Automatic Metric Calculation Methods</name>
anchor='sec_auto_metric_methods'> <t>
<t> In automatic metric calculation for simple and Interface Group Mode,
In automatic metric calculation for simple and interface group mode,
Maximum Link Bandwidth of the links is used to derive the metric. Maximum Link Bandwidth of the links is used to derive the metric.
There are two types of automatic metric derivation methods.</t> There are two types of automatic metric derivation methods.</t>
<t> <ol type="1" spacing="normal">
<list> <li>Reference bandwidth method</li>
<t> 1. Reference bandwidth method</t> <li>Bandwidth thresholds method</li>
<t> 2. Bandwidth thresholds method </t> </ol>
</list>
</t>
<section title="Reference Bandwidth method" anchor='sec_ref_bw_method'>
<t>In many networks, the metric is inversely proportional to the link <section anchor="sec_ref_bw_method" numbered="true" toc="default">
<name>Reference Bandwidth Method</name>
<t>In many networks, the metric is inversely proportional to the lin
k
bandwidth. The administrator or implementation selects a reference bandwidth. The administrator or implementation selects a reference
bandwidth and the metric is derived by dividing the reference bandwidth and the metric is derived by dividing the reference
bandwidth by the advertised Maximum Link Bandwidth. Advertising bandwidth by the advertised Maximum Link Bandwidth. Advertising
the reference bandwidth in the FAD constraints allows the metric the reference bandwidth in the FAD constraints allows the metric
computation to be done on every node for each link. computation to be done on every node for each link.
The metric is computed using reference bandwidth and the advertised link band width. The metric is computed using reference bandwidth and the advertised link band width.
Centralized control of this Centralized control of this
reference bandwidth simplifies management in the case that the reference bandwidth simplifies management in the case where the
reference bandwidth changes. In order to ensure that small reference bandwidth changes. In order to ensure that small
bandwidth changes do not change the link metric, it is useful to bandwidth changes do not change the link metric, it is useful to
define the granularity of the bandwidth that is of interest. The define the granularity of the bandwidth that is of interest. The
link bandwidth will be truncated to this granularity before link bandwidth will be truncated to this granularity before
deriving the metric. </t> deriving the metric. </t>
<t>For example,</t>
<t> <t indent="3">reference bandwidth = 1000G </t>
For example,</t> <t indent="3">Granularity = 20G </t>
<t><list> <t indent="3">The derived metric is 10 for link bandwidth in the
<t>reference bandwidth = 1000G </t> range 100G to 119G </t>
<t>Granularity = 20G </t> </section>
<t>The derived metric is 10 for link bandwidth in the range 100G to 119G </t> <section anchor="sec_bw_threshold_method" numbered="true" toc="default
</list></t> ">
<name>Bandwidth Thresholds Method</name>
</section> <t> The reference bandwidth approach described above provides a unif
orm
<section title="Bandwidth Thresholds method" metric value for a range of link bandwidths. In certain cases,
anchor='sec_bw_threshold_method'>
<t> The reference bandwidth approach described above provides a uniform
metric value for a range of link bandwidths. In certain cases
there may be a need to define non-proportional metric values for there may be a need to define non-proportional metric values for
the varying ranges of link bandwidth. For example, bandwidths from the varying ranges of link bandwidth. For example, bandwidths from
10G to 30G are assigned metric value 100, bandwidth from 30G to 70G 10G to 30G are assigned metric value 100, bandwidth from 30G to 70G
get a metric value of 50, and bandwidths greater than 70G have a are assigned a metric value of 50, and bandwidths greater than 70G have a
metric of 10. In order to support this, a staircase mapping based metric of 10. In order to support this, a staircase mapping based
on bandwidth thresholds is supported in the FAD. This on bandwidth thresholds is supported in the FAD. This
advertisement contains a set of threshold values and associated advertisement contains a set of threshold values and associated
metrics. </t> metrics. </t>
</section> </section>
</section>
</section> <section anchor="sec_auto_isis" numbered="true" toc="default">
<name>IS-IS FAD Constraint Sub-TLVs for Automatic Metric Calculation</
<section title="IS-IS FAD constraint Sub-TLVs for automatic metric calculation" name>
anchor='sec_auto_isis'> <section anchor="sec_isis_auto_ref_bw" numbered="true" toc="default">
<section title="Reference Bandwidth Sub-TLV" anchor='sec_isis_auto_ref_bw'> <name>Reference Bandwidth Sub-TLV</name>
<t> <t>
This section provides FAD constraint advertisement details for the This section provides FAD constraint advertisement details for the
reference bandwidth method of metric calculation as described in reference bandwidth method of metric calculation, as described in
<xref target ='sec_ref_bw_method'/>. <xref target="sec_ref_bw_method" format="default"/>.
The Flexible Algorithm Definition Reference Bandwidth sub-TLV (FADRB sub-TLV) is The Flexible Algorithm Definition Reference Bandwidth (FADRB) sub-TLV is
a sub-TLV of the IS-IS FAD sub-TLV. It has the following format: a sub-TLV of the IS-IS FAD sub-TLV. It has the following format:
<figure anchor="isis_fadrb_sub_tlv" title="IS-IS FADRB Sub-TLV"> </t>
<artwork> <figure anchor="isis_fadrb_sub_tlv">
<name>IS-IS FADRB Sub-TLV</name>
<artwork name="" type="" align="left" alt=""><![CDATA[
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Flags | | Type | Length | Flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reference Bandwidth | | Reference Bandwidth |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Granularity Bandwidth | | Granularity Bandwidth |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
</figure>
where: <t>where:</t>
Type (1 octet):
An 8-bit field assigned by IANA (To Be Determined as TBD7).
This value uniquely identifies the IS-IS FADRB sub-TLV.
Length (1 octet):
An 8-bit field indicating the total length, in octets,
of the subsequent fields. For this sub-TLV, the Length is set to 9.
Flags (1 octet):
An 8-bit field containing flags.
<dl spacing="normal" newline="true">
<dt>Type (1 octet):</dt>
<dd>An 8-bit field assigned by IANA (8). This value
uniquely identifies the IS-IS FADRB sub-TLV.</dd>
<dt>Length (1 octet):</dt>
<dd>An 8-bit field indicating the total length, in octets, of the subsequent
fields. For this sub-TLV, the Length is set to 9.</dd>
<dt>Flags (1 octet):</dt>
<dd><t>An 8-bit field containing flags.</t>
<artwork name="" type="" align="left" alt=""><![CDATA[
0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
|G| | |G| |
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
]]></artwork></dd>
<dt>G-flag:</dt>
<dd>When set, Interface Group Mode <bcp14>MUST</bcp14> be used to derive
total link bandwidth. Unassigned bits <bcp14>MUST</bcp14> be set to
zero.</dd>
<dt>Reference Bandwidth (4 octets):</dt>
<dd>A 32-bit field with Bandwidth encoded in IEEE floating point format
<xref target="IEEE754-2019"/>. The units are bytes per second.</dd>
<dt>Granularity Bandwidth (4 octets):</dt>
<dd>A 32-bit field with Bandwidth encoded in IEEE floating point format
<xref target="IEEE754-2019"/>. The units are bytes per second.</dd>
</dl>
G-flag: When set, Interface Group Mode MUST be used to <t>When granularity_bw is less than or equal to Total_link_bandwidth, then:</t>
derive total link bandwidth.
Unassigned bits MUST be set to zero.
Reference Bandwidth (4 octets):
A 32-bit field with Bandwidth encoded in
IEEE floating point format [IEEE754-2019].
The units are bytes-per-second.
Granularity Bandwidth (4 octets):
A 32-bit field with Bandwidth encoded in
IEEE floating point format [IEEE754-2019].
The units are bytes-per-second.
When granularity_bw is less than or equal to Total_link_bandwidth
Metric calculation: (Reference_bandwidth) / <dl spacing="normal" newline="false">
(Total_link_bandwidth - <dt>Metric calculation:</dt><dd>(Reference_bandwidth) / (Total_link_bandwidth
(Modulus of(Total_link_bandwidth, - (Modulus of(Total_link_bandwidth, granularity_bw)))</dd>
granularity_bw))) </dl>
When granularity_bw is greater than Total_link_bandwidth <t>When granularity_bw is greater than Total_link_bandwidth, then:</t>
Metric calculation: Reference_bandwidth / <dl spacing="normal" newline="false">
Total_link_bandwidth <dt>Metric calculation:</dt><dd>Reference_bandwidth / Total_link_bandwidth</dd
>
</dl>
The division used here is integer division. <t>The division used here is integer division. Modulus of operation is
Modulus of operation is defined as a remainder defined as a remainder value when two numbers are divided.</t>
value when two numbers are divided.
</artwork> <t> The Granularity Bandwidth value ensures that the metric
</figure>
</t>
<t> The Granularity Bandwidth value ensures that the metric
does not change when there is a small does not change when there is a small
change in the link bandwidth. change in the link bandwidth.
The IS-IS FADRB sub-TLV MUST NOT appear more than once in an IS-IS FAD The IS-IS FADRB sub-TLV <bcp14>MUST NOT</bcp14> appear more than once in an I
sub-TLV. If it appears more than once, the IS-IS FAD sub-TLV MUST be ignored S-IS FAD
by the receiver. The value advertised in the Reference Bandwidth field MUST b sub-TLV. If it appears more than once, the IS-IS FAD sub-TLV <bcp14>MUST</bc
e non-zero. p14> be ignored
If a zero value is advertised in the Reference Bandwidth Field in the IS-IS F by the receiver. The value advertised in the Reference Bandwidth field <bcp14
ADRB sub-TLV, >MUST</bcp14> be non-zero.
the sub-TLV MUST be ignored.</t> If a zero value is advertised in the Reference Bandwidth field in the IS-IS F
<t>If a Generic Metric sub-TLV with Bandwidth metric ADRB sub-TLV,
the sub-TLV <bcp14>MUST</bcp14> be ignored.</t>
<t>If a Generic Metric sub-TLV with a Bandwidth metric
type is advertised for a link, type is advertised for a link,
the Flex-Algorithm calculation MUST use the advertised Bandwidth Metric, the Flex-Algorithm calculation <bcp14>MUST</bcp14> use the advertised Bandwid
and MUST NOT use the automatically derived metric for that link. th Metric
and <bcp14>MUST NOT</bcp14> use the automatically derived metric for that lin
k.
In case of Interface Group Mode, if all the parallel links have been In case of Interface Group Mode, if all the parallel links have been
advertised with the Bandwidth Metric, The individual link Bandwidth Metric advertised with the Bandwidth Metric, the individual link Bandwidth Metric
MUST be used. If only some links among the parallel links have the Bandwidth <bcp14>MUST</bcp14> be used. If only some links among the parallel links have
Metric advertisement, the Bandwidth Metric for such links MUST be ignored and the Bandwidth
automatic Metric calculation MUST be used to derive link metric. Metric advertisement, the Bandwidth Metric for such links <bcp14>MUST</bcp14>
</t> be ignored, and
<t>If the calculated metric evaluates to zero, a metric of 1 MUST be used.</t automatic Metric calculation <bcp14>MUST</bcp14> be used to derive link metri
> c.
<t> If the calculated metric evaluates to a number greater than 0xFFFFFF, </t>
<t>If the calculated metric evaluates to zero, a metric of 1 <bcp14>
MUST</bcp14> be used.</t>
<t> If the calculated metric evaluates to a number greater than 0xFF
FFFF,
it is set to 0xFFFFFF.</t> it is set to 0xFFFFFF.</t>
</section> </section>
<section anchor="sec_isis_threshold_metric" numbered="true" toc="defau
<section title="Bandwidth Thresholds Sub-TLV" anchor='sec_isis_threshold_metric' lt">
> <name>Bandwidth Threshold Sub-TLV</name>
<t> <t>
This section provides FAD constraint advertisement details for the This section provides FAD constraint advertisement details for the
Bandwidth Thresholds method of metric calculation as Bandwidth Thresholds method of metric calculation as
described in <xref target ='sec_bw_threshold_method'/>. described in <xref target="sec_bw_threshold_method" format="default"/>.
The Flexible Algorithm Definition Bandwidth Threshold sub-TLV (FADBT sub-TLV) is The Flexible Algorithm Definition Bandwidth Threshold (FADBT) sub-TLV is
a sub-TLV of the IS-IS FAD sub-TLV. It has the following format: a sub-TLV of the IS-IS FAD sub-TLV. It has the following format:
<figure anchor="isis_fadbt_sub_tlv" title="IS-IS FADBT Sub-TLV"> </t>
<artwork> <figure anchor="isis_fadbt_sub_tlv">
<name>IS-IS FADBT Sub-TLV</name>
<artwork name="" type="" align="left" alt=""><![CDATA[
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Flags | | Type | Length | Flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Bandwidth Threshold 1 | | Bandwidth Threshold 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Threshold Metric 1 | | Threshold Metric 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Bandwidth Threshold 2 | | Bandwidth Threshold 2 |
skipping to change at line 1035 skipping to change at line 1076
| Bandwidth Threshold 3 | | Bandwidth Threshold 3 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
..... .....
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Threshold Metric N-1 | | Threshold Metric N-1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Bandwidth Threshold N | | Bandwidth Threshold N |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Threshold Metric N | | Threshold Metric N |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
</figure>
where: <t>where:</t>
Type (1 octet):
An 8-bit field assigned by IANA (To Be Determined as TBD8).
This value uniquely identifies the IS-IS FADBT sub-TLV.
Length (1 octet):
An 8-bit field indicating the total length, in octets,
of the subsequent fields. For this sub-TLV,
the Length is calculated as (1+n*7). Here n is equal
to number of Threshold Metrics specified.
n MUST be greater than or equal to 1
Flags (1 octet):
<dl spacing="normal" newline="true">
<dt>Type (1 octet):</dt>
<dd> An 8-bit field assigned by IANA (9). This value
uniquely identifies the IS-IS FADBT sub-TLV.</dd>
<dt>Length (1 octet):</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, N is
equal to the number of Threshold Metrics specified. n <bcp14>MUST</bcp14> be
greater than or equal to 1.</dd>
<dt>Flags (1 octet):</dt>
<dd><artwork name="" type="" align="left" alt=""><![CDATA[
0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
|G| | | | |G| | | |
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
]]></artwork>
<dl spacing="normal" newline="false">
<dt>G-flag:</dt><dd>When set, Interface Group Mode <bcp14>MUST</bcp14> be
used to derive total link bandwidth.</dd>
<dt>Unassigned bits</dt><dd> <bcp14>MUST</bcp14> be set to zero.</dd>
</dl>
</dd>
</dl>
G-flag: when set, interface group Mode MUST be used to derive <!--[rfced] We updated this text to make it a complete sentence. There
total link bandwidth. are two instances in the document. Please let us know if this is not correct.
Unassigned bits MUST be set to zero.
Staircase bandwidth threshold and associated metric values. Original:
Staircase bandwidth threshold and associated metric values.
Bandwidth Threshold 1 (4 octets): Current:
Minimum Link Bandwidth is encoded in in Following is the staircase bandwidth threshold and associated metric
IEEE floating point format (32 bits)[IEEE754-2019]. values.
The units are bytes-per-second. -->
Threshold Metric 1 (3 octets): <t>Following is the staircase bandwidth threshold and associated metric values.<
Metric value range (1 - 16,777,215 (0xFFFFFF)) /t>
Bandwidth Threshold n (4 octets): <dl spacing="normal" newline="true">
Maximum Link Bandwidth is encoded in <dt>Bandwidth Threshold 1 (4 octets):</dt>
IEEE floating point format (32 bits)[IEEE754-2019]. <dd>Minimum Link Bandwidth is encoded in IEEE floating point format (32
The units are bytes-per-second. bits)<xref target="IEEE754-2019"/>. The units are bytes per second.</dd>
<dt>Threshold Metric 1 (3 octets):</dt>
<dd>Metric value range (1 - 16,777,215 (0xFFFFFF))</dd>
<dt>Bandwidth Threshold n (4 octets):</dt>
<dd>Maximum Link Bandwidth is encoded in IEEE floating point format (32
bits)<xref target="IEEE754-2019"/>. The units are bytes per second.</dd>
<dt>Threshold Metric n (3 octets):</dt>
<dd>Metric value range (1 - 16,777,215 (0xFFFFFF))</dd>
</dl>
Threshold Metric n (3 octest) : <t>When the G-flag is set, the cumulative bandwidth of the parallel links is
Metric value range (1 - 16,777,215 (0xFFFFFF)) computed as described in <xref target="sec_intf_grp" format="default"/>. If the
G-flag is not set, the advertised Maximum Link Bandwidth is used.</t>
</artwork> <t>The assignment of the Bandwidth Metric based on computed link bandwidth is de
</figure> scribed below.</t>
</t> <t>The Bandwidth Metric for a link during the Flex-Algorithm Shortest Path
First (SPF) calculation <bcp14>MUST</bcp14> be assigned according to the
following rules:</t>
<ol type="1" spacing="normal">
<li><t>When the computed link bandwidth is less than Bandwidth Threshold 1:
</t>
<t>The Bandwidth Metric <bcp14>MUST</bcp14> be set to the maximum metric va
lue of 4,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 Threshold 2:</t>
<t>The Bandwidth Metric <bcp14>MUST</bcp14> be set to Threshold Metric 1.</
t>
</li>
<li><t>When the computed link bandwidth is greater than or equal to
Bandwidth Threshold 2 and less than Bandwidth Threshold 3:</t>
<t>The Bandwidth Metric <bcp14>MUST</bcp14> be set to Threshold Metric 2.</
t>
</li>
<li><t>In general, for all integer values of X such that 1 ≤ X &lt; N:</t>
<t>When the computed link bandwidth is greater than or equal to Bandwidth
Threshold X and less than Bandwidth Threshold X+1:</t>
<t>The Bandwidth Metric <bcp14>MUST</bcp14> be set to Threshold Metric X.</
t>
</li>
<li><t>When the computed link bandwidth is greater than or equal to Bandwid
th Threshold N:</t>
<t>The Bandwidth Metric <bcp14>MUST</bcp14> be set to Threshold Metric N.</
t>
</li>
</ol>
<t>When G-flag is set, the cumulative bandwidth of the <t>Notes:</t>
parallel links is computed <ul spacing="normal">
as described in <xref target ='sec_intf_grp'/>. If G-flag is <li>The term "Bandwidth Threshold X" refers to a predefined threshold
not set, the advertised Maximum Link value corresponding to the index X.</li>
Bandwidth is used.</t> <li>The term "Threshold Metric X" refers to the metric value
<t>Assignment of Bandwidth Metric Based on Computed Link Bandwidth:</t> associated with Bandwidth Threshold X.</li>
<li>N represents the total number of bandwidth thresholds
defined in the system.</li>
</ul>
<t>The Bandwidth Metric for a link during the Flex-Algorithm Shortest <t>Implementations <bcp14>MUST</bcp14> ensure that these rules are c
Path First (SPF) calculation MUST be assigned according to onsistently applied to
the following rules:</t> maintain interoperability and optimal path computation
<t> within the network.</t>
<list> <t>The IS-IS FADBT sub-TLV <bcp14>MUST NOT</bcp14> appear more than
<t>1. When the computed link bandwidth is less than Bandwidth Threshold 1 once in an IS-IS FAD
: sub-TLV. If it appears more than once, the IS-IS FAD sub-TLV <bcp14>MUST</bc
<ul> p14>
<li> The Bandwidth Metric MUST be set to the maximum metric value of 4,26 be ignored by the receiver.</t>
1,412,864.</li> <t>A FAD <bcp14>MUST NOT</bcp14> contain both the FADBT sub-TLV and
</ul> the FADRB sub-TLV. If both
</t> of these sub-TLVs are advertised in the same FAD for a Flexible
<t>2. When the computed link bandwidth is greater than or equal to Algorithm, the FAD <bcp14>MUST</bcp14> be ignored by the receiver.</t>
Bandwidth Threshold 1 and less than Bandwidth Threshold 2: <t>If a Generic Metric sub-TLV with Bandwidth metric type is adverti
<ul> sed
<li> The Bandwidth Metric MUST be set to Threshold Metric 1.</li> for a link, the Flex-Algorithm calculation <bcp14>MUST</bcp14> use the Bandwi
</ul> dth
</t> Metric advertised on the link and <bcp14>MUST NOT</bcp14> use the automatical
ly
derived metric for that link.</t>
<t>3. When the computed link bandwidth is greater than or equal <!--[rfced] We note similar text in Sections 4.1.3.1, 4.1.3.2, and
to Bandwidth Threshold 2 and less than Bandwidth Threshold 3: 4.1.4.2. Should any of this text be in paragraph form or
<ul> bulleted form for consistency?
<li> The Bandwidth Metric MUST be set to Threshold Metric 2.</li>
</ul>
</t>
<t>4. In general, for all integer values of X such that 1 ≤ X &lt; N: Original
<ul> Section 4.1.3.1:
<li> When the computed link bandwidth is greater than or equal to In case of Interface Group Mode, if
Bandwidth Threshold X and less than Bandwidth Threshold X+1:</li> all the parallel links have been advertised with the Bandwidth
<li> The Bandwidth Metric MUST be set to Threshold Metric X.</li> Metric, The individual link Bandwidth Metric MUST be used. If only
</ul> some links among the parallel links have the Bandwidth Metric
</t> advertisement, the Bandwidth Metric for such links MUST be ignored
and automatic Metric calculation MUST be used to derive link metric.
<t>5. When the computed link bandwidth is greater than or equal to Bandwidth Section 4.1.3.2:
Threshold N: In case of Interface Group Mode, if all the parallel links have been
<ul> advertised with the Bandwidth Metric, The individual link Bandwidth
<li> The Bandwidth Metric MUST be set to Threshold Metric N.</l Metric MUST be used. If only some links among the parallel links
i> have the Bandwidth Metric advertisement, the Bandwidth Metric for
</ul> such links MUST be ignored and automatic Metric calculation MUST be
</t> used to derive link metric.
</list>
</t>
<t>Notes:
<list>
<t>The term Bandwidth Threshold X refers to a predefined threshold
value corresponding to the index X.</t>
<t>The term Threshold Metric X refers to the metric value
associated with Bandwidth Threshold X.</t>
<t>N represents the total number of bandwidth thresholds
defined in the system.</t>
</list>
</t>
<t>Implementations MUST ensure that these rules are consistently applied to
maintain interoperability and optimal path computation
within the network.</t>
<t>The IS-IS FADBT sub-TLV MUST NOT appear more than once in an IS-IS FAD Section 4.1.4.2:
sub-TLV. If it appears more than once, the IS-IS FAD sub-TLV MUST In the context of Interface Group Mode, the following rules apply to
be ignored by the receiver.</t> parallel links:
<t>A FAD MUST NOT contain both the FADBT sub-TLV and the FADRB sub-TLV. If b * If all parallel links have advertised the Bandwidth Metric:
oth
these sub-TLVs are advertised in the same FAD for a Flexible
Algorithm, the FAD MUST be ignored by the receiver.</t>
<t>If a Generic Metric sub-TLV with Bandwidth metric type is advertised The individual link Bandwidth Metrics MUST be used for each link
for a link, the Flex-Algorithm calculation MUST use the Bandwidth during path computation.
Metric advertised on the link, and MUST NOT use the automatically
derived metric for that link.</t>
<t>In case of Interface Group Mode, if all the parallel links * If only some of the parallel links have advertised the Bandwidth
have been advertised with the Bandwidth Metric, The individual Metric:
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.</t>
</section> - The Bandwidth Metric advertisements for those links MUST be
</section> ignored.
<section title="OSPF FAD constraint Sub-TLVs for automatic metric calculation" - Automatic metric calculation MUST be used to derive the link
anchor='sec_auto_ospf'> metrics for all parallel links.
<section title="Reference Bandwidth Sub-TLV" anchor='sec_ospf_auto_ref_bw'> -->
<t>
The Flexible Algorithm Definition Reference Bandwidth sub-TLV (FADRB sub-TLV) is
a sub-TLV of the OSPF FAD TLV. It has the following format:
<figure anchor="ospf_fadrb_sub_tlv" title="OSPF FADRB Sub-TLV"> <t>In case of Interface Group Mode, if all the parallel links
<artwork> 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 m
etric.</t>
</section>
</section>
<section anchor="sec_auto_ospf" numbered="true" toc="default">
<name>OSPF FAD Constraint Sub-TLVs for Automatic Metric Calculation</n
ame>
<section anchor="sec_ospf_auto_ref_bw" numbered="true" toc="default">
<name>Reference Bandwidth Sub-TLV</name>
<t>
The Flexible Algorithm Definition Reference Bandwidth (FADRB) sub-TLV is
a sub-TLV of the OSPF FAD TLV. It has the following format:
</t>
<figure anchor="ospf_fadrb_sub_tlv">
<name>OSPF FADRB Sub-TLV</name>
<artwork name="" type="" align="left" alt=""><![CDATA[
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | | Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags | Reserved | | Flags | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reference Bandwidth | | Reference Bandwidth |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Granularity Bandwidth | | Granularity Bandwidth |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
</figure>
where: <t>where:</t>
Type (2 octets):
A 16-bit field assigned by IANA (To Be Determined as TBD9).
This value uniquely identifies the OSPF FADRB sub-TLV.
Length (2 octets):
A 16-bit field indicating the total length, in octets,
of the subsequent fields. For this sub-TLV, Length is set to 14.
Flags (1 octet):
<dl spacing="normal" newline="true">
<dt>Type (2 octets):</dt>
<dd>A 16-bit field assigned by IANA (8). This value
uniquely identifies the OSPF FADRB sub-TLV.</dd>
<dt>Length (2 octets):</dt>
<dd>A 16-bit field indicating the total length, in octets, of the subsequent
fields. For this sub-TLV, Length is set to 14.</dd>
<dt>Flags (1 octet):</dt>
<dd><artwork name="" type="" align="left" alt=""><![CDATA[
0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
|G| | | | |G| | | |
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
]]></artwork>
<dl spacing="normal" newline="false">
<dt>G-flag:</dt><dd>When set, Interface Group Mode <bcp14>MUST</bcp14> be
used to derive total link bandwidth.</dd>
<dt>Unassigned bits</dt><dd> <bcp14>MUST</bcp14> be set to zero.</dd>
</dl></dd>
<dt>Reference Bandwidth (4 octets):</dt>
<dd>Bandwidth encoded in 32 bits in IEEE floating point format
<xref target="IEEE754-2019"/>. The units are in bytes per second.</dd>
<dt>Granularity Bandwidth (4 octets):</dt>
<dd>Bandwidth encoded in 32 bits in IEEE floating point format
<xref target="IEEE754-2019"/>. The units are in bytes per second.</dd>
</dl>
G-flag: When set, Interface Group Mode MUST be used <t>When granularity_bw is less than or equal to Total_link_bandwidth, then:</t>
to derive total link bandwidth.
Unassigned bits MUST be set to zero.
Reference Bandwidth (4 octets):
Bandwidth encoded in 32 bits in
IEEE floating point format [IEEE754-2019].
The units are in bytes per second.
Granularity Bandwidth (4 octets):
Bandwidth encoded in 32 bits in
IEEE floating point format [IEEE754-2019].
The units are in bytes per second.
When granularity_bw is less than or equal to Total_link_bandwidth
Metric calculation: (Reference_bandwidth) / <dl spacing="normal" newline="true">
(Total_link_bandwidth - <dt>Metric calculation:</dt><dd>(Reference_bandwidth) /
(Modulus of(Total_link_bandwidth, (Total_link_bandwidth - (Modulus of(Total_link_bandwidth,
granularity_bw))) granularity_bw)))</dd>
</dl>
When granularity_bw is greater than Total_link_bandwidth <t>When granularity_bw is greater than Total_link_bandwidth, then:</t>
Metric calculation: Reference_bandwidth/ <dl spacing="normal" newline="true">
Total_link_bandwidth <dt>Metric calculation:</dt><dd>Reference_bandwidth/
Total_link_bandwidth</dd>
</dl>
The division used here is integer division. <t>The division used here is integer division.</t>
Modulus of operation is defined as a remainder <t>Modulus of operation is defined as a remainder value when two numbers are
value when two numbers are divided. divided.</t>
</artwork>
</figure>
The Granularity Bandwidth value is used to ensure that the <t>The Granularity Bandwidth value is used to ensure that the metric does not
metric does not change when there is a small change when there is a small change in the link bandwidth. The OSPF FADRB
change in the link bandwidth. sub-TLV <bcp14>MUST NOT</bcp14> appear more than once in an OSPF FAD TLV. If
The OSPF FADRB sub-TLV MUST NOT appear more than once in an OSPF FAD it appears more than once, the OSPF FAD TLV <bcp14>MUST</bcp14> be ignored by
TLV. If it appears more than once, the OSPF FAD TLV MUST be ignored the receiver. The value advertised in the Reference Bandwidth field
by the receiver.The value advertised in the Reference Bandwidth field MUST be <bcp14>MUST</bcp14> be non-zero. If a zero value is advertised in the
non-zero. Reference Bandwidth field in the OSPF FADRB sub-TLV, the sub-TLV
If a zero value is advertised in the Reference Bandwidth Field in the OSPF FA <bcp14>MUST</bcp14> be ignored. If a Generic Metric sub-TLV with Bandwidth
DRB sub-TLV, metric type is advertised for a link, the Flex-Algorithm calculation
the sub-TLV MUST be ignored. <bcp14>MUST</bcp14> use the advertised Bandwidth Metric on the link and
If a Generic Metric sub-TLV with Bandwidth metric type is <bcp14>MUST NOT</bcp14> use the automatically derived metric for that link.
advertised for a link, the Flex-Algorithm calculation MUST use In the case of Interface Group Mode, the following procedures apply:
the advertised Bandwidth Metric </t>
on the link, and MUST NOT use the automatically derived <ul spacing="normal">
metric for that link. <li>
In the case of Interface Group Mode, the following procedures apply: <t> When all parallel links have advertised the Bandwidth
<list> Metric: The individual link Bandwidth Metric
<t> When all parallel links have advertised the Bandwidth Metric: <bcp14>MUST</bcp14> be used for each link.</t>
The individual link Bandwidth Metric MUST be used for each link.</t> </li>
<t> When only a subset of the parallel links have advertised <li>
the Bandwidth Metric: The Bandwidth Metric advertisements for <t> When only a subset of the parallel links have advertised
those links MUST be ignored. In this scenario, automatic the Bandwidth Metric: The Bandwidth Metric advertisements for
metric calculation MUST be used to derive the link metrics those links <bcp14>MUST</bcp14> be ignored. In this scenario,
for all parallel links.</t> automatic metric calculation <bcp14>MUST</bcp14> be used to
</list> derive the link metrics for all parallel links.</t>
</li>
</ul>
</t> <t>If the calculated metric evaluates to zero, a metric of 1 <bcp14>
<t>If the calculated metric evaluates to zero, a metric of 1 MUST be used.</t> MUST</bcp14> be used.</t>
<t> If the calculated metric evaluates to a number greater than 0xFFFFFFFF, <t> If the calculated metric evaluates to a number greater than 0xFF
FFFFFF,
it is set to 0xFFFFFFFF.</t> it is set to 0xFFFFFFFF.</t>
</section> </section>
<section anchor="sec_ospf_threshold_metric" numbered="true" toc="defau
<section title="Bandwidth Threshold Sub-TLV" anchor='sec_ospf_threshold_metric'> lt">
<t> <name>Bandwidth Threshold Sub-TLV</name>
The Flexible Algorithm Definition Bandwidth Thresholds sub-TLV <t>
(FADBT sub-TLV) is The Flexible Algorithm Definition Bandwidth Threshold (FADBT) sub-TLV is
a sub-TLV of the OSPF FAD TLV. It has the following format: a sub-TLV of the OSPF FAD TLV. It has the following format:
<figure anchor="ospf_fadbt_sub_tlv" title="OSPF FADBT Sub-TLV"> </t>
<artwork> <figure anchor="ospf_fadbt_sub_tlv">
<name>OSPF FADBT Sub-TLV</name>
<artwork name="" type="" align="left" alt=""><![CDATA[
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | | Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags | Reserved | | Flags | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Bandwidth Threshold 1 | | Bandwidth Threshold 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Threshold Metric 1 | | Threshold Metric 1 |
skipping to change at line 1300 skipping to change at line 1375
| Bandwidth Threshold 3 | | Bandwidth Threshold 3 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
..... .....
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Threshold Metric N-1 | | Threshold Metric N-1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Bandwidth Threshold N | | Bandwidth Threshold N |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Threshold Metric N | | Threshold Metric N |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
</figure>
where: <t>where:</t>
Type (2 octets): <dl spacing="normal" newline="true">
A 16-bit field assigned by IANA (To Be Determined as TBD10). <dt>Type (2 octets):</dt>
This value uniquely identifies the OSPF FADBT sub-TLV. <dd>A 16-bit field assigned by IANA (9). This value
uniquely identifies the OSPF FADBT sub-TLV.</dd>
Length (2 octets): <dt>Length (2 octets):</dt>
A 16-bit field indicating the total length, in octets, <dd>A 16-bit field indicating the total length, in octets, of the subsequent
of the subsequent fields. For this sub-TLV, Length is set fields. For this sub-TLV, Length is set to 2 + N*8 octets. Here, N is equal to
2 + N*8 octets. Here N is equal to number of the number of Threshold Metrics specified. N <bcp14>MUST</bcp14> be greater th
Threshold Metrics specified. N MUST be greater than or equal to 1. an
or equal to 1.</dd>
Flags (1 octet): <dt>Flags (1 octet):</dt>
<dd>
<artwork name="" type="" align="left" alt=""><![CDATA[
0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
|G| | |G| |
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
]]></artwork>
<dl spacing="normal" newline="false">
<dt>G-flag:</dt><dd>When set, Interface Group Mode <bcp14>MUST</bcp14>
be used to derive total link bandwidth.</dd>
<dt>Unassigned bits</dt><dd><bcp14>MUST</bcp14> be set to zero.</dd>
</dl>
</dd>
</dl>
G-flag: when set, interface group Mode MUST be used to <t>Following is the staircase bandwidth threshold and associated metric values.<
derive total link bandwidth. /t>
Unassigned bits MUST be set to zero.
Staircase bandwidth threshold and associated metric values.
Bandwidth Threshold 1 (4 octets):
Minimum Link Bandwidth is encoded
in IEEE floating point format (32 bits)[IEEE754-2019].
The units are bytes per second.
Threshold Metric 1 (4 octets):
Metric value range (1 - 4,294,967,296 (0xFFFFFFFF))
Bandwidth Threshold N (4 octets):
Maximum Link Bandwidth is encoded
in IEEE floating point format (32 bits)[IEEE754-2019].
The units are bytes per second.
Threshold Metric N (4 octets): <dl spacing="normal" newline="true">
Metric value range (1 - 4,294,967,296 (0xFFFFFFFF)) <dt>Bandwidth Threshold 1 (4 octets):</dt>
<dd>Minimum Link Bandwidth is encoded in IEEE floating point format (32
bits)<xref target="IEEE754-2019"/>. The units are bytes per second.</dd>
<dt>Threshold Metric 1 (4 octets):</dt>
<dd>Metric value range (1 - 4,294,967,296 (0xFFFFFFFF))</dd>
<dt>Bandwidth Threshold N (4 octets): </dt>
<dd>Maximum Link Bandwidth is encoded in IEEE floating point format (32
bits)<xref target="IEEE754-2019"/>. The units are bytes per second.</dd>
<dt>Threshold Metric N (4 octets):</dt>
<dd>Metric value range (1 - 4,294,967,296 (0xFFFFFFFF))</dd>
</dl>
</artwork> <t>When the G-flag is set, the cumulative bandwidth of the parallel links is
</figure> computed as described in <xref target="sec_intf_grp" format="default"/>. If
</t> the G-flag is not set, the advertised Maximum Link Bandwidth is used.</t>
<t>When G-flag is set, the cumulative bandwidth of the parallel links is <t>The assignment of the Bandwidth Metric based on computed link bandwidth is de
computed as described in <xref target ='sec_intf_grp'/>. scribed below.</t>
If G-flag is not set, the advertised Maximum Link <t>During the Flex-Algorithm SPF calculation, the Bandwidth Metric for a link <
Bandwidth is used.</t> bcp14>MUST</bcp14> be assigned according to the following rules:</t>
<t>Assignment of Bandwidth Metric Based on Computed Link Bandwidth:</t> <ol type="1" spacing="normal">
<li><t>When the computed link bandwidth is less than Bandwidth Threshold 1:</t
>
<t>The Bandwidth Metric <bcp14>MUST</bcp14> be set to the maximum metric
value of 4,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 Threshold 2:</t>
<t>The Bandwidth Metric <bcp14>MUST</bcp14> be set to Threshold Metric 1.</t>
</li>
<li><t>When the computed link bandwidth is greater than or equal to
Bandwidth Threshold 2 and less than Bandwidth Threshold 3:</t>
<t>The Bandwidth Metric <bcp14>MUST</bcp14> be set to Threshold Metric 2.</t><
/li>
<li><t>In general, for all integer values of X where 1 ≤X &lt; N:</t>
<t>When the computed link bandwidth is greater than or equal to Bandwidth
Threshold X and less than Bandwidth Threshold X+1:</t>
<t>The Bandwidth Metric <bcp14>MUST</bcp14> be set to Threshold Metric X.</t><
/li>
<li><t>When the computed link bandwidth is greater than or equal to
Bandwidth Threshold N:</t>
<t>The Bandwidth Metric <bcp14>MUST</bcp14> be set to Threshold Metric N.</t><
/li>
</ol>
<t>The Bandwidth Metric for a link during the Flex-Algorithm <t>Notes:</t>
Shortest Path First (SPF) calculation MUST be assigned according <ul spacing="normal">
to the following rules:</t> <li>
<t> <t>Bandwidth Threshold X refers to the predefined bandwidth threshold
<list> corresponding to index X.</t>
<t>1. When the computed link bandwidth is less than Bandwidth Threshold 1: </li>
<ul> <li>
<li>The Bandwidth Metric MUST be set to the maximum metric <t>Threshold Metric X is the metric value associated with Bandwidth
value of 4,294,967,296.</li> Threshold X.</t>
</ul> </li>
</t> <li>
<t>2. When the computed link bandwidth is greater than or equal <t>N represents the total number of bandwidth thresholds defined in the
to Bandwidth Threshold 1 and less than Bandwidth Threshold 2: system.</t>
<ul> </li>
<li>The Bandwidth Metric MUST be set to Threshold Metric 1.</li> </ul>
</ul>
</t>
<t>3. When the computed link bandwidth is greater than or equal
to Bandwidth Threshold 2 and less than Bandwidth Threshold 3:
<ul>
<li> The Bandwidth Metric MUST be set to Threshold Metric 2.</li>
</ul>
</t>
<t>4. In general, for all integer values of X where 1 ≤X &lt; N:
<ul>
<li>When the computed link bandwidth is greater than or equal to
Bandwidth Threshold X and less than Bandwidth Threshold X+1:</li>
<li>The Bandwidth Metric MUST be set to Threshold Metric X.</li>
</ul>
</t>
<t>5. When the computed link bandwidth is greater than or equal
to Bandwidth Threshold N:
<ul>
<li>The Bandwidth Metric MUST be set to Threshold Metric N.</li>
</ul>
</t>
</list>
</t>
<t>Notes:
<list>
<t>Bandwidth Threshold X refers to the predefined bandwidth
threshold corresponding to index X.</t>
<t>Threshold Metric X is the metric value associated with
Bandwidth Threshold X.</t>
<t>N represents the total number of bandwidth thresholds
defined in the system.</t>
</list> <t>Implementations <bcp14>MUST</bcp14> consistently apply these rule
</t> s to ensure accurate
<t>Implementations MUST consistently apply these rules to ensure accurate
path computations and maintain interoperability within the network.</t> path computations and maintain interoperability within the network.</t>
<t>The OSPF FADBT sub-TLV <bcp14>MUST NOT</bcp14> appear more than o
<t>The OSPF FADBT sub-TLV MUST NOT appear more than once in an OSPF FAD nce in an OSPF FAD
sub-TLV. If it appears more than once, the OSPF FAD MUST sub-TLV. If it appears more than once, the OSPF FAD sub-TLV <bcp14>MUST</bcp
14>
be ignored by the receiver.</t> be ignored by the receiver.</t>
<t>A FAD <bcp14>MUST NOT</bcp14> contain both the FADBT sub-TLV and
<t>A FAD MUST NOT contain both the FADBT sub-TLV and the FADRB sub-TLV. If b the FADRB sub-TLV. If both
oth
these sub-TLVs are advertised in the same FAD for a Flexible these sub-TLVs are advertised in the same FAD for a Flexible
Algorithm, the FAD MUST be ignored by the receiver.</t> Algorithm, the FAD <bcp14>MUST</bcp14> be ignored by the receiver.</t>
<t>If a Generic Metric sub-TLV with Bandwidth metric type is adverti
<t>If a Generic Metric sub-TLV with Bandwidth metric type is advertised sed
for a link, the Flex-Algorithm calculation MUST use the Bandwidth for a link, the Flex-Algorithm calculation <bcp14>MUST</bcp14> use the Bandwi
Metric advertised on the link, and MUST NOT use the automatically dth
Metric advertised on the link and <bcp14>MUST NOT</bcp14> use the automatical
ly
derived metric for that link.</t> 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 metric <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>
<ul spacing="normal">
<li>
<t>If all parallel links have advertised the Bandwidth Metric:</
t>
<t>The individual link Bandwidth Metrics <bcp14>MUST</bcp14> be
used for each link during path computation.</t>
</li>
<li>
<t>If only some of the parallel links have advertised the Bandwi
dth Metric:</t>
<ul>
<li>The Bandwidth Metric advertisements for those links <bcp14
>MUST</bcp14> be ignored.</li>
<li>Automatic metric calculation <bcp14>MUST</bcp14> be used t
o derive the link metrics for all parallel links.</li>
</ul>
</li>
</ul>
<t> Metric Assignment in Interface Group Mode:</t> <t>This approach ensures consistent metric calculation and avoids di
<t>When a link does not have a configured Bandwidth Metric, screpancies
the automatically derived metric MUST 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 all parallel links have advertised the Bandwidth Metric:
<ul>
<li>The individual link Bandwidth Metrics MUST be used for each link duri
ng path computation.</li>
</ul>
</t>
<t>If only some of the parallel links have advertised the Bandwidth Metric:
<ul>
<li>The Bandwidth Metric advertisements for those links MUST be ignored.<
/li>
<li>Automatic metric calculation MUST be used to derive the link metrics for
all parallel links.</li>
</ul>
</t>
</list>
</t>
<t>This approach ensures consistent metric calculation and avoids discrepancies
caused by partial Bandwidth Metric advertisements among parallel links.</t> caused by partial Bandwidth Metric advertisements among parallel links.</t>
</section>
</section> </section>
</section>
</section> </section>
</section> <section anchor="sec-metric" numbered="true" toc="default">
</section> <name>Bandwidth Metric Considerations</name>
<t>
<section title='Bandwidth metric considerations' anchor='sec-metric'>
<t>
This section specifies the rules of deriving the Bandwidth Metric if This section specifies the rules of deriving the Bandwidth Metric if
and only if the winning FAD for the Flex-Algorithm specifies the and only if the winning FAD for the Flex-Algorithm specifies the
metric-type as "Bandwidth Metric". metric-type as "Bandwidth Metric".
<list> </t>
<t>1. If the Generic Metric sub-TLV with Bandwidth metric type <ol type="1" spacing="normal">
is advertised for the link as <li>If the Generic Metric sub-TLV with Bandwidth metric type is
described in <xref target ='sec_bw_metric'/>, advertised for the link as described in <xref target="sec_bw_metric"
it MUST be used during the Flex-Algorithm format="default"/>, it <bcp14>MUST</bcp14> be used during the
calculation.</t> Flex-Algorithm calculation.</li>
<li>If the Generic Metric sub-TLV with Bandwidth metric type is not
<t>2. If the Generic Metric sub-TLV with Bandwidth metric type advertised for the link and the winning FAD for the Flex-Algorithm
is not advertised for the link does not specify the automatic bandwidth metric calculation (as
and the winning FAD for the Flex-Algorithm does not specify defined in <xref target="sec_auto_metric" format="default"/>), the
the automatic bandwidth metric calculation (as defined in link is treated as if the Bandwidth Metric is not available for the
<xref target ='sec_auto_metric'/> ), link.</li>
the link is treated as if the Bandwidth Metric is not <li>If the Generic Metric sub-TLV with Bandwidth metric type is not
available for the link.</t> advertised for the link and the winning FAD (<xref section="5.3"
target="RFC9350" format="default"/>) for the Flex-Algorithm specifies
the automatic bandwidth metric calculation (as defined in <xref
target="sec_auto_metric" format="default"/>), the Bandwidth Metric
<bcp14>MUST</bcp14> be automatically calculated per the
procedures defined in <xref target="sec_auto_metric"
format="default"/>. If the Link Bandwidth is not advertised for a
link, the link <bcp14>MUST</bcp14> be pruned for the Flex-Algorithm
calculations.</li>
<li>In ISIS, for Flex-Algorithm purposes, the Link Bandwidth is
advertised as a sub-sub-TLV 9 of the Flex-Algorithm-specific ASLA
sub-TLV. It is also possible to advertise the link bandwidth or
Flex-Algorithm in sub-TLV 9 of TLV 22/222/23/223/141 <xref target="RFC53
05"/>
together with the L-flag set in the Flex-Algorithm-specific ASLA
advertisement. In the absence of both of these advertisements, the
bandwidth of the link is not available for Flex-Algorithm
purposes.</li>
</ol>
<t>3. If the Generic Metric sub-TLV with Bandwidth metric type </section>
is not advertised for the link
and the winning FAD (sec 5.3 <xref target ='RFC9350'/>
for the Flex-Algorithm specifies the automatic bandwidth
metric calculation (as defined in
<xref target ='sec_auto_metric'/>),
the Bandwidth Metric metric MUST be automatically calculated as per
the procedures defined in <xref target ='sec_auto_metric'/>.
If the Link Bandwidth is not advertised for a link, the link MUST be
pruned for the Flex-Algorithm calculations.</t>
<t>4.In ISIS the Link Bandwidth for Flex-Algorithm purposes is advertised <!-- This section sounds like this it updates RFC 9350. Please confirm that an
as a Updates tag is not needed on this document.
sub-sub-TLV 9 of the Flex-algorithm specific ASLA sub-TLV. It is also possi
ble
to advertise the link bandwidth or Flex-Algorithm, in sub-TLV 9 of
TLV 22/222/23/223/141 [RFC5305], together with the L-Flag set
in the Flex-Algorithm specific ASLA advertisement. In the absence of both
of these advertisements, the bandwidth of the link is not available
for Flex-Algorithm purposes.</t>
</list> Original:
6. Calculation of Flex-Algorithm paths
</t> Two new additional rules are added to the existing rules in the Flex-
</section> Algorithm calculations specified in Section 13 of [RFC9350].
<section title='Calculation of Flex-Algorithm paths' anchor='sec-calc'> 6. Check if any exclude FAEMB rule is part of the Flex-Algorithm
<t> Two new additional rules are added to the existing rules in the definition. If such exclude rule exists and the link has Maximum
Flex-Algorithm calculations specified in Section 13 of Link Bandwidth advertised, check if the link bandwidth satisfies
<xref target ='RFC9350'/>.</t> the FAEMB rule. If the link does not satisfy the FAEMB rule, the
link MUST be pruned from the Flex-Algorithm computation.
<t> 7. Check if any exclude FAEMD rule is part of the Flex-Algorithm
<list> definition. If such exclude rule exists and the link has Min
Unidirectional link delay advertised, check if the link delay
satisfies the FAEMD rule. If the link does not satisfy the FAEMD
rule, the link MUST be pruned from the Flex-Algorithm computation.
-->
<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>
<t>6. Check if any exclude FAEMB rule is part of the Flex-Algorithm <blockquote>
definition. If such exclude rule exists and the link has Maximum Link <ol spacing="normal" start="6">
Bandwidth advertised, check if the link bandwidth satisfies the <li>Check if any exclude FAEMB rule is part of the Flex-Algorithm
FAEMB rule. If the link does not satisfy the FAEMB rule, definition. If such exclude rule exists and the link has Maximum Link
the link MUST be pruned from the Flex-Algorithm computation.</t> Bandwidth advertised, check if the link bandwidth satisfies the FAEMB
<t>7. Check if any exclude FAEMD rule is part of the Flex-Algorithm rule. If the link does not satisfy the FAEMB rule, the link
definition. If such exclude rule exists and the link has <bcp14>MUST</bcp14> be pruned from the Flex-Algorithm computation.</li>
Min Unidirectional link delay advertised, check if the link delay <li>Check if any exclude FAEMD rule is part of the Flex-Algorithm
satisfies the FAEMD rule. If the link does not satisfy the FAEMD rule, definition. If such exclude rule exists and the link has Min
the link MUST be pruned from the Flex-Algorithm computation.</t> Unidirectional link delay advertised, check if the link delay
</list> satisfies the FAEMD rule. If the link does not satisfy the FAEMD rule,
</t> the link <bcp14>MUST</bcp14> be pruned from the Flex-Algorithm
computation.</li>
</ol>
</blockquote>
</section> </section>
<section anchor='backward_compatibility' title='Backward Compatibility'> <section anchor="backward_compatibility" numbered="true" toc="default">
<t> This extension brings no new backward-compatibility issues. <name>Backward Compatibility</name>
This document defines new FAD constraints in <t> This extension brings no new backward-compatibility issues.
<xref target ='sec_fad_con'/> <xref target ='sec_auto_isis'/> an This document defines new FAD constraints in Sections
d <xref target="sec_fad_con" format="counter"/>, <xref target="sec
<xref target ='sec_auto_ospf'/>. As described in <xref target = _auto_isis" format="counter"/>, and
'RFC9350'/>, <xref target="sec_auto_ospf" format="counter"/>. As described in
any node that does not understand sub-TLVs in a FAD TLV, stops p <xref target="RFC9350" format="default"/>,
articipation in the any node that does not understand sub-TLVs in a FAD TLV stops pa
rticipation in the
corresponding Flex-Algorithm. The new extensions can be deployed among the nodes that are 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. upgraded to understand the new extensions without affecting the nodes that are not upgraded.
This document also defines a new metric advertisement as describ ed in This document also defines a new metric advertisement as describ ed in
<xref target ='sec_generic_metric'/>. As per Section 13 of <xref <xref target="sec_generic_metric" format="default"/>. As per <xr
target ='RFC9350'/>, ef target="RFC9350" sectionFormat="of" section="13"/>,
the links that do not advertise the metric-type specified by the when the links do not advertise the metric-type specified by the
selected FAD, selected FAD,
the link is pruned from Flex-Algorithm calculations. The new met the link is pruned from Flex-Algorithm calculations. The new met
ric-types and the ric-types and
Flex-Algorithms using new metric-types can be deployed in the network w Flex-Algorithms using the new metric-types can be deployed in the netwo
ithout affecting rk without affecting
existing deployment. </t> existing deployment. </t>
</section>
</section> <section anchor="sec-con" numbered="true" toc="default">
<section title='Security Considerations' anchor='sec-con'> <name>Security Considerations</name>
<t>This document inherits security considerations from <xref target ='RFC935 <t>This document inherits security considerations from <xref target="RFC93
0'/>.</t> 50" format="default"/>.</t>
</section> </section>
<section anchor="sec-ops" numbered="true" toc="default">
<section title='Operational Considerations' anchor='sec-ops'> <name>Operational Considerations</name>
<t>Operational consideration defined in <xref target ='RFC9350'/> generally <t>Operational considerations defined in <xref target="RFC9350" format="de
apply to fault"/> generally apply to
the extensions defined in this document as well. This document defines me the extensions defined in this document as well. This document defines a
tric-type metric-type
range for user defined metrics. When user-defined metrics are used in an range for user-defined metrics. When user-defined metrics are used in an
inter-area or inter-area or
inter-level network, all the domains should assign same meaning to the pa rticular inter-level network, all the domains should assign same meaning to the pa rticular
metric-type. The YANG data models for Flex-Algorithm extensions are defin ed in metric-type. The YANG data models for Flex-Algorithm extensions are defin ed in
documents <xref target ='I-D.ietf-lsr-ospf-yang-augmentation-v1'/> and documents <xref target="I-D.ietf-lsr-ospf-yang-augmentation-v1" format="d
<xref target ='I-D.ietf-lsr-isis-yang-augmentation-v1'/></t> efault"/> and
<t>Before the router goes into maintenance activity, the traffic needs to <xref target="I-D.ietf-lsr-isis-yang-augmentation-v1" format="default"/>.
be diverted away </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 setti ng link metrics on the from the router. This is achieved by setting the overload bit or setti ng link metrics on the
router to a high value. In case of Generic Metric, the link metrics ca router to a high value. In case of Generic Metric, the link metrics ca
n be set to Maximum n be set to a Maximum
usable metric for OSPF and ISIS. The traffic will be diverted away fro usable metric for OSPF and IS-IS. The traffic will be diverted away fr
m the router to a shorter om the router to a shorter
available path. If there are no alternate paths available, traffic wil l stay on the router as available path. If there are no alternate paths available, traffic wil l stay on the router as
the links are not removed from Flex-algorithm calculation when they ar the links are not removed from the Flex-Algorithm calculation when the
e set to maximum metric as per y are set to a maximum metric per
<xref target ='RFC9350'/> <xref target="RFC9350" format="default"/>.
</t> </t>
</section> </section>
<section anchor="IANA" title="IANA Considerations"> <section anchor="IANA" numbered="true" toc="default">
<name>IANA Considerations</name>
<section anchor='igp_metric_type' title='IGP Metric-Type Registry'> <section anchor="igp_metric_type" numbered="true" toc="default">
<name>IGP Metric-Type Registry</name>
<t>IGP Metric-type Registry is updated to include another column specify <t>The "IGP Metric-Type" registry has been updated to include another co
ing lumn
whether the particular metric-type is allowed in the generic-metric sub- specifying whether the particular metric-type is allowed in the
TLV or not. Generic Metric sub-TLV. The range 128-255 is redefined
The range 128-255 is being redefined in this document as user-defined ra by this document as a user-defined range, and this range does not requir
nge e
and this range does not standards action. Standards Action <xref target="RFC8126"/>. </t>
</t>
<t>
<figure anchor="iana_metric_type" title="IANA IGP Metric-Type Registry">
<artwork>
Type Description Reference Allowed in
generic-metric
----------------------------------------------------------------
0 IGP Metric [RFC9350] No
Section 5.1
1 Min Unidirectional [RFC9350] No
Link Delay as defined Section 5.1
in [RFC8570,
Section 4.2],and
[RFC7471, Section 4.2]
2 Traffic Engineering Default [RFC9350] No
Metric as defined in Section 5.1
[RFC5305,Section 3.7],
and [RFC3630, Section 2.5.5]
3(TBA) Bandwidth Metric this document yes
128-255(TBA) User defined metric this document yes
</artwork>
</figure>
</t>
</section>
<section anchor='isis_fad'
title='IS-IS Sub-Sub-TLVs for Flexible Algorithm Definition Sub-TLV'>
<t>IS-IS Sub-Sub-TLVs for Flexible Algorithm Definition Sub-TLV is part
of the “IS-IS TLV Codepoints” registry group.</t>
<t> Type: 6(TBD3)</t>
<t> Description: IS-IS Exclude Minimum Bandwidth Sub-TLV </t>
<t>Reference: This document <xref target ='sec_isis_bw_exclusion'/></t>
<t> Type: 7 (TBD4)</t>
<t> Description: IS-IS Exclude Maximum Delay Sub-TLV </t>
<t>Reference: This document <xref target ='sec_isis_delay_exclusion'/></t>
<t> Type: 8 (TBD7)</t>
<t> Description: IS-IS Reference Bandwidth 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> <table anchor="iana_metric_type">
<name>IGP Metric-Type Registry</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 Link Delay as defined in <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 Metric as defined in <xref
target="RFC5305" sectionFormat="comma" section="3.7"/> and Traffic Engine
ering Metric as defined in <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 Definition Sub-TLV</name
>
<t>The "IS-IS Sub-Sub-TLVs for Flexible Algorithm Definition Sub-TLV" re
gistry is part
of the "IS-IS TLV Codepoints" registry group.</t>
<section anchor='ospf_fad' <dl spacing="compact" newline="false">
title='OSPF Sub-TLVs for Flexible Algorithm Definition Sub-TLV'> <dt>Type:</dt><dd>6</dd>
<t>OSPF Flexible Algorithm Definition TLV Sub-TLVs <dt>Description:</dt><dd>IS-IS Exclude Minimum Bandwidth</dd>
registry is part of the “Open Shortest Path First (OSPF) Parameters” <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 Maximum Delay</dd>
<dt>Reference:</dt><dd>RFC 9843, <xref target="sec_isis_delay_exclusion" forma
t="default"/></dd>
</dl>
<dl spacing="compact" newline="false">
<dt>Type:</dt><dd>8</dd>
<dt>Description:</dt><dd>IS-IS Reference Bandwidth</dd>
<dt>Reference:</dt><dd>RFC 9843, <xref target="sec_isis_auto_ref_bw" format="d
efault"/></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" form
at="default"/></dd>
</dl>
</section>
<section anchor="ospf_fad" numbered="true" toc="default">
<name>OSPF Sub-TLVs for Flexible Algorithm Definition Sub-TLV</name>
<t>The "OSPF Flexible Algorithm Definition TLV Sub-TLVs"
registry is part of the "Open Shortest Path First (OSPF) Parameters"
registry group.</t> registry group.</t>
<dl spacing="compact" newline="false">
<dt>Bit Number:</dt><dd>6</dd>
<dt>Description:</dt><dd>OSPF Exclude Minimum Bandwidth</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 Maximum Delay</dd>
<dt>Reference:</dt><dd>RFC 9843, <xref target="sec_ospf_delay_exclusion" forma
t="default"/></dd>
</dl>
<dl spacing="compact" newline="false">
<dt>Bit Number:</dt><dd>8</dd>
<dt>Description:</dt><dd>OSPF Reference Bandwidth</dd>
<dt>Reference:</dt><dd>RFC 9843, <xref target="sec_ospf_auto_ref_bw" format="d
efault"/></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" form
at="default"/></dd>
</dl>
</section>
<section anchor="isis_gen_metric" numbered="true" toc="default">
<name>IS-IS Sub-TLVs for TLVs Advertising Neighbor Information</name>
<t>The "IS-IS Sub-TLVs for TLVs Advertising Neighbor Information" regist
ry
is part of the "IS-IS TLV Codepoints" registry group.</t>
<t> Type:6 (TBD5)</t> <dl spacing="compact" newline="false">
<dt>Type:</dt><dd>17</dd>
<t> Description: OSPF Exclude Minimum Bandwidth Sub-TLV </t> <dt>Description:</dt><dd>Generic Metric</dd>
<dt>TLVs set to "Y":</dt><dd>22, 23, 25, 141, 222, and 223</dd>
<t>Reference: This document <xref target ='sec_ospf_bw_exclusion'/></t> <dt>Reference:</dt><dd>RFC 9843, <xref target="sec_isis_gen_metric" format="de
fault"/></dd>
<t> Type: 7(TBD6)</t> </dl>
<t> Description: OSPF Exclude Maximum Delay Sub-TLV </t>
<t>Reference: This document <xref target ='sec_ospf_delay_exclusion'/></t>
<t> Type: 8(TBD9)</t>
<t> Description: OSPF Reference Bandwidth 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_te_app" numbered="true" toc="default">
<name>Sub-Sub-TLV Codepoints for Application-Specific Link Attributes</n
ame>
<t>The "IS-IS Sub-Sub-TLV Codepoints for Application-Specific Link Attri
butes" registry
is part of the "IS-IS TLV Codepoints" registry group.</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="de
fault"/></dd>
</dl>
</section>
<section anchor="ospf_gen_metric" numbered="true" toc="default">
<name>OSPFv2 Extended Link TLV Sub-TLVs</name>
<t>The "OSPFv2 Extended Link TLV Sub-TLVs" registry
is part of the "Open Shortest Path First v2 (OSPFv2) Parameters" registry grou
p.</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="de
fault"/></dd>
</dl>
</section>
<section anchor="ospf_gen_metric_te_lsa" numbered="true" toc="default">
<name>Types for Sub-TLVs of TE Link TLV (Value 2)</name>
<t>The "Types for sub-TLVs of TE Link TLV (Value 2)" registry
is part of the "Open Shortest Path First (OSPF) Traffic Engineering TLVs" regi
stry group.</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="de
fault"/></dd>
</dl>
</section>
<section anchor="ospfv3_gen_metric_te_lsa" numbered="true" toc="default">
<name>OSPFv3 Extended-LSA Sub-TLVs</name>
<t> The "OSPFv3 Extended-LSA Sub-TLVs" registry
is part of the "Open Shortest Path First v3 (OSPFv3) Parameters" registry grou
p.</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="de
fault"/></dd>
</dl>
</section>
</section>
</section> </middle>
<section anchor='isis_gen_metric' <back>
title='IS-IS Sub-TLVs for TLVs Advertising Neighbor Information'>
<t>IS-IS Sub-TLVs for TLVs Advertising Neighbor Information registry
is part of the “IS-IS TLV Codepoints” registry group</t>
<t> Type:17 (TBD1)</t> <displayreference target="I-D.bashandy-rtgwg-segment-routing-uloop" to="SR-L
OOP-AVOID"/>
<displayreference target="I-D.ietf-lsr-isis-yang-augmentation-v1" to="ISIS-A
UGMENTATION"/>
<displayreference target="I-D.ietf-lsr-ospf-yang-augmentation-v1" to="OSPF-A
UGMENTATION"/>
<references>
<name>References</name>
<references>
<name>Normative References</name>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2
119.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
174.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5
305.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3
630.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7
684.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
479.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
492.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
362.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
350.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
356.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5
392.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5
329.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
668.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.1
195.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2
328.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.81
26.xml"/>
<t> Description: Generic metric </t> <reference anchor="IEEE754-2019" target="">
<front>
<title>IEEE Standard for 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.8
570.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7
471.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5
311.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
346.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5
120.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5
715.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4
655.xml"/>
<t>Reference: This document <xref target ='sec_isis_gen_metric'/></t> <!-- [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"/>
<t> TLV 22,23,25, 141, 222 and 223 set to Y</t> <!-- [I-D.ietf-lsr-isis-yang-augmentation-v1]
</section> draft-ietf-lsr-isis-yang-augmentation-v1-09
<section anchor='isis_gen_metric_te_app' IESG State: I-D Exists as of 07/29/25.
title='Sub-sub-TLV Codepoints for Application-Specific Link Attributes'> -->
<t>IS-IS Sub-sub-TLV Codepoints for Application-Specific Link Attributes regis <xi:include href="https://bib.ietf.org/public/rfc/bibxml3/reference.I-D.
try ietf-lsr-isis-yang-augmentation-v1.xml"/>
is part of the “IS-IS TLV Codepoints” registry group</t>
<t> Type: 17 (TBD1)</t>
<t> Description: Generic metric </t> <!-- [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>
<t>Reference: This document <xref target ='sec_isis_gen_metric'/></t> <section anchor="rules" numbered="true" toc="default">
<name>Updated List of Rules for Pruning Links in Flex-Algorithm Topology<
/name>
</section> <t>This section lists the entire set of rules to prune links from
Flex-Algorithm topology during Flexible Algorithm calculation. It
includes the original rules defined in <xref target="RFC9350"
sectionFormat="of" section="13"/> as well as the new additions (rules 6
and 7) described in
this document.</t>
<section anchor='ospf_gen_metric' title='OSPFv2 Extended Link TLV Sub-TLVs'> <t>For all links in the topology:</t>
<t> OSPFv2 Extended Link TLV Sub-TLVs registry <ol type="1" spacing="normal">
is part of the “Open Shortest Path First v2 (OSPFv2) Parameters” registry grou <li>Check if any exclude Administrative Group rule is part of the
p</t> Flex-Algorithm Definition. If such exclude rule exists, check if
<t> Type: 25(TBD21)</t> any color that is part of the exclude rule is also set on the link.
If such a color is set, the link <bcp14>MUST</bcp14> be pruned from
the computation.</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 is also part of the SRLG exclude rule. If the link
is part of such SRLG, the link <bcp14>MUST</bcp14> be pruned from
the computation.</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 link <bcp14>MUST</bcp14>
be pruned from the computation.</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
link <bcp14>MUST</bcp14> be pruned from the computation.</li>
<li>If the Flex-Algorithm Definition uses something other than the
IGP metric (<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 link
<bcp14>MUST</bcp14> be pruned from the computation. A metric of
value 0 <bcp14>MUST NOT</bcp14> be assumed in such a case.</li>
<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>
</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>
<t> Description: Generic metric </t> <contact fullname="Salih K.A.">
<organization>Juniper Networks</organization>
<address>
<email>salih@juniper.net</email>
</address>
</contact>
</section>
<t>Reference: This document <xref target ='sec_ospf_gen_metric'/></t> <!-- [rfced] Please review whether any of the notes in this document
should be in the <aside> element. It is defined as "a container for
content that is semantically less important or tangential to the
content that surrounds it" (https://authors.ietf.org/en/rfcxml-vocabulary#aside)
.
-->
<t> L2BM set to Y</t> <!-- [rfced] Terminology
</section>
<section anchor='ospf_gen_metric_te_lsa' a) Throughout the text, the following terminology appears to be used
title='Types for Sub-TLVs of TE Link TLV (Value 2)'> inconsistently. Please review these occurrences and let us know if/how
<t> Types for Sub-TLVs of TE Link TLV (Value 2) registry they may be made consistent.
is part of the “Open Shortest Path First (OSPF) Traffic Engineering TLVs” regi
stry group</t>
<t> Type: 36 (TBD22)</t>
<t> Description: Generic metric </t> Bandwidth metric type vs. bandwidth metric calculation
(Should "bandwidth metric calculation" be "Bandwidth metric calculation"
to match "Bandwidth metric type"?)
<t> Reference: This document <xref target ='sec_ospf_gen_metric'/></t> metric-type vs. metric type
</section> Minimum Bandwidth value vs. Minimum bandwidth advertised
(Are these terms different or should "bandwidth" be uppercase
for consistency?)
<section anchor='ospfv3_gen_metric_te_lsa' title='OSPFv3 Extended-LSA Sub-TLVs' Maximum Delay constraint vs. Maximum delay advertised
> (Are these terms different or should "delay" be uppercase
<t> OSPFv3 Extended-LSA Sub-TLVs for consistency?
is part of the “Open Shortest Path First v3 (OSPFv3) Parameters” registry grou
p</t>
<t> Type: 34 (TBD23)</t>
<t> Description: Generic metric </t> 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"?
<t> Reference: This document <xref target ='sec_ospf_gen_metric'/></t> b) We updated the document to reflect the forms on the right for consistency.
Please let us know of any objections.
<t> L2BM set to Y</t> 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)
</section> Flexible Algorithm Definition Bandwidth Thresholds ->
Flexible Algorithm Definition Bandwidth Threshold (singular)
</section> Generic metric -> Generic Metric (for consistency and per IANA)
<section title='Acknowledgements' anchor='ack'> IGP metric -> IGP Metric (per RFC 9350 and IANA)
<t>Many thanks to Chris Bowers, Krzysztof Szarcowitz, Julian Lucek, ISIS -> IS-IS
Ram Santhanakrishnan, Ketan Talaulikar and Acee Lindem interface group mode -> Interface Group Mode
for discussions and inputs.</t> L-Flag -> L-flag (per RFC 9350)
</section> layer-2 -> Layer 2
<section title='Contributors'> layer-3 -> Layer 3
Max link delay -> Max Link Delay
<t>1. Salih K A</t> Min Unidirectional link delay and Minimum Unidirectional Link Delay ->
<t>Juniper Networks</t> Min Unidirectional Link Delay (per RFC 9350)
<t>salih@juniper.net</t>
</section> Minimum link bandwidth -> Minimum Link Bandwidth
nexthops -> next hops
Reference Bandwidth Field -> Reference Bandwidth field
<section title='APPENDIX' anchor='app'> c) Should "simple mode" be made uppercase to match "Interface Group Mode"
<section title='Updated list of rules for pruning links in Flex-algorithm topo since they are both listed as automatic metric calculation modes?
logy ' anchor='rules'> -->
<t>This section lists the entire set of rules to prune links from
Flex-Algorithm topology during Flexible-algorithm calculation.
It includes the original rules defined in Section 13 of <xref target ='RFC9350
'/>
as well as new additions proposed in this document.
<list>
<t>For all links in the topology:</t>
<t>1. Check if any exclude Administrative Group rule is part of the Flex-
Algorithm Definition.
If such exclude rule exists, check if any color that is part of the exclu
de rule is also set on the link.
If such a color is set, the link MUST be pruned from the computat
ion.</t>
<t>2. Check if any exclude SRLG rule is part of the Flex-Algorithm Definitio
n.
If such exclude rule exists, check if the link is part of any SRLG that i
s a
lso part of the SRLG exclude rule. If the link is part of such SRLG,
the link MUST be pruned from the computation.</t>
<t>3. Check if any include-any Administrative Group rule is part
of the Flex-Algorithm Definition. If such include-any rule exists,
check if any color that is part of the include-any rule is also set on th
e link.
If no such color is set, the link MUST be pruned from the computation.</t
>
<t>4. Check if any include-all Administrative Group rule is part of the
Flex-Algorithm Definition. If such include-all rule exists, check if all
colors that are part of the include-all rule are also set on the link.
If all such colors are not set on the link, the link MUST be pruned from
the
computation.</t>
<t>5. If the Flex-Algorithm Definition uses something other than the
IGP metric (Section 5 of <xref target ='RFC9350'/>),
and such metric is not advertised for the particular
link in a topology for which the computation is done, such link MUST be p
runed
from the computation. A metric of value 0 MUST NOT be assumed in such a c
ase.</t>
<t>6. Check if any exclude FAEMB rule is part of the Flex-Algorithm
definition. If such exclude rule exists and the link has Maximum Link
Bandwidth advertised, check if the link bandwidth satisfies the
FAEMB rule. If the link does not satisfy the FAEMB rule,
the link MUST be pruned from the Flex-Algorithm computation.</t>
<t>7. Check if any exclude FAEMD rule is part of the Flex-Algorithm
definition. If such exclude rule exists and the link has
Min Unidirectional link delay advertised, check if the link delay
satisfies the FAEMD rule. If the link does not satisfy the FAEMD rule,
the link MUST be pruned from the Flex-Algorithm computation.</t>
</list> <!-- [rfced] Abbreviations
</t>
</section>
</section>
</middle>
<back> a) FYI - We have added expansions for the following abbreviations
<references title='Normative References'> per Section 3.6 of RFC 7322 ("RFC Style Guide"). Please review each
expansion in the document carefully to ensure correctness.
&RFC2119; Area Border Router (ABR)
&RFC8174; Link Aggregation Group (LAG)
&RFC5305; Link State Advertisement (LSA)
&RFC3630; Link State Protocol Data Unit (LSPDU)
&RFC7684;
&RFC9479;
&RFC9492;
&RFC8362;
&RFC9350;
&RFC9356;
&RFC5392;
&RFC5329;
&RFC8668;
&RFC1195;
&RFC2328;
<reference anchor="IEEE754"> b) We made the following change to follow use in RFC 9350. Please let us
<front> know of any objections.
<title>IEEE Standard for Floating-Point Arithmetic</title>
<author>
<organization>Institute of Electrical and Electronics Engineers</organ
ization>
</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> Flex-Algorithm Definition (FAD) -> Flexible Algorithm Definition (FAD)
-->
<references title='Informative References'> <!-- [rfced] Please review the "Inclusive Language" portion of the online
&RFC8570; Style Guide <https://www.rfc-editor.org/styleguide/part2/#inclusive_language>
&RFC7471; and let us know if any changes are needed. Updates of this nature typically
&RFC5311; result in more precise language, which is helpful for readers.
&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"?> Note that our script did not flag any words in particular, but this should
still be reviewed as a best practice.
-->
</references> </back>
</back>
</rfc> </rfc>
 End of changes. 252 change blocks. 
1426 lines changed or deleted 1733 lines changed or added

This html diff was produced by rfcdiff 1.48.