<?xml version="1.0" encoding="US-ASCII"?>
<!-- edited with XMLSPY v5 rel. 3 U (http://www.xmlspy.com)
     by Daniel M Kohn (private) --> encoding="UTF-8"?>

<!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"?> "rfc2629-xhtml.ent">

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

  <front>
    <title abbrev="OSPF Prefix Originator Extensions">OSPF Prefix Originator
    Extensions</title>
    <seriesInfo name="RFC" value="9084"/>
    <author fullname="Aijun Wang" initials="A" surname="Wang">
      <organization>China Telecom</organization>
      <address>
        <postal>
          <street>Beiqijia Town, Changping
	  <extaddr>Beiqijia Town</extaddr>
	  <street>Changping District</street>
          <city>Beijing</city>
          <region/>
          <code>102209</code>
          <country>China</country>
        </postal>
        <email>wangaj3@chinatelecom.cn</email>
      </address>
    </author>
    <author fullname="Acee Lindem" initials="A" surname="Lindem">
      <organization>Cisco Systems</organization> Systems, Inc.</organization>
      <address>
        <postal>
          <street>301 Midenhall Way</street>
          <city>Cary</city>
          <region>NC</region>
          <code>27513</code>

          <country>USA</country>
          <country>United States of America</country>
        </postal>
        <email>acee@cisco.com</email>
      </address>
    </author>

 <author fullname="Jie Dong" initials="J" initials="J." surname="Dong">
      <organization>Huawei Technologies</organization>
      <address>
        <postal>
          <street/>
          <street>Huawei Campus, No. 156 Beiqing Rd.</street>
          <city>Beijing</city>
          <region/>

          <code/>
          <code>100095</code>
          <country>China</country>
        </postal>
        <email>jie.dong@huawei.com</email>
      </address>
 </author>

    <author fullname="Peter Psenak" initials="P" surname="Psenak">
      <organization>Cisco Systems</organization> Systems, Inc.</organization>
      <address>
        <postal>
          <street>Pribinova Street 10</street>
          <city>Bratislava</city>

          <region>Eurovea
          <extaddr>Eurovea Centre, Central 3</region> 3</extaddr>
          <code>81109</code>
          <country>Slovakia</country>
        </postal>
        <phone/>

        <facsimile/>
        <email>ppsenak@cisco.com</email>
        <uri/>
      </address>
    </author>
    <author fullname="Ketan Talaulikar" initials="K" role="editor" surname="Talaulikar">
      <organization>Cisco Systems</organization> Systems, Inc.</organization>
      <address>
        <postal>
          <street/>
          <city/>
          <region/>
          <code/>
          <country>India</country>
        </postal>
        <email>ketant@cisco.com</email>
      </address>
    </author>
    <date year=""/>

    <area>RTG Area</area>

    <workgroup>LSR Working Group</workgroup> year="2021" month="August" />
    <area>RTG</area>
    <workgroup>LSR</workgroup>
    <keyword>OSPF</keyword>
    <abstract>
      <t>This document defines OSPF extensions to include information
      associated with the node originating a prefix along with the prefix
      advertisement. These extensions do not change the core OSPF route
      computation functionality but provide useful information for network
      analysis, troubleshooting, and use-cases use cases like traffic engineering.</t>
    </abstract>
  </front>
  <middle>
    <section anchor="intro" title="Introduction"> numbered="true" toc="default">
      <name>Introduction</name>
      <t>Prefix attributes are advertised in OSPFv2 <xref target="RFC2328"/> target="RFC2328" format="default"/>
      using the Extended Prefix Opaque Link State Advertisement (LSA) <xref
      target="RFC7684"/> target="RFC7684" format="default"/> and in OSPFv3 <xref target="RFC5340"/> target="RFC5340" format="default"/> using the
      various Extended Prefix LSA types <xref target="RFC8362"/>.</t> target="RFC8362" format="default"/>.</t>
      <t>The procedures for identification of the originating router for a
      prefix in OSPF vary by the type of the prefix and, currently, it is not
      always possible to produce an accurate result. For intra-area prefixes,
      the originating router is identified by the Advertising Router field of
      the area-scoped LSA used for those prefix advertisements. However, for
      the
      inter-area prefixes advertised by the an Area Border Router (ABR), the
      Advertising Router field of their area-scoped LSAs is set to the ABR
      itself and the information about the router originating the prefix
      advertisement is lost in this the process of prefix propagation across
      areas. For Autonomous System (AS) external prefixes, the originating
      router may be considered as the Autonomous System Border Router (ASBR)
      and is identified by the Advertising Router field of the AS-scoped LSA
      used. However, the actual originating router for the prefix may be a
      remote router outside the OSPF domain. Similarly, when an ABR performs
      translation of Not-So-Stubby Area (NSSA) <xref target="RFC3101"/> target="RFC3101"
      format="default"/> LSAs to AS-external LSAs, the information associated
      with the NSSA ASBR (or the router outside the OSPF domain) is not conveyed
      propagated across the OSPF domain.</t>
      <t>While typically the originator of information in OSPF is identified
      by its OSPF Router ID, it does not necessarily represent a reachable
      address for the router since the OSPF Router ID is a 32-bit number.
      There exists number that
      is unique in the OSPF domain.  For OSPFv2, a prevalent common practice is to use
      one of the IPv4 address addresses of the node (e.g. (e.g., a loopback interface) as an
      the OSPF Router ID in the case of
      OSPFv2. ID. However, this cannot be always be assumed and this
      approach does not extend apply to IPv6 addresses with OSPFv3. The IPv4/IPv6
      Router Address Address, as respectively defined in <xref target="RFC3630"/> target="RFC3630"
      format="default"/> and <xref target="RFC5329"/> target="RFC5329" format="default"/> for
      OSPFv2 and OSPFv3 respectively provide OSPFv3, provides an address to reach that the advertising
      router.</t>
      <t>The primary use case for the extensions proposed in this document is
      to be able to identify the originator of a prefix in the network. In
      cases where multiple prefixes are advertised by a given router, it is
      also useful to be able to associate all these prefixes with a single
      router even when prefixes are advertised outside of the area in which
      they originated. It also helps to determine when the same prefix is
      being originated by multiple routers across areas.</t>
      <t>This document proposes extensions to the OSPF protocol for the
      inclusion of information associated with the router originating the
      prefix along with the prefix advertisement. These extensions do not
      change the core OSPF route computation functionality. They provide
      useful information for topology analysis and traffic engineering,
      especially on a controller when this information is advertised as an
      attribute of the prefixes via mechanisms such as Border Gateway Protocol
      Link-State
      - Link State (BGP-LS) <xref target="RFC7752"/> target="RFC7752" format="default"/> <xref
      target="I-D.ietf-idr-bgp-ls-segment-routing-ext"/>.</t>
      target="RFC9085" format="default"/>.</t>
      <section anchor="reqlang" title="Requirements Language"> numbered="true" toc="default">
        <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
        14 BCP&nbsp;14 <xref target="RFC2119"/>
        target="RFC2119" format="default"/> <xref target="RFC8174"/> target="RFC8174"
        format="default"/> when, and only when, they appear in all capitals,
        as shown here.</t>
      </section>
    </section>
    <section anchor="extensions." title="Protocol Extensions"> numbered="true" toc="default">
      <name>Protocol Extensions</name>
      <t>This document defines the Prefix Source OSPF Router-ID and the Prefix
      Source Router Address Sub-TLVs. They are used, respectively, to include
      the Router ID of, and a reachable address of, the router that originates
      the prefix as a prefix attribute.</t>
      <section anchor="SrcRtrTLV" title="Prefix numbered="true" toc="default">
        <name>Prefix Source OSPF Router-ID Sub-TLV"> Sub-TLV</name>
        <t>For OSPFv2, the Prefix Source OSPF Router-ID Sub-TLV is an optional
        Sub-TLV
        sub-TLV of the OSPFv2 Extended Prefix TLV <xref target="RFC7684"/>. target="RFC7684" format="default"/>.
        For OSPFv3, the Prefix Source OSPF Router-ID Sub-TLV is an optional
        Sub-TLV
        sub-TLV of the Intra-Area-Prefix TLV, Inter-Area-Prefix TLV, and
        External-Prefix TLV <xref target="RFC8362"/> target="RFC8362" format="default"/> when originating either
        an IPv4 <xref target="RFC5838"/> target="RFC5838" format="default"/> or an IPv6 prefix advertisement.</t>
        <t>The Prefix Source OSPF Router-ID Sub-TLV has the following
        format:</t>

        <figure>
          <artwork><![CDATA[
<figure title="Prefix Source OSPF Router-ID Sub-TLV Format">
        <artwork name="" type="" align="left" alt=""><![CDATA[
  0                   1                   2                   3
  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |               Type            |              Length           |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                        OSPF Router ID                         |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      Figure 1: Prefix Source OSPF Router-ID Sub-TLV Format

 Where:
 ]]></artwork>
</figure>

        <t><list style="symbols">
            <t>Type: 4

<dl newline="true">
<dt>Where:
</dt>

<dd>
  <dl>

    <dt>Type:</dt>
    <dd>4 for OSPFv2 and 27 for OSPFv3</t>

            <t>Length: 4</t>

            <t>OSPF Router ID : the OSPFv3</dd>

    <dt>Length:</dt>
    <dd>4</dd>

    <dt>OSPF Router ID:
    </dt>
    <dd>the OSPF Router ID of the OSPF router that originated the prefix
    advertisement in the OSPF domain.</t>
          </list></t> domain
    </dd>

  </dl>

</dd>
</dl>

        <t>The parent TLV of a prefix advertisement MAY <bcp14>MAY</bcp14> include
        more than one Prefix Source OSPF Router-ID sub-TLV, Sub-TLV, one corresponding
        to each of the Equal-Cost Multi-Path Multipath (ECMP) nodes that originated the given
        advertised prefix.</t>
        <t>For intra-area prefix advertisements, the Prefix Source OSPF
        Router-ID Sub-TLV MUST <bcp14>MUST</bcp14> be considered invalid and ignored if the OSPF
        Router ID field is not the same as the Advertising Router field in the
        containing LSA. Similar validation cannot be reliably performed for
        inter-area and external prefix advertisements.</t>
        <t>A received Prefix Source OSPF Router-ID Sub-TLV with the OSPF
        Router ID field set to 0 MUST <bcp14>MUST</bcp14> be considered invalid and
        ignored. Additionally, reception of such Sub-TLV SHOULD sub-TLVs
        <bcp14>SHOULD</bcp14> be logged as an error (subject to
        rate-limiting).</t> rate
        limiting).</t>
      </section>
      <section anchor="POTLV" title="Prefix numbered="true" toc="default">
        <name>Prefix Source Router Address Sub-TLV"> Sub-TLV</name>
        <t>For OSPFv2, the Prefix Source Router Address Sub-TLV is an optional
        Sub-TLV
        sub-TLV of the OSPFv2 Extended Prefix TLV <xref target="RFC7684"/>. target="RFC7684" format="default"/>.
        For OSPFv3, the Prefix Source Router Address Sub-TLV is an optional
        Sub-TLV
        sub-TLV of the Intra-Area-Prefix TLV, Inter-Area-Prefix TLV, and
        External-Prefix TLV <xref target="RFC8362"/> target="RFC8362" format="default"/> when originating either
        an IPv4 <xref target="RFC5838"/> target="RFC5838" format="default"/> or an IPv6 prefix advertisement.</t>
        <t>The Prefix Source Router Address Sub-TLV has the following
        format:</t>

        <figure>
          <artwork><![CDATA[
<figure title="Prefix Source Router Address Sub-TLV Format">
        <artwork name="" type="" align="left" alt=""><![CDATA[
  0                   1                   2                   3
  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |               Type            |              Length           |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |              Router Address (4 or 16 octets)                  |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

       Figure 2: Prefix Source Router Address Sub-TLV Format

 Where:
 ]]></artwork>
</figure>

        <t><list style="symbols">
            <t>Type: 5 (suggested)

<dl newline="true">

<dt>Where:
</dt>
<dd>

<dl>

<dt>Type:
</dt>
<dd>5 for OSPFv2 and 28 (suggested) for
            OSPFv3</t>

            <t>Length: 4 OSPFv3
</dd>

<dt>Length:
</dt>
<dd>4 or 16</t>

            <t>Router 16
</dd>

<dt>Router Address: A
</dt>
<dd>A reachable IPv4 or IPv6 router address for the router that originated the
IPv4 or IPv6 prefix advertisement advertisement, respectively. Such an address would be
semantically equivalent to what may be advertised in the OSPFv2 Router Address
TLV <xref
            target="RFC3630"/> target="RFC3630" format="default"/> or in the OSPFv3 Router IPv6
Address TLV <xref
            target="RFC5329"/>.</t>
          </list></t> target="RFC5329" format="default"/>.
</dd>

</dl>

</dd>

</dl>

    <t>The parent TLV of a prefix advertisement MAY <bcp14>MAY</bcp14> include
    more than one Prefix Source Router Address Sub-TLV, one corresponding to
    each of the Equal-Cost Multi-Path Multipath (ECMP) nodes that originated the given
    advertised prefix.</t>
        <t>A received Prefix Source Router Address Sub-TLV that has an invalid
        length (i.e. (i.e., not consistent with the prefix's address family) MUST
        <bcp14>MUST</bcp14> be considered invalid and ignored. Additionally,
        reception of such
        Sub-TLV SHOULD sub-TLVs <bcp14>SHOULD</bcp14> be logged as an
        error (subject to rate-limiting).</t> rate limiting).</t>
      </section>
    </section>

    <section anchor="procedures" title="Elements numbered="true" toc="default">
      <name>Elements of Procedure"> Procedure</name>
      <t>This section describes the procedure for the advertisement of the
      Prefix Source OSPF Router-ID and Prefix Source Router Address Sub-TLVs
      along with the prefix advertisement.</t>
      <t>The OSPF Router ID of the Prefix Source OSPF Router-ID is set to the
      OSPF Router ID of the node originating the prefix in the OSPF
      domain.</t>
      <t>If the originating node is advertising an OSPFv2 Router Address TLV
      <xref target="RFC3630"/> target="RFC3630" format="default"/> or an OSPFv3 Router IPv6
      Address TLV <xref
      target="RFC5329"/>, target="RFC5329" format="default"/>, then the same
      address MUST <bcp14>MUST</bcp14> be used in the Router Address field of the
      Prefix Source Router Address Sub-TLV. When the originating node is not
      advertising such an address, implementations can
      determine select a unique and
      reachable local address (for example, advertised with the N-flag N-Flag set
      <xref target="RFC7684"/> target="RFC7684" format="default"/> or N-bit set <xref
      target="RFC8362"/>) belonging to
      target="RFC8362" format="default"/>) on the originating node to set
      advertise in the Router Address field.</t>
      <t>When an ABR generates inter-area prefix advertisements into its
      non-backbone areas corresponding to an inter-area prefix advertisement
      from the backbone area, the only way to determine the originating node
      information is based on the Prefix Source OSPF Router-ID and Prefix
      Source Router Address Sub-TLVs present in the inter-area prefix
      advertisement originated into the backbone area by an ABR from another
      non-backbone area. The ABR performs its prefix calculation to determine
      the set of nodes that contribute to ECMP paths for the best prefix reachability. prefix. It
      MUST
      <bcp14>MUST</bcp14> only use the prefix originator information only from this
      set of nodes.  The ABR MUST NOT <bcp14>MUST NOT</bcp14> include the Prefix Source
      OSPF Router-ID or the Prefix Source Router Address Sub-TLVs when it is
      unable to determine the information of for the best originating nodes.</t> nodes
      contributing ECMP paths.</t>

      <t>Implementations may support the propagation of the originating node
      information along with a redistributed prefix into the OSPF domain from
      another routing domain. The details of such mechanisms are outside the
      scope of this document. Such implementations may also provide control on
      whether the Router Address in the Prefix Source Router Address Sub-TLV
      is set as the ABSR ASBR node address or as the address of the actual node
      outside the OSPF domain that owns the prefix.</t>

      <t>When translating the NSSA prefix advertisements <xref
      target="RFC3101"/> target="RFC3101"
      format="default"/> to the AS external prefix advertisements, the NSSA
      ABR, ABR
      follows the same procedures as an ABR generating inter-area prefix
      advertisements for the propagation of the originating node
      information.</t>
    </section>
    <section anchor="security" title="Security Considerations"> numbered="true" toc="default">
      <name>Security Considerations</name>
      <t>Since this document extends the OSPFv2 Extended Prefix LSA, the
      security considerations for <xref target="RFC7684"/> target="RFC7684" format="default"/> are applicable.
      Similarly, since this document extends the OSPFv3
      E-Intra-Area-Prefix-LSA, E-Inter-Area-Prefix-LSA, E-AS-External LSA, E-AS-External-LSA, and
      E-NSSA-LSA, the security considerations for <xref target="RFC8362"/> target="RFC8362" format="default"/> are
      applicable. The new sub-TLVs introduced in this document are optional
      and do not affect the OSPF route computation and therefore do not affect
      the security aspects of OSPF protocol operations.</t>

      <t>A rogue node that can inject prefix advertisements may use the new
      extensions introduced in this document to indicate an incorrect advertise bogus prefix
      source information.</t>
    </section>
    <section anchor="operational" title="Operational Considerations"> numbered="true" toc="default">
      <name>Operational Considerations</name>
      <t>Consideration should be given to the operational impact of the
      increase in the size of the OSPF Link-State Database as a result of the
      protocol extensions in this document. Based on deployment design and
      requirements, a subset of prefixes may be identified for which the
      originating node information needs is required to be included with their in prefix
      advertisements.</t>

      <t>The propagation of the prefix source node information when doing for prefix
      advertisements advertised across an OSPF area or domain boundaries results in
      the exposure of node will
      expose information outside of an area or domain within
      which where it is would normally
      be hidden or abstracted by the base OSPF protocol.  Based on deployment
      design and requirements, a subset of prefixes may be
      identified for which the propagation of the originating node information across area
      or domain boundaries is disabled at may be limited to a subset of prefixes in the ABRs
      or ASBRs
      respectively.</t> ASBRs, respectively.
</t>

      <t>The identification of the node that is originating a specific prefix
      in the network may aid in the debugging of issues related to prefix
      reachability within an OSPF network.</t>
    </section>
    <section anchor="iana" title="IANA Considerations">
      <t>This document requests numbered="true" toc="default">
      <name>IANA Considerations</name>
      <t>Per this document, IANA for the allocation of has allocated the following codepoints from
      the "OSPFv2 Extended Prefix TLV Sub-TLVs" registry under the "Open
      Shortest Path First v2 (OSPFv2) Parameters" registry.</t>

      <figure>
        <artwork><![CDATA[
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Code  |        Description            |    IANA Allocation    |
| Point |                               |        Status         |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|   4   | Prefix Source OSPF Router-ID  | early allocation done |
|   5   | Prefix Source Router Address  |     suggested         |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

    Figure 3:  Codepoints

<table anchor="extended_prefix">
  <name>Codepoints in OSPFv2 Extended Prefix TLV Sub-TLVs

]]></artwork>
      </figure>

      <t>This document requests Sub-TLVs</name>
  <thead>
    <tr>
      <th>Value</th>
      <th>Description</th>
      <th>Reference</th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <td>4</td>
      <td>Prefix Source OSPF Router-ID</td>
      <td>RFC 9084</td>
    </tr>
    <tr>
      <td>5</td>
      <td>Prefix Source Router Address</td>
      <td>RFC 9084</td>
    </tr>

  </tbody>
</table>

      <t>Per this document, IANA for the allocation of has allocated the following codepoints from
      the "OSPFv3 Extended-LSA Sub-TLVs" registry under the "Open Shortest
      Path First v3 (OSPFv3) Parameters" registry.</t>

      <t><figure>
          <artwork><![CDATA[
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Code  |         Description           |    IANA Allocation    |
| Point |                               |        Status         |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  27   | Prefix Source OSPF Router-ID  | early allocation done |
|  28   | Prefix Source Router Address  |      suggested        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

    Figure 4:  Codepoints

<table anchor="extended_lsa">
  <name>Codepoints in OSPFv3 Extended-LSA Sub-TLVs

]]></artwork>
        </figure></t> Sub-TLVs</name>
  <thead>
    <tr>
      <th>Value</th>
      <th>Description</th>
      <th>Reference</th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <td>27</td>
      <td>Prefix Source OSPF Router-ID</td>
      <td>RFC 9084</td>
    </tr>
    <tr>
      <td>28</td>
      <td>Prefix Source Router Address</td>
      <td>RFC 9084</td>
    </tr>

  </tbody>
</table>
    </section>

  </middle>
  <back>
    <references>
      <name>References</name>
      <references>
        <name>Normative References</name>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2328.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3630.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5340.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7684.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5329.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8362.xml"/>
      </references>
      <references>
        <name>Informative References</name>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3101.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5838.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7752.xml"/>

<reference anchor='RFC9085' target='https://www.rfc-editor.org/info/rfc9085'>
  <front>
    <title>Border Gateway Protocol - Link State (BGP-LS) Extensions for Segment Routing</title>

    <author initials='S' surname='Previdi' fullname='Stefano Previdi'>
      <organization />
    </author>

    <author initials='K' surname='Talaulikar' fullname='Ketan Talaulikar' role='editor'>
      <organization />
    </author>

    <author initials='C' surname='Filsfils' fullname='Clarence Filsfils'>
      <organization />
    </author>

    <author initials='H' surname='Gredler' fullname='Hannes Gredler'>
      <organization />
    </author>

    <author initials='M' surname='Chen' fullname='Mach(Guoyi) Chen'>
      <organization />
    </author>

    <date month='August' year='2021' />

  </front>
  <seriesInfo name="RFC" value="9085"/>
  <seriesInfo name="DOI" value="10.17487/RFC9085"/>
</reference>

      </references>
    </references>

 <section anchor="ack" title="Acknowledgement"> numbered="false" toc="default">
      <name>Acknowledgement</name>
<t>Many thanks to Les Ginsberg <contact fullname="Les Ginsberg"/> for his suggestions
on this draft. Also document. Also, thanks to Jeff Tantsura, Rob Shakir, Gunter <contact fullname="Jeff Tantsura"/>,
<contact fullname="Rob Shakir"/>, <contact fullname="Gunter Van De Velde, Goethals Dirk,
      Smita Selot, Shaofu Peng, John E Drake and Baalajee S de
Velde"/>, <contact fullname="Goethals Dirk"/>, <contact fullname="Smita
Selot"/>, <contact fullname="Shaofu Peng"/>, <contact fullname="John E. Drake"/>, and <contact fullname="Baalajee S."/> for their review and
valuable comments. The authors would also like to thank Alvaro
      Retana <contact
fullname="Alvaro Retana"/> for his detailed review and suggestions for
the improvement of this document.</t>
 </section>
  </middle>

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

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

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

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

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

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

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

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

    <references title="Informative References">
      <?rfc include="reference.RFC.3101"?>

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

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

      <?rfc include="reference.I-D.ietf-idr-bgp-ls-segment-routing-ext.xml"?>
    </references>

  </back>
</rfc>