<?xml version="1.0" encoding="US-ASCII"?>
<!-- edited with XMLSPY v5 rel. 3 U (http://www.xmlspy.com)
     by Daniel M Kohn (private) -->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY rfc2119 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
]>
<?rfc toc="yes"?>
<?rfc tocompact="yes"?>
<?rfc tocdepth="3"?>
<?rfc tocindent="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<rfc category="std" docName="draft-ietf-idr-bgpls-inter-as-topology-ext-16"
     ipr="trust200902">
  <front>
    <title abbrev="BGP-LS-Inter-AS-Ext">BGP-LS Extension for Inter-AS Topology
    Retrieval</title>

    <author fullname="Aijun Wang" initials="A" surname="Wang">
      <organization>China Telecom</organization>

      <address>
        <postal>
          <street>Beiqijia Town, Changping District</street>

          <city>Beijing</city>

          <region>Beijing</region>

          <code>102209</code>

          <country>China</country>
        </postal>

        <email>wangaj3@chinatelecom.cn</email>
      </address>
    </author>

    <author fullname="Huaimo Chen" initials="H" surname="Chen">
      <organization>Futurewei</organization>

      <address>
        <postal>
          <street/>

          <city>Boston</city>

          <region>MA</region>

          <code/>

          <country>USA</country>
        </postal>

        <email>hchen.ietf@gmail.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>

        <phone/>

        <facsimile/>

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

        <uri/>
      </address>
    </author>

    <author fullname="Shunwan Zhuang" initials="S" surname="Zhuang">
      <organization>Huawei Technologies</organization>

      <address>
        <postal>
          <street>Huawei Building, No.156 Beiqing Rd.</street>

          <city>Beijing</city>

          <region/>

          <code>100095</code>

          <country>China</country>
        </postal>

        <phone/>

        <facsimile/>

        <email>zhuangshunwan@huawei.com</email>

        <uri/>
      </address>
    </author>

    <author fullname="Changwang Lin" initials="C" surname="Lin">
      <organization>New H3C Technologies</organization>

      <address>
        <postal>
          <street>Huawei Building, No.156 Beiqing Rd.</street>

          <city>Beijing</city>

          <region/>

          <code/>

          <country>China</country>
        </postal>

        <phone/>

        <facsimile/>

        <email>linchangwang.04414@h3c.com</email>

        <uri/>
      </address>
    </author>

    <date day="3" month="June" year="2024"/>

    <area>RTG Area</area>

    <workgroup>IDR Working Group</workgroup>

    <keyword>RFC</keyword>

    <abstract>
      <t>This document describes the process to distribute Border Gateway
      Protocol- Link State (BGP-LS) key parameters for inter-domain links
      between two Autonomous Systems. This document defines a new type within
      the BGP-LS NLRI for a Stub Link and three new type-length-values (TLVs)
      for BGP-LS Link descriptor. These additions to BGP-LS let Software
      Definition Network (SDN) controllers retrieve the network topology
      automatically under various inter-AS environments. </t>

      <t>Such extension and process can enable the network operator to collect
      the interconnect information between different domains and then
      calculate the overall network topology automatically based on the
      information provided by BGP-LS protocol.</t>
    </abstract>
  </front>

  <middle>
    <section anchor="intro" title="Introduction">
      <t>BGP-LS <xref target="RFC9552"/> describes the methodology that using
      BGP protocol to transfer the Link-State information. Such method can
      enable SDN controller to collect the underlay network topology
      automatically, but normally it can only get the information within one
      Interior Gateway Protocol (IGP) domain. If the operator has more than
      one IGP domain, and these domains interconnect with each other, there is
      no mechanic within current BGP- LS to transfer the interconnect topology
      information.</t>

      <t><xref target="RFC9086"/> defines some extensions for exporting BGP
      peering node topology information (including its peers, interfaces and
      peering ASs) in a way that is exploitable in order to compute efficient
      BGP Peering Engineering policies and strategies. Such information can
      also be used to calculate the interconnection topology among different
      IGP domains, but it requires every border router to run BGP-LS protocol
      and report the information to SDN controller. Considering there will be
      plenty of border routers on the network boundary, such solution
      restricts its deployment flexibility.</t>

      <t> This draft analyzes the situations during which the SDN controller
      needs to get the interconnected topology information between different
      AS domains. After describing these situations, this draft defines a new
      Stub Link type within the BGP-LS NLRI<xref target="RFC9552"/> to
      describe the Iner-AS link and some new TLVs for that new BGP-LS type.
      After that, the SDN controller can then deduce the multi-domain topology
      automatically based on the information from BGP-LS protocol.</t>
    </section>

    <section title="Conventions used in this document">
      <t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
      "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
      document are to be interpreted as described in RFC 2119 <xref
      target="RFC2119"/> .</t>
    </section>

    <section title="Terminology">
      <t>The following terms are defined in this document:</t>

      <t><list style="symbols">
          <t>IDCs: Internet Data Centers</t>

          <t>MAN: Metrio-Area-Network</t>

          <t>SDN: Software Definition Network</t>
        </list></t>
    </section>

    <section anchor="s-Inter-AS-Scenario" title="Inter-AS Domain Scenarios">
      <t>Figure 1 illustrates the multi-domain scenarios that this draft
      discusses. Normally, SDN Controller can get the topology of IGP A and
      IGP B individually via the BGP-LS protocol, but it can't get the
      topology connection information between these two IGP domains because
      there is generally no IGP protocol run on the connected links.<figure>
          <artwork align="center"><![CDATA[                      +-----------------+
                 +----+IP SDN Controller+----+
                 |    +-----------------+    |
                 |                           |
                 |BGP-LS                     |BGP-LS
                 |                           |
 +---------------+-----+               +-----+--------------+
 | +--+        +-++   ++-+           +-++   +|-+        +--+|
 | |S1+--------+S2+---+B1+-----------+B2+---+T1+--------+T2||
 | +-++   N1   +-++   ++-+           +-++   ++++   N2   +-++|
 |   |           |     |               |     ||           | |
 |   |           |     |               |     ||           | |
 | +-++        +-++   ++-+           +-++   ++++        +-++|
 | |S4+--------+S3+---+B3+-----------+B4+---+T3+--------+T4||
 | +--+        +--+   ++-+           +-++   ++-+        +--+|
 |                     |               |                    |
 |                     |               |                    |
 |       IGP A         |               |      IGP B         |
 +---------------------+               +--------------------+

             Figure 1: Inter-AS Domain Scenarios
]]></artwork>
        </figure></t>
    </section>

    <section anchor="s-Stub-Link-NLRI" title="Stub Link NLRI">
      <t><xref target="RFC9552"/> defines four types within the BGP Link-State
      NLRI (Node NLRI, Link NLRI, IPv4 Topology Prefix NLRI, and IPv6 Topology
      Prefix NLRI) to transfer the topology and prefix information. For
      inter-as link, the two ends of the link exist in different IGP domains,
      so it is not appropriate to transfer their information within the
      current defined NLRI types.</t>

      <t>This draft defines one new NLRI type(TBD1, see<spanx> </spanx><xref
      target="s-IANA"> </xref>) within the BGP Link-State (BGP-LS) NLRI,
      called the Stub link NLRI. The Stub link NLRI is encoded in the format
      shown in Figure 2 and explained below:</t>

      <t><figure>
          <artwork><![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
     +-+-+-+-+-+-+-+-+
     |  Protocol-ID  |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                           Identifier                          |
     |                            (64 bits)                          |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     //              Local Node Descriptors (variable)              //
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     //               Stub Link Descriptors (variable)              //
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

            Figure 2: Stub Link NLRI Format]]></artwork>
        </figure></t>

      <t>The "Protocol-ID" should be set to the value that indicates the
      source protocol of the stub link information, as indicated in <xref
      target="RFC9552"/> in section 5.2.</t>

      <t>Local Node descriptors: define the ASBRs that are attached to the
      Inter-AS stub link, and use the <xref target="RFC9552"/> &ldquo;Local
      Node Descriptor&rdquo; in section 5.2.1.4. The following Node Descriptor
      sub-TLVs from <xref target="RFC9552"/> are valid for inclusion in the
      local Node descriptor: AS system, OSPF Area-ID, IGP Router-ID.</t>

      <t>Stub Link Descriptors: define the Stub link which has only one end
      Located in the IGP domain using the <xref target="RFC9552"/> &ldquo;Link
      Descriptor definition&rdquo; in section 5.2.2 with the exceptions noted
      below.</t>

      <t>The Stub link Descriptor supports the inclusion of the following
      subTLVs:</t>

      <t> &bull; Link/Local Identifier (TLV 258, <xref target="RFC9552"/>),
      </t>

      <t>&bull; IPv4 Interface Address (TLV 259, <xref target="RFC9552"/>),
      </t>

      <t>&bull; IPv4 Neighbor Address (TLV 260,<xref target="RFC9552"/>), </t>

      <t>&bull; IPv6 Interface Address (TLV 261, <xref target="RFC9552"/>),
      </t>

      <t>&bull; IPv6 Neighbor Address (TLV 262, <xref target="RFC9552"/>),
      </t>

      <t>&bull; Multi-topology identifier (TLV 263, <xref target="RFC9552"/>),
      </t>

      <t>&bull; Remote-AS Number (TLV TBD1, [This document], section <xref
      target="sec7.1"/>), </t>

      <t>&bull; IPv4 Remote ASBR ID [TLV TBD2, [This document], section <xref
      target="sec7.2"/>), and</t>

      <t> &bull; IPv6 Remote ASBR ID [TLV TBD2, [This document], section <xref
      target="sec7.3"/>). </t>

      <t>This newly defined NLRI can be used to describe the link that has
      only one end located within the IGP domain, as described in the
      following sections. The Node and Link Descriptor sub-TLVs and Node and
      Link attributes that are defined in <xref target="RFC9552"/> can be
      included in the NLRI if necessary. The interface and neighbor address
      sub- TLVs SHOULD be included in the Local Node Descriptors to
      differentiate the parallel links between two ASBRs. </t>
    </section>

    <section title="IGP Information for Inter-AS Link">
      <t><xref target="RFC9346"/> and <xref target="RFC5392"/> define IS-IS
      and OSPF extensions respectively to deal with the reasons for reporting
      inter-AS link. Three sub-TLVs relating to Inter-Domain Links (Remote AS
      Number&#12289;IPv4 Remote ASBR ID&#12289; and IPv6 Remote ASBR ID) are
      defined in these documents. .</t>

      <t>These IGP TLVs are flooded within the IGP domain automatically. This
      document specifies that these MAY also be carried within the newly
      defined Stub Link NLRI within the BGP-LS protocol, as the descriptors
      for the inter-AS stub link. The "Local Node Descriptors" in the Stub
      Link NLRI within the BGP-LS NLRI should describe the characteristics of
      ASBRs that are connected across the inter-AS links. </t>

      <t>If the SDN controller knows these information via one of the interior
      router that runs BGP-LS protocol, the SDN controller can rebuild the
      inter-AS topology correctly according to the procedure described in
      <xref target="s-Topology-Reconstruction"/></t>
    </section>

    <section title="BGP-LS Extensions for Inter-AS Link">
      <t>This section proposes to add three new TLVs to be supported in the
      Stub Link NLRI in the BGP-LS NLRI. These new TLVs allow BGP-LS to
      transfer inter-AS information gathered by the SDN controller. </t>

      <t>The following Link Descriptor TLVs are added into the BGP-LS protocol
      :</t>

      <t><figure>
          <artwork><![CDATA[+-----------+---------------------+--------------+----------------+
|  TLV Code | Description         |IS-IS/OSPF TLV| Reference      |
|   Point   |                     |   /Sub-TLV   | (RFC/Section)  |
+-----------+---------------------+--------------+----------------+
|    TBD2   |Remote AS Number     |   24/21      | [RFC9346]/3.3.1|
|           |                     |              | [RFC5392]/3.3.1|
|    TBD3   |IPv4 Remote ASBR ID  |   25/22      | [RFC9346]/3.3.2|
|           |                     |              | [RFC5392]/3.3.2| 
|    TBD4   |IPv6 Remote ASBR ID  |   26/24      | [RFC9346]/3.3.3|
|           |                     |              | [RFC5392]/3.3.3|
+-----------+---------------------+--------------+----------------+
             Figure 3: Stub Link Descriptor TLVs]]></artwork>
        </figure></t>

      <t>Detail encoding of these TLVs are synchronized with the corresponding
      parts in <xref target="RFC9346"/> and <xref target="RFC5392"/>, which
      keeps the BGP-LS protocol agnostic to the underly protocol.</t>

      <section anchor="sec7.1" title="Remote AS Number TLV">
        <t>A new TLV, the remote AS number TLV, is defined for inclusion in
        the link descriptor when advertising inter-AS links. The remote AS
        number TLV specifies the AS number of the neighboring AS to which the
        advertised link connects.</t>

        <t>The remote AS number TLV is TLV type TBD2 (see <xref
        target="s-IANA"/> ) and is 4 octets in length. The format is as
        follows:</t>

        <t><figure>
            <artwork><![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            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                       Remote AS Number                        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
           Figure 4: Remote AS Number TLV Format    ]]></artwork>
          </figure>The Remote AS number field has 4 octets. When only 2 octets
        are used for the AS number, as in current deployments, the left
        (high-order) 2 octets MUST be set to 0. The remote AS number TLV MUST
        be included when a router advertises an inter-AS link.</t>
      </section>

      <section anchor="sec7.2" title="IPv4 Remote ASBR ID">
        <t>A new TLV, which is referred to as the IPv4 remote ASBR ID TLV, is
        defined for inclusion in the link descriptor when advertising inter-AS
        links. The IPv4 remote ASBR ID TLV specifies the IPv4 identifier of
        the remote ASBR to which the advertised inter-AS link connects. This
        could be any stable and routable IPv4 address of the remote ASBR. Use
        of the TE Router ID as specified in the Traffic Engineering router ID
        TLV <xref target="RFC9346"/> is RECOMMENDED.</t>

        <t>The IPv4 remote ASBR ID TLV is TLV type TBD3 (see <xref
        target="s-IANA"/>) and is 4 octets in length. The format of the IPv4
        remote ASBR ID TLV is as follows:</t>

        <t><figure>
            <artwork><![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            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                       Remote ASBR ID                          |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
            Figure 5:  IPv4 Remote ASBR ID TLV Format ]]></artwork>
          </figure></t>

        <t>The IPv4 remote ASBR ID TLV MUST be included if the neighboring
        ASBR has an IPv4 address. If the neighboring ASBR does not have an
        IPv4 address (not even an IPv4 TE Router ID), the IPv6 remote ASBR ID
        TLV MUST be included instead. An IPv4 remote ASBR ID TLV and IPv6
        remote ASBR ID TLV MAY both be present in an inter-AS stub link
        NLRI.</t>
      </section>

      <section anchor="sec7.3" title="IPv6 Remote ASBR ID">
        <t>A new TLV, which is referred to as the IPv6 remote ASBR ID TLV, is
        defined for inclusion in the link descriptor when advertising inter-AS
        links. The IPv6 remote ASBR ID TLV specifies the IPv6 identifier of
        the remote ASBR to which the advertised inter-AS link connects. This
        could be any stable and routable IPv6 address of the remote ASBR. Use
        of the TE Router ID as specified in the IPv6 Traffic Engineering
        router ID TLV <xref target="RFC9346"/> is RECOMMENDED.</t>

        <t>The IPv6 remote ASBR ID TLV is TLV type TBD4 (see <xref
        target="s-IANA"/>) and is 16 octets in length. The format of the IPv6
        remote ASBR ID TLV is as follows:</t>

        <t><figure>
            <artwork><![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            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                       Remote ASBR ID                          |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                       Remote ASBR ID (continued)              |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                       Remote ASBR ID (continued)              |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                       Remote ASBR ID (continued)              |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
           Figure 6:  IPv6 Remote ASBR ID TLV Format]]></artwork>
          </figure></t>

        <t>The IPv6 remote ASBR ID TLV MUST be included if the neighboring
        ASBR has an IPv6 address. If the neighboring ASBR does not have an
        IPv6 address, the IPv4 remote ASBR ID TLV MUST be included instead. An
        IPv4 remote ASBR ID TLV and IPv6 remote ASBR ID TLV MAY both be
        present in an inter-AS stub link NLRI.</t>
      </section>
    </section>

    <section anchor="s-Topology-Reconstruction"
             title="Topology Reconstruction.">
      <t>When SDN controller gets such information from BGP-LS protocol, it
      should find information from the associated router. Based on this
      information it can create a logical topology that contains the link
      between these two border routers. Iterating the above procedures for all
      of the stub links, the SDN controller can automatically retrieve the
      Inter-AS connection topology. </t>
    </section>

    <section title="Security Considerations">
      <t>BGP-LS security is described in [RFC9552]. This addition to BGP-LS
      focuses on the case when one network operated by a single entity has
      several IGP domains that are composited by its backbone network and
      several MANs (Metro-Area- Networks) and Internet Data Centers (IDCs).
      The configuration of these networks operated by the single
      administrative entity creates a &ldquo;walled garden&rdquo;. Within this
      single Administrative Domain, the network operator needs to monitor and
      engineer traffic flows that traverse such a network that spans multiple
      Autonomous Systems. The network operators can obtain this information on
      inter-as topology via the process described in this draft. Using the
      passive-interface features or configuring the Traffic Engineering (TE)
      parameters on the interconnect links will not provide the real-time
      Information for this single Administrative Domain. </t>
    </section>

    <section anchor="s-IANA" title="IANA Considerations">
      <t>This document defines:</t>

      <t><list style="symbols">
          <t>A new BGP NLRI Type: Stub Link NLRI. The codepoint is from the
          "BGP-LS NLRI Types"</t>

          <t>Three new Link Descriptors TLV: Remote AS Number TLV, IPv4 Remote
          ASBR ID, IPv6 Remote ASBR ID. The codepoint are from "BGP-LS Node
          Descriptor, Link Descriptor, Prefix Descriptor, and Attribute TLVs"
          registry.</t>
        </list></t>

      <section title="New BGP-LS NLRI type">
        <t>This document defines a new value in the registry "BGP-LS NLRI
        Types":</t>

        <t><figure>
            <artwork><![CDATA[+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|    Code Point    |   Description  |          Status           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|TBD1(suggestion 7)| Stub Link NLRI |  Allocation from IANA     |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
           Figure 7:  Stub Link NLRI Codepoint]]></artwork>
          </figure></t>
      </section>

      <section title="New Stub Link Descriptors">
        <t>This document defines three new values in the registry "BGP-LS NLRI
        and Attribute TLVs":</t>

        <t><figure>
            <artwork><![CDATA[+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|    Code Point      |   Description        |        Status       |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|TBD2(suggestion 270)|  Remote AS Number    | Allocation from IANA|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|TBD3(suggestion 271)|  IPv4 Remote ASBR ID | Allocation from IANA|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|TBD4(suggestion 272)|  IPv6 Remote ASBR ID | Allocation from IANA|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
           Figure 8:  BGP-LS Link Descriptors TLV]]></artwork>
          </figure></t>
      </section>
    </section>

    <section title="Acknowledgement">
      <t>The author would like to thank Susan Hares, Acee Lindem, Jie Dong,
      Shaowen Ma, Jeff Tantsura and Dhruv Dhody for their valuable comments
      and suggestions.</t>
    </section>
  </middle>

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

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

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

      <?rfc include="reference.RFC.9552"?>
    </references>

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