<?xml version="1.0" encoding="US-ASCII"?>
<?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"?> encoding="UTF-8"?>

<!DOCTYPE rfc [
  <!ENTITY nbsp    "&#160;">
  <!ENTITY zwsp   "&#8203;">
  <!ENTITY nbhy   "&#8209;">
  <!ENTITY wj     "&#8288;">
]>

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

  <front>
    <title abbrev="IP Flex-Algorithm">IGP abbrev="IGP IP Flexible Algorithms (Flex-Algorithm)
    In Algorithm">IGP Flexible Algorithm in IP
    Networks</title>
    <seriesInfo name="RFC" value="9502"/>
    <author fullname="William Britto" initials="W." surname="Britto">
      <organization>Juniper Networks</organization>
      <address>
        <postal>
          <street>Elnath-Exora Business Park Survey</street>
          <city>Bangalore</city>
          <region>Karnataka</region>
          <code>560103</code>
          <country>India</country>
        </postal>
        <email>bwilliam@juniper.net</email>
      </address>
    </author>
    <author fullname="Shraddha Hegde" initials="S." surname="Hegde">
      <organization>Juniper Networks</organization>
      <address>
        <postal>
          <street>Elnath-Exora Business Park Survey</street>
          <city>Bangalore</city>
          <region>Karnataka</region>
          <code>560103</code>
          <country>India</country>
        </postal>
        <email>shraddha@juniper.net</email>
      </address>
    </author>
    <author fullname="Parag Kaneriya " initials="P." surname="Kaneriya">
      <organization>Juniper Networks</organization>
      <address>
        <postal>
          <street>Elnath-Exora Business Park Survey</street>
          <city>Bangalore</city>
          <region>Karnataka</region>
          <code>560103</code>
          <country>India</country>
        </postal>
        <email>pkaneria@juniper.net</email>
      </address>
    </author>
    <author fullname="Rejesh Shetty" initials="R." surname="Shetty">
      <organization>Juniper Networks</organization>
      <address>
        <postal>
          <street>Elnath-Exora Business Park Survey</street>
          <city>Bangalore</city>
          <region>Karnataka</region>
          <code>560103</code>
          <country>India</country>
        </postal>
        <email>mrajesh@juniper.net</email>
      </address>
    </author>
    <author fullname="Ron Bonica" initials="R." surname="Bonica">
      <organization>Juniper Networks</organization>
      <address>
        <postal>
          <street>2251 Corporate Park Drive</street>
          <city>Herndon</city>
          <code>20171</code>
          <region>Virginia</region>

          <country>USA</country>
          <country>United States of America</country>
        </postal>
        <email>rbonica@juniper.net</email>
      </address>
    </author>
    <author fullname="Peter Psenak" initials="P." surname="Psenak">
      <organization>Cisco Systems</organization>
      <address>
        <postal>
          <street>Apollo
          <extaddr>Apollo Business Center</street> Center</extaddr>
          <street>Mlynske nivy 43</street>
          <city>Bratislava</city>
          <code>82109</code>
          <country>Slovakia</country>
        </postal>
        <email>ppsenak@cisco.com</email>
      </address>
    </author>

    <date/>

    <area>Routing Area</area>

    <workgroup>LSR Working Group</workgroup>
    <date year="2023" month="November"/>
    <area>rtg</area>
    <workgroup>lsr</workgroup>
    <keyword>IS-IS</keyword>

    <keyword>Draft</keyword>
    <abstract>
      <t>This document extends IGP Flex-Algorithm, Flexible Algorithm so that it can be used with
      regular IPv4 and IPv6 forwarding.</t>
    </abstract>
  </front>
  <middle>
    <section title="Introduction">
    <section>
      <name>Introduction</name>
      <t>An IGP Flexible Algorithm (Flex-Algorithm) allows IGPs to compute
      constraint-based paths. The base IGP Flex-Algorithm Flexible Algorithm specification
      describes how it is used with Segment Routing (SR) data planes - planes: SR MPLS and
      SRv6.</t>
      <t>An IGP Flex-Algorithm Flexible Algorithm as specified in <xref target="RFC9350"/>
      computes a constraint-based path to:
      <list style="symbols">
          <t>All Flex-Algorithm specific
      </t>
      <ul spacing="normal">
        <li>All Flexible-Algorithm-specific Prefix Segment Identifiers (SIDs)
        <xref target="RFC8402"/>.</t>

          <t>All Flex-Algorithm specific target="RFC8402"/>.</li>
        <li>All Flexible-Algorithm-specific SRv6 Locators <xref
          target="RFC8986"/>.</t>
        </list>Therefore, Flex-Algorithm
        target="RFC8986"/>.</li>
      </ul>
      <t>Therefore, Flexible Algorithm cannot be deployed in the absence of
      SR or SRv6.</t>
      <t>This document extends Flex-Algorithm, Flexible Algorithm, allowing it to compute paths
      to IPv4 and IPv6 prefixes.</t>
    </section>
    <section anchor="ReqLang" title="Requirements Language">
      <t>The anchor="ReqLang">
      <name>Requirements Language</name>
        <t> The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
      "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", "<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
      "OPTIONAL" "<bcp14>OPTIONAL</bcp14>" in this document
        are to be interpreted as described in BCP&nbsp;14 <xref
      target="RFC2119">BCP 14</xref>
        target="RFC2119"/> <xref target="RFC8174"/> when, and only when, they
        appear in all capitals, as shown here.</t> here.
        </t>
    </section>

    <section title="Use
    <section>
      <name>Use Case Example"> Example</name>
      <t>In this subsection, section, we illustrate one use case that motivates this
      specification: if a specific service can be identified by an IP
      address, traffic to it can use constraint-based paths computed
      according to this specification.</t>
      <t> The System Architecture architecture for the 5G System <xref
      target="TS.23.501-3GPP"/> describes the N3 interface between gNodeB and
      UPF (User Plane Function).</t>
      <t>Mobile networks are becoming more and more IP centric. IP-centric. Each end-user
      session from a gNodeB can be destined to a specific UPFs (User Plane Function) UPF based on the
      session requirements. For example, some sessions require high bandwidth,
      while others need to be routed along the lowest latency path. Each UPF is
      assigned a unique IP address. As a result, traffic for different
      sessions is destined to a different destination IP address.</t>
      <t>The IP address allocated to the UPF can be associated with an
      algorithm. The mobile user traffic is then forwarded along the path
      based on the algorithm-specific metric and constraints. As a result,
      traffic can be sent over a path that is optimized for minimal latency or
      highest bandwidth. This mechanism is used to achieve SLA
      (Service Service Level Agreement)
      Agreement (SLA) appropriate for a user session.</t>
    </section>

    <section title="Advertising Flex-Algorithm
    <section>
      <name>Advertising Flexible Algorithm Definitions (FAD)"> (FADs)</name>
      <t>To guarantee loop-free forwarding, all routers that participate in a
      Flex-Algorithm MUST <bcp14>MUST</bcp14> agree on the Flex-Algorithm Flexible Algorithm Definition (FAD).</t>
      <t>Selected nodes within the IGP domain MUST <bcp14>MUST</bcp14> advertise
      FADs as described in Sections 5, 6, <xref target="RFC9350" section="5"
      sectionFormat="bare"/>, <xref target="RFC9350" section="6"
      sectionFormat="bare"/>, and 7 <xref target="RFC9350" section="7"
      sectionFormat="bare"/> of <xref target="RFC9350"/>.</t>
    </section>
    <section anchor="PARTICIPATION"
             title="Advertising anchor="PARTICIPATION">
      <name>Advertising IP Flex-Algorithm Participation"> Flexible Algorithm Participation</name>
      <t>A node may use various algorithms when calculating paths to nodes and
      prefixes. Algorithm values are defined in the <xref
      target="IANA-ALG">IGP target="IANA-ALG">"IGP Algorithm Type Registry Types" registry </xref>.</t>
      <t>Only a node that is participating in a Flex-Algorithm is:</t>

      <t><list style="symbols">
          <t>Able
      <ul spacing="normal">
        <li>Able to compute a path for such Flex-Algorithm</t>

          <t>Part Flex-Algorithm</li>
        <li>Part of the topology for such Flex-Algorithm</t>
        </list></t>

      <t>Flex-Algorithm Flex-Algorithm</li>
      </ul>
      <t>Flexible Algorithm participation MUST <bcp14>MUST</bcp14> be advertised for
      each
      Flex-Algorithm data-plane Flexible Algorithm data plane independently, as specified in <xref
      target="RFC9350"/>. Using Flex-Algorithm Flexible Algorithm for regular IPv4 and IPv6
      prefixes represents an independent Flex-Algorithm
      data-plane, and Flexible Algorithm data plane; as
      such, the Flex-Algorithm Flexible Algorithm participation for the IP Flex-Algorithm
      data-plane MUST Flexible Algorithm
      data plane <bcp14>MUST</bcp14> be signalled signaled independently of any other Flex-Algorithm
      data-plane
      Flexible Algorithm data plane (e.g., SR).</t>
      <t>All routers in an IGP domain participate in default algorithm 0.
	  Advertisement of participation in IP Flex-Algorithm Flexible Algorithm does not impact
      the router participation in default algorithm 0.
      </t>
      <t>Advertisement of participation in IP Flex-Algorithm Flexible Algorithm does not impact
      the router participation signaled for other data-planes. data planes. For example,
	  it is possible that a router participates in a particular flex-algo Flex-Algorithm
	  for the IP data-plane data plane but does not participate in the
	  same flex-algo Flex-Algorithm for the SR data-plane.</t> data plane.</t>
      <t>The following sections describe how the IP Flex-Algorithm Flexible Algorithm participation
      is advertised in IGP protocols.</t>
      <section anchor="IS-IS-ALG_TLV" title="The anchor="IS-IS-ALG_TLV">
        <name>The IS-IS IP Algorithm Sub-TLV"> Sub-TLV</name>
        <t>The IS-IS <xref target="ISO10589"/> IP Algorithm Sub-TLV is a
        sub-TLV of the IS-IS Router Capability TLV <xref target="RFC7981"/>
        and has the following format:
        </t>
        <figure align="center" anchor="ISISAlg"
            title="IS-IS align="center">
          <name>IS-IS IP Algorithm Sub-TLV">
            <artwork><![CDATA[ Sub-TLV</name>
          <artwork align="center"><![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 2  | Algorithm ... |  Algorithm n  |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
        </figure> <list style="symbols">
            <t>Type
        <dl spacing="normal" newline="false">
          <dt>Type (1 octet): IP octet):</dt> <dd>IP Algorithm Sub-TLV (Value 29)</t>

            <t>Length 29)</dd>
          <dt>Length (1 octet): Variable</t>

            <t>Algorithm octet):</dt> <dd>Variable</dd>
          <dt>Algorithm (1 octet): Value octet):</dt> <dd>Value from 128 to 255.</t>
          </list></t> 255</dd>
        </dl>
        <t>The IP Algorithm Sub-TLV MUST <bcp14>MUST</bcp14> be propagated
        throughout the level and MUST NOT <bcp14>MUST NOT</bcp14> be advertised across
        level boundaries. Therefore, the S bit in the Router Capability TLV,
        in which the IP Algorithm Sub-TLV is advertised, MUST NOT <bcp14>MUST
        NOT</bcp14> be set.</t>
        <t>The IP Algorithm Sub-TLV is optional. It MUST NOT <bcp14>MUST NOT</bcp14> be
        advertised more than once at a given level. A router receiving
        multiple IP Algorithm sub-TLVs from the same originator MUST
        <bcp14>MUST</bcp14> select the first advertisement in the
        lowest-numbered LSP Link State PDU (LSP), and subsequent instances of the IP Algorithm
        Sub-TLV MUST <bcp14>MUST</bcp14> be ignored.</t>
        <t>Algorithms outside the Flex-Algorithm range (128-255) MUST
        <bcp14>MUST</bcp14> be ignored by the receiver. This situation SHOULD
        <bcp14>SHOULD</bcp14> be logged as an error.</t>
        <t>The IP Flex-Algorithm participation advertised in the IS-IS IP
        Algorithm Sub-TLV is topology independent. When a router advertises
        participation in the IS-IS IP Algorithm Sub-TLV, the participation
        applies to all topologies in which the advertising node
        participates.</t>
      </section>
      <section anchor="OSPF-ALG_TLV" title="The anchor="OSPF-ALG_TLV">
        <name>The OSPF IP Algorithm TLV"> TLV</name>
        <t>The OSPF <xref target="RFC2328"/> IP Algorithm TLV is a top-level
        TLV of the
        <xref target="RFC7770"> Router Information Opaque LSA</xref> Link State Advertisement (LSA)
        <xref target="RFC7770"/> and has the following format: </t>
        <figure align="center" anchor="OSPFAlg"
            title="OSPF align="center">
          <name>OSPF IP Algorithm TLV">
            <artwork><![CDATA[ TLV</name>
          <artwork align="center"><![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> <list style="symbols">
            <t>Type
        <dl spacing="normal" newline="false">
          <dt>Type (2 octets): IP octets):</dt> <dd>IP Algorithm TLV (Value TBD1 by IANA)</t>

            <t>Length( (21)</dd>
          <dt>Length( 2 octets): Variable</t>

            <t>Algorithm octets):</dt> <dd>Variable</dd>
          <dt>Algorithm (1 octet): Value octet):</dt> <dd>Value from 128 to 255.</t>
          </list></t> 255</dd>
        </dl>
        <t>The IP Algorithm TLV is optional. It MUST <bcp14>MUST</bcp14> only be
        advertised once in the Router Information LSA.</t>
        <t>Algorithms outside the Flex-Algorithm range (128-255) MUST
        <bcp14>MUST</bcp14> be ignored by the receiver. This situation SHOULD
        <bcp14>SHOULD</bcp14> be logged as an error.</t>
        <t>When multiple IP Algorithm TLVs are received from a given router,
        the receiver MUST <bcp14>MUST</bcp14> use the first occurrence of the TLV
        in the Router Information LSA. If the IP Algorithm TLV appears in
        multiple Router Information LSAs that have different flooding scopes,
        the IP Algorithm TLV in the Router Information LSA with the
        area-scoped flooding scope MUST <bcp14>MUST</bcp14> be used. If the IP
        Algorithm TLV appears in multiple Router Information LSAs that have
        the same flooding scope, the IP Algorithm TLV in the Router
        Information LSA with the numerically smallest Instance ID (Opaque ID
        for OSPFv2 or Link State ID for OSPFv3)
        MUST <bcp14>MUST</bcp14> be used used,
        and subsequent instances of the IP Algorithm TLV MUST <bcp14>MUST</bcp14>
        be ignored.</t>

        <t>The Router Information LSA can be advertised at any of the defined
        flooding scopes (link, area, or Autonomous System (AS)). For the
        purpose of IP Algorithm TLV advertisement, area area- or Autonomous System scoped AS-scoped flooding
        is REQUIRED. <bcp14>REQUIRED</bcp14>.  The AS flooding scope SHOULD NOT <bcp14>SHOULD
        NOT</bcp14> be used unless local configuration policy on the
        originating router indicates domain-wide flooding.</t>
        <t>The IP Flex-Algorithm Flexible Algorithm participation advertised in the OSPF IP Algorithm
        TLV is topology independent. When a router advertises participation in
        OSPF IP Algorithm TLV, the participation applies to all topologies in
        which the advertising node participates.</t>
      </section>
    </section>
    <section anchor="ASSOCIATE"
             title="Advertising anchor="ASSOCIATE">
      <name>Advertising IP Flex-Algorithm Reachability"> Flexible Algorithm Reachability</name>
      <t>To be able to associate the prefix with the Flex-Algorithm, the
      existing prefix reachability advertisements cannot be used, because
      they advertise the prefix reachability in default algorithm 0. Instead,
      new IP Flex-Algorithm Flexible Algorithm reachability advertisements are defined in IS-IS
      and OSPF.</t>
      <t>The M-flag in the FAD is not applicable to IP Algorithm Prefixes. Any IP
      Algorithm Prefix advertisement includes the Algorithm and Metric fields.
      When an IP Algorithm Prefix is advertised between areas or domains, the
      metric field in the IP Algorithm Prefix advertisement MUST <bcp14>MUST</bcp14> be used
      irrespective of the M-flag in the FAD advertisement.</t>
      <section anchor="IS-IS-IPV4_PFX_TLV"
               title="The anchor="IS-IS-IPV4_PFX_TLV">
        <name>The IS-IS IPv4 Algorithm Prefix Reachability TLV"> TLV</name>
        <t>The IPv4 Algorithm Prefix Reachability top-level TLV is defined for advertising IPv4 Flex-Algorithm Flexible Algorithm
        Prefix Reachability in IS-IS.</t>
        <t>This new TLV shares the sub-TLV space defined for TLVs Advertising Prefix
        Reachability.</t>
        <t>The IS-IS IPv4 Algorithm Prefix Reachability TLV has the following
        format: </t>
        <figure anchor="ISISipv4" title="IS-IS align="center">
          <name>IS-IS IPv4 Algorithm Prefix Reachability TLV">
            <artwork><![CDATA[ TLV</name>
          <artwork align="center"><![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    |  Rsvd |    MTID               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
        </figure> <list style="symbols">
            <t>Type
        <dl spacing="normal" newline="false">
          <dt>Type (1 octet): IPv4 octet):</dt> <dd>IPv4 Algorithm Prefix Reachability TLV
          (Value 126).</t>

            <t>Length 126)</dd>
          <dt>Length (1 octet): Variable octet):</dt> <dd>Variable based on number of prefix
          entries encoded</t>

            <t>Rsvd encoded</dd>
          <dt>Rsvd (4 bits): Reserved bits):</dt> <dd>Reserved for future use. They MUST
          <bcp14>MUST</bcp14> be set to zero on transmission and MUST
          <bcp14>MUST</bcp14> be ignored on receipt.</t>

            <t>MTID receipt.</dd>
          <dt>MTID (12 bits): Multitopology bits):</dt> <dd>Multitopology Identifier as defined in
            [RFC5120].
          <xref target="RFC5120" format="default"/>. Note that the value 0 is legal.</t>
          </list></t>
          legal.</dd>
        </dl>
        <t>Followed by one or more prefix entries of the form: form:</t>
        <figure anchor="ISISpfxentry" title="IS-IS align="center">
          <name>IS-IS IPv4 Algorithm Prefix Reachability TLV">
            <artwork><![CDATA[ TLV</name>
          <artwork align="center"><![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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                          Metric                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|   Flags       |  Algorithm    |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  Pfx Length   |  Prefix (variable)...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  Sub-tlv-len  |         Sub-TLVs (variable) . . .             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
        </figure> <list style="symbols">
            <t>Metric

        <dl spacing="normal" newline="false">
          <dt>Metric (4 octets): Metric octets):</dt> <dd>Metric information as defined in <xref target="RFC5305"/>.</t>

            <t>Flags target="RFC5305"/></dd>
          <dt>Flags (1 octet): <figure> octet):</dt>
<dd>
<artwork><![CDATA[
 0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
|D|  Reserved   |
+-+-+-+-+-+-+-+-+
]]></artwork>
              </figure> <list style="hanging">
                <t>D-flag:

            <dl newline="false" spacing="normal">
              <dt>D-flag:</dt>
              <dd>The D-flag is described as the "up/down bit" in <xref
              target="RFC5305" sectionFormat="of" section="4.1"/>. When the
              Prefix is leaked from level-2 level 2 to level-1, level 1, the D bit MUST
              <bcp14>MUST</bcp14> be set. Otherwise, this bit MUST
              <bcp14>MUST</bcp14> be clear.  Prefixes with the D bit set MUST NOT
              <bcp14>MUST NOT</bcp14> be leaked from level-1 level 1 to
                level-2. level 2. This
              is to prevent looping.</t>
              </list></t>

            <t>Algorithm looping.</dd>
	      <dt>The remaining bits:</dt>
	      <dd>Are reserved for future use. They <bcp14>MUST</bcp14> be set
	      to zero on transmission and <bcp14>MUST</bcp14> be ignored on
	      receipt.</dd>
            </dl>
	</dd>
          <dt>Algorithm (1 octet): Associated octet):</dt> <dd>Associated Algorithm from 128 to 255.</t>

            <t>Prefix
          255</dd>
          <dt>Prefix Len (1 octet): Prefix octet):</dt> <dd>Prefix length measured in bits.</t>

            <t>Prefix
          bits</dd>
          <dt>Prefix (variable length): Prefix length):</dt> <dd>Prefix mapped to Flex-Algorithm.</t>

            <t>Optional
          Flex-Algorithm</dd>
          <dt>Optional Sub-TLV-length (1 octet): Number octet):</dt> <dd>Number of octets
          used by
            sub-TLVs</t>

            <t>Optional sub-TLVs</dd>
          <dt>Optional sub-TLVs (variable length).</t>
          </list></t> length)</dt>
	  <dd></dd>
        </dl>
        <t>If the Algorithms in the IS-IS IPv4 Algorithm Prefix Reachability
        TLV is are outside the Flex-Algorithm range (128-255), the IS-IS IPv4
        Algorithm Prefix Reachability TLV MUST <bcp14>MUST</bcp14> be ignored by
        the receiver. This situation SHOULD <bcp14>SHOULD</bcp14> be logged as an
        error.</t>
        <t> If a router receives multiple IPv4 Algorithm Prefix Reachability
        advertisements for the same prefix from the same originator, it
        MUST
        <bcp14>MUST</bcp14> select the first advertisement in
        the lowest-numbered LSP and ignore any subsequent IPv4 Algorithm
        Prefix Reachability advertisements for the same prefix.</t>
        <t>If a router receives multiple IPv4 Algorithm Prefix Reachability
        advertisements for the same prefix, from different originators,
        where all of them do not advertise the same algorithm, it MUST <bcp14>MUST</bcp14> ignore all of them and
        MUST NOT
        <bcp14>MUST NOT</bcp14> install any forwarding entries based on these
        advertisements.  This situation SHOULD <bcp14>SHOULD</bcp14> be logged as an error.</t>
        <t>In cases where a prefix advertisement is received in both a an IPv4
        Prefix Reachability TLV (<xref target="RFC5305"/>, <xref target="RFC5120"/>) target="RFC5305"/> <xref
        target="RFC5120"/> and an IPv4 Algorithm Prefix Reachability TLV, the
        IPv4 Prefix Reachability advertisement MUST <bcp14>MUST</bcp14> be
        preferred when installing entries in the forwarding plane.</t>
      </section>
      <section anchor="IS-IS-IPV6_PFX_TLV"
               title="The anchor="IS-IS-IPV6_PFX_TLV">
        <name>The IS-IS IPv6 Algorithm Prefix Reachability TLV"> TLV</name>
        <t>The IS-IS IPv6 Algorithm Prefix Reachability TLV is identical to the
        IS-IS IPv4 Algorithm Prefix Reachability TLV, except that it has a
        distinct type. The type is 127.</t>
        <t>If the Algorithms in the IS-IS IPv6 Algorithm Prefix Reachability
        TLV is are outside the Flex-Algorithm range (128-255), the IS-IS IPv6
        Algorithm Prefix Reachability TLV MUST <bcp14>MUST</bcp14> be ignored by
        the receiver. This situation SHOULD <bcp14>SHOULD</bcp14> be logged as an
        error.</t>
        <t> If a router receives multiple IPv6 Algorithm Prefix Reachability
        advertisements for the same prefix from the same originator, it
        MUST
        <bcp14>MUST</bcp14> select the first advertisement in
        the lowest-numbered LSP and ignore any subsequent IPv6 Algorithm
        Prefix Reachability advertisements for the same prefix.</t>
        <t>If a router receives multiple IPv6 Algorithm Prefix Reachability
        advertisements for the same prefix, from different originators,
        where all of them do not advertise the same algorithm, it MUST <bcp14>MUST</bcp14> ignore all of them and
        MUST NOT
        <bcp14>MUST NOT</bcp14> install any forwarding entries based on these
       advertisements.  This situation SHOULD <bcp14>SHOULD</bcp14> be logged as an error.</t>
        <t>In cases where a prefix advertisement is received in both an IPv6
        Prefix Reachability TLV (<xref target="RFC5308"/>, <xref target="RFC5120"/>) target="RFC5308"/> <xref
        target="RFC5120"/> and an IPv6 Algorithm Prefix Reachability TLV, the
        IPv6 Prefix Reachability advertisement MUST <bcp14>MUST</bcp14> be
        preferred when installing entries in the forwarding plane.</t>
        <t>In cases where a prefix advertisement is received in both an IS-IS SRv6
        Locator TLV  <xref target="RFC9352"/> and in IS-IS IPv6 Algorithm Prefix Reachability TLV, the receiver
        MUST
        <bcp14>MUST</bcp14> ignore both of them and MUST NOT <bcp14>MUST NOT</bcp14> install any forwarding entries based
        on these advertisements. This situation SHOULD <bcp14>SHOULD</bcp14> be logged as an error.</t>
      </section>
      <section anchor="OSPF-IPV4_PFX_TLV"
               title="The anchor="OSPF-IPV4_PFX_TLV">
        <name>The OSPFv2 IP Algorithm Prefix Reachability Sub-TLV"> Sub-TLV</name>
        <t>A new Sub-TLV sub-TLV of the OSPFv2 Extended Prefix TLV is defined for
        advertising IP Algorithm Prefix Reachability in OSPFv2, the OSPFv2 IP
        Algorithm Prefix Reachability Sub-TLV.</t>
        <t>The OSPFv2 IP Algorithm Prefix Reachability Sub-TLV has the
        following format:</t>

        <t><figure
        <figure anchor="OSPFvpfx2" title="OSPFv2 align="center">
          <name>OSPFv2 IP Algorithm Prefix Reachability Sub-TLV">
            <artwork><![CDATA[ Sub-TLV</name>
          <artwork align="center"><![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            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|       MT-ID   |  Algorithm    |     Flags     |     Reserved  |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                          Metric                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
          </figure></t>

        <t><list style="symbols">
            <t>Type
        </figure>
        <dl spacing="normal" newline="false">
          <dt>Type (2 octets) : The octets):</dt> <dd>The value is TBD2.</t>

            <t>Length 6</dd>
          <dt>Length (2 octets): 8</t>

            <t>MT-ID octets):</dt> <dd>8</dd>
          <dt>MT-ID (1 octet): Multi-Topology octet):</dt> <dd>Multi-Topology ID as defined in <xref
            target="RFC4915"/></t>

            <t>Algorithm
          target="RFC4915"/></dd>
          <dt>Algorithm (1 octet): Associated octet):</dt> <dd>Associated Algorithm from 128 to 255.</t>

            <t>Flags:
          255</dd>
          <dt>Flags (1 octet):  The octet):</dt>
	  <dd><t>The following flags are defined:
            <figure>
                align="center">
                <artwork> defined:</t>
            <artwork><![CDATA[
 0 1 2 3 4 5 6 7 8
+-+-+-+-+-+-+-+-+-+
|E|   Reserved    |
+-+-+-+-+-+-+-+-+-+

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

            <t><list>

               <t>bit E: Same
]]></artwork>
          <t>Where:</t>
            <dl spacing="normal" newline="false">
              <dt>E bit:</dt> <dd>The same as bit the E bit defined in section A.4.5 of
              <xref target="RFC2328"/>.</t>

               <t>The target="RFC2328" sectionFormat="of" section="A.4.5"/>.</dd>
	      <dt>The remaining bits, are bits:</dt> <dd>Are reserved for future
	      use. They MUST <bcp14>MUST</bcp14> be set to zero on transmission and MUST
	      <bcp14>MUST</bcp14> be ignored on receipt.</t>

            </list></t>

            <t>Reserved: receipt.</dd>
            </dl>
          </dd>
          <dt>Reserved (1 octet). SHOULD octet):</dt> <dd><bcp14>SHOULD</bcp14> be set to 0
          on transmission and
            MUST <bcp14>MUST</bcp14> be ignored on reception.</t>

            <t>Metric
          reception.</dd>
          <dt>Metric (4 octets): The octets):</dt> <dd>The algorithm-specific metric
          value. The metric value of 0XFFFFFFFF MUST <bcp14>MUST</bcp14> be
          considered as unreachable.</t>
          </list></t> unreachable.</dd>
        </dl>
        <t>If the Algorithms in the OSPFv2 IP Algorithm Prefix Reachability
        Sub-TLV is are outside the Flex-Algorithm range (128-255), the OSPFv2 IP
        Algorithm Prefix Reachability Sub-TLV MUST <bcp14>MUST</bcp14> be ignored
        by the receiver. This situation SHOULD <bcp14>SHOULD</bcp14> be logged as an
        error.</t>
        <t>An OSPFv2 router receiving multiple OSPFv2 IP Algorithm Prefix
        Reachability Sub-TLVs in the same OSPFv2 Extended Prefix TLV, MUST TLV
        <bcp14>MUST</bcp14> select the first advertisement of this Sub-TLV sub-TLV and MUST
        <bcp14>MUST</bcp14> ignore all remaining occurences occurrences of this Sub-TLV sub-TLV in
        the OSPFv2 Extended Prefix TLV.</t>
        <t>An OSPFv2 router receiving multiple OSPFv2 IP Algorithm Prefix
        Reachability TLVs for the same prefix, prefix from different originators, originators
        where all of them do not advertise the same algorithm, MUST algorithm <bcp14>MUST</bcp14> ignore all of them and MUST NOT <bcp14>MUST NOT</bcp14>
        install any forwarding entries based on these advertisements.
        This situation SHOULD <bcp14>SHOULD</bcp14> be logged as an error.</t>
        <t>In cases where a prefix advertisement is received in any of the
        LSAs advertising the prefix reachability for algorithm 0 and in an OSPFv2
        IP Algorithm Prefix Reachability Sub-TLV, only the prefix reachability
        advertisement for algorithm 0 MUST <bcp14>MUST</bcp14> be used used, and all occurences occurrences of the
        OSPFv2 IP Algorithm Prefix Reachability Sub-TLV MUST <bcp14>MUST</bcp14> be ignored.</t>
        <t>When computing the IP Algorithm Prefix reachability in OSPFv2, only
        information present in the OSPFv2 Extended Prefix TLV MUST
        <bcp14>MUST</bcp14> be used. There will not be any information
        advertised for the IP Algorithm Prefix in any of the OSPFv2 LSAs that
        advertise prefix reachability for algorithm 0. For the IP Algorithm Prefix
        Prefix, the OSPFv2 Extended Prefix TLV is used to advertise the prefix
        reachability, unlike for algorithm 0 prefixes, where the OSPFv2
        Extended Prefix TLV is only used to advertise additional attributes, attributes --
        but not the reachability itself.</t>
        <section anchor="OSPFV2_FA-SUBTLV"
               title="The anchor="OSPFV2_FA-SUBTLV">
          <name>The OSPFv2 IP Forwarding Address Sub-TLV"> Sub-TLV</name>
          <t>A new Sub-TLV sub-TLV of the OSPFv2 Extended Prefix TLV is defined for
        advertising IP Forwarding Address, the OSPFv2 IP Forwarding Address Sub-TLV.</t>
          <t>The OSPFv2 IP Forwarding Address Sub-TLV has the
        following format:</t>

        <t><figure
          <figure anchor="OSPFV2_FA" title="OSPFv2 align="center">
            <name>OSPFv2 IP Forwarding Address Sub-TLV">
            <artwork><![CDATA[ Sub-TLV</name>
            <artwork align="center"><![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            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                     Forwarding Address                        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
          </figure></t>

          <t><list style="symbols">
            <t>Type
          </figure>
          <dl spacing="normal" newline="false">
            <dt>Type (2 octets) : The octets):</dt> <dd>The value is TBD4.</t>

            <t>Length 7</dd>
            <dt>Length (2 octets): 4</t>

            <t>Forwarding octets):</dt> <dd>4</dd>
            <dt>Forwarding Address (4 octets): Same octets):</dt> <dd>The same as defined in section A.4.5 of <xref target="RFC2328"/>.</t>

            </list></t> target="RFC2328" sectionFormat="of" section="A.4.5"/></dd>
          </dl>
          <t>The OSPFv2 IP Forwarding Address Sub-TLV MUST NOT <bcp14>MUST NOT</bcp14>
          be used for computing algorithm 0 prefix reachability and MUST
          <bcp14>MUST</bcp14> be ignored for algorithm 0 prefixes.</t>
          <t>The OSPFv2 IP Forwarding Address Sub-TLV is optional. If it is
          not present, the forwarding address for computing the IP Algorithm
          Prefix reachability is assumed to be equal to 0.0.0.0.</t>

          <t>The OSPFv2 IP Forwarding Address Sub-TLV is only applicable to Autonomous System
             (AS) AS External and Not-So-Stubby Area (NSSA) External route types. If the
             OSPFv2 IP Forwarding Address Sub-TLV is advertised in the OSPFv2 Extended
             Prefix TLV that has the Route Type field set to any other type, the OSPFv2
             IP Forwarding Address Sub-TLV MUST <bcp14>MUST</bcp14> be ignored.</t>
        </section>
      </section>
      <section anchor="OSPFV3_ALGTLV"
               title="The anchor="OSPFV3_ALGTLV">
        <name>The OSPFv3 IP Algorithm Prefix Reachability Sub-TLV"> Sub-TLV</name>
        <t>The OSPFv3 <xref target="RFC5340"/> IP Algorithm Prefix Reachability Sub-TLV
        is defined for advertisement of the IP Algorithm Prefix Reachability in OSPFv3.</t>
        <t>The OSPFv3 IP Algorithm Prefix Reachability Sub-TLV is a sub-TLV of
        the following OSPFv3 TLVs defined in <xref target="RFC8362"/>: <list
            style="symbols">
            <t>Intra-Area-Prefix TLV</t>

            <t>Inter-Area-Prefix TLV</t>

            <t>External-Prefix TLV</t>
          </list></t> </t>
        <ul spacing="normal">
          <li>Intra-Area-Prefix TLV</li>
          <li>Inter-Area-Prefix TLV</li>
          <li>External-Prefix TLV</li>
        </ul>
        <t>The format of OSPFv3 IP Algorithm Prefix Reachability Sub-TLV is
        shown below:</t>

        <t><figure
        <figure anchor="OSPFv3pfx" title="OSPFv3 align="center">
          <name>OSPFv3 IP Algorithm Prefix Reachability Sub-TLV">
            <artwork><![CDATA[ Sub-TLV</name>
          <artwork align="center"><![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    |                 Reserved                      |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                          Metric                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
          </figure>Where:<list>
            <t>Type
        </figure>
        <t>Where:</t>
        <dl spacing="normal" newline="false">
          <dt>Type (2 octets): The octets):</dt> <dd>The value is TBD3.</t>

            <t>Length 35</dd>
          <dt>Length (2 octets): 8.</t>

            <t>Algorithm octets):</dt> <dd>8</dd>
          <dt>Algorithm (1 octet): Associated octet):</dt> <dd>Associated Algorithm from 128 to 255.</t>

            <t>Reserved:
          255</dd>
          <dt>Reserved (3 octets). SHOULD octets):</dt> <dd><bcp14>SHOULD</bcp14> be set to 0
          on transmission and
            MUST <bcp14>MUST</bcp14> be ignored on reception.</t>

            <t>Metric
          reception.</dd>
          <dt>Metric (4 octets): The octets):</dt> <dd>The algorithm-specific metric
          value. The metric value of 0XFFFFFFFF MUST <bcp14>MUST</bcp14> be
          considered as unreachable.</t>
          </list></t> unreachable.</dd>
        </dl>
        <t>If the Algorithms in the OSPFv3 IP Algorithm Prefix Reachability
        Sub-TLV is are outside the Flex-Algorithm range (128-255), the OSPFv3 IP
        Algorithm Prefix Reachability Sub-TLV MUST <bcp14>MUST</bcp14> be ignored
        by the receiver. This situation SHOULD <bcp14>SHOULD</bcp14> be logged as an
        error.</t>
        <t>When the OSPFv3 IP Algorithm Prefix Reachability Sub-TLV is
        present, the NU-bit in the PrefixOptions field of the parent TLV MUST
        <bcp14>MUST</bcp14> be set.  This is needed to prevent the OSPFv3 IP
        Algorithm Prefix Reachability advertisement from contributing to the
        base algorithm reachability. If the NU-bit in the PrefixOptions field
        of the parent TLV is not set, the OSPFv3 IP Algorithm Prefix Sub-TLV MUST
        <bcp14>MUST</bcp14> be ignored by the receiver.</t>
        <t>The metric value in the parent TLV is RECOMMENDED <bcp14>RECOMMENDED</bcp14> to
        be set to LSInfinity <xref target="RFC2328"/>. This recommendation is
        provided as a network troubleshooting convenience; if it is not followed
        followed, the protocol will still function correctly.</t>
        <t>An OSPFv3 router receiving multiple OSPFv3 IP Algorithm Prefix
        Reachability Sub-TLVs in the same parent TLV, MUST TLV <bcp14>MUST</bcp14> select the first
        advertisement of this Sub-TLV sub-TLV and MUST <bcp14>MUST</bcp14> ignore all remaining occurences occurrences
        of this Sub-TLV sub-TLV in the parent TLV.</t>
        <t>An OSPFv3 router receiving multiple OSPFv3 IP Algorithm Prefix
        Reachability TLVs for the same prefix, prefix from different originators, originators
        where all of them do not advertise the same algorithm, MUST algorithm <bcp14>MUST</bcp14> ignore all of them and MUST NOT <bcp14>MUST NOT</bcp14>
        install any forwarding entries based on these advertisements.
        This situation SHOULD <bcp14>SHOULD</bcp14> be logged as an error.</t>
        <t>In cases where a prefix advertisement is received in any of the
        LSAs advertising the prefix reachability for algorithm 0 and in an OSPFv3
        OSPFv3 IP Algorithm Prefix Reachability Sub-TLV, only the prefix reachability
        advertisement for algorithm 0 MUST <bcp14>MUST</bcp14> be used used, and all occurences occurrences of the
        OSPFv3 IP Algorithm Prefix Reachability Sub-TLV MUST <bcp14>MUST</bcp14> be ignored.</t>
        <t>In cases where a prefix advertisement is received in both an OSPFv3 SRv6 Locator TLV
        and in an OSPFv3 IP Algorithm Prefix Reachability Sub-TLV, the receiver
        MUST
        <bcp14>MUST</bcp14> ignore both of them and MUST NOT <bcp14>MUST NOT</bcp14> install any forwarding entries based
        on these advertisements. This situation SHOULD <bcp14>SHOULD</bcp14> be logged as an error.</t>
      </section>
      <section anchor="IPFAAL"
               title="The anchor="IPFAAL">
        <name>The OSPF IP Flexible Algorithm ASBR Metric Sub-TLV"> Sub-TLV</name>
        <t><xref target="RFC9350"/> defines the OSPF Flexible Algorithm ASBR
        Metric Sub-TLV (FAAM) Sub-TLV that is used by an OSPFv2 or an OSPFv3 ABR Area
        Border Router (ABR) to advertise a Flex-Algorithm specific Flex-Algorithm-specific metric
        associated with the corresponding ASBR LSA.</t>
        <t>As described in <xref target="RFC9350"/> target="RFC9350"/>, each data-plane data plane signals
        its participation independently. IP Flex-Algorithm Flexible Algorithm participation is
        signaled independent of Segment Routing (SR) Flex-Algorithm SR Flexible Algorithm participation. As a result,
        the calculated topologies for SR and IP
        Flex-Algorithm Flexible Algorithm could be
        different. Such a difference prevents the usage of FAAM for the purpose
        of the IP Flex-Algorithm.</t> Flexible Algorithm.</t>
        <t>The OSPF IP Flexible Algorithm ASBR Metric (IPFAAM) Sub-TLV is
        defined for the advertisement of the IP Flex-Algorithm specific Flex-Algorithm-specific metric
        associated with an ASBR by the ABR.</t>
        <t>The IPFAAM Sub-TLV is a Sub-TLV sub-TLV of the: <list style="hanging">
            <t>- OSPFv2 the:</t>
        <ul spacing="normal">
          <li>OSPFv2 Extended Inter-Area ASBR TLV TLV, as defined in <xref
            target="RFC9350"/></t>

            <t>- OSPFv3
          target="RFC9350"/></li>
          <li>OSPFv3 Inter-Area-Router TLV TLV, as defined in <xref
            target="RFC8362"/></t>
          </list></t>
          target="RFC8362"/></li>
        </ul>
        <t>The OSPF IPFAAM Sub-TLV has the following format:</t>
         <t><figure
        <figure anchor="OSPFfaal" title="OSPF align="center">
          <name>OSPF IP Flexible Algorithm ASBR Metric Sub-TLV">
            <artwork><![CDATA[ Sub-TLV</name>
          <artwork align="center"><![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   |                   Reserved                    |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                            Metric                             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

where:
]]></artwork>
        </figure> <list style="hanging">
            <t>Type
	<t>Where:</t>
        <dl newline="false" spacing="normal">
          <dt>Type (2 octets): 2 octets):</dt> <dd>2 (allocated by IANA) for OSPFv2, TBD5 36
          for OSPFv3.</t>

            <t>Length OSPFv3</dd>
          <dt>Length (2 octets): 8.</t>

            <t>Algorithm octets):</dt> <dd>8</dd>
          <dt>Algorithm (1 octet): Associated octet):</dt> <dd>Associated Algorithm from 128 to 255.</t>

            <t>Reserved:
          255</dd>
          <dt>Reserved (3 octets). SHOULD octets):</dt> <dd><bcp14>SHOULD</bcp14> be set to 0
          on transmission and
            MUST <bcp14>MUST</bcp14> be ignored on reception.</t>

            <t>Metric
          reception</dd>
          <dt>Metric (4 octets): The octets):</dt> <dd>The algorithm-specific metric value.</t>
          </list></t>
          value</dd>
        </dl>
        <t>If the Algorithms in the OSPF IP Flexible Algorithm ASBR Metric
        Sub-TLV is are outside the Flex-Algorithm range (128-255), the OSPF IP
        Flexible Algorithm ASBR Metric Sub-TLV
         MUST <bcp14>MUST</bcp14> be ignored
        by the receiver. This situation SHOULD <bcp14>SHOULD</bcp14> be logged as an
        error.</t>
        <t>The usage of the IPFAAM Sub-TLV is similar to the usage of the FAAM
        Sub-TLV defined in <xref target="RFC9350"/>, but it is used to
        advertise IP Flex-Algorithm Flexible Algorithm metric.</t>
        <t>An OSPF ABR MUST <bcp14>MUST</bcp14> include the OSPF IPFAAM Sub-TLVs as
        part of the any IP Flexible Algorithm ASBR reachability advertisement
        between areas for every IP
        Flex-Algorithm in which it participates and the ASBR is reachable
        in.</t> areas.</t>
        <t>The FAAM Sub-TLV as defined in <xref target="RFC9350"/>
        MUST NOT <bcp14>MUST
        NOT</bcp14> be used during IP Flex-Algorithm Flexible Algorithm path calculation, calculation; the
        IPFAAM Sub-TLV MUST <bcp14>MUST</bcp14> be used instead.</t>
      </section>
    </section>

    <section title="Calculating
    <section>
      <name>Calculating of IP Flex-Algorithm Paths"> Flexible Algorithm Paths</name>
      <t>The IP Flex-Algorithm Flexible Algorithm is considered as yet another data-plane data plane of the
      Flex-Algorithm
      Flexible Algorithm as described in <xref target="RFC9350"/>.</t>
      <t>Participation in the IP Flex-Algorithm Flexible Algorithm is signalled signaled as described in
      <xref target="PARTICIPATION"/> and is specific to the IP Flex-Algorithm
      data-plane.</t> Flexible Algorithm
      data plane.</t>
      <t>Calculation of IP Flex-Algorithm Flexible Algorithm paths follows what is described in
      <xref target="RFC9350"/>. This computation uses the IP
      Flex-Algorithm data-plane
      Flexible Algorithm data plane participation and is independent of the Flex-Algorithm Flexible Algorithm
      calculation done for any other Flex-Algorithm data-plane Flexible Algorithm data plane (e.g., SR,
      SRv6).</t>
      <t>The IP Flex-Algorithm data-plane Flexible Algorithm data plane only considers participating nodes
      during the Flex-Algorithm Flexible Algorithm calculation. When computing paths for a given
      Flex-Algorithm, all nodes that do not advertise participation for the such IP
      Flex-Algorithm, as described in <xref target="PARTICIPATION"/>, MUST <bcp14>MUST</bcp14> be
      pruned from the topology.</t>
    </section>

    <section title="IP Flex-Algorithm Forwarding">
    <section>
      <name>IP Flexible Algorithm Forwarding</name>
      <t>The IP Algorithm Prefix Reachability advertisement as described in <xref target="PARTICIPATION"/> includes the MTID value that associates the
      prefix with a specific topology. Algorithm Prefix Reachability
      advertisement also includes an Algorithm value that explicitly
      associates the prefix with a specific Flex-Algorithm. The paths to the
      prefix MUST <bcp14>MUST</bcp14> be calculated using the specified Flex-Algorithm in the
      associated topology.</t>
      <t>Forwarding entries for the IP Flex-Algorithm prefixes advertised in
      IGPs MUST <bcp14>MUST</bcp14> be installed in the forwarding plane of the receiving IP
      Flex-Algorithm prefix capable routers when they participate in the
      associated topology and algorithm. Forwarding entries for IP
      Flex-Algorithm prefixes associated with Flex-Algorithms in which the
      node is not participating MUST NOT <bcp14>MUST NOT</bcp14> be installed in the forwarding
      plane.</t>
    </section>

    <section title="Deployment Considerations">
    <section>
      <name>Deployment Considerations</name>
      <t>IGP Flex-Algorithm Flexible Algorithm can be used by many data-planes. data planes. The original
      specification was done for SR and SRv6, SRv6; this specification adds IP as
      another data-plane data plane that can use IGP Flex-Algorithm. Flexible Algorithm. Other data-planes data planes
      may be defined in the future. This section provides some details about
      the coexistence of the various data-planes data planes of an IGP Flex-Algorithm.</t>

      <t>Flex-Algorithm definition Flexible Algorithm.</t>
      <t>Flexible Algorithm Definition (FAD), as described in <xref target="RFC9350"/>, is data-plane data plane independent and is
      used by all Flex-Algorithm data-planes.</t> Flexible Algorithm data planes.</t>
      <t>Participation in the Flex-Algorithm, Flexible Algorithm, as described in <xref target="RFC9350"/>, is data-plane data plane specific.</t>
      <t>Calculation of the flex-algo Flexible Algorithm paths is data-plane data plane specific and uses
      data-plane specific
      data-plane-specific participation advertisements.</t>

      <t>Data-plane specific
      <t>Data-plane-specific participation and calculation guarantee that the
      forwarding of the traffic over the Flex-Algorithm data-plane specific data-plane-specific
      paths is consistent between all nodes that apply the IGP Flex-Algorithm
      to the data-plane.</t> data plane.</t>
      <t>Multiple data-planes data planes can use the same Flex-Algorithm value at the
      same time and, and as such, share the FAD for it. For example, SR-MPLS
      and IP can both use a common Flex-Algorithm. Traffic for SR-MPLS will be
      forwarded based on Flex-algorithm specific Flex-Algorithm-specific SR SIDs. Traffic for IP
      Flex-Algorithm will be forwarded based on Flex-Algorithm specific Flex-Algorithm-specific prefix
      reachability advertisements. Note that for a particular Flex-Algorithm,
      for a particular IP prefix, there will only be path(s) calculated and
      installed for a single data-plane.</t> data plane.</t>
    </section>

    <section title="Protection">
    <section>
      <name>Protection</name>
      <t>In many networks where IGP Flexible Algorithms are deployed, IGP
      restoration will be fast and additional protection mechanisms will not
      be required. IGP restoration may be enhanced by Equal Cost Multipath
      (ECMP).</t>
      <t>In other networks, operators can deploy additional protection
      mechanisms. The following are examples:</t>

      <t><list style="symbols">
          <t><xref target="RFC5286">Loop Free
      <ul spacing="normal">
        <li>Loop-Free Alternates (LFA)</xref></t>

          <t><xref target="RFC7490">Remote Loop Free (LFAs) <xref target="RFC5286"/></li>
        <li>Remote Loop-Free Alternates (R-LFA)
          </xref></t>
        </list>LFA (R-LFAs) <xref target="RFC7490"/></li>
      </ul>
      <t>LFA and R-LFA computations MUST <bcp14>MUST</bcp14> be restricted to the flex-algo
      Flex-Algorithm topology and the computed backup nexthops next hops should be programmed
      for the IP flex-algo Flex-Algorithm prefixes.</t>
    </section>
    <section anchor="IANA" title="IANA Considerations"> anchor="IANA">
      <name>IANA Considerations</name>
      <t>This specification updates the OSPF "OSPF Router Information (RI) TLVs
      Registry TLVs"
      registry as follows:</t>

      <t/>

      <texttable

      <table anchor="T1">
        <ttcol>Value</ttcol>

        <ttcol>TLV Name</ttcol>

        <ttcol>Reference</ttcol>

        <c>TBD1</c>

        <c>IP Algorithm</c>

        <c>This Document <xref target="OSPF-ALG_TLV"/></c>
      </texttable>
        <thead>
          <tr>
            <th>Value</th>
            <th>TLV Name</th>
            <th>Reference</th>
          </tr>
        </thead>
        <tbody>
          <tr>
            <td>21</td>
            <td>IP Algorithm</td>
            <td>RFC 9502, <xref target="OSPF-ALG_TLV"/></td>
          </tr>
        </tbody>
      </table>
      <t>This document also updates the IS-IS "IS-IS Sub-TLVs for IS-IS Router CAPABILITY TLV"
      registry as follows:</t>

      <t/>

      <texttable
      <table anchor="T2">
        <ttcol>Value</ttcol>

        <ttcol>TLV Name</ttcol>

        <ttcol>Reference</ttcol>

        <c>29</c>

        <c>IP Algorithm</c>

        <c>This Document <xref target="IS-IS-ALG_TLV"/></c>
      </texttable>
        <thead>
          <tr>
            <th>Value</th>
            <th>TLV Name</th>
            <th>Reference</th>
          </tr>
        </thead>
        <tbody>
          <tr>
            <td>29</td>
            <td>IP Algorithm</td>
            <td>RFC 9502, <xref target="IS-IS-ALG_TLV"/></td>
          </tr>
        </tbody>
      </table>
      <t>This document also updates the "IS-IS Top-Level TLV Codepoints Registry" Codepoints"
      registry as follows:</t>

      <t/>

      <texttable

      <table anchor="T3">
        <ttcol>Value</ttcol>

        <ttcol>TLV Name</ttcol>

        <ttcol>IIH</ttcol>

        <ttcol>LSP</ttcol>

        <ttcol>SNP</ttcol>

        <ttcol>Purge</ttcol>

        <ttcol>Reference</ttcol>

        <c>126</c>

        <c>IPv4 Algorithm Prefix Reachability</c>

        <c>N</c>

        <c>Y</c>

        <c>N</c>

        <c>N</c>

        <c>This document, <xref target="IS-IS-IPV4_PFX_TLV"/></c>

        <c>127</c>

        <c>IPv6 Algorithm Prefix Reachability</c>

        <c>N</c>

        <c>Y</c>

        <c>N</c>

        <c>N</c>

        <c>This document, <xref target="IS-IS-IPV6_PFX_TLV"/></c>
      </texttable>
        <thead>
          <tr>
            <th>Value</th>
            <th>TLV Name</th>
            <th>IIH</th>
            <th>LSP</th>
            <th>SNP</th>
            <th>Purge</th>
            <th>Reference</th>
          </tr>
        </thead>
        <tbody>
          <tr>
            <td>126</td>
            <td>IPv4 Algorithm Prefix Reachability</td>
            <td>n</td>
            <td>y</td>
            <td>n</td>
            <td>n</td>
            <td>RFC 9502, <xref target="IS-IS-IPV4_PFX_TLV"/></td>
          </tr>
          <tr>
            <td>127</td>
            <td>IPv6 Algorithm Prefix Reachability</td>
            <td>n</td>
            <td>y</td>
            <td>n</td>
            <td>n</td>
            <td>RFC 9502, <xref target="IS-IS-IPV6_PFX_TLV"/></td>
          </tr>
        </tbody>
      </table>
      <t>Since the above TLVs share the sub-TLV space managed in the "IS-IS
      Sub-TLVs for TLVs Advertising Prefix Reachability" registry, IANA is
   requested to add has
      added "IPv4 Algorithm Prefix Reachability TLV (126)" and
      "IPv6 Algorithm Prefix Reachability TLV (127)" to the list of TLVs in
      the description of that registry.</t>
      <t>In addition, columns headed '126' "126" and '127' are "127" have been added to that
      registry, as follows:</t>

      <t><figure>
            <artwork><![CDATA[
     Type  Description                          126 127
     ----  ----------------------------------   --- ---
      1    32-bit

<table anchor="attribute126-127" align="center">
  <name></name>
  <thead>
    <tr>
      <th>Type</th>
      <th>Description</th>
      <th>126</th>
      <th>127</th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <td>1</td>
      <td>32-bit Administrative Tag Sub-TLV     y   y
      2    64-bit Sub-TLV</td>
      <td>y</td>
      <td>y</td>
    </tr>
    <tr>
      <td>2</td>
      <td>64-bit Administrative Tag Sub-TLV     y   y
      3    Prefix Sub-TLV</td>
      <td>y</td>
      <td>y</td>
    </tr>
    <tr>
      <td>3</td>
      <td>Prefix Segment Identifier             n   n
      4    Prefix Identifier</td>
      <td>n</td>
      <td>n</td>
    </tr>
    <tr>
      <td>4</td>
      <td>Prefix Attribute Flags                y   y
      5    SRv6 Flags</td>
      <td>y</td>
      <td>y</td>
    </tr>
    <tr>
      <td>5</td>
      <td>SRv6 End SID                          n   n
      6    Flex-Algorithm SID</td>
      <td>n</td>
      <td>n</td>
    </tr>
    <tr>
      <td>6</td>
      <td>Flexible Algorithm Prefix Metric          n   n
      11   IPv4 (FAPM)</td>
      <td>n</td>
      <td>n</td>
      </tr>
      <tr>
	<td>11</td>
	<td>IPv4 Source Router ID                 y   y
      12   IPv6 ID</td>
        <td>y</td>
	<td>y</td>
      </tr>
      <tr>
	<td>12</td>
	<td>IPv6 Source Router ID                 y   y
      32   BIER Info                             n   n
     ]]></artwork>
          </figure></t> ID</td>
        <td>y</td>
	<td>y</td>
      </tr>
      <tr>
	<td>32</td>
	<td>BIER Info</td>
        <td>n</td>
	<td>n</td>
      </tr>
  </tbody>
