<?xml version="1.0"?> 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"> nbsp    "&#160;">
  <!ENTITY RFC5305 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5305.xml"> zwsp   "&#8203;">
  <!ENTITY RFC7684 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.7684.xml"> nbhy   "&#8209;">
  <!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"> wj     "&#8288;">
]>
<?rfc toc="yes"?>
<?rfc tocompact="yes"?>
<?rfc tocdepth="3"?>
<?rfc tocindent="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>

<rfc xmlns:xi="http://www.w3.org/2001/XInclude" category="std" docName="draft-ietf-lsr-flex-algo-bw-con-22" ipr="trust200902"> number="9843" consensus="true" ipr="trust200902" obsoletes="" updates="" submissionType="IETF" xml:lang="en" tocInclude="true" tocDepth="3" symRefs="true" sortRefs="true" version="3">

  <front>
    <title abbrev="IGP Flex-Algorithm: Flex-Algorithms: Bandwidth, Delay, Metric">
  IGP and Metrics">IGP Flexible
    Algorithms: Bandwidth, Delay, Metrics Metrics, and Constraints</title>
    <seriesInfo name="RFC" value="9843"/>
    <author initials="S." surname="Hegde" fullname="Shraddha Hegde">
      <organization>Juniper Networks Inc.</organization>
      <address>
        <postal>
          <street>Exora Business Park</street>
          <city>Bangalore</city>
        <region>KA</region>
          <region>Karnataka</region>
          <code>560103</code>
          <country>India</country>
        </postal>
        <email>shraddha@juniper.net</email>
      </address>
    </author>

<!--[rfced] We removed "A J" from William Britto's name to match use
in RFC 9502. If that is not desired, please let us know.
-->
    <author initials="W." surname="Britto" fullname="William Britto A J"> Britto">
      <organization>Juniper Networks Inc.</organization>
      <address>
      <postal>
        <street></street>
        <city></city>
        <region></region>
        <code></code>
        <country></country>
      </postal>
        <email>bwilliam@juniper.net</email>
      </address>
    </author>
    <author initials="R." surname="Shetty" fullname="Rajesh Shetty">
      <organization>Juniper Networks Inc.</organization>
      <address>
      <postal>
        <street></street>
        <city></city>
        <region></region>
        <code></code>
        <country></country>
      </postal>
        <email>mrajesh@juniper.net</email>
      </address>
    </author>
    <author initials="B." surname="Decraene" fullname="Bruno Decraene">
      <organization>Orange</organization>
      <address>
      <postal>
        <street></street>
        <city></city>
        <region></region>
        <code></code>
        <country></country>
      </postal>
        <email>bruno.decraene@orange.com</email>
      </address>
    </author>
    <author initials="P." surname="Psenak" fullname="Peter Psenak">
      <organization>Cisco Systems</organization>
      <address>
      <postal>
        <street></street>
        <city></city>
        <region></region>
        <code></code>
        <country></country>
      </postal>
        <email>ppsenak@cisco.com</email>
      </address>
    </author>
    <author initials="T." surname="Li" fullname="Tony Li">
      <organization>Juniper Networks Inc.</organization>
      <address>
      <postal>
        <street></street>
        <city></city>
        <region></region>
        <code></code>
        <country></country>
      </postal>
        <email>tony.li@tony.li</email>
      </address>
    </author>
    <date year="2025"/>
  <area>Routing</area>
  <workgroup>LSR</workgroup> year="2025" month="August"/>

    <area>RTG</area>
    <workgroup>lsr</workgroup>

    <keyword>AS</keyword>
    <keyword>IGP</keyword>

    <abstract>
      <t>
    Many networks configure the IGP link metric relative to the link capacity.
    High capacity, and high
    bandwidth traffic gets routed as per the link capacity. Flexible
    algorithms <xref target ='RFC9350'/>provide
    Algorithms provide mechanisms to create constraint based constraint-based paths in an IGP.
    This draft specification documents a generic metric type and a
    set of bandwidth related bandwidth-related constraints to be used in Flexible Algorithms.
</t>
    </abstract>

  <note title="Requirements Language">
    <t>   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
   "OPTIONAL" in this document are to be interpreted as described in BCP
   14, <xref target ='RFC2119'/>, <xref target ='RFC8174'/>  when, and only when,
   they appear in all capitals, as shown here.
	</t>
  </note>

  </front>
  <middle>
    <section title="Introduction" anchor='sec_introduction'> anchor="sec_introduction" numbered="true" toc="default">
      <name>Introduction</name>
      <t>  High bandwidth traffic such as residential Internet traffic and
   machine-to-machine elephant flows benefit from using high capacity
   links.  Accordingly, many network operators define a link's metric
   relative to its capacity to help direct traffic to higher bandwidth
   links, but this is no guarantee that lower bandwidth links will be
   avoided, especially in failure scenarios.  To ensure that elephant
   flows are only placed on high capacity links, it would be useful to
   explicitly exclude the high throughput traffic from utilizing links
   below a certain capacity. Flex-Algorithm <xref target ='RFC9350'/> target="RFC9350" format="default"/>
   provides a mechanism to create constrained paths by defining
   a set of parameters consisting of
   calculation-type, metric-type, and a set of constraints.  In
   this document, we define further extensions to Flex-Algorithm the Flexible Algorithm Definition (FAD) that
   will allow operators additional control over their traffic flows,
   especially with respect to bandwidth constraints. </t>
      <t>Historically, IGPs have done path computation by minimizing the
   sum of the link metrics along the path from source to
   destination. While the metric has been administratively defined,
   implementations have defaulted to a metric that is inversely
   proportional to link bandwidth. This has driven traffic to higher
   bandwidth links and has required manual metric manipulation to
   achieve the desired loading of the network.</t>
      <t>Over time, with the addition of different traffic types, the need
   for alternate types of metrics has evolved. Flex-Algorithm
   already supports using the minimum link delay and the
   administratively assigned traffic-engineering metrics in path
   computation. However, it is clear that additional metrics may be of
   interest in different situations. A network operator may seek to
   minimize their operational costs and thus may want a metric that
   reflects the actual fiscal costs of using a link.  Other traffic
   may require low jitter, leading to an entirely different set of
   metrics. With Flex-Algorithm, all of these different metrics, and
   more, could be used concurrently on the same network.</t>
      <t>In some circumstances, path computation constraints, such as
   administrative groups, can be used to ensure that traffic avoids
   particular portions of the network. These strict constraints are
   appropriate when there is an absolute requirement to avoid parts of
   the topology, even in failure conditions. If, however, However, if the
   requirement is less strict, then using a high metric in a portion
   of the topology may be more appropriate. </t>
      <t>This document defines a family of generic metrics that can advertise
      various types of administratively assigned metrics.

<!--[rfced] How may we clarify "and require to be standardized"? Please
let us know if option A or option B captures in the intended
meaning.

In addition, as this document is being published as a Standards-Track RFC, please consider whether "proposes" is accurate.  Perhaps "introduces" would work?

Original:
   This document proposes standard metric-types which have
   specific semantics and require to be standardized.

Perhaps A:
   This document proposes standard metric-types that have
   specific semantics and require standardization.

Perhaps B:
   This document proposes standard metric-types that have
   specific semantics and requirements for standardization.
-->

      This document proposes
   standard metric-types that have specific semantics and require
   to be standardized.
   This document also specifies user defined user-defined metric-types where specifics are
   not defined, defined so that administrators are free to assign semantics as
      they see fit.</t>
   <t>In <xref target ='sec_bw_metric'/>,

<!--[rfced] Should the section references be in order for ease of
reading as shown below?

Original:
   In Section 4, this document specifies a new bandwidth based metric
   type to be used with Flex-Algorithm and other applications.
    <xref target ='sec_fad_con'/>
   Section 3 defines additional Flexible Algorithm Definition (FAD)
   [RFC9350] constraints that allow the network administrator to
   preclude the use of low bandwidth links or high delay links.

   Section 4.1 defines...

Perhaps:
   Section 3 defines additional FAD [RFC9350] constraints that allow
   the network administrator to preclude the use of low bandwidth
   links or high delay links. In Section 4, this document specifies
   a new bandwidth-based metric type to be used with Flex-Algorithm
   and other applications.

   Section 4.1 defines...
-->
      <t>In <xref target ='RFC9350'/> target="sec_bw_metric" format="default"/>, this document specifies a
   new bandwidth-based metric
   type to be used with Flex-Algorithm and other applications.
    <xref target="sec_fad_con" format="default"/> defines additional FAD <xref target="RFC9350" format="default"/>
   constraints that allow the network
   administrator to preclude the use of low bandwidth links or high
   delay links.</t>
      <t> <xref target ='sec_auto_metric'/> target="sec_auto_metric" format="default"/>
   defines mechanisms to automatically calculate link metrics based on
   the parameters defined in the FAD and the advertised Maximum Link Bandwidth
   of each link. This is advantageous because administrators can change their
   criteria for metric assignment centrally, without individual
   modification of each link metric throughout the network. The procedures
   described in this document are intended to assign a metric to a link based on
   the total link capacity capacity, and they are not intended to update the metric based
   on actual traffic flow. Thus, the procedures described in this document are not a
   replacement to the capability of a PCE  <xref target ='RFC4655'/> target="RFC4655" format="default"/>, which has a dynamic view of
   the network and provides real-time bandwidth management or a distributed bandwidth
      management protocol.</t>

 <section anchor="req_lang" numbered="true" toc="default">
   <name>Requirements Language</name>
        <t>
    The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
    NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
    "<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to be interpreted as
    described in BCP&nbsp;14 <xref target="RFC2119"/> <xref target="RFC8174"/>
    when, and only when, they appear in all capitals, as shown here.
        </t>
 </section>
</section>

    <section title="Generic anchor="sec_generic_metric" numbered="true" toc="default">
      <name>Generic Metric Advertisement"
         anchor='sec_generic_metric'> Advertisement</name>
      <t> IS-IS <xref target ='RFC1195'/>and target="RFC1195" format="default"/> and OSPF <xref target ='RFC2328'/> target="RFC2328" format="default"/> advertise
a metric for each link in their respective
 link state advertisements. Multiple metric types are  already supported.
 Administratively assigned metrics are described in the original OSPF
 and IS-IS specifications.

<!--[rfced] Should "Min Unidirectional delay metric" be
"Unidirectional Link Delay" or "Min/Max Unidirectional
Link Delay" per RFCs 8570 and 7471?

Original:
   The Traffic Engineering Default Metric is defined in [RFC5305]
   and [RFC3630] and the Min Unidirectional delay metric is
   defined in [RFC8570] and [RFC7471].

Perhaps:
   The Traffic Engineering Default Metric is defined in [RFC5305]
   and [RFC3630], and the Min/Max Unidirectional Link Delay is
   defined in [RFC8570] and [RFC7471].
-->

 The Traffic Engineering Default Metric
is defined in <xref target ='RFC5305'/> target="RFC5305" format="default"/> and <xref target ='RFC3630'/> target="RFC3630" format="default"/>,
and the Min Unidirectional delay metric is defined in
<xref target ='RFC8570'/> target="RFC8570" format="default"/> and <xref target ='RFC7471'/>. target="RFC7471" format="default"/>.
Other metrics, such as jitter, reliability, and fiscal cost may be
   helpful, depending on the traffic class. Rather than attempt to
   enumerate all possible metrics of interest, this document specifies
   a generic mechanism for advertising metrics. </t>

      <t>
Each generic metric advertisement is on a per-link and per-metric
   type per-metric-type
   basis.  The metric advertisement consists of a metric type
   field and a value for the metric.  The metric type field is has been
   assigned by in the "IGP Metric-Type" IANA registry.  Metric types
   0-127 are standard metric types as assigned by IANA.  This document
   further specifies a user-defined metric type space of metric types
   128-255.  These are user defined and can be assigned by an operator
   for local use.
      </t>
<t>Implementations

<!--[rfced] We find "TLV 22/extended link LSA/TE-LSAs" hard to
read. How may we reword this for clarity and to also include the
expansion of "LSA"?

Also, should "generic metric sub-TLV" be singular and uppercase
for consistency as shown below?

Original:
   Implementations MUST support sending and receiving generic metric
   sub-TLV in Application Specific Link Attributes (ASLA)encodings as
   well as in the TLV 22/extended link LSA/TE-LSAs.

Perhaps:
   Implementations MUST support sending and receiving a Generic Metric
   sub-TLV in Application-Specific Link Attributes (ASLA) encodings as
   well as in TLV 22 and extended Link State Advertisements (LSAs)
   and TE-LSAs.
-->

      <t>Implementations <bcp14>MUST</bcp14> support sending and receiving generic metric
 sub-TLV in Application-Specific Link Attributes (ASLA) encodings as
 well as in the TLV 22/extended link LSA/TE-LSAs.
 The usage of a generic metric by an individual application is subject to the same
 rules that apply to other link attributes as defined in <xref target ='RFC3630'/>, target="RFC3630" format="default"/>,
 <xref target ='RFC5305'/>, target="RFC5305" format="default"/>, <xref target ='RFC9479'/>, target="RFC9479" format="default"/>,
 <xref target ='RFC9492'/> target="RFC9492" format="default"/>, and <xref target ='RFC9350'/>.</t> target="RFC9350" format="default"/>.</t>
      <section title="IS-IS anchor="sec_isis_gen_metric" numbered="true" toc="default">
        <name>IS-IS Generic Metric Sub-TLV"
         anchor='sec_isis_gen_metric'> Sub-TLV</name>
        <t>The IS-IS Generic Metric sub-TLV specifies the link metric for a given
   metric type.  Typically, this metric is assigned by a
   network administrator.
   The Generic Metric sub-TLV is advertised in the TLVs/sub-TLVs below:</t>

   <t><list>
      <t>a. TLV-22
        <ol spacing="normal" type="a">
          <li>TLV 22 (Extended IS reachability) <xref target ='RFC5305'/></t>

      <t>b. TLV-222 target="RFC5305"
          format="default"/></li>
          <li>TLV 222 (MT-ISN) <xref target ='RFC5120'/></t>

      <t>c. TLV-23 target="RFC5120" format="default"/></li>
          <li>TLV 23 (IS Neighbor Attribute) <xref target ='RFC5311'/></t>

      <t>d. TLV-223 target="RFC5311"
          format="default"/></li>
          <li>TLV 223 (MT IS Neighbor Attribute) <xref target ='RFC5311'/> </t>

      <t>e. TLV-141 (inter-AS reachability information) <xref target ='RFC9346'/></t>

      <t>f. target="RFC5311"
          format="default"/></li>
          <li>TLV 141 (Inter-AS Reachability Information) <xref
          target="RFC9346" format="default"/></li>

