<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc toc="yes"?>
<?rfc tocompact="yes"?>
<?rfc tocdepth="3"?>
<?rfc tocindent="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<rfc category="std" docName="draft-ietf-idr-bgp-ls-flex-algo-ext-01"
     ipr="trust200902">
  <front>
    <title abbrev="Flexible Algorithm Extn in BGP-LS">Advertising Flexible
    Algorithm Extensions in BGP Link-State</title>

    <author fullname="Shraddha Hegde" initials="S." surname="Hegde">
      <organization>Juniper Networks Inc.</organization>

      <address>
        <postal>
          <street>Exora Business Park</street>

          <city>Bangalore</city>

          <region>KA</region>

          <code>560103</code>

          <country>India</country>
        </postal>

        <email>shraddha@juniper.net</email>
      </address>
    </author>

    <author fullname="Aravind Babu MahendraBabu" initials="A."
            surname="MahendraBabu">
      <organization>Cisco Systems</organization>

      <address>
        <postal>
          <street/>

          <city/>

          <region/>

          <code/>

          <country>India</country>
        </postal>

        <email>aramahen@cisco.com</email>
      </address>
    </author>

    <author fullname="Ketan Talaulikar" initials="K." surname="Talaulikar">
      <organization>Cisco Systems</organization>

      <address>
        <postal>
          <street/>

          <city/>

          <region/>

          <code/>

          <country>India</country>
        </postal>

        <email>ketant.ietf@gmail.com</email>
      </address>
    </author>

    <author fullname="Peter Psenak" initials="P." surname="Psenak">
      <organization>Cisco Systems</organization>

      <address>
        <postal>
          <street/>

          <city/>

          <region/>

          <code/>

          <country>Slovakia</country>
        </postal>

        <email>ppsenak@cisco.com</email>
      </address>
    </author>

    <author fullname="Bruno Decraene" initials="B." surname="Decraene">
      <organization>Orange</organization>

      <address>
        <postal>
          <street/>

          <city/>

          <region/>

          <code/>

          <country>France</country>
        </postal>

        <email>bruno.decraene@orange.com</email>
      </address>
    </author>

    <date year=""/>

    <area>Routing</area>

    <workgroup>Inter-Domain Routing</workgroup>

    <keyword>BGP-LS</keyword>

    <keyword>Segment Routing</keyword>

    <keyword>IS-IS</keyword>

    <keyword>OSPF</keyword>

    <keyword>OSPFv3</keyword>

    <abstract>
      <t>Flexible Algorithm is a solution that allows some routing protocols
      (IS-IS and OSPF) to compute paths over a network based on
      user-defined (and hence, flexible) constraints and metrics. The
      computation is performed by routers participating in the specific
      network in a distributed manner using a Flexible Algorithm Definition.
      This Definition is provisioned on one or more routers and propagated
      through the network by IS-IS and OSPF flooding.</t>

      <t>BGP Link-State (BGP-LS) enables the collection of various topology
      information from the network. BGP-LS supports the advertisement of
      Flexible Algorithm Definition and other Flexible Algorithm related
      advertisements as a part of the topology information from the network.
      This document specifies the advertisement of further Flexible Algorithm
      related extensions in BGP-LS.</t>
    </abstract>
  </front>

  <middle>
    <section anchor="INTRO" title="Introduction">
      <t>Flexible Algorithm is a solution that allows some routing protocols
      (IS-IS and OSPF) to compute paths over a network based on
      user-defined (and hence, flexible) constraints and metrics. The
      computation is performed by routers participating in the specific
      network in a distributed manner using a Flexible Algorithm Definition.
      This Definition is provisioned on one or more routers and propagated
      through the network by IS-IS and OSPF flooding. <xref target="RFC9350"/>
      defines the base Flexible Algorithm solution that allows IGPs themselves
      to compute constraint-based paths over the network.</t>

      <t>The extensions to BGP-LS <xref target="RFC9552"/> for the
      advertisement of the Flexible Algorithm Definition (FAD) information to
      enable learning of the mapping of the flexible algorithm number to its
      Definition in each area/domain of the underlying IGPs are defined in
      <xref target="RFC9351"/>.</t>

      <t>This document defines further extensions to BGP-LS for Flexible
      Algorithm as below: <list style="symbols">
          <t>The extensions to the Flexible Algorithm so that it can be used
          with the regular IPv4 and IPv6 forwarding as defined for IGPs in
          <xref target="RFC9502"/>.</t>

          <t>The Flexible Algorithm Definition that is used to exclude based
          on bandwidth and metric constraints and to automatically calculate
          metrics for use in SPF calculation as defined for IGPs in <xref
          target="RFC9843"/>.</t>

          <t>The Flexible Algorithm Definition that is used to include/exclude
          links in the reverse direction of the traffic flow for SPF
          calculation as defined for IGPs in <xref
          target="I-D.ietf-lsr-igp-flex-algo-reverse-affinity"/>.</t>
        </list></t>

      <section 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>
      </section>
    </section>

    <section anchor="IPA" title="Advertising IP Algorithm Participation">
      <t>The IP Algorithm TLV is a BGP-LS Node Attribute TLV associated with
      the Node NLRI that is used for the algorithms associated with a given
      node. The format of this TLV is as follows:</t>

      <figure align="left" anchor="FIGIPA" title="IP Algorithm TLV">
        <artwork align="left"><![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           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|   Algorithm 1 | Algorithm ... |  Algorithm n  |              //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

]]></artwork>
      </figure>

      <t>Where:</t>

      <t><list style="symbols">
          <t>Type: TBA1</t>

          <t>Length: Variable</t>

          <t>Algorithm: Single octet algorithm value between 128 and 255
          inclusive.</t>
        </list></t>

      <t>The IP Algorithm TLV is derived from the following IGP
      protocol-specific advertisements:<list style="symbols">
          <t>In the case of IS-IS, from the IS-IS IP Algorithm sub-TLV defined
          in <xref target="RFC9502"/>.</t>

          <t>In the case of OSPFv2/OSPFv3, from the OSPF IP Algorithm sub-TLV
          defined in <xref target="RFC9502"/>.</t>
        </list></t>

      <t>The IP Algorithm TLV is optional and it MUST NOT be advertised more
      than once in the BGP-LS Attribute. If multiple instances are present,
      then the first one MUST be considered valid, and the rest MUST be
      ignored.</t>
    </section>

    <section anchor="IPAREACH" title="Advertising IP Algorithm Reachability">
      <t>The normal or base (i.e., algorithm 0) prefix reachabilities are done
      using the BGP-LS IPv4/IPv6 Topology Prefix NLRIs defined in <xref
      target="RFC9552"/> along with its associated IGP metric carried within
      the IGP Metric TLV (TLV 1095) in the BGP-LS Attribute associated with
      the NLRI. The presence of IGP Metric TLV is what identifies the
      base/normal prefix reachability.</t>

      <t>The IP algorithm-specific reachability advertisements are also done
      using the BGP-LS IPv4/IPv6 Topology Prefix NLRIs. However, these
      algorithm-specific advertisements MUST NOT carry an IGP Metric TLV along
      with them. Instead, the metric associated with the IP algorithm-specific
      prefix reachability is carried within the TLVs introduced in the
      following subsections.</t>

      <t>A BGP-LS Consumer receiving an IPv4/IPv6 Topology Prefix NLRI
      advertisement that carries both an IGP Metric TLV along with any of the
      TLVs introduced in the following subsections, MUST consider it as a
      normal (i.e., algorithm 0) prefix reachability advertisement and MUST
      ignore all TLVs corresponding to algorithm-specific prefix reachability
      advertisements.</t>

      <t>The IP Algorithm Prefix Reachability TLV is a BGP-LS Prefix Attribute
      TLV associated with the IPv4/IPv6 Topology Prefix NLRI that is used for
      the advertisement of the algorithm-specific prefix reachability from a
      given node. The format of this TLV is as follows:</t>

      <figure align="left" anchor="FIGIPAPFX"
              title="IP Algorithm Prefix Reachability TLV">
        <artwork align="left"><![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    |  Algorithm    |            Reserved           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                           Metric                              |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

]]></artwork>
      </figure>

      <t>Where:</t>

      <t><list style="symbols">
          <t>Type: TBA2</t>

          <t>Length: 8</t>

          <t>Flags: 1 octet of flags. The flags are copied from the IS-IS
          IPv4/IPv6 Algorithm Prefix Reachability TLV <xref target="RFC9502"/>
          or the OSPFv2/OSPFv3 IP Algorithm Prefix Reachability sub-TLV <xref
          target="RFC9502"/> in the case of IS-IS or OSPFv2/OSPFv3
          respectively.</t>

          <t>Algorithm: 1 octet value providing the Associated Algorithm from
          128 to 255.</t>

          <t>Reserved: 2 octet value that MUST be set to 0 by the originator
          and ignored by the receiver.</t>

          <t>Metric: The algorithm-specific metric value.</t>

        </list></t>

      <t>The IP Algorithm Prefix Reachability TLV is derived from the
      following IGP protocol-specific advertisements:</t>

      <t><list style="symbols">
          <t>In the case of IS-IS, from the IS-IS IPv4/IPv6 Algorithm Prefix
          Reachability TLV defined in <xref target="RFC9502"/>. The sub-TLVs
          are encoded using the BGP-LS Attribute TLVs defined for the
          IPv4/IPv6 Topology Prefix NLRI.</t>

          <t>In the case of OSPF, from the OSPFv2/OSPFv3 IP Algorithm Prefix
          Reachability sub-TLV defined in <xref target="RFC9502"/>.</t>
        </list></t>

      <t>The Multi-topology ID (MTID) associated with the underlying IGP
      advertisements is encoded using the Multi-Topology Identifier TLV (TLV
      263) <xref target="RFC9552"/> as a Prefix Descriptor TLV when the
      advertisement is associated with a non-default topology. The IP Prefix
      value itself is encoded using the IP Reachability Information TLV (TLV
      265) <xref target="RFC9552"/> as a Prefix Descriptor TLV.</t>

      <t>The IP Algorithm Prefix Reachability TLV MUST NOT be advertised more
      than once in the BGP-LS Attribute. If multiple instances are present,
      then the first one MUST be considered valid, and the rest MUST be
      ignored.</t>
    </section>

    <section anchor="GENMET" title="Advertising Generic Metric for Links">
      <t>The Generic Metric TLV is a BGP-LS Link Attribute TLV associated with
      the Link NLRI that is used for the advertisement of the generic
      metric(s) associated with a link. The format of this TLV is as
      follows:</t>

      <figure align="left" anchor="FIGGENMET" title="Generic Metric TLV">
        <artwork align="left"><![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                    |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                            Metric                             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

]]></artwork>
      </figure>

      <t>Where:</t>

      <t><list style="symbols">
          <t>Type: TBA3</t>

          <t>Length: 8.</t>

          <t>Metric Type: 1 octet that carries a metric type from the IGP
          Metric Type registry</t>

          <t>Reserved: 3 octet value that MUST be set to 0 by the originator
          and ignored by the receiver.</t>

          <t>Metric: 4-octet field carrying the metric value. In the case of
          IS-IS, the value MUST be in the range of 0 - 16,777,215.</t>
        </list></t>

      <t>The Generic Metric TLV is derived from the following IGP
      protocol-specific advertisements:</t>

      <t><list style="symbols">
          <t>In the case of IS-IS, from the IS-IS Generic Metric sub-TLV
          defined in <xref target="RFC9843"/>.</t>

          <t>In the case of OSPF, from the OSPF Generic Metric sub-TLV defined
          in <xref target="RFC9843"/>.</t>
        </list></t>

      <t>The advertisement of the Generic Metric TLV as a top-level TLV or as
      a sub-TLV of the BGP-LS ASLA TLV <xref target="RFC9294"/> in the BGP-LS
      Attribute associated with the Link NLRI is based on the encoding in the
      underlying IGP advertisement.</t>

      <t>The Generic Metric TLV MAY be advertised more than once in the BGP-LS
      Attribute, one for each metric type. If multiple instances are present
      for the same metric type, then the first one MUST be considered valid,
      and the rest MUST be ignored.</t>
    </section>

    <section anchor="FADTLVEXT"
             title="Advertising Flexible Algorithm Definition Extensions">
      <t><xref target="RFC9351"/> introduced the Flexible Algorithm Definition
      (FAD) TLV that is advertised in the BGP-LS Attribute along with the Node
      NLRI for the advertisement of the Flexible Algorithm definition
      advertised by a given node in IGPs.</t>

      <t>The following subsections define new sub-TLVs of the FAD TLV to cover
      further extensions of the IGP Flexible Algorithm solution.</t>

      <section anchor="FADMINBW" title="FAD Exclude Minimum Bandwidth Sub-TLV">
        <t>The FAD Exclude Minimum Bandwidth sub-TLV is an optional sub-TLV
        that is used to carry the minimum bandwidth associated with the FAD
        that is used in the computation of the specific algorithm as
        described in <xref target="RFC9843"/>.</t>

        <t>The sub-TLV has the following format:</t>

        <figure align="left" anchor="FIGFADMINBW"
                title="FAD Exclude Minimum Bandwidth sub-TLV">
          <artwork align="left"><![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           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                       Minimum Bandwidth                       |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

]]></artwork>
        </figure>

        <t>Where:</t>

        <t><list style="symbols">
            <t>Type: TBA4</t>

            <t>Length: 4 octets.</t>

            <t>Minimum Bandwidth: The minimum link bandwidth is encoded in 32 bits
            in IEEE floating point format <xref target="IEEE.754-2019"/>. The units 
            are bytes per second.</t>
          </list></t>

        <t>The information in the FAD Exclude Minimum Bandwidth sub-TLV is
        derived from the IS-IS and OSPF protocol-specific FAD Exclude Minimum
        Bandwidth sub-TLVs as defined in <xref
        target="RFC9843"/>.</t>
      </section>

      <section anchor="FADMAXDELAY"
               title="FAD Exclude Maximum Link Delay Sub-TLV">
        <t>The FAD Exclude Maximum Link Delay sub-TLV is an optional sub-TLV
        that is used to carry the maximum link delay information associated
        with the FAD that is used in the computation of the specific algorithm
        as described in <xref target="RFC9843"/>.</t>

        <t>The sub-TLV has the following format:</t>

        <figure align="left" anchor="FIGFADMAXDELAY"
                title="FAD Exclude Maximum Link Delay sub-TLV">
          <artwork align="left"><![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   |               Maximum Link Delay              |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  

]]></artwork>
        </figure>

        <t>Where:</t>

        <t><list style="symbols">
            <t>Type: TBA5</t>

            <t>Length: 4 octets.</t>

            <t>Reserved: 1 octet field that MUST be set to 0 by the originator
            and ignored by the receiver.</t>

            <t>Maximum Link Delay: A 24-bit unsigned integer representing the 
            maximum link delay value in microseconds.</t>
          </list></t>

        <t>The information in the FAD Exclude Maximum Link Delay sub-TLV is
        derived from the IS-IS and OSPF protocol-specific FAD Exclude Maximum
        Link Delay sub-TLVs as defined in <xref
        target="RFC9843"/>.</t>
      </section>

      <section anchor="FADAMCREFBW" title="FAD Reference Bandwidth Sub-TLV">
        <t>The FAD Reference Bandwidth sub-TLV is an optional sub-TLV that is
        used to carry the information needed for the reference bandwidth
        method of metric calculation associated with the FAD that is used in
        the computation of the specific algorithm as described in <xref
        target="RFC9843"/>.</t>

        <t>The sub-TLV has the following format:</t>

        <figure align="left" anchor="FIGFADAMCREFBW"
                title="FAD Reference Bandwidth sub-TLV">
          <artwork align="left"><![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                        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

]]></artwork>
        </figure>

        <t>Where:</t>

        <t><list style="symbols">
            <t>Type: TBA6</t>

            <t>Length: 12 octets.</t>

            <t>Flags: 1 octet of flags. The flags are copied from the IS-IS
            FAD Reference Bandwidth sub-TLV <xref
            target="RFC9843"/> or the OSPF FAD Reference
            Bandwidth sub-TLV <xref target="RFC9843"/>
            in the case of IS-IS or OSPF respectively.</t>

            <t>Reserved: 3 octet field that MUST be set to 0 by the originator
            and ignored by the receiver.</t>

            <t>Reference Bandwidth: The reference bandwidth is encoded in 32
            bits in IEEE floating point format <xref target="IEEE.754-2019"/>. 
            The units are bytes per second.</t>

            <t>Granularity Bandwidth: The granularity bandwidth is encoded in
            32 bits in IEEE floating point format <xref target="IEEE.754-2019"/>. 
            The units are bytes per second.</t>
          </list></t>

        <t>The information in the FAD Reference Bandwidth sub-TLV is derived
        from the IS-IS and OSPF protocol-specific FAD Reference Bandwidth
        sub-TLV as defined in <xref
        target="RFC9843"/>.</t>
      </section>

      <section anchor="FADAMCBWTHR" title="FAD Bandwidth Thresholds Sub-TLV">
        <t>The FAD Bandwidth Thresholds sub-TLV is an optional sub-TLV that is
        used to carry the information needed for the bandwidth threshold method 
        of metric calculation associated with the FAD that is used in the
        computation of the specific algorithm as described in <xref
        target="RFC9843"/>.</t>

        <t>The sub-TLV has the following format:</t>

        <figure align="left" anchor="FIGFADAMCBWTHR"
                title="FAD Bandwidth Thresholds sub-TLV">
          <artwork align="left"><![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 n                       |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                     Threshold Metric n                        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

]]></artwork>
        </figure>

        <t>Where:</t>

        <t><list style="symbols">
            <t>Type: TBA7</t>

            <t>Length: 4 + (n * 8) octets. Here n is equal to the number of
            Threshold Metrics specified. n MUST be greater than or equal to
            1.</t>

            <t>Flags: 1 octet of flags. The flags are copied from the IS-IS
            FAD Bandwidth Thresholds sub-TLV <xref
            target="RFC9843"/> or the OSPF FAD Bandwidth
            Thresholds sub-TLV <xref target="RFC9843"/>
            in the case of IS-IS or OSPF respectively.</t>

            <t>Reserved: 3 octet field that MUST be set to 0 by the originator
            and ignored by the receiver.</t>

            <t>Bandwidth Threshold (1 ... n): The bandwidth threshold is
            encoded in 32 bits in IEEE floating point format <xref 
            target="IEEE.754-2019"/>. The units are bytes per second.</t>

            <t>Threshold Metric (1 ... n): 4 octet field carrying the
            threshold metric value. In the case of IS-IS, the value MUST be in
            the range of 0 - 16,777,215.</t>
          </list></t>

        <t>The information in the FAD Bandwidth Thresholds sub-TLV is derived
        from the IS-IS and OSPF protocol-specific FAD Bandwidth Thresholds
        sub-TLV as defined in <xref
        target="RFC9843"/>.</t>
      </section>

      <section anchor="FADAFFINITYEXCLANYREV"
               title="Flexible Algorithm Exclude-Any Reverse Affinity Sub-TLV">
        <t>The Flexible Algorithm Exclude-Any Reverse Affinity sub-TLV is an
        optional sub-TLV that is used to carry the reverse affinity
        constraints associated with the FAD and enable the exclusion of links
        carrying any of the specified affinities from the computation of the
        specific algorithm as described in <xref
        target="I-D.ietf-lsr-igp-flex-algo-reverse-affinity"/>. The affinity
        is expressed in terms of Extended Admin Group (EAG) as defined in
        <xref target="RFC7308"/>.</t>

        <t>The sub-TLV has the following format:</t>

        <figure align="left" anchor="FIGFADAFFINITYEXCLANYREV"
                title="Flexible Algorithm Exclude-Any Reverse Affinity sub-TLV">
          <artwork align="left"><![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           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|           Exclude-Any Reverse EAG (variable)                 //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  

]]></artwork>
        </figure>

        <t><list style="symbols">
            <t>Type: TBA8</t>

            <t>Length: The total length of the value field in octets dependent
            on the size of the EAG. It MUST be a non-zero value and a multiple
            of 4.</t>

            <t>Exclude-Any Reverse EAG: the EAG value.</t>
          </list></t>

        <t>The information in the Flexible Algorithm Exclude Any Reverse
        Affinity sub-TLV is derived from the IS-IS and OSPF protocol-specific
        Flexible Algorithm Exclude Admin Group sub-TLV as defined in <xref
        target="I-D.ietf-lsr-igp-flex-algo-reverse-affinity"/>.</t>
      </section>

      <section anchor="FADAFFINITYINCLANYREV"
               title="Flexible Algorithm Include-Any Reverse Affinity Sub-TLV">
        <t>The Flexible Algorithm Include-Any Reverse Affinity sub-TLV is an
        optional sub-TLV that is used to carry the affinity constraints
        associated with the FAD and enable the inclusion of links carrying any
        of the specified affinities in the computation of the specific
        algorithm as described in <xref
        target="I-D.ietf-lsr-igp-flex-algo-reverse-affinity"/>. The affinity
        is expressed in terms of Extended Admin Group (EAG) as defined in
        <xref target="RFC7308"/>.</t>

        <t>The sub-TLV has the following format:</t>

        <figure align="left" anchor="FIGFADAFFINITYINCANYREV"
                title="Flexible Algorithm Include-Any Reverse Affinity sub-TLV">
          <artwork align="left"><![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           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|         Include-Any Reverse EAG (variable)                   //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  

]]></artwork>
        </figure>

        <t>Where:</t>

        <t><list style="symbols">
            <t>Type: TBA9</t>

            <t>Length: The total length of the value field in octets dependent
            on the size of the EAG. It MUST be a non-zero value and a multiple
            of 4.</t>

            <t>Include-Any EAG: the EAG value.</t>
          </list></t>

        <t>The information in the Flexible Algorithm Include-Any Reverse
        Affinity sub-TLV is derived from the IS-IS and OSPF protocol-specific
        Flexible Algorithm Include-Any Reverse Admin Group sub-TLV as defined
        in <xref target="I-D.ietf-lsr-igp-flex-algo-reverse-affinity"/>.</t>
      </section>

      <section anchor="FADAFFINITYINCLALLREV"
               title="Flexible Algorithm Include-All Reverse Affinity Sub-TLV">
        <t>The Flexible Algorithm Include-All Reverse Affinity sub-TLV is an
        optional sub-TLV that is used to carry the affinity constraints
        associated with the FAD and enable the inclusion of links carrying all
        of the specified affinities in the computation of the specific
        algorithm as described in <xref
        target="I-D.ietf-lsr-igp-flex-algo-reverse-affinity"/>. The affinity
        is expressed in terms of Extended Admin Group (EAG) as defined in
        <xref target="RFC7308"/>.</t>

        <t>The sub-TLV has the following format:</t>

        <figure align="left" anchor="FIGFADAFFINITYINCALLREV"
                title="Flexible Algorithm Include-All Reverse Affinity sub-TLV">
          <artwork align="left"><![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           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|         Include-All Reverse EAG (variable)                   //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  

]]></artwork>
        </figure>

        <t>Where:</t>

        <t><list style="symbols">
            <t>Type: TBA10</t>

            <t>Length: The total length of the value field in octets dependent
            on the size of the EAG. It MUST be a non-zero value and a multiple
            of 4.</t>

            <t>Include-All EAG: the EAG value.</t>
          </list></t>

        <t>The information in the Flexible Algorithm Include-All Reverse
        Affinity sub-TLV is derived from the IS-IS and OSPF protocol-specific
        Flexible Algorithm Include-All Reverse Admin Group sub-TLV as defined
        in <xref target="I-D.ietf-lsr-igp-flex-algo-reverse-affinity"/>.</t>
      </section>
    </section>

    <section anchor="IANA" title="IANA Considerations">
      <t>This document requests IANA to allocate code points from the "BGP-LS
      NLRI and Attribute TLVs" sub-registry of the "Border Gateway Protocol -
      Link-State (BGP-LS) Parameters" registry group.</t>

      <figure align="left" anchor="IANACP"
              title="BGP-LS Flexible Algorithm Extensions Code Points">
        <artwork align="left"><![CDATA[
+--------+------------------------------------------+---------------+
| Code   |                                          |               |
| Point  |         Description                      |   Reference   |
+--------+------------------------------------------+---------------+
|  TBA1  | IP Algorithm                             | this document |
|  TBA2  | IP Algorithm Prefix Reachability         | this document |
|  TBA3  | Generic Metric                           | this document |
|  TBA4  | Flexible Algorithm Exclude               | this document |
|        | Minimum Bandwidth                        |               | 
|  TBA5  | Flexible Algorithm Exclude               | this document |
|        | Maximum Link Delay                       |               |
|  TBA6  | Flexible Algorithm Reference Bandwidth   | this document |
|  TBA7  | Flexible Algorithm Bandwidth Thresholds  | this document |
|  TBA8  | Flexible Algorithm Exclude Any Reverse   | this document |
|        | Affinity                                 |               |
|  TBA9  | Flexible Algorithm Include Any Reverse   | this document |
|        | Affinity                                 |               |
|  TBA10 | Flexible Algorithm Include All Reverse   | this document |
|        | Affinity                                 |               |
+--------+------------------------------------------+---------------+

]]></artwork>
      </figure>
    </section>

    <section anchor="Manageability" title="Manageability Considerations">
      <t>This document does not introduce any new manageability considerations
      beyond those covered by <xref target="RFC9351"/>.</t>
    </section>

    <section anchor="Security" title="Security Considerations">
      <t>This document does not introduce any new security considerations
      beyond those covered by <xref target="RFC9351"/>.</t>
    </section>

    <section anchor="Acknowledgements" title="Acknowledgements">
      <t>The authors would like to thank John Scudder for his review and
      comments on this document.</t>
    </section>
  </middle>

  <back>
    <references title="Normative References">
      <?rfc include="reference.IEEE.754-2019.xml"?>

      <?rfc include="reference.RFC.2119"?>

      <?rfc include="reference.RFC.8174"?>

      <?rfc include='reference.RFC.9552'?>

      <?rfc include='reference.RFC.9294'?>

      <?rfc include='reference.RFC.9350'?>

      <?rfc include='reference.RFC.9351'?>

      <?rfc include='reference.RFC.9843'?>

      <?rfc include='reference.RFC.9502'?>

      <?rfc include='reference.I-D.ietf-lsr-igp-flex-algo-reverse-affinity'?>
    </references>

    <references title="Informative References">
      <?rfc include='reference.RFC.7308'?>
    </references>
  </back>
</rfc>