</table>

      <t>This document updates registers the following in the "OSPFv2 Extended Prefix TLV Sub-TLVs"
      registry as follows:</t>

      <t/>

      <texttable       registry:</t>

      <table anchor="T4">
        <ttcol>Value</ttcol>

        <ttcol>TLV Name</ttcol>

        <ttcol>Reference</ttcol>

        <c>TBD2</c>

        <c>OSPFv2
        <thead>
          <tr>
            <th>Value</th>
            <th>TLV Name</th>
            <th>Reference</th>
          </tr>
        </thead>
        <tbody>
          <tr>
            <td>6</td>
            <td>OSPFv2 IP Algorithm Prefix Reachability</c>

        <c>This Document, <xref target="OSPF-IPV4_PFX_TLV"/></c>

        <c>TBD4</c>

        <c>OSPFv2 Reachability</td>
            <td>RFC 9502, <xref target="OSPF-IPV4_PFX_TLV"/></td>
          </tr>
          <tr>
            <td>7</td>
            <td>OSPFv2 IP Forwarding Address</c>

        <c>This Document, <xref target="OSPFV2_FA-SUBTLV"/></c>

      </texttable>

      <t>This document creates a new Address</td>
            <td>RFC 9502, <xref target="OSPFV2_FA-SUBTLV"/></td>
          </tr>
        </tbody>
      </table>
      <t>IANA has created the "IP Algorithm Prefix Reachability Sub-TLV Flags" registry under within the "Open Shortest Path First v2 (OSPFv2) Parameters" registry, called  "IP Algorithm Prefix Reachability Sub-TLV Flags". group of registries.  The new registry defines the bits in the
      8-bit Flags field in the OSPFv2 IP Algorithm Prefix Reachability Sub-TLV
      (<xref target="OSPF-IPV4_PFX_TLV"/>). New bits can be allocated via IETF
      Review or IESG Approval <xref target="RFC8126"/></t>

      <texttable
      <table anchor="T5">
        <ttcol>Bit #</ttcol>

        <ttcol>Name</ttcol>

        <ttcol>Reference</ttcol>

        <c>0</c>

        <c>bit E</c>

        <c>This Document, <xref target="OSPF-IPV4_PFX_TLV"/></c>

        <c>1-7</c>

        <c>Reserved</c>

        <c>This Document, <xref target="OSPF-IPV4_PFX_TLV"/></c>

      </texttable>
        <thead>
          <tr>
            <th>Bit</th>
            <th>Name</th>
            <th>Reference</th>
          </tr>
        </thead>
        <tbody>
          <tr>
            <td>0</td>
            <td>E bit</td>
            <td>RFC 9502, <xref target="OSPF-IPV4_PFX_TLV"/></td>
          </tr>
          <tr>
            <td>1-7</td>
            <td>Unassigned</td>
            <td></td>
          </tr>
        </tbody>
      </table>
      <t>This document updates registers the following in the "OSPFv3 Extended-LSA Sub-TLVs" registry as
      follows:</t>

      <t/>

      <texttable registry:
      </t>
      <table anchor="T6">
        <ttcol>Value</ttcol>

        <ttcol>TLV Name</ttcol>

        <ttcol>Reference</ttcol>

        <c>TBD3</c>

        <c>OSPFv3
        <thead>
          <tr>
            <th>Value</th>
            <th>Description</th>
            <th>L2BM</th>
            <th>Reference</th>
          </tr>
        </thead>
        <tbody>
          <tr>
            <td>35</td>
            <td>OSPFv3 IP Algorithm Prefix Reachability</c>

        <c>This Document, <xref target="OSPFV3_ALGTLV"/></c>

        <c>TBD5</c>

        <c>OSPFv3 Reachability</td>
            <td>X</td>
            <td>RFC 9502, <xref target="OSPFV3_ALGTLV"/></td>
          </tr>
          <tr>
            <td>36</td>
            <td>OSPFv3 IP Flexible Algorithm ASBR Metric</c>

        <c>This Document, <xref target="IPFAAL"/></c>
      </texttable> Metric</td>
            <td>X</td>
            <td>RFC 9502, <xref target="IPFAAL"/></td>
          </tr>
        </tbody>
      </table>
      <t>This document updates registers the following in the "OSPFv2 Extended Inter-Area ASBR Sub-TLVs"
      registry as follows:</t>

      <t/>

      <texttable
      registry:</t>

      <table anchor="T7">
        <ttcol>Value</ttcol>

        <ttcol>TLV Name</ttcol>

        <ttcol>Reference</ttcol>

        <c>2</c>

        <c>OSPF
        <thead>
          <tr>
            <th>Value</th>
            <th>Description</th>
            <th>Reference</th>
          </tr>
        </thead>
        <tbody>
          <tr>
            <td>2</td>
            <td>OSPF IP Flexible Algorithm ASBR Metric</c>

        <c>This Document, <xref target="IPFAAL"/></c>
      </texttable> Metric</td>
            <td>RFC 9502, <xref target="IPFAAL"/></td>
          </tr>
        </tbody>
      </table>
    </section>
    <section anchor="Security" title="Security Considerations"> anchor="Security">
      <name>Security Considerations</name>
      <t>This document inherits security considerations from <xref
      target="RFC9350"/>.</t>
      <t>This document adds one new way to disrupt IGP networks that are using
	  Flex-Algorithm:
      Flexible Algorithm: an attacker can suppress reachability for a given prefix
      whose reachability is advertised by a legitimate node for a particular
      IP Flex-Algorithm X, X by advertising the same prefix in Flex-Algorithm Y
      from another, another malicious node. (To see why this is, consider, for
      example, the rule given in the second-last second-to-last paragraph of <xref
      target="IS-IS-IPV4_PFX_TLV"/>).</t>
      <t>This attack can be addressed by the existing security extensions, as
      described in <xref target="RFC5304"/> and <xref target="RFC5310"/> for
      IS-IS, in <xref target="RFC2328"/> and <xref target="RFC7474"/>for target="RFC7474"/> for
      OSPFv2, and in <xref target="RFC4552"/> and <xref target="RFC5340"/> for
      OSPFv3.</t>
      <t>If a node that is authenticated is taken over by an attacker, such a
      rogue node can perform the attack described above.  Such an attack is
      not preventable through authentication, and it is not different from
      advertising any other incorrect information through IS-IS or OSPF.</t>
    </section>

    <section anchor="Acknowledgements" title="Acknowledgements">
      <t>Thanks to Bruno Decraene for his contributions to this document.
      Special thanks to Petr Bonbon Adamec of Cesnet for supporting
      interoperability testing.</t>
    </section>

  </middle>
  <back>
    <references title="Normative References">
      <?rfc include='reference.RFC.2119'?>

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

      <?fc include='reference.RFC.5305'?>
    <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.2328.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4552.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.5304.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5308.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5310.xml"/>