<!--[rfced] When referring to "TLV 22/222/23/223/141" (or "TLV 22/23/141/222/223"
if updated), should "TLV" be plural (e.g., "TLVs 22/222/23/223/141")?
We note that the plural form is used in the "Sub-TLVs for TLVs 22, 23, 141,
222, and 223" registry.

Original:
   f.  sub-TLV 16 (Application-Specific Link Attributes (ASLA)) of TLV
       22/222/23/223/141 <xref target ='RFC9479'/></t>

	  <t>g. [RFC9479]

   g.  TLV 25 (L2 Bundle Member Attributes) [RFC8668] Marked as "y(s)"
       (shareable among bundle members)

...
One example in the running text (see the document for more instances).

Original:
   For a particular metric type, the Generic Metric sub-TLV MUST be advertised
   only once for a link when advertised in TLV 22, 222, 23, 223 and 141.
-->

          <li>sub-TLV 16 (Application-Specific Link Attributes (ASLA)) of TLV
          22/222/23/223/141 <xref target="RFC9479" format="default"/></li>
          <li>TLV 25 (L2 Bundle Member Attributes) <xref target ='RFC8668'/> target="RFC8668"
          format="default"/>. Marked as "y(s)" (shareable among bundle members)</t>

    </list></t>
          members).</li>
        </ol>
        <t>The Generic Metric sub-TLV, type TBD1 (IANA), and 17, is six 6 octets in length.
        </t>
        <figure anchor="isis_gen_metric_sub_tlv"
           title="IS-IS anchor="isis_gen_metric_sub_tlv">
          <name>IS-IS Generic Metric Sub-TLV">
      <artwork> Sub-TLV</name>
          <artwork name="" type="" align="left" alt=""><![CDATA[
    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Type        |     Length    |  metric-type  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         Value                 |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      Type
]]></artwork>
	</figure>
	<t>
where:
	</t>

<dl spacing="normal" newline="true">
  <dt>Type (1 octet):
      An octet):</dt>
  <dd>An 8-bit field assigned by IANA (To Be Determined as TBD1). (17).  This value
  uniquely identifies the Generic Metric TLV.

      Length TLV.</dd>
  <dt>Length (1 octet):
      An 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.

      Metric-Type 4.</dd>
  <dt>Metric-Type (1 octet):
      An 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 which that is indicated as allowed in the generic metric Generic Metric sub-TLV by the
	  IGP Metric-Type Registry.

      Value
  "IGP Metric-Type" registry.</dd>
  <dt>Value (3 octets):
      A octets):</dt>
  <dd>A 24-bit unsigned integer representing the metric value.  The valid
  range is from 0 to 16,777,215 (0xFFFFFF).

    </artwork>
    </figure>
	</t> (0xFFFFFF).</dd>
</dl>
        <t>
    The Generic Metric sub-TLV MAY <bcp14>MAY</bcp14> be advertised multiple times.
    For a particular metric type,
    the Generic Metric sub-TLV MUST <bcp14>MUST</bcp14> be advertised only once for a link
    when advertised in TLV 22, 222, 23, 223 223, and 141.
    When the Generic metric Metric sub-TLV is advertised in ASLA,
    each metric type MUST <bcp14>MUST</bcp14> be advertised only once per-application for a link.
    If there are multiple Generic Metric sub-TLVs advertised for a link
    for the same metric type  (and the same application in case of ASLA)
    in one or more received LSPDUs, Link State Protocol Data Units (LSPDUs), advertisement in the lowest numbered lowest-numbered fragment
    MUST
    <bcp14>MUST</bcp14> be used used, and the subsequent instances MUST <bcp14>MUST</bcp14> be ignored.
        </t>
        <t>For a link, if the metric type corresponds to a metric type for
	which legacy advertisement mechanisms exist (e.g., the IGP metric, Metric,
	the Minimum Min Unidirectional Link Delay, or the
    Traffic Engineering Default Metric), the legacy metric types MUST <bcp14>MUST</bcp14>
	be utilized from the existing TLV or sub-TLVs. If a Generic Metric
	advertises a legacy metric, it MUST <bcp14>MUST</bcp14> be ignored.
.
        </t>
        <t>A metric value of
   0xFFFFFF is considered as a maximum link metric metric, and a link having
   this metric value MUST <bcp14>MUST</bcp14> be used during Flex-algorithm Flex-Algorithm calculations
   as a last resort link as described in sec 15.3 of <xref target ='RFC9350'/>. section="15.3" target="RFC9350" format="default"/>.
   A link can be made unusable by Flex-algorithm Flex-Algorithm by leaving out Generic metric Metric
   advertisement of the particular metric-type that the Flex-algorithm
   uses Flex-Algorithm
   uses, as described in <xref target ='RFC9350'/>. target="RFC9350" format="default"/>.
        </t>
        <t> During the router maintenance activity, the Generic Metric for
   all the links on the node MAY <bcp14>MAY</bcp14> be set to a maximum value of
   16,777,215 (0xFFFFFF), as it is the maximum usable link metric for the
   Flex-algorithm
   Flex-Algorithm calculations.</t>
      </section>
      <section title="OSPF anchor="sec_ospf_gen_metric" numbered="true" toc="default">
        <name>OSPF Generic Metric Sub-TLV"
         anchor='sec_ospf_gen_metric'> Sub-TLV</name>
        <t>
   The OSPF Generic Metric sub-TLV specifies the link metric for a given
   metric type. Typically, this metric is assigned by a
   network administrator.
   The Generic Metric sub-TLV is advertised in the TLVs below:</t>

   <t><list>
   <t>a.
   <ol type="a" spacing="normal">

<!--[rfced] Would it be correct to update "2" to "type 2" as shown
below for clarity?

Original:
   a.  sub-TLV of TE Link TLV (2) of OSPF TE LSA <xref target ='RFC3630'/>.</t>
   <t>b. [RFC3630].

   b.  sub-TLV of TE Link TLV (2) of OSPFv2 Inter-AS-TE-v2 LSA <xref target ='RFC5392'/>.</t>
   <t>c.
       [RFC5392].

   c.  sub-TLV of TE Link TLV (2) of OSPFv3 Intra-Area-TE-LSA <xref target ='RFC5329'/>.</t>
   <t>d. [RFC5329].

   d.  sub-TLV of TE Link TLV (2) of OSPFv3 Inter-AS-TE-v3 LSA <xref target ='RFC5392'/>.</t>
   <t>e.
       [RFC5392].

Perhaps:
   a.  sub-TLV of TE Link TLV (type 2) of OSPF TE LSA [RFC3630].

   b.  sub-TLV of TE Link TLV (type 2) of OSPFv2 Inter-AS-TE-v2 LSA
       [RFC5392].

   c.  sub-TLV of TE Link TLV (type 2) of OSPFv3 Intra-Area-TE-LSA [RFC5329].

   d.  sub-TLV of TE Link TLV (type 2) of OSPFv3 Inter-AS-TE-v3 LSA
       [RFC5392].
-->

          <li>sub-TLV of TE Link TLV (2) of OSPF TE LSA <xref target="RFC3630" format="default"/>.</li>
          <li>sub-TLV of TE Link TLV (2) of OSPFv2 Inter-AS-TE-v2 LSA <xref target="RFC5392" format="default"/>.</li>
          <li>sub-TLV of TE Link TLV (2) of OSPFv3 Intra-Area-TE-LSA <xref target="RFC5329" format="default"/>.</li>
          <li>sub-TLV of TE Link TLV (2) of OSPFv3 Inter-AS-TE-v3 LSA <xref target="RFC5392" format="default"/>.</li>
          <li>sub-TLV of Application-Specific Link Attributes (ASLA) sub-TLV <xref target ='RFC9492'/> target="RFC9492" format="default"/>
            of the OSPFv2 Extended Link TLV <xref target ='RFC7684'/>.</t>
   <t>f.	sub-TLV target="RFC7684" format="default"/>.</li>
          <li>sub-TLV of Application-Specific Link Attributes (ASLA) sub-TLV <xref target ='RFC9492'/> target="RFC9492" format="default"/>
            of the OSPFv3 Router-Link TLV <xref target ='RFC8362'/>.</t>
   <t>g.    sub-TLV target="RFC8362" format="default"/>.</li>
          <li>sub-TLV of the OSPFv2 L2 Bundle Member Attributes sub-TLV <xref target ='RFC9356'/>.</t>
   <t>h.    sub-TLV target="RFC9356" format="default"/>.</li>
          <li>sub-TLV of the OSPFv3 L2 Bundle Member Attributes sub-TLV <xref target ='RFC9356'/>.</t>

</list></t> target="RFC9356" format="default"/>.</li>
        </ol>

        <t>The Generic Metric sub-TLV, type TBD21/TBD22/TB23 (IANA), and types 25/36/34, is eight
   octets in length.

</t>
        <figure anchor="ospf_gen_metric_sub_tlv"
        title="OSPF anchor="ospf_gen_metric_sub_tlv">
          <name>OSPF Generic Metric Sub-TLV ">
      <artwork> Sub-TLV</name>
          <artwork name="" type="" align="left" alt=""><![CDATA[
       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |              Type             |             Length            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | metric-type   |         Reserved (MBZ)                        |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                            Value                              |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      Type
     ]]></artwork>
	</figure>

<t>
  where:
</t>
<dl spacing="normal" newline="true">
  <dt>Type (2 octets):
      A octets):</dt>
  <dd>A 16-bit field assigned by IANA (To Be Determined as TBD21/TBD22/TBD23). (25/36/34).
  This value uniquely identifies the Generic Metric TLV.

      Length TLV.</dd>
  <dt>Length (2 octets):
      A octets):</dt>
  <dd>A 16-bit field indicating the total length, in octets, of the subsequent
  fields. For this TLV, the Length is set to 8.

      Metric-Type 8.</dd>
  <dt>Metric-Type (1 octet):
      An 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 which that is indicated as allowed in the generic metric Generic Metric sub-TLV by the
	  IGP Metric-Type Registry.

	  Reserved
  "IGP Metric-Type" registry.</dd>
  <dt>Reserved (3 octets):
	  Must octets):</dt>
  <dd>Must set to zero by the sender and must be ignored by receiver.

      Value the receiver.</dd>
  <dt>Value (4 octets):
      A octets):</dt>
  <dd>A 32-bit unsigned integer representing the metric value.
  The valid
  range is from 0 to 4,294,967,295(0xFFFFFFFF).

    </artwork>
    </figure> 4,294,967,295 (0xFFFFFFFF).</dd>
</dl>

<t>The Generic Metric sub-TLV MAY <bcp14>MAY</bcp14> be advertised multiple times.
For a particular metric type, the Generic Metric sub-TLV MUST <bcp14>MUST</bcp14>
be advertised only once for a link when advertised as (a) through (d) above.
When the Generic Metric sub-TLV is advertised as a sub-TLV of ASLA, it MUST
<bcp14>MUST</bcp14> be advertised only once per-application per application for a link.  If
there are multiple Generic Metric sub-TLVs advertised for a link for the same
metric type (and the same application in case of ASLA) in one or more received
LSAs, advertisement in the lowest numbered lowest-numbered LSA MUST <bcp14>MUST</bcp14> be used used, and
the subsequent instances MUST <bcp14>MUST</bcp14> be ignored.</t>
        <t>For a link, if the metric type corresponds to a metric type for
	which legacy advertisement mechanisms exist (e.g., the IGP metric, Metric,
	the Minimum Min Unidirectional Link Delay, or the Traffic Engineering
	Default Metric), the legacy metric types MUST <bcp14>MUST</bcp14> be utilized from
	the existing TLV or sub-TLVs. If a Generic Metric advertises a
	legacy metric, it MUST <bcp14>MUST</bcp14> be ignored.
</t>
        <t>A metric value of
   0xFFFFFFFF is considered as a maximum link metric metric, and a link having
   this metric value MUST <bcp14>MUST</bcp14> be used during Flex-algorithm Flex-Algorithm calculations
   as a last resort link link, as described in sec 15.3 of <xref target ='RFC9350'/>.</t>
    </t> section="15.3" target="RFC9350" format="default"/>.</t>
        <t>A link can be made unusable by Flex-algorithm Flex-Algorithm by leaving out Generic metric Metric
   advertisement of the particular metric-type that the Flex-algorithm
   uses Flex-Algorithm
	uses, as described in <xref target ='RFC9350'/>.</t> target="RFC9350" format="default"/>.</t>

        <t> During the router maintenance activity, the Generic Metric for
   all the links on the node MAY <bcp14>MAY</bcp14> be set to a maximum value of
   4,294,967,295 ((0xFFFFFFFF), (0xFFFFFFFF), as it is the maximum usable link metric for the
   Flex-algorithm
   Flex-Algorithm calculations.</t>
      </section>
      <section
title="Generic anchor="sec_multi_area" numbered="true" toc="default">
        <name>Generic Metric applicability Applicability to Flexible Algorithms Multi-domain/Multi-area networks "
anchor='sec_multi_area'> Algorithm Multi-Domain/Multi-Area Networks</name>
        <t>Generic Metric can be used by Flex-Algorithms Flex-Algorithm
 by specifying the metric type in the
Flexible Algorithm Definitions. When Flex-Algorithms Flex-Algorithm is used in a multi-area network,
<xref target ='RFC9350'/> target="RFC9350" format="default"/> defines the Flexible Algorithm Prefix Metric (FAPM)
 sub-TLV that carries
the Flexible-Algorithm-specific metric. Metrics carried in FAPM will be equal
to the metric to reach the prefix for that Flex-Algorithm in its
source area or domain (source area from the ABR Area Border Router (ABR) perspective). When Flex-Algorithm uses
Generic metric, Metric, the same procedures as described in section 13 of
<xref target ='RFC9350'/> target="RFC9350" sectionFormat="of" section="13"/>
are used to send and process the FAPM sub-TLV.</t>
      </section>
    </section>
    <section title=" FAD constraint Sub-TLVs" anchor='sec_fad_con'> anchor="sec_fad_con" numbered="true" toc="default">
      <name>FAD Constraint Sub-TLVs</name>
      <t>

   Large high throughput flows are referred to as "elephant flows".
   Directing an elephant flow
   down a low-bandwidth link might congest the link and cause other
   critical application traffic flowing on the link to drop. Thus, in the
   context of Flex-Algorithm, it would be useful to be able to
   constrain the topology to only those links capable of supporting a
      minimum amount of bandwidth.</t>

<!--[rfced] Please clarify what "this" refers to in the following sentence.

Original:
   If the capacity of a link is constant, this can already be achieved
   through the use of administrative groups.
-->

      <t>If the capacity of a link is constant, this can already be achieved
   through the use of administrative groups. However, when a layer-3 Layer 3
   link is actually a collection of layer-2 Layer 2 links (LAG/layer-2 (Link Aggregation Group (LAG) / Layer 2
   Bundle), the link bandwidth will vary based on the set of active
   constituent links. This could be automated by having an
   implementation vary the advertised administrative groups based on
   bandwidth, but this seems unnecessarily complex and expressing this
   requirement as a direct constraint on the topology seems
   simpler. This is also advantageous if the minimum required
   bandwidth changes, as this constraint would provide a single
   centralized, coordinated point of control.</t>
      <t>To satisfy this requirement, this document defines an
   Exclude Minimum Bandwidth
   constraint.  When this constraint is advertised in a FAD,
   a link will be pruned from the Flex-Algorithm topology if the
   link's advertised Maximum Link Bandwidth is below the advertised
   Minimum Bandwidth value.</t>
      <t>Similarly, this document defines an Exclude Maximum Link Delay
   constraint. Applications, such as High-Frequency Trading are sensitive
   to link delays and may perform poorly in networks prone to delay
   variability, such as those with transparent Layer 2 link
   recovery mechanisms or satellite links.". links.
   Mechanisms already exist to measure the link delay dynamically and
   advertise it in the IGP.  Networks that employ dynamic link-delay
   measurement, may want to exclude links that have a delay over a
   given threshold.</t>
      <section title="IS-IS FAD constraint Sub-TLVs" anchor='sec_isis'>
<section title="IS-IS 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" anchor='sec_isis_bw_exclusion'> Sub-TLV</name>
          <t>

IS-IS Flex-Algorithm Exclude Minimum Bandwidth sub-TLV (FAEMB) sub-TLV  is a
sub-TLV of the IS-IS FAD sub-TLV. It has the following format:

</t>
          <figure anchor="isis_faemb_sub_tlv" title="IS-IS anchor="isis_faemb_sub_tlv">
            <name>IS-IS FAEMB Sub-TLV">
      <artwork> Sub-TLV</name>
            <artwork name="" type="" align="left" alt=""><![CDATA[
    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      Type     |    Length     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                     Min Bandwidth                             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   where:

      Type
]]></artwork>
	  </figure>

<t>where:</t>
<dl spacing="normal" newline="true">
  <dt>Type (1 octet):
      An octet):</dt>
  <dd>An 8-bit field assigned by IANA (To Be Determined as TBD3). (6).  This value
  uniquely identifies the FAEMB sub-TLV.

      Length sub-TLV.</dd>
  <dt>Length (1 octet):
      An 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.

      Min 4.</dd>
  <dt>Min Bandwidth (4 octets):
      A octets):</dt>
  <dd>A 32-bit field specifying the link bandwidth encoded in IEEE floating
  point format (32 bits)[IEEE754-2019]. bits) <xref target="IEEE754-2019"/>.  The units are bytes-per-second.

      </artwork>
    </figure>
    </t> bytes per second.</dd>
</dl>

          <t>The FAEMB sub-TLV MUST <bcp14>MUST</bcp14> appear once at most once in the FAD sub-TLV.
    If it appears more than once, the IS-IS FAD sub-TLV MUST <bcp14>MUST</bcp14> be
   ignored by the receiver. </t>
          <t>The Minimum bandwidth advertised in the FAEMB sub-TLV MUST <bcp14>MUST</bcp14> be compared with
   Maximum Link Bandwidth advertised in sub-sub-TLV 9 of the ASLA sub-TLV <xref target ='RFC9479'/>. target="RFC9479" format="default"/>.
   If L-Flag the L-flag is set in the ASLA sub-TLV, the Minimum bandwidth advertised in the FAEMB
   sub-TLV MUST <bcp14>MUST</bcp14> be compared with the Maximum Link Bandwidth as
   advertised in the sub-TLV 9 of the TLV
   22/222/23/223/141 <xref target ='RFC5305'/> target="RFC5305" format="default"/>, as defined in <xref target ='RFC9479'/>
   Section 4.2. target="RFC9479" sectionFormat="of" section="4.2"/>. </t>
          <t>If the Maximum Link Bandwidth is lower than the Minimum
   link bandwidth
   Link Bandwidth advertised in the FAEMB sub-TLV,
   the link MUST <bcp14>MUST</bcp14> be excluded from the Flex-Algorithm topology.

  If a link does not have the Maximum Link Bandwidth advertised but the
  FAD contains this sub-TLV, then that link
   MUST NOT
   <bcp14>MUST NOT</bcp14> be excluded from the topology based on the Minimum
   Bandwidth constraint.
          </t>
        </section>
        <section title="IS-IS anchor="sec_isis_delay_exclusion" numbered="true" toc="default">
          <name>IS-IS Exclude Maximum Delay Sub-TLV"
         anchor='sec_isis_delay_exclusion'> Sub-TLV</name>
          <t>

IS-IS Flex-Algorithm Exclude Maximum Delay sub-TLV (FAEMD) sub-TLV is a
sub-TLV of the IS-IS FAD sub-TLV. It has the following format. format:

</t>
          <figure anchor="isis_faemd_sub_tlv" title="IS-IS anchor="isis_faemd_sub_tlv">
            <name>IS-IS FAEMD Sub-TLV">
      <artwork> Sub-TLV</name>
            <artwork name="" type="" align="left" alt=""><![CDATA[
    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      Type     |    Length     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                     Max Link Delay          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   where:

      Type
]]></artwork>
	  </figure>
<t>where:</t>
<dl spacing="normal" newline="true">
  <dt>Type (1 octet):
      An octet):</dt>
  <dd>An 8-bit field assigned by IANA (To Be Determined as TBD4). (7).  This value
  uniquely identifies the FAEMD sub-TLV.

      Length sub-TLV.</dd>
  <dt>Length (1 octet):
      An 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 3.

      Max link delay 3.</dd>
  <dt>Max Link Delay (3 octets):
      A octets):</dt>
  <dd>A 24-bit field specifying the Maximum link delay in microseconds.

      </artwork>
    </figure>
    </t> microseconds.</dd>
</dl>

<t>The FAEMD sub-TLV MUST <bcp14>MUST</bcp14> appear only once in the FAD sub-TLV.
If it appears more than once, the IS-IS FAD sub-TLV MUST <bcp14>MUST</bcp14> be
ignored by the receiver.</t>
          <t>The Maximum link delay advertised in the FAEMD sub-TLV MUST <bcp14>MUST</bcp14> be compared with
   Min Unidirectional Link Delay advertised in sub-sub-TLV 34 of the ASLA sub-TLV <xref target ='RFC9479'/>. target="RFC9479" format="default"/>.
   If the L-Flag L-flag is set in the ASLA sub-TLV, the Maximum link delay advertised in the FAEMD
   sub-TLV MUST <bcp14>MUST</bcp14> be compared with Min Unidirectional Link Delay as
   advertised by the sub-TLV 34 of the TLV
   22/222/23/223/141 <xref target ='RFC8570'/> target="RFC8570" format="default"/>, as defined in <xref target ='RFC9479'/>
   Section 4.2. target="RFC9479" sectionFormat="of" section="4.2"/>. </t>
          <t>If the  Min Unidirectional Link Delay value is higher than the
   Maximum link delay advertised in the FAEMD sub-TLV, the link MUST <bcp14>MUST</bcp14> be
   excluded from the Flex-Algorithm topology.

If a link does not have the Min Unidirectional Link Delay advertised but
the FAD contains this sub-TLV, then that link MUST NOT <bcp14>MUST NOT</bcp14> be
   excluded from the topology based on the Maximum Delay constraint.
          </t>
        </section>
      </section>
      <section title="OSPF FAD constraint Sub-TLVs" anchor='sec_ospf'>

<section title="OSPF anchor="sec_ospf" numbered="true" toc="default">
        <name>OSPF FAD Constraint Sub-TLVs</name>
        <section anchor="sec_ospf_bw_exclusion" numbered="true" toc="default">
          <name>OSPF Exclude Minimum Bandwidth Sub-TLV"
         anchor='sec_ospf_bw_exclusion'> Sub-TLV</name>
          <t>

OSPF Flex-Algorithm Exclude Minimum Bandwidth sub-TLV (FAEMB) sub-TLV is a
sub-TLV of the OSPF FAD TLV. It has the following format:

</t>
          <figure anchor="ospf_faemb_sub_tlv" title="OSPF anchor="ospf_faemb_sub_tlv">
            <name>OSPF FAEMB Sub-TLV">
      <artwork> Sub-TLV</name>
            <artwork name="" type="" align="left" alt=""><![CDATA[
    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      Type                     |    Length                     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                     Min Bandwidth                             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   where:

      Type
]]></artwork>
	  </figure>
<t>where:</t>
<dl spacing="normal" newline="true">
  <dt>Type (2 octets):
      A octets):</dt>
  <dd>A 16-bit field assigned by IANA (To Be Determined as TBD5). (6).  This value
  uniquely identifies the OSPF FAEMB sub-TLV.

      Length sub-TLV.</dd>
  <dt>Length (2 octets):
      A 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.

      Min 4.</dd>
  <dt>Min Bandwidth (4 octets):
      A octets):</dt>
  <dd>A 32-bit field specifying the link bandwidth encoded in IEEE floating
  point format (32 bits)[IEEE754-2019]. bits)<xref target="IEEE754-2019"/>.  The units are bytes-per-second.

      </artwork>
    </figure>
	</t> bytes per second.</dd>
</dl>

          <t>The FAEMB sub-TLV MUST <bcp14>MUST</bcp14> only appear once in the FAD sub-TLV.
    If it appears more than once, the OSPF FAD TLV MUST <bcp14>MUST</bcp14> be
    ignored by the receiver.</t>
          <t>The Maximum Link Bandwidth as advertised in the Extended Link TLV
   in the Extended Link Opaque LSA in OSPFv2 <xref target ='RFC7684'/> target="RFC7684" format="default"/>
   or as a sub-TLV
   of the Router-Link TLV of the E-Router-LSA Router-Link TLV in
   OSPFv3 <xref target ='RFC8362'/> MUST target="RFC8362" format="default"/> <bcp14>MUST</bcp14> be  compared against
   the Minimum bandwidth advertised in the FAEMB sub-TLV.
   If the link bandwidth is lower than the Minimum bandwidth
   advertised in the FAEMB sub-TLV, the link MUST <bcp14>MUST</bcp14> be excluded
   from the Flex-Algorithm topology.
          </t>
          <t>If a link does not have the Maximum Link Bandwidth advertised
   but the FAD contains this sub-TLV, then that link MUST <bcp14>MUST</bcp14> be included in the
   topology and proceed to apply further pruning rules for the link.
          </t>
        </section>
        <section title="OSPF anchor="sec_ospf_delay_exclusion" numbered="true" toc="default">
          <name>OSPF Exclude Maximum Delay Sub-TLV"
         anchor='sec_ospf_delay_exclusion'> Sub-TLV</name>
          <t>

The OSPF Flex-Algorithm Exclude Maximum Delay sub-TLV (FAEMD) sub-TLV is a
sub-TLV of the OSPF FAD TLV. It has the following format.

</t>
          <figure anchor="ospf_faemd_sub_tlv" title="OSPF anchor="ospf_faemd_sub_tlv">
            <name>OSPF FAEMD Sub-TLV">
      <artwork> Sub-TLV</name>
            <artwork name="" type="" align="left" alt=""><![CDATA[
    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      Type                     |    Length                     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  RESERVED     |                     Max link Link Delay            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   where:

      Type
]]></artwork>
</figure>

<t>where:</t>
<dl spacing="normal" newline="true">
  <dt>Type (2 octets):
      A octets):</dt>
  <dd>A 16-bit field assigned by IANA (To Be Determined as TBD6). (7).  This value
  uniquely identifies the OSPF FAEMD sub-TLV.

      Length sub-TLV.</dd>
  <dt>Length (2 octets):
      A 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.

	  Reserved 4.</dd>
  <dt>Reserved (1 octet):
	  Must octet):</dt>
  <dd>Must be set to zero by the sender and must be ignored by receiver.

      Max link delay the receiver.</dd>
  <dt>Max Link Delay (3 octets):
      A octets):</dt>
  <dd>A 24-bit field specifying the Maximum link delay in microseconds.

      </artwork>
    </figure>
	</t> microseconds.</dd>