<reference anchor="RFC5340" target="https://www.rfc-editor.org/info/rfc5340">
<front>
<title>OSPF for IPv6</title>
<author fullname="R. Coltun" initials="R." surname="Coltun"/>
<author fullname="D. Ferguson" initials="D." surname="Ferguson"/>
<author fullname="J. Moy" initials="J." surname="Moy"/>
<author fullname="A. Lindem" initials="A." surname="Lindem" role="editor"/>
<date month="July" year="2008"/>
</front>
<seriesInfo name="RFC" value="5340"/>
<seriesInfo name="DOI" value="10.17487/RFC5340"/>
</reference>

        <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.4915.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7770.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7474.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7981.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.9352.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.5305.xml"/>

        <reference anchor="ISO10589" target="ISO/IEC 10589:2002"> anchor="ISO10589">
          <front>
          <title>Intermediate system
            <title>Information technology - Telecommunications and information exchange between systems - Intermediate System to Intermediate system routing System intra-domain routeing information exchange protocol for use in conjunction with the
          Protocol protocol for providing the Connectionless-mode Network Service connectionless-mode network service (ISO 8473)</title>
            <author>
              <organization abbrev="ISO">International Organization for
              Standardization</organization>
            </author>
            <date month="Nov" month="November" year="2002"/>
          </front>
	  <seriesInfo name="ISO/IEC" value="10589:2002"/>
	  <refcontent>Second Edition</refcontent>
        </reference>
      </references>

    <references title="Informative References">

      <references>
        <name>Informative References</name>

        <reference anchor='TS.23.501-3GPP'> anchor="TS.23.501-3GPP">
          <front>
            <title>System Architecture architecture for 5G System; Stage 2, 3GPP TS 23.501 v16.4.0</title> System (5GS)</title>
            <author>
        <organization>
        3rd Generation Partnership Project (3GPP)
        </organization>
              <organization>3GPP</organization>
            </author>
            <date month="March" year="2020"/> month="September" year="2023"/>
          </front>
	  <seriesInfo name="3GPP TS" value="23.501"/>
	  <refcontent>Release 18.3.0</refcontent>
        </reference>

        <reference anchor="IANA-ALG"
                 target="https://www.iana.org/assignments/igp-parameters/igp-parameters.xhtml#igp-algorithm-types"> target="https://www.iana.org/assignments/igp-parameters">
          <front>
          <title>IS-IS Sub-TLVs for IS-IS Router CAPABILITY TLV</title>
            <title>IGP Algorithm Types</title>
            <author fullname="" initials="" surname="">
              <organization>IANA</organization>
            </author>

          <date month="August" year="1987"/>
          </front>
        </reference>

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

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

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

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

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

        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8402.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8126.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5286.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7490.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8986.xml"/>
      </references>
    </references>

    <section anchor="Acknowledgements" numbered="false" toc="default">
      <name>Acknowledgements</name>
      <t>Thanks to <contact fullname="Bruno Decraene"/> for his contributions
      to this document.  Special thanks to <contact fullname="Petr Bonbon
      Adamec"/> of Cesnet for supporting interoperability testing.</t>
    </section>

  </back>

</rfc>