</dl>

          <t> The FAEMD sub-TLV MUST <bcp14>MUST</bcp14> only appear once in the OSPF FAD TLV.
    If it appears more than once, the OSPF FAD TLV MUST <bcp14>MUST</bcp14> be
   ignored by the receiver.
          </t>

          <t>The Min Delay value advertised via the Min/Max Unidirectional Link Delay
    of the ASLA sub-TLV <xref target ='RFC9492'/>, MUST target="RFC9492" format="default"/> <bcp14>MUST</bcp14> be compared against the Maximum delay
    advertised in the FAEMD sub-TLV. If the Min Unidirectional Link Delay is higher
    than the Maximum delay advertised in the FAEMD sub-TLV, the link MUST <bcp14>MUST</bcp14> be
    excluded from the Flex-Algorithm topology. If the
    Min/Max Unidirectional Link Delay is not advertised for a link but
	the FAD contains this sub-TLV,then sub-TLV, then that link MUST NOT <bcp14>MUST NOT</bcp14> be
   excluded from the topology based on the Maximum Delay constraint.
          </t>
        </section>
      </section>
    </section>
    <section title="Bandwidth anchor="sec_bw_metric" numbered="true" toc="default">
      <name>Bandwidth Metric Advertisement"
         anchor='sec_bw_metric'> Advertisement</name>
      <t>
   Historically, IGP implementations have made default metric
   assignments based on link bandwidth. This has proven to be useful, useful
   but has suffered from having different defaults across
   implementations and from the rapid growth of link bandwidths. With
   Flex-Algorithm, the network administrator can define a function
   that will produce a metric for each link and have each node
   automatically compute each link's metric based on its bandwidth.</t>
      <t>This document defines a standard metric type for this purpose
   called the "Bandwidth Metric".  The Bandwidth Metric MAY <bcp14>MAY</bcp14> be
   advertised in the Generic Metric sub-TLV with the metric type set
   to "Bandwidth Metric".  IS-IS and OSPF will advertise this type
   of metric in their link advertisements.

<!--[rfced] May we update this sentence for clarity as shown below?

Original:
   Bandwidth metric is a link attribute and for the advertisement and
   processing of this attribute for Flex-algorithm, MUST follow the
   section 12 of [RFC9350].

Perhaps:
   The Bandwidth Metric is a link attribute, and it MUST follow Section 12
   of [RFC9350] for its advertisement and processing during Flex-Algorithm
   calculation.
-->

   The Bandwidth Metric is a link
   attribute and for the advertisement and processing of this attribute for Flex-Algorithm, <bcp14>MUST</bcp14> follow <xref target ='RFC9350'/></t> target="RFC9350" sectionFormat="of" section="12"/>.</t>
      <t> Flex-Algorithm uses this
   metric type by specifying the bandwidth metric as the metric type
   in a FAD TLV. A FAD TLV may also specify an automatic computation
   of the bandwidth metric based on a link's advertised bandwidth. An
   explicit advertisement of a link's bandwidth metric using the
   Generic Metric sub-TLV overrides this automatic computation.
   The automatic bandwidth metric calculation sub-TLVs are advertised
   in the FAD TLV TLV, and these parameters are applicable to applications
   such as Flex-algorithm Flex-Algorithm that make use of the FAD TLV.
</t>
      <section title="Automatic anchor="sec_auto_metric" numbered="true" toc="default">
        <name>Automatic Metric Calculation" anchor='sec_auto_metric'> Calculation</name>
        <t> Networks which that are designed to be highly regular and that follow uniform
   metric assignment may want to simplify their operations by
   automatically calculating the bandwidth metric. When
   a FAD advertises the metric type as Bandwidth Metric and the link does
   not have the Bandwidth Metric advertised, automatic metric derivation
   can be used with additional FAD constraint advertisement as
   described in this section.  </t>
        <t> If a link's bandwidth changes, then the delay in learning about the
   change may create the possibility of micro-loops in the
   topology. This is no different from the IGP's susceptibility to
   micro-loops during a metric change.  The micro-loop avoidance
   procedures described in <xref target ='I-D.bashandy-rtgwg-segment-routing-uloop'/> target="I-D.bashandy-rtgwg-segment-routing-uloop" format="default"/>
   or any other mechanism as described in the framework <xref target ='RFC5715'/> target="RFC5715" format="default"/>
   can be used to avoid micro-loops when the automatic metric
   calculation is deployed.</t>
        <t> Computing the metric between adjacent systems based on bandwidth
   becomes more complex in the case of parallel adjacencies. If there
   are parallel adjacencies between systems, then the bandwidth
   between the systems is the sum of the bandwidth of the parallel
   links. This is somewhat more complex to deal with, so there is an
   optional mode for computing the aggregate bandwidth.</t>
        <section title="Automatic anchor="sec_auto_metric_mode" numbered="true" toc="default">
          <name>Automatic Metric Calculation Modes"
         anchor='sec_auto_metric_mode'> Modes</name>
          <section title="Simple Mode" anchor='sec_simple'> anchor="sec_simple" numbered="true" toc="default">
            <name>Simple Mode</name>
            <t> In simple mode, the Maximum Link Bandwidth of a single layer-3 Layer 3 link
   is used to derive the metric.  This mode is suitable for
   deployments that do not use parallel layer-3 Layer 3 links. In this case,
   the computation of the metric is straightforward.

   If a layer-3 Layer 3 link is composed of a layer-2 Layer 2 bundle, then the link
   bandwidth is the sum of the bandwidths of the working components
   and may vary with layer-2 Layer 2 link failures. </t>
          </section>
          <section title="Interface anchor="sec_intf_grp" numbered="true" toc="default">
            <name>Interface Group Mode" anchor='sec_intf_grp'> Mode</name>
            <t> The simple mode of metric calculation may not work well when there
   are multiple parallel layer-3 Layer 3 interfaces between two nodes.
   Ideally, the metric between two systems should be the same given
   the same bandwidth, whether the bandwidth is provided by parallel
   layer-2
   Layer 2 links or parallel layer-3 Layer 3 links. To address this, in
   Interface Group Mode, nodes MUST <bcp14>MUST</bcp14> compute the aggregate bandwidth of
   all parallel adjacencies, MUST <bcp14>MUST</bcp14> derive the metric based on the
   aggregate bandwidth, and MUST <bcp14>MUST</bcp14> apply the resulting metric to each of
   the parallel adjacencies. Note that a single elephant flow is normally
   pinned to a single layer-3 Layer 3 interface. If the single layer-3 Layer 3 link
   bandwidth is not sufficient for any single elephant flow, the mechanisms
   to solve this issue are outside the scope of this document.
</t>
            <figure anchor="interface_grp" title="Parallel interfaces">
      <artwork> anchor="interface_grp">
              <name>Parallel Interfaces</name>
              <artwork name="" type="" align="left" alt=""><![CDATA[
        A------B====C====F====D
               |              |
                ------E-------
      </artwork>
      ]]></artwork>
            </figure>
            <t>
   For example, in the above diagram, there are two parallel links
   between B->C, C->F, F->D. B-&gt;C, C-&gt;F, F-&gt;D.  Let us assume the link bandwidth is
   uniform 10Gbps 10 Gbps on all links. When bandwidth is used to derive the metric
   for the links, the metric for each link will be
   the same. Traffic from B to D will be forwarded B->E->D as B-&gt;E-&gt;D because
   the metric will be lower.  Since the
   bandwidth is higher on the B->C->F->D B-&gt;C-&gt;F-&gt;D path, the metric for that
   path should be lower than the B->E->D B-&gt;E-&gt;D path to attract the traffic on
   B->C->F->D
   the B-&gt;C-&gt;F-&gt;D path.  Interface
   Group Mode should be preferred in cases where there are parallel layer-3 Layer 3
   links.
            </t>
            <t>
    In the interface group mode, Interface Group Mode, every node  MUST  <bcp14>MUST</bcp14>
    identify the set of parallel links between a pair
    of nodes based on IGP link advertisements
    and MUST <bcp14>MUST</bcp14> consider cumulative bandwidth of the
    parallel links while arriving at the metric of each link. </t>
            <t>The parallel layer-3 Layer 3 links between two nodes may not have the
	   same bandwidth. In such cases cases, the method described in interface group mode Interface Group Mode will
	   result in the same metric being used for all the parallel links links, which may cause
	   undesired load-balancing load balancing on the links. In such cases, a device may locally
	   apply a load-balancing factor relative to the link bandwidth on the ECMP nexthops. next hops.
	   The load-balancing mechanisms are outside the scope of this document.</t>
          </section>
        </section>
        <section title="Automatic anchor="sec_auto_metric_methods" numbered="true" toc="default">
          <name>Automatic Metric Calculation Methods"
         anchor='sec_auto_metric_methods'> Methods</name>
          <t>
In automatic metric calculation for simple and interface group mode, Interface Group Mode,
Maximum Link Bandwidth of the links is used to derive the metric.
There are two types of automatic metric derivation methods.</t>
<t>
<list>
<t> 1. Reference
          <ol type="1" spacing="normal">
            <li>Reference bandwidth method</t>
<t> 2. Bandwidth method</li>
            <li>Bandwidth thresholds method </t>
</list>
</t> method</li>
          </ol>

          <section title="Reference anchor="sec_ref_bw_method" numbered="true" toc="default">
            <name>Reference Bandwidth method" anchor='sec_ref_bw_method'> Method</name>
            <t>In many networks, the metric is inversely proportional to the link
   bandwidth.  The administrator or implementation selects a reference
   bandwidth and the metric is derived by dividing the reference
   bandwidth by the advertised Maximum Link Bandwidth.  Advertising
   the reference bandwidth in the FAD constraints allows the metric
   computation to be done on every node for each link.
   The metric is computed using reference bandwidth and the advertised link bandwidth.
   Centralized control of this
   reference bandwidth simplifies management in the case that where the
   reference bandwidth changes. In order to ensure that small
   bandwidth changes do not change the link metric, it is useful to
   define the granularity of the bandwidth that is of interest.  The
   link bandwidth will be truncated to this granularity before
   deriving the metric.  </t>

<t>
For
            <t>For example,</t>
<t><list>
 <t>reference
                <t indent="3">reference bandwidth = 1000G  </t>
 <t>Granularity
                <t indent="3">Granularity = 20G </t>
 <t>The
                <t indent="3">The derived metric is 10 for link bandwidth in the range 100G to 119G </t>
 </list></t>
          </section>
          <section title="Bandwidth anchor="sec_bw_threshold_method" numbered="true" toc="default">
            <name>Bandwidth Thresholds method"
          anchor='sec_bw_threshold_method'> Method</name>
            <t> The reference bandwidth approach described above provides a uniform
   metric value for a range of link bandwidths.  In certain cases cases,
   there may be a need to define non-proportional metric values for
   the varying ranges of link bandwidth.  For example, bandwidths from
   10G to 30G are assigned metric value 100, bandwidth from 30G to 70G
   get
   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
   on bandwidth thresholds is supported in the FAD.  This
   advertisement contains a set of threshold values and associated
   metrics. </t>
          </section>
        </section>
        <section title="IS-IS anchor="sec_auto_isis" numbered="true" toc="default">
          <name>IS-IS FAD constraint Constraint Sub-TLVs for automatic metric calculation"
 anchor='sec_auto_isis'> Automatic Metric Calculation</name>
          <section title="Reference anchor="sec_isis_auto_ref_bw" numbered="true" toc="default">
            <name>Reference Bandwidth Sub-TLV" anchor='sec_isis_auto_ref_bw'> Sub-TLV</name>
            <t>
This section provides FAD constraint advertisement details for the
reference bandwidth method of metric calculation calculation, as described in
 <xref target ='sec_ref_bw_method'/>. target="sec_ref_bw_method" format="default"/>.

The Flexible Algorithm Definition Reference Bandwidth (FADRB) sub-TLV (FADRB sub-TLV) is
a sub-TLV of the IS-IS FAD sub-TLV. It has the following format:

</t>
            <figure anchor="isis_fadrb_sub_tlv" title="IS-IS anchor="isis_fadrb_sub_tlv">
              <name>IS-IS FADRB Sub-TLV">
      <artwork> Sub-TLV</name>
              <artwork name="" type="" align="left" alt=""><![CDATA[
    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      Type     |    Length     |     Flags     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                      Reference Bandwidth                      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                      Granularity Bandwidth                    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   where:

      Type
]]></artwork>
</figure>

<t>where:</t>

<dl spacing="normal" newline="true">
  <dt>Type (1 octet):
      An octet):</dt>
  <dd>An 8-bit field assigned by IANA (To Be Determined as TBD7). (8).  This value
  uniquely identifies the IS-IS FADRB sub-TLV.

      Length sub-TLV.</dd>
  <dt>Length (1 octet):
      An 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.

      Flags 9.</dd>
  <dt>Flags (1 octet):
      An octet):</dt>
  <dd><t>An 8-bit field containing flags. flags.</t>
  <artwork name="" type="" align="left" alt=""><![CDATA[
                 0 1 2 3 4 5 6 7
                +-+-+-+-+-+-+-+-+
                |G|             |
                +-+-+-+-+-+-+-+-+

         G-flag: When
		]]></artwork></dd>
  <dt>G-flag:</dt>
  <dd>When set, Interface Group Mode MUST <bcp14>MUST</bcp14> be used to derive
  total link bandwidth.  Unassigned bits MUST <bcp14>MUST</bcp14> be set to zero.

      Reference
  zero.</dd>
  <dt>Reference Bandwidth (4 octets):
      A octets):</dt>
  <dd>A 32-bit field with Bandwidth encoded in IEEE floating point format [IEEE754-2019].
  <xref target="IEEE754-2019"/>.  The units are bytes-per-second.

      Granularity bytes per second.</dd>
  <dt>Granularity Bandwidth (4 octets):
      A octets):</dt>
  <dd>A 32-bit field with Bandwidth encoded in IEEE floating point format [IEEE754-2019].
  <xref target="IEEE754-2019"/>.  The units are bytes-per-second.

    When bytes per second.</dd>
</dl>

<t>When granularity_bw is less than or equal to Total_link_bandwidth

        Metric calculation: (Reference_bandwidth) Total_link_bandwidth, then:</t>

<dl spacing="normal" newline="false">
  <dt>Metric calculation:</dt><dd>(Reference_bandwidth) / (Total_link_bandwidth - (Modulus of(Total_link_bandwidth,
                                           granularity_bw)))

    When granularity_bw)))</dd>
</dl>

<t>When granularity_bw is greater than Total_link_bandwidth
            Metric calculation: Reference_bandwidth Total_link_bandwidth, then:</t>
<dl spacing="normal" newline="false">
  <dt>Metric calculation:</dt><dd>Reference_bandwidth /
                                       Total_link_bandwidth

    The Total_link_bandwidth</dd>
</dl>

<t>The division used here is integer division.  Modulus of operation is
defined as a remainder value when two numbers are divided.

       </artwork>
    </figure>
    </t> divided.</t>

            <t>   The Granularity Bandwidth value ensures that the metric
         does not change when there is a small
         change in the link bandwidth.
   The IS-IS FADRB sub-TLV MUST NOT <bcp14>MUST NOT</bcp14> appear more than once in an IS-IS FAD
   sub-TLV.  If it appears more than once, the IS-IS FAD sub-TLV MUST <bcp14>MUST</bcp14> be ignored
   by the receiver. The value advertised in the Reference Bandwidth field MUST <bcp14>MUST</bcp14> be non-zero.
   If a zero value is advertised in the Reference Bandwidth Field field in the IS-IS FADRB sub-TLV,
   the sub-TLV MUST <bcp14>MUST</bcp14> be ignored.</t>
            <t>If a Generic Metric sub-TLV with a Bandwidth metric
   type is advertised for a link,
   the Flex-Algorithm calculation MUST <bcp14>MUST</bcp14> use the advertised Bandwidth Metric, Metric
   and MUST NOT <bcp14>MUST NOT</bcp14> use the automatically derived metric for that link.
   In case of Interface Group Mode, if all the parallel links have been
   advertised with the Bandwidth Metric, The the individual link Bandwidth Metric
   MUST
   <bcp14>MUST</bcp14> be used. If only some links among the parallel links have the Bandwidth
   Metric advertisement, the Bandwidth Metric for such links MUST <bcp14>MUST</bcp14> be ignored ignored, and
   automatic Metric calculation MUST <bcp14>MUST</bcp14> be used to derive link metric.
            </t>
            <t>If the calculated metric evaluates to zero, a metric of 1 MUST <bcp14>MUST</bcp14> be used.</t>
            <t> If the calculated metric evaluates to a number greater than 0xFFFFFF,
   it is set to 0xFFFFFF.</t>
          </section>
          <section title="Bandwidth Thresholds Sub-TLV" anchor='sec_isis_threshold_metric'> anchor="sec_isis_threshold_metric" numbered="true" toc="default">
            <name>Bandwidth Threshold Sub-TLV</name>
            <t>
This section provides FAD constraint advertisement details for the
Bandwidth Thresholds method of metric calculation as
described in <xref target ='sec_bw_threshold_method'/>. target="sec_bw_threshold_method" format="default"/>.
The Flexible Algorithm Definition Bandwidth Threshold (FADBT) sub-TLV (FADBT sub-TLV) is
a sub-TLV of the IS-IS FAD sub-TLV. It has the following format:

</t>
            <figure anchor="isis_fadbt_sub_tlv" title="IS-IS anchor="isis_fadbt_sub_tlv">
              <name>IS-IS FADBT Sub-TLV">
      <artwork> Sub-TLV</name>
              <artwork name="" type="" align="left" alt=""><![CDATA[
    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      Type     |    Length     |       Flags   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                     Bandwidth Threshold 1                     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                     Threshold Metric 1        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                     Bandwidth Threshold 2                     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                     Threshold Metric 2        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                     Bandwidth Threshold 3                     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                                  .....
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                     Threshold Metric N-1      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                     Bandwidth Threshold N                     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                     Threshold Metric N        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      where:

      Type
]]></artwork>
</figure>

<t>where:</t>

<dl spacing="normal" newline="true">
  <dt>Type (1 octet): octet):</dt>
  <dd> An 8-bit field assigned by IANA (To Be Determined as TBD8). (9).  This value
  uniquely identifies the IS-IS FADBT sub-TLV.

      Length sub-TLV.</dd>
  <dt>Length (1 octet):
      An 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 Here, N is
  equal to the number of Threshold Metrics specified.  n MUST <bcp14>MUST</bcp14> be
  greater than or equal to 1

      Flags 1.</dd>
  <dt>Flags (1 octet): octet):</dt>
  <dd><artwork name="" type="" align="left" alt=""><![CDATA[
                 0 1 2 3 4 5 6 7
                +-+-+-+-+-+-+-+-+
                |G| | |         |
                +-+-+-+-+-+-+-+-+

        G-flag: when
		]]></artwork>
  <dl spacing="normal" newline="false">
  <dt>G-flag:</dt><dd>When set, interface group Interface Group Mode MUST <bcp14>MUST</bcp14> be
  used to derive total link bandwidth.
        Unassigned bits MUST bandwidth.</dd>
  <dt>Unassigned bits</dt><dd> <bcp14>MUST</bcp14> be set to zero. zero.</dd>
  </dl>
  </dd>
</dl>

<!--[rfced] We updated this text to make it a complete sentence. There
are two instances in the document. Please let us know if this is not correct.

Original:
   Staircase bandwidth threshold and associated metric values.

        Bandwidth

Current:
   Following is the staircase bandwidth threshold and associated metric
   values.
-->

<t>Following is the staircase bandwidth threshold and associated metric values.</t>

<dl spacing="normal" newline="true">
  <dt>Bandwidth Threshold 1 (4 octets):
        Minimum octets):</dt>
  <dd>Minimum Link Bandwidth is encoded in in IEEE floating point format (32 bits)[IEEE754-2019].
  bits)<xref target="IEEE754-2019"/>.  The units are bytes-per-second.

        Threshold bytes per second.</dd>
  <dt>Threshold Metric 1 (3 octets):
        Metric octets):</dt>
  <dd>Metric value range (1 - 16,777,215 (0xFFFFFF))

        Bandwidth (0xFFFFFF))</dd>
  <dt>Bandwidth Threshold n (4 octets):
        Maximum octets):</dt>
  <dd>Maximum Link Bandwidth is encoded in IEEE floating point format (32 bits)[IEEE754-2019].
  bits)<xref target="IEEE754-2019"/>.  The units are bytes-per-second.

        Threshold bytes per second.</dd>
  <dt>Threshold Metric n (3 octest) :
        Metric octets):</dt>
  <dd>Metric value range (1 - 16,777,215 (0xFFFFFF))

       </artwork>
    </figure>
</t> (0xFFFFFF))</dd>
</dl>

<t>When the G-flag is set, the cumulative bandwidth of the parallel links is
computed as described in <xref target ='sec_intf_grp'/>. target="sec_intf_grp" format="default"/>. If the
G-flag is not set, the advertised Maximum Link Bandwidth is used.</t>
   <t>Assignment

<t>The assignment of the Bandwidth Metric Based based on Computed Link Bandwidth:</t> computed link bandwidth is described below.</t>
<t>The Bandwidth Metric for a link during the Flex-Algorithm Shortest Path
First (SPF) calculation MUST <bcp14>MUST</bcp14> be assigned according to the
following rules:</t>
    <t>
	<list>
	<t>1. When
   <ol type="1" spacing="normal">
     <li><t>When the computed link bandwidth is less than Bandwidth Threshold 1:
	<ul>
       <li> The 1:</t>
     <t>The Bandwidth Metric MUST <bcp14>MUST</bcp14> be set to the maximum metric value of 4,261,412,864.</li>
    </ul>
	</t>
    <t>2. When 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:
		<ul>
          <li> The 2:</t>
     <t>The Bandwidth Metric MUST <bcp14>MUST</bcp14> be set to Threshold Metric 1.</li>
		</ul>
		</t>

    <t>3. When 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:
		<ul>
        <li> The 3:</t>
     <t>The Bandwidth Metric MUST <bcp14>MUST</bcp14> be set to Threshold Metric 2.</li>
		</ul>
		</t>

    <t>4. In 2.</t>
     </li>
     <li><t>In general, for all integer values of X such that 1 ≤ X &lt; N:
	    <ul>
        <li> When N:</t>
     <t>When the computed link bandwidth is greater than or equal to Bandwidth
     Threshold X and less than Bandwidth Threshold X+1:</li>
        <li> The X+1:</t>
     <t>The Bandwidth Metric MUST <bcp14>MUST</bcp14> be set to Threshold Metric X.</li>
		</ul>
	</t>

    <t>5. When X.</t>
     </li>
     <li><t>When the computed link bandwidth is greater than or equal to Bandwidth Threshold N:
        <ul>
		  <li> The N:</t>
     <t>The Bandwidth Metric MUST <bcp14>MUST</bcp14> be set to Threshold Metric N.</li>
		</ul>
	</t>
    </list>
	</t>
<t>Notes:
<list>
    <t>The N.</t>
     </li>
   </ol>

   <t>Notes:</t>
   <ul spacing="normal">
     <li>The term Bandwidth "Bandwidth Threshold X X" refers to a predefined threshold
       value corresponding to the index X.</t>
    <t>The X.</li>
       <li>The term Threshold "Threshold Metric X X" refers to the metric value
       associated with Bandwidth Threshold X.</t>
    <t>N X.</li>
       <li>N represents the total number of bandwidth thresholds
       defined in the system.</t>
</list>
</t> system.</li>
   </ul>

            <t>Implementations MUST <bcp14>MUST</bcp14> ensure that these rules are consistently applied to
maintain interoperability and optimal path computation
within the network.</t>
            <t>The IS-IS FADBT sub-TLV MUST NOT <bcp14>MUST NOT</bcp14> appear more than once in an IS-IS FAD
   sub-TLV.  If it appears more than once, the IS-IS FAD sub-TLV MUST <bcp14>MUST</bcp14>
   be ignored by the receiver.</t>
            <t>A FAD MUST NOT <bcp14>MUST NOT</bcp14> contain both the FADBT sub-TLV and the FADRB sub-TLV.  If both
   of these sub-TLVs are advertised in the same FAD for a Flexible
   Algorithm, the FAD MUST <bcp14>MUST</bcp14> be ignored by the receiver.</t>
            <t>If a Generic Metric sub-TLV with Bandwidth metric type is advertised
   for a link, the Flex-Algorithm calculation MUST <bcp14>MUST</bcp14> use the Bandwidth
   Metric advertised on the link, link and MUST NOT <bcp14>MUST NOT</bcp14> use the automatically
	    derived metric for that link.</t>

   <t>In

<!--[rfced] We note similar text in Sections 4.1.3.1, 4.1.3.2, and
4.1.4.2.  Should any of this text be in paragraph form or
bulleted form for consistency?

Original
Section 4.1.3.1:
   In case of Interface Group Mode, if
   all the parallel links have been advertised with the Bandwidth
   Metric, The individual link Bandwidth Metric MUST be used.  If only
   some links among the parallel links have the Bandwidth Metric
   advertisement, the Bandwidth Metric for such links MUST be ignored
   and automatic Metric calculation MUST be used to derive link metric.

Section 4.1.3.2:
   In case of Interface Group Mode, if all the parallel links have been
   advertised with the Bandwidth Metric, The individual link Bandwidth
   Metric MUST be used.  If only some links among the parallel links
   have the Bandwidth Metric advertisement, the Bandwidth Metric for
   such links MUST be ignored and automatic Metric calculation MUST be
   used to derive link metric.

Section 4.1.4.2:
   In the context of Interface Group Mode, the following rules apply to
   parallel links:

   *  If all parallel links have advertised the Bandwidth Metric:

      The individual link Bandwidth Metrics MUST be used for each link
      during path computation.

   *  If only some of the parallel links have advertised the Bandwidth
      Metric:

      -  The Bandwidth Metric advertisements for those links MUST be
         ignored.

      -  Automatic metric calculation MUST be used to derive the link
         metrics for all parallel links.
-->

            <t>In case of Interface Group Mode, if all the parallel links
   have been advertised with the Bandwidth Metric, the individual
   link Bandwidth Metric <bcp14>MUST</bcp14> be used. If only some links among
   the parallel links have advertised the Bandwidth Metric,
   the Bandwidth Metric for such links <bcp14>MUST</bcp14> be ignored and
   automatic Metric calculation <bcp14>MUST</bcp14> be used to derive the link metric.</t>
          </section>
        </section>
        <section title="OSPF anchor="sec_auto_ospf" numbered="true" toc="default">
          <name>OSPF FAD constraint Constraint Sub-TLVs for automatic metric calculation"
 anchor='sec_auto_ospf'> Automatic Metric Calculation</name>
          <section title="Reference anchor="sec_ospf_auto_ref_bw" numbered="true" toc="default">
            <name>Reference Bandwidth Sub-TLV" anchor='sec_ospf_auto_ref_bw'> Sub-TLV</name>
            <t>
The Flexible Algorithm Definition Reference Bandwidth (FADRB) sub-TLV (FADRB sub-TLV) is
a sub-TLV of the OSPF FAD TLV. It has the following format:

</t>
            <figure anchor="ospf_fadrb_sub_tlv" title="OSPF anchor="ospf_fadrb_sub_tlv">
              <name>OSPF FADRB Sub-TLV">
      <artwork> Sub-TLV</name>
              <artwork name="" type="" align="left" alt=""><![CDATA[
    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      Type                     |    Length                     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    Flags   |     Reserved                                     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                      Reference Bandwidth                      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                      Granularity Bandwidth                    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   where:

      Type
]]></artwork>
</figure>

<t>where:</t>

<dl spacing="normal" newline="true">
  <dt>Type (2 octets):
      A octets):</dt>
  <dd>A 16-bit field assigned by IANA (To Be Determined as TBD9). (8).  This value
  uniquely identifies the OSPF FADRB sub-TLV.

      Length sub-TLV.</dd>
  <dt>Length (2 octets):
      A 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.

      Flags 14.</dd>
  <dt>Flags (1 octet): octet):</dt>
  <dd><artwork name="" type="" align="left" alt=""><![CDATA[
                 0 1 2 3 4 5 6 7
                +-+-+-+-+-+-+-+-+
                |G| | |         |
                +-+-+-+-+-+-+-+-+

         G-flag: When
		]]></artwork>
  <dl spacing="normal" newline="false">
    <dt>G-flag:</dt><dd>When set, Interface Group Mode MUST <bcp14>MUST</bcp14> be
    used to derive total link bandwidth.
        Unassigned bits MUST bandwidth.</dd>
    <dt>Unassigned bits</dt><dd> <bcp14>MUST</bcp14> be set to zero.

      Reference zero.</dd>
  </dl></dd>
  <dt>Reference Bandwidth (4 octets):
      Bandwidth octets):</dt>
  <dd>Bandwidth encoded in 32 bits in IEEE floating point format [IEEE754-2019].
  <xref target="IEEE754-2019"/>.  The units are in bytes per second.
      Granularity second.</dd>
  <dt>Granularity Bandwidth (4 octets):
      Bandwidth octets):</dt>
  <dd>Bandwidth encoded in 32 bits in IEEE floating point format [IEEE754-2019].
  <xref target="IEEE754-2019"/>.  The units are in bytes per second.

    When second.</dd>
</dl>

<t>When granularity_bw is less than or equal to Total_link_bandwidth

        Metric calculation: (Reference_bandwidth) Total_link_bandwidth, then:</t>

<dl spacing="normal" newline="true">
  <dt>Metric calculation:</dt><dd>(Reference_bandwidth) /
  (Total_link_bandwidth - (Modulus of(Total_link_bandwidth,
                                            granularity_bw)))

    When
  granularity_bw)))</dd>
</dl>

<t>When granularity_bw is greater than Total_link_bandwidth

        Metric calculation: Reference_bandwidth/
                    Total_link_bandwidth

    The Total_link_bandwidth, then:</t>

<dl spacing="normal" newline="true">
  <dt>Metric calculation:</dt><dd>Reference_bandwidth/
  Total_link_bandwidth</dd>
</dl>

<t>The division used here is integer division.

	Modulus division.</t>

<t>Modulus of operation is defined as a remainder value when two numbers are divided.
       </artwork>
    </figure>

   The
divided.</t>

<t>The Granularity Bandwidth value is used to ensure that the metric does not
change when there is a small change in the link bandwidth.  The OSPF FADRB
sub-TLV MUST NOT <bcp14>MUST NOT</bcp14> appear more than once in an OSPF FAD TLV.  If
it appears more than once, the OSPF FAD TLV MUST <bcp14>MUST</bcp14> be ignored by
the receiver.The receiver. The value advertised in the Reference Bandwidth field MUST
<bcp14>MUST</bcp14> be non-zero.  If a zero value is advertised in the
Reference Bandwidth Field field in the OSPF FADRB sub-TLV, the sub-TLV MUST
<bcp14>MUST</bcp14> be ignored.  If a Generic Metric sub-TLV with Bandwidth
metric type is advertised for a link, the Flex-Algorithm calculation MUST
<bcp14>MUST</bcp14> use the advertised Bandwidth Metric on the link, link and MUST NOT
<bcp14>MUST NOT</bcp14> use the automatically derived metric for that link.
In the case of Interface Group Mode, the following procedures apply:
   <list>
            </t>
            <ul spacing="normal">
              <li>
                <t> When all parallel links have advertised the Bandwidth
                Metric: The individual link Bandwidth Metric MUST
                <bcp14>MUST</bcp14> be used for each link.</t>
              </li>
              <li>
                <t> When only a subset of the parallel links have advertised
                the Bandwidth Metric: The Bandwidth Metric advertisements for
                those links MUST <bcp14>MUST</bcp14> be ignored. In this scenario,
                automatic metric calculation MUST <bcp14>MUST</bcp14> be used to
                derive the link metrics for all parallel links.</t>
	</list>

   </t>
              </li>
            </ul>

            <t>If the calculated metric evaluates to zero, a metric of 1 MUST <bcp14>MUST</bcp14> be used.</t>
            <t> If the calculated metric evaluates to a number greater than 0xFFFFFFFF,
     it is set to 0xFFFFFFFF.</t>
          </section>
          <section title="Bandwidth anchor="sec_ospf_threshold_metric" numbered="true" toc="default">
            <name>Bandwidth Threshold Sub-TLV" anchor='sec_ospf_threshold_metric'> Sub-TLV</name>
            <t>
The Flexible Algorithm Definition Bandwidth Thresholds Threshold (FADBT) sub-TLV
(FADBT sub-TLV) is
a sub-TLV of the OSPF FAD TLV. It has the following format:

</t>
            <figure anchor="ospf_fadbt_sub_tlv" title="OSPF anchor="ospf_fadbt_sub_tlv">
              <name>OSPF FADBT Sub-TLV">
      <artwork> Sub-TLV</name>
              <artwork name="" type="" align="left" alt=""><![CDATA[
    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      Type                     |    Length                     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    Flags   | Reserved                                         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                     Bandwidth Threshold 1                     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                     Threshold Metric 1                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                     Bandwidth Threshold 2                     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                     Threshold Metric 2                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                     Bandwidth Threshold 3                     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                                  .....
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                     Threshold Metric N-1                      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                     Bandwidth Threshold N                     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                     Threshold Metric N                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   where:
    Type
]]></artwork>
</figure>

<t>where:</t>
<dl spacing="normal" newline="true">
  <dt>Type (2 octets):
    A octets):</dt>
  <dd>A 16-bit field assigned by IANA (To Be Determined as TBD10). (9).  This value
  uniquely identifies the OSPF FADBT sub-TLV.

    Length sub-TLV.</dd>
  <dt>Length (2 octets):
    A 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 2 + N*8 octets. Here Here, N is equal to
  the number of Threshold Metrics specified. N MUST <bcp14>MUST</bcp14> be greater than
  or equal to 1.

     Flags 1.</dd>
  <dt>Flags (1 octet): octet):</dt>
  <dd>
    <artwork name="" type="" align="left" alt=""><![CDATA[
                 0 1 2 3 4 5 6 7
                +-+-+-+-+-+-+-+-+
                |G|             |
                +-+-+-+-+-+-+-+-+

         G-flag: when
		]]></artwork>
    <dl spacing="normal" newline="false">
      <dt>G-flag:</dt><dd>When set, interface group Interface Group Mode MUST <bcp14>MUST</bcp14>
      be used to derive total link bandwidth.
		Unassigned bits MUST bandwidth.</dd>
      <dt>Unassigned bits</dt><dd><bcp14>MUST</bcp14> be set to zero.

	Staircase zero.</dd>
    </dl>
  </dd>
</dl>

<t>Following is the staircase bandwidth threshold and associated metric values.

    Bandwidth values.</t>

<dl spacing="normal" newline="true">
  <dt>Bandwidth Threshold 1 (4 octets):
	Minimum octets):</dt>
  <dd>Minimum Link Bandwidth is encoded in IEEE floating point format (32 bits)[IEEE754-2019].
  bits)<xref target="IEEE754-2019"/>.  The units are bytes per second.

    Threshold second.</dd>
  <dt>Threshold Metric 1 (4 octets):
	Metric octets):</dt>
  <dd>Metric value range (1 - 4,294,967,296 (0xFFFFFFFF))

    Bandwidth (0xFFFFFFFF))</dd>
  <dt>Bandwidth Threshold N (4 octets):
	Maximum </dt>
  <dd>Maximum Link Bandwidth is encoded in IEEE floating point format (32 bits)[IEEE754-2019].
  bits)<xref target="IEEE754-2019"/>.  The units are bytes per second.

    Threshold second.</dd>
  <dt>Threshold Metric N (4 octets):
	Metric octets):</dt>
  <dd>Metric value range (1 - 4,294,967,296 (0xFFFFFFFF))

       </artwork>
   </figure>
   </t> (0xFFFFFFFF))</dd>
</dl>

<t>When the G-flag is set, the cumulative bandwidth of the parallel links is
computed as described in <xref target ='sec_intf_grp'/>. target="sec_intf_grp" format="default"/>.  If
the G-flag is not set, the advertised Maximum Link Bandwidth is used.</t>

   <t>Assignment

<t>The assignment of the Bandwidth Metric Based based on Computed Link Bandwidth:</t>

    <t>The computed link bandwidth is described below.</t>
<t>During the Flex-Algorithm SPF calculation, the Bandwidth Metric for a link during the Flex-Algorithm
	Shortest Path First (SPF) calculation MUST  <bcp14>MUST</bcp14> be assigned according to the following rules:</t>
<t>
<list>
 <t>1. When

<ol type="1" spacing="normal">
  <li><t>When the computed link bandwidth is less than Bandwidth Threshold 1:
  <ul>
  <li>The 1:</t>
  <t>The Bandwidth Metric MUST <bcp14>MUST</bcp14> be set to the maximum metric
  value of 4,294,967,296.</li>
  </ul>
  </t>
  <t>2. When 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:
	<ul>
  <li>The 2:</t>
  <t>The Bandwidth Metric MUST <bcp14>MUST</bcp14> be set to Threshold Metric 1.</li>
  </ul>
    </t>
   <t>3. When 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:
		 <ul>
    <li> The 3:</t>
  <t>The Bandwidth Metric MUST <bcp14>MUST</bcp14> be set to Threshold Metric 2.</li>
	   </ul>
    </t>
    <t>4. In 2.</t></li>
  <li><t>In general, for all integer values of X where 1 ≤X &lt; N:
	<ul>
    <li>When N:</t>
  <t>When the computed link bandwidth is greater than or equal to Bandwidth
  Threshold X and less than Bandwidth Threshold X+1:</li>
    <li>The X+1:</t>
  <t>The Bandwidth Metric MUST <bcp14>MUST</bcp14> be set to Threshold Metric X.</li>
	</ul>
     </t>
    <t>5. When X.</t></li>
  <li><t>When the computed link bandwidth is greater than or equal to
  Bandwidth Threshold N:
	<ul>
    <li>The N:</t>
  <t>The Bandwidth Metric MUST <bcp14>MUST</bcp14> be set to Threshold Metric N.</li>
	</ul>
	</t>
</list>
</t>
<t>Notes:
<list> N.</t></li>
</ol>

<t>Notes:</t>
<ul spacing="normal">
  <li>
    <t>Bandwidth Threshold X refers to the predefined bandwidth threshold
    corresponding to index X.</t>
  </li>
  <li>
    <t>Threshold Metric X is the metric value associated with Bandwidth
    Threshold X.</t>
  </li>
  <li>
    <t>N represents the total number of bandwidth thresholds defined in the
    system.</t>

</list>
</t>
  </li>
</ul>

            <t>Implementations MUST <bcp14>MUST</bcp14> consistently apply these rules to ensure accurate
 path computations and maintain interoperability within the network.</t>
            <t>The OSPF FADBT sub-TLV MUST NOT <bcp14>MUST NOT</bcp14> appear more than once in an OSPF FAD
   sub-TLV.  If it appears more than once, the OSPF FAD MUST sub-TLV <bcp14>MUST</bcp14>
   be ignored by the receiver.</t>
            <t>A FAD MUST NOT <bcp14>MUST NOT</bcp14> contain both the FADBT sub-TLV and the FADRB sub-TLV.  If both
   these sub-TLVs are advertised in the same FAD for a Flexible
   Algorithm, the FAD MUST <bcp14>MUST</bcp14> be ignored by the receiver.</t>
            <t>If a Generic Metric sub-TLV with Bandwidth metric type is advertised
   for a link, the Flex-Algorithm calculation MUST <bcp14>MUST</bcp14> use the Bandwidth
   Metric advertised on the link, link and MUST NOT <bcp14>MUST NOT</bcp14> use the automatically
   derived metric for that link.</t>
            <t> Metric Assignment in Interface Group Mode:</t>
            <t>When a link does not have a configured Bandwidth Metric,
   the automatically derived metric MUST <bcp14>MUST</bcp14> be used for that link.</t>
            <t>In the context of Interface Group Mode, the following rules apply to parallel links:</t>
<t>
<list>
 <t> If
            <ul spacing="normal">
              <li>
                <t>If all parallel links have advertised the Bandwidth Metric:
    <ul>
	<li>The Metric:</t>
                <t>The individual link Bandwidth Metrics MUST <bcp14>MUST</bcp14> be used for each link during path computation.</li>
	</ul>
  </t> computation.</t>
              </li>
              <li>
                <t>If only some of the parallel links have advertised the Bandwidth Metric: Metric:</t>
		<ul>
                  <li>The Bandwidth Metric advertisements for those links MUST <bcp14>MUST</bcp14> be ignored.</li>
                  <li>Automatic metric calculation MUST <bcp14>MUST</bcp14> be used to derive the link metrics for all parallel links.</li>
                </ul>
  </t>
</list>
</t>
              </li>
            </ul>

            <t>This approach ensures consistent metric calculation and avoids discrepancies
caused by partial Bandwidth Metric advertisements among parallel links.</t>
          </section>
        </section>
      </section>
    </section>
    <section title='Bandwidth metric considerations' anchor='sec-metric'> anchor="sec-metric" numbered="true" toc="default">
      <name>Bandwidth Metric Considerations</name>
      <t>
    This section specifies the rules of deriving the Bandwidth Metric if
    and only if the winning FAD for the Flex-Algorithm specifies the
    metric-type as "Bandwidth Metric".
    <list>
    <t>1. If
      </t>
      <ol type="1" spacing="normal">
        <li>If the Generic Metric sub-TLV with Bandwidth metric type is
        advertised for the link as described in <xref target ='sec_bw_metric'/>, target="sec_bw_metric"
        format="default"/>, it MUST <bcp14>MUST</bcp14> be used during the
        Flex-Algorithm
    calculation.</t>

    <t>2. If calculation.</li>
        <li>If the Generic Metric sub-TLV with Bandwidth metric type is not
        advertised for the link and the winning FAD for the Flex-Algorithm
        does not specify the automatic bandwidth metric calculation (as
        defined in <xref target ='sec_auto_metric'/> ), target="sec_auto_metric" format="default"/>), the
        link is treated as if the Bandwidth Metric is not available for the link.</t>

    <t>3. If
        link.</li>
        <li>If the Generic Metric sub-TLV with Bandwidth metric type is not
        advertised for the link and the winning FAD (sec 5.3 <xref target ='RFC9350'/> (<xref section="5.3"
        target="RFC9350" format="default"/>) for the Flex-Algorithm specifies
        the automatic bandwidth metric calculation (as defined in <xref target ='sec_auto_metric'/>),
        target="sec_auto_metric" format="default"/>), the Bandwidth Metric metric MUST
        <bcp14>MUST</bcp14> be automatically calculated as per the
        procedures defined in <xref target ='sec_auto_metric'/>. target="sec_auto_metric"
        format="default"/>.  If the Link Bandwidth is not advertised for a
        link, the link MUST <bcp14>MUST</bcp14> be pruned for the Flex-Algorithm calculations.</t>

	<t>4.In ISIS
        calculations.</li>
        <li>In ISIS, for Flex-Algorithm purposes, the Link Bandwidth for Flex-Algorithm purposes is
        advertised as a sub-sub-TLV 9 of the Flex-algorithm specific Flex-Algorithm-specific ASLA
        sub-TLV.  It is also possible to advertise the link bandwidth or Flex-Algorithm,
        Flex-Algorithm in sub-TLV 9 of TLV 22/222/23/223/141 [RFC5305], <xref target="RFC5305"/>
        together with the L-Flag L-flag set in the Flex-Algorithm specific 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>

    </t>
        purposes.</li>
      </ol>

    </section>

    <section title='Calculation

<!--  This section sounds like this it updates RFC 9350.  Please confirm that an Updates tag is not needed on this document.

Original:
6.  Calculation of Flex-Algorithm paths' anchor='sec-calc'>
     <t> paths

   Two new additional rules are added to the existing rules in the
     Flex-Algorithm Flex-
   Algorithm calculations specified in Section 13 of
     <xref target ='RFC9350'/>.</t>

    <t>
       <list>

       <t>6. [RFC9350].

      6.  Check if any exclude FAEMB rule is part of the Flex-Algorithm
      definition.  If such exclude rule exists and the link has Maximum
      Link Bandwidth advertised, check if the link bandwidth satisfies
      the FAEMB rule.  If the link does not satisfy the FAEMB rule, the
      link MUST be pruned from the Flex-Algorithm computation.</t>
      <t>7. computation.

      7.  Check if any exclude FAEMD rule is part of the Flex-Algorithm
      definition.  If such exclude rule exists and the link has Min
      Unidirectional link delay advertised, check if the link delay
      satisfies the FAEMD rule.  If the link does not satisfy the FAEMD
      rule, the link MUST be pruned from the Flex-Algorithm computation.</t>
       </list>
    </t> computation.
-->
    <section anchor="sec-calc" numbered="true" toc="default">
      <name>Calculation of Flex-Algorithm Paths</name>
      <t>The following two new additional rules are added to the existing rules in the
      Flex-Algorithm calculations specified in <xref target="RFC9350"
      sectionFormat="of" section="13"/>:</t>

<blockquote>
      <ol spacing="normal" start="6">
        <li>Check if any exclude FAEMB rule is part of the Flex-Algorithm
        definition.  If such exclude rule exists and the link has Maximum Link
        Bandwidth advertised, check if the link bandwidth satisfies the FAEMB
        rule. If the link does not satisfy the FAEMB rule, the link
        <bcp14>MUST</bcp14> be pruned from the Flex-Algorithm computation.</li>
        <li>Check if any exclude FAEMD rule is part of the Flex-Algorithm
        definition.  If such exclude rule exists and the link has Min
        Unidirectional link delay advertised, check if the link delay
        satisfies the FAEMD rule. If the link does not satisfy the FAEMD rule,
        the link <bcp14>MUST</bcp14> be pruned from the Flex-Algorithm
        computation.</li>
      </ol>
</blockquote>

    </section>
    <section anchor='backward_compatibility' title='Backward Compatibility'> anchor="backward_compatibility" numbered="true" toc="default">
      <name>Backward Compatibility</name>
      <t> This extension brings no new backward-compatibility issues.
		 This document defines new FAD constraints in Sections
		 <xref target ='sec_fad_con'/> target="sec_fad_con" format="counter"/>, <xref target ='sec_auto_isis'/> target="sec_auto_isis" format="counter"/>, and
		 <xref target ='sec_auto_ospf'/>. target="sec_auto_ospf" format="counter"/>. As described in  <xref target ='RFC9350'/>, target="RFC9350" format="default"/>,
		 any node that does not understand sub-TLVs in a FAD TLV, TLV stops participation in the
		 corresponding Flex-Algorithm. The new extensions can be deployed among the nodes that are
		 upgraded to understand the new extensions without affecting the nodes that are not upgraded.
		 This document also defines a new metric advertisement as described in
		 <xref target ='sec_generic_metric'/>. target="sec_generic_metric" format="default"/>. As per Section 13 of <xref target ='RFC9350'/>, target="RFC9350" sectionFormat="of" section="13"/>,
		 when the links that do not advertise the metric-type specified by the selected FAD,
		 the link is pruned from Flex-Algorithm calculations. The new metric-types and the
         Flex-Algorithms using the new metric-types can be deployed in the network without affecting
         existing deployment.	 </t>
    </section>
    <section title='Security Considerations' anchor='sec-con'> anchor="sec-con" numbered="true" toc="default">
      <name>Security Considerations</name>
      <t>This document inherits security considerations from <xref target ='RFC9350'/>.</t> target="RFC9350" format="default"/>.</t>
    </section>
    <section title='Operational Considerations' anchor='sec-ops'> anchor="sec-ops" numbered="true" toc="default">
      <name>Operational Considerations</name>
      <t>Operational consideration considerations defined in <xref target ='RFC9350'/> target="RFC9350" format="default"/> generally apply to
	the extensions defined in this document as well. This document defines a metric-type
	range for user defined user-defined metrics. When user-defined metrics are used in an inter-area or
	inter-level network, all the domains should assign same meaning to the particular
	metric-type. The YANG data models for Flex-Algorithm extensions are defined in
	documents <xref target ='I-D.ietf-lsr-ospf-yang-augmentation-v1'/> target="I-D.ietf-lsr-ospf-yang-augmentation-v1" format="default"/> and
	<xref target ='I-D.ietf-lsr-isis-yang-augmentation-v1'/></t> target="I-D.ietf-lsr-isis-yang-augmentation-v1" format="default"/>.</t>
      <t>Before the router goes into maintenance activity, the traffic needs to be diverted away
	   from the router. This is achieved by setting the overload bit or setting link metrics on the
	   router to a high value. In case of Generic Metric, the link metrics can be set to a Maximum
	   usable metric for OSPF and ISIS. IS-IS. The traffic will be diverted away from the router to a shorter
	   available path. If there are no alternate paths available, traffic will stay on the router as
	   the links are not removed from Flex-algorithm the Flex-Algorithm calculation when they are set to a maximum metric as per
	   <xref target ='RFC9350'/> target="RFC9350" format="default"/>.
      </t>
    </section>
    <section anchor="IANA" title="IANA Considerations">

  <section anchor='igp_metric_type' title='IGP numbered="true" toc="default">
      <name>IANA Considerations</name>
      <section anchor="igp_metric_type" numbered="true" toc="default">
        <name>IGP Metric-Type Registry'>

	 <t>IGP Metric-type Registry is Registry</name>
        <t>The "IGP Metric-Type" registry has been updated to include another column
        specifying whether the particular metric-type is allowed in the generic-metric sub-TLV or not.
        Generic Metric sub-TLV.  The range 128-255 is being redefined in
        by this document as a user-defined range range, and this range does not standards action. require
        Standards Action <xref target="RFC8126"/>. </t>
	 <t>
	 <figure anchor="iana_metric_type" title="IANA IGP

<table anchor="iana_metric_type">
  <name>IGP Metric-Type Registry">
      <artwork>
     Type Description                 Reference       Allowed in
                                                      generic-metric
     ----------------------------------------------------------------
      0    IGP Metric                  [RFC9350]        No
                                      Section 5.1
      1    Min 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          [RFC9350]        No Link Delay as defined      Section 5.1 in [RFC8570,
           Section 4.2],and
           [RFC7471, Section 4.2]

      2    Traffic <xref target="RFC8570"
      sectionFormat="comma" section="4.2"/> and <xref target="RFC7471"
      sectionFormat="comma" section="4.2"/></td>
      <td><xref target="RFC9350" sectionFormat="of" section="5.1"/></td>
      <td>No</td>
    </tr>
    <tr>
      <td>2</td>
      <td>Traffic Engineering Default [RFC9350]        No Metric as defined in       Section 5.1
          [RFC5305,Section 3.7], <xref
      target="RFC5305" sectionFormat="comma" section="3.7"/> and [RFC3630, Section 2.5.5]
      3(TBA) Bandwidth  Traffic Engineering Metric         this document     yes

    128-255(TBA) User as defined metric this document     yes
	    </artwork>
    </figure>
   </t>

  </section>
    <section anchor='isis_fad'
	title='IS-IS 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'>
	<t>IS-IS Sub-TLV</name>
        <t>The "IS-IS Sub-Sub-TLVs for Flexible Algorithm Definition Sub-TLV Sub-TLV" registry is part
	of the “IS-IS "IS-IS TLV Codepoints” Codepoints" registry group.</t>
  <t> Type: 6(TBD3)</t>

     <t> Description: IS-IS

<dl spacing="compact" newline="false">
  <dt>Type:</dt><dd>6</dd>
  <dt>Description:</dt><dd>IS-IS Exclude 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 Bandwidth</dd>
  <dt>Reference:</dt><dd>RFC 9843, <xref target="sec_isis_bw_exclusion" format="default"/></dd>
</dl>
<dl spacing="compact" newline="false">
  <dt>Type:</dt><dd>7</dd>
  <dt>Description:</dt><dd>IS-IS Exclude 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 Delay</dd>
  <dt>Reference:</dt><dd>RFC 9843, <xref target="sec_isis_delay_exclusion" format="default"/></dd>
</dl>
<dl spacing="compact" newline="false">
  <dt>Type:</dt><dd>8</dd>
  <dt>Description:</dt><dd>IS-IS 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>

      <section anchor='ospf_fad'
	  title='OSPF Bandwidth</dd>
  <dt>Reference:</dt><dd>RFC 9843, <xref target="sec_isis_auto_ref_bw" format="default"/></dd>
</dl>
<dl spacing="compact" newline="false">
  <dt>Type:</dt><dd>9</dd>
  <dt>Description:</dt><dd>IS-IS Bandwidth Threshold</dd>
  <dt>Reference:</dt><dd>RFC 9843, <xref target="sec_isis_threshold_metric" format="default"/></dd>
</dl>
      </section>
      <section anchor="ospf_fad" numbered="true" toc="default">
        <name>OSPF Sub-TLVs for Flexible Algorithm Definition Sub-TLV'>
	  <t>OSPF Sub-TLV</name>
        <t>The "OSPF Flexible Algorithm Definition TLV Sub-TLVs Sub-TLVs"
	  registry is part of the “Open "Open Shortest Path First (OSPF) Parameters” Parameters"
	  registry group.</t>

  <t> Type:6  (TBD5)</t>

     <t> Description: OSPF
<dl spacing="compact" newline="false">
  <dt>Bit Number:</dt><dd>6</dd>
  <dt>Description:</dt><dd>OSPF Exclude Minimum Bandwidth Sub-TLV </t>

     <t>Reference: This document <xref target ='sec_ospf_bw_exclusion'/></t>

     <t> Type: 7(TBD6)</t>

     <t> Description: OSPF 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 Sub-TLV </t>

     <t>Reference: This document <xref target ='sec_ospf_delay_exclusion'/></t>

     <t> Type:  8(TBD9)</t>

     <t> Description: OSPF Delay</dd>
  <dt>Reference:</dt><dd>RFC 9843, <xref target="sec_ospf_delay_exclusion" format="default"/></dd>
</dl>
<dl spacing="compact" newline="false">
  <dt>Bit Number:</dt><dd>8</dd>
  <dt>Description:</dt><dd>OSPF 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'
  title='IS-IS Bandwidth</dd>
  <dt>Reference:</dt><dd>RFC 9843, <xref target="sec_ospf_auto_ref_bw" format="default"/></dd>
</dl>
<dl spacing="compact" newline="false">
  <dt>Bit Number:</dt><dd>9</dd>
  <dt>Description:</dt><dd>OSPF Bandwidth Threshold</dd>
  <dt>Reference:</dt><dd>RFC 9843, <xref target="sec_ospf_threshold_metric" format="default"/></dd>
</dl>
      </section>
      <section anchor="isis_gen_metric" numbered="true" toc="default">
        <name>IS-IS Sub-TLVs for TLVs Advertising Neighbor Information'>
  <t>IS-IS Information</name>
        <t>The "IS-IS Sub-TLVs for TLVs Advertising Neighbor Information Information" registry
  is part of the “IS-IS "IS-IS TLV Codepoints” Codepoints" registry group</t>

     <t> Type:17 (TBD1)</t>

     <t> Description: Generic metric </t>

     <t>Reference: This document <xref target ='sec_isis_gen_metric'/></t>

	 <t> TLV 22,23,25, 141, 222 and 223 group.</t>

<dl spacing="compact" newline="false">
  <dt>Type:</dt><dd>17</dd>
  <dt>Description:</dt><dd>Generic Metric</dd>
  <dt>TLVs set to Y</t> "Y":</dt><dd>22, 23, 25, 141, 222, and 223</dd>
  <dt>Reference:</dt><dd>RFC 9843, <xref target="sec_isis_gen_metric" format="default"/></dd>
</dl>

      </section>
      <section anchor='isis_gen_metric_te_app'
 title='Sub-sub-TLV anchor="isis_gen_metric_te_app" numbered="true" toc="default">
        <name>Sub-Sub-TLV Codepoints for Application-Specific Link Attributes'>
  <t>IS-IS Sub-sub-TLV Attributes</name>
        <t>The "IS-IS Sub-Sub-TLV Codepoints for Application-Specific Link Attributes Attributes" registry
  is part of the “IS-IS "IS-IS TLV Codepoints” Codepoints" registry group</t>
   <t> Type: 17 (TBD1)</t>

     <t> Description: Generic metric </t>

     <t>Reference: This document <xref target ='sec_isis_gen_metric'/></t>

</section>

 <section anchor='ospf_gen_metric' title='OSPFv2 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="default"/></dd>
</dl>
      </section>
      <section anchor="ospf_gen_metric" numbered="true" toc="default">
        <name>OSPFv2 Extended Link TLV Sub-TLVs'>
 <t> OSPFv2 Sub-TLVs</name>
        <t>The "OSPFv2 Extended Link TLV Sub-TLVs Sub-TLVs" registry
  is part of the “Open "Open Shortest Path First v2 (OSPFv2) Parameters” Parameters" registry group</t>
     <t> Type: 25(TBD21)</t>

     <t> Description: Generic metric </t>

     <t>Reference: This document <xref target ='sec_ospf_gen_metric'/></t>

	 <t> L2BM set to Y</t>
</section>

 <section anchor='ospf_gen_metric_te_lsa'
 title='Types group.</t>
<dl spacing="compact" newline="false">
  <dt>Value:</dt><dd>25</dd>
  <dt>Description:</dt><dd>Generic Metric</dd>
  <dt>L2BM:</dt><dd>Y</dd>
  <dt>Reference:</dt><dd>RFC 9843, <xref target="sec_ospf_gen_metric" format="default"/></dd>
</dl>
      </section>
      <section anchor="ospf_gen_metric_te_lsa" numbered="true" toc="default">
        <name>Types for Sub-TLVs of TE Link TLV (Value 2)'>
 <t> Types 2)</name>
        <t>The "Types for Sub-TLVs sub-TLVs of TE Link TLV (Value 2) 2)" registry
  is part of the “Open "Open Shortest Path First (OSPF) Traffic Engineering TLVs” TLVs" registry group</t>
     <t> Type: 36 (TBD22)</t>

     <t> Description: Generic metric </t>

     <t> Reference: This document <xref target ='sec_ospf_gen_metric'/></t>

</section>

 <section anchor='ospfv3_gen_metric_te_lsa' title='OSPFv3 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="default"/></dd>
</dl>
      </section>
      <section anchor="ospfv3_gen_metric_te_lsa" numbered="true" toc="default">
        <name>OSPFv3 Extended-LSA Sub-TLVs'> Sub-TLVs</name>
        <t> OSPFv3 The "OSPFv3 Extended-LSA Sub-TLVs Sub-TLVs" registry
  is part of the “Open "Open Shortest Path First v3 (OSPFv3) Parameters” Parameters" registry group</t>
     <t> Type: 34 (TBD23)</t>

     <t> Description: Generic metric </t>

     <t> Reference: This document <xref target ='sec_ospf_gen_metric'/></t>

	 <t> L2BM set to Y</t> group.</t>
<dl spacing="compact" newline="false">
  <dt>Value:</dt><dd>34</dd>
  <dt>Description:</dt><dd>Generic Metric</dd>
  <dt>L2BM:</dt><dd>Y</dd>
  <dt>Reference:</dt><dd>RFC 9843, <xref target="sec_ospf_gen_metric" format="default"/></dd>
</dl>
      </section>
    </section>
   <section title='Acknowledgements' anchor='ack'>
    <t>Many thanks to  Chris Bowers, Krzysztof Szarcowitz, Julian Lucek,
    Ram Santhanakrishnan, Ketan Talaulikar and Acee Lindem

  </middle>
  <back>

    <displayreference target="I-D.bashandy-rtgwg-segment-routing-uloop" to="SR-LOOP-AVOID"/>
    <displayreference target="I-D.ietf-lsr-isis-yang-augmentation-v1" to="ISIS-AUGMENTATION"/>
    <displayreference target="I-D.ietf-lsr-ospf-yang-augmentation-v1" to="OSPF-AUGMENTATION"/>
    <references>
      <name>References</name>
      <references>
        <name>Normative References</name>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5305.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3630.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7684.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9479.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9492.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8362.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9350.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9356.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5392.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5329.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8668.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.1195.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2328.xml"/>
	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8126.xml"/>

        <reference anchor="IEEE754-2019" target="">
          <front>
            <title>IEEE Standard for discussions and inputs.</t>
  </section>
     <section title='Contributors'>

    <t>1. Salih K A</t>
    <t>Juniper Networks</t>
    <t>salih@juniper.net</t>

  </section>

  <section title='APPENDIX' anchor='app'> Floating-Point Arithmetic</title>
            <author>
              <organization>IEEE</organization>
            </author>
            <date day="22" month="July" year="2019"/>
          </front>
          <seriesInfo name="IEEE Std" value="754-2019"/>
          <seriesInfo name="DOI" value="10.1109/ieeestd.2019.8766229"/>
        </reference>
      </references>
      <references>
        <name>Informative References</name>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8570.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7471.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5311.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9346.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5120.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5715.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4655.xml"/>

<!-- [I-D.ietf-lsr-ospf-yang-augmentation-v1]
draft-ietf-lsr-ospf-yang-augmentation-v1-16
IESG State: I-D Exists as of 07/29/25.
-->
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-lsr-ospf-yang-augmentation-v1.xml"/>

<!-- [I-D.ietf-lsr-isis-yang-augmentation-v1]
draft-ietf-lsr-isis-yang-augmentation-v1-09
IESG State: I-D Exists as of 07/29/25.
-->
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-lsr-isis-yang-augmentation-v1.xml"/>

<!-- [I-D.bashandy-rtgwg-segment-routing-uloop]
draft-bashandy-rtgwg-segment-routing-uloop-17
IESG State: Expired as of 07/29/25.
-->
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml3/reference.I-D.bashandy-rtgwg-segment-routing-uloop.xml"/>
      </references>
    </references>

    <section title='Updated list anchor="rules" numbered="true" toc="default">
	<name>Updated List of rules Rules for pruning links Pruning Links in Flex-algorithm topology ' anchor='rules'> Flex-Algorithm Topology</name>

        <t>This section lists the entire set of rules to prune links from
        Flex-Algorithm topology during Flexible-algorithm Flexible Algorithm calculation.  It
        includes the original rules defined in Section 13 of <xref target ='RFC9350'/> target="RFC9350"
        sectionFormat="of" section="13"/> as well as the new additions proposed (rules 6 and 7) described in
        this document.
  <list> document.</t>

        <t>For all links in the topology:</t>
	<t>1. Check
        <ol type="1" spacing="normal">
          <li>Check if any exclude Administrative Group rule is part of the
          Flex-Algorithm Definition.  If such exclude rule exists, check if
          any color that is part of the exclude rule is also set on the link.
          If such a color is set, the link MUST <bcp14>MUST</bcp14> be pruned from
          the computation.</t>
    <t>2. Check 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 a
	lso also part of the SRLG exclude rule. If the link
          is part of such SRLG, the link MUST <bcp14>MUST</bcp14> be pruned from
          the computation.</t>
	<t>3. Check 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 MUST <bcp14>MUST</bcp14>
          be pruned from the computation.</t>
	<t>4. Check 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 MUST <bcp14>MUST</bcp14> be pruned from the
	computation.</t>
	<t>5. If computation.</li>
          <li>If the Flex-Algorithm Definition uses something other than the
          IGP metric (Section 5 of <xref target ='RFC9350'/>), (<xref target="RFC9350" sectionFormat="of" section="5"/>),
          and such metric is not advertised for the particular link in a
          topology for which the computation is done, such link MUST
          <bcp14>MUST</bcp14> be pruned from the computation. A metric of
          value 0 MUST NOT <bcp14>MUST NOT</bcp14> be assumed in such a case.</t>
	 <t>6.  Check case.</li>
          <li>Check if any exclude FAEMB rule is part of the Flex-Algorithm
      definition.
          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
          <bcp14>MUST</bcp14> be pruned from the Flex-Algorithm computation.</t>
      <t>7.  Check
          computation.</li>
          <li>Check if any exclude FAEMD rule is part of the Flex-Algorithm
      definition.
          Definition.  If such exclude rule exists and the link has Min
          Unidirectional link delay Link Delay advertised, check if the link delay
          satisfies the FAEMD rule. If the link does not satisfy the FAEMD
          rule, the link MUST <bcp14>MUST</bcp14> be pruned from the Flex-Algorithm computation.</t>

  </list>
  </t>
          computation.</li>
        </ol>
      </section>
       <section anchor="ack" numbered="false" toc="default">
      <name>Acknowledgements</name>
      <t>Many thanks to <contact fullname="Chris Bowers"/>, <contact
      fullname="Krzysztof Szarcowitz"/>, <contact fullname="Julian Lucek"/>,
      <contact fullname="Ram Santhanakrishnan"/>, <contact fullname="Ketan
      Talaulikar"/>, and <contact fullname="Acee Lindem"/> for discussions and
      input.</t>
    </section>
        <section numbered="false" toc="default">
      <name>Contributors</name>

    <contact fullname="Salih K.A.">
      <organization>Juniper Networks</organization>
      <address>
        <email>salih@juniper.net</email>
      </address>
    </contact>
    </section>
</middle>

<back>
  <references title='Normative References'>

    &RFC2119;
	&RFC8174;
    &RFC5305;
    &RFC3630;
    &RFC7684;
    &RFC9479;
    &RFC9492;
    &RFC8362;
	&RFC9350;
    &RFC9356;
	&RFC5392;
    &RFC5329;
    &RFC8668;
	&RFC1195;
	&RFC2328;

	<reference anchor="IEEE754">
    <front>
      <title>IEEE Standard

<!-- [rfced] Please review whether any of the notes in this document
should be in the <aside> element. It is defined as "a container for Floating-Point Arithmetic</title>
        <author>
          <organization>Institute
content that is semantically less important or tangential to the
content that surrounds it" (https://authors.ietf.org/en/rfcxml-vocabulary#aside).
-->

<!-- [rfced] Terminology

a) Throughout the text, the following terminology appears to be used
inconsistently. Please review these occurrences and let us know if/how
they may be made consistent.

 Bandwidth metric type  vs. bandwidth metric calculation
   (Should "bandwidth metric calculation" be "Bandwidth metric calculation"
   to match "Bandwidth metric type"?)

 metric-type vs. metric type

 Minimum Bandwidth value vs. Minimum bandwidth advertised
   (Are these terms different or should "bandwidth" be uppercase
   for consistency?)

 Maximum Delay constraint vs. Maximum delay advertised
   (Are these terms different or should "delay" be uppercase
   for consistency?

 Min Delay value (used once in this document)
    Is this the intended term or should it perhaps be
    "Minimum Delay value" or "Min Unidirectional Link Delay
    value"?

b) We updated the document to reflect the forms on the right for consistency.
Please let us know of Electrical any objections.

 Bandwidth metric -> Bandwidth Metric
 bytes-per-second -> bytes per second
 Flex-algorithm -> Flex-Algorithm (per RFC 9350)
 Flex-Algorithm definition -> Flex Algorithm Definition (per RFC 9350)

 Flexible Algorithm Definition Bandwidth Thresholds ->
    Flexible Algorithm Definition Bandwidth Threshold (singular)

 Generic metric -> Generic Metric (for consistency and Electronics Engineers</organization>
        </author>
      <date day="22" month="July" year="2019"/>
    </front>
    <seriesInfo name="IEEE" value="754-2019"/>
    <seriesInfo name="DOI" value="10.1109/ieeestd.2019.8766229"/>
    <format target="https://ieeexplore.ieee.org/document/8766220" type="HTML"/>
    </reference>

  </references>

   <references title='Informative References'>
    &RFC8570;
    &RFC7471;
    &RFC5311;
    &RFC9346;
    &RFC5120;
	&RFC5715;
	&RFC4655;
	<?rfc include="reference.I-D.ietf-lsr-ospf-yang-augmentation-v1"?>
    <?rfc include="reference.I-D.ietf-lsr-isis-yang-augmentation-v1"?>

   <?rfc include="reference.I-D.bashandy-rtgwg-segment-routing-uloop"?>

  </references> per IANA)
 IGP metric -> IGP Metric (per RFC 9350 and IANA)
 ISIS -> IS-IS
 interface group mode -> Interface Group Mode
 L-Flag -> L-flag (per RFC 9350)
 layer-2 -> Layer 2
 layer-3 -> Layer 3
 Max link delay -> Max Link Delay

 Min Unidirectional link delay and Minimum Unidirectional Link Delay ->
    Min Unidirectional Link Delay (per RFC 9350)

 Minimum link bandwidth -> Minimum Link Bandwidth
 nexthops -> next hops
 Reference Bandwidth Field -> Reference Bandwidth field

c) Should "simple mode" be made uppercase to match "Interface Group Mode"
since they are both listed as automatic metric calculation modes?
-->

<!-- [rfced] Abbreviations

a) FYI - We have added expansions for the following abbreviations
per Section 3.6 of RFC 7322 ("RFC Style Guide"). Please review each
expansion in the document carefully to ensure correctness.

 Area Border Router (ABR)
 Link Aggregation Group (LAG)
 Link State Advertisement (LSA)
 Link State Protocol Data Unit (LSPDU)

b) We made the following change to follow use in RFC 9350. Please let us
know of any objections.

 Flex-Algorithm Definition (FAD) -> Flexible Algorithm Definition (FAD)
-->

<!-- [rfced] Please review the "Inclusive Language" portion of the online
Style Guide <https://www.rfc-editor.org/styleguide/part2/#inclusive_language>
and let us know if any changes are needed.  Updates of this nature typically
result in more precise language, which is helpful for readers.

Note that our script did not flag any words in particular, but this should
still be reviewed as a best practice.
-->

  </back>
</rfc>