<?xml version='1.0' encoding='utf-8'?>
<!DOCTYPE rfc [
  <!ENTITY nbsp    "&#160;">
  <!ENTITY zwsp   "&#8203;">
  <!ENTITY nbhy   "&#8209;">
  <!ENTITY wj     "&#8288;">
]>
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
<!-- generated by https://github.com/cabo/kramdown-rfc version 1.7.17 (Ruby 3.0.2) -->
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft-dong-idr-bgp-nrp-policy-00" category="std" consensus="true" submissionType="IETF" version="3">
  <!-- xml2rfc v2v3 conversion 3.22.0 -->
  <front>
    <title abbrev="BGP NRP Policy">Advertising Network Resource Partition (NRP) Policy in BGP</title>
    <seriesInfo name="Internet-Draft" value="draft-dong-idr-bgp-nrp-policy-00"/>
    <author initials="J." surname="Dong" fullname="Jie Dong">
      <organization>Huawei Technologies</organization>
      <address>
        <postal>
          <street>No. 156 Beiqing Road</street>
          <city>Beijing</city>
          <country>China</country>
        </postal>
        <email>jie.dong@huawei.com</email>
      </address>
    </author>
    <author initials="K." surname="Zhang" fullname="Ka Zhang">
      <organization>Huawei Technologies</organization>
      <address>
        <postal>
          <street>No. 156 Beiqing Road</street>
          <city>Beijing</city>
          <country>China</country>
        </postal>
        <email>zhangka@huawei.com</email>
      </address>
    </author>
    <date year="2024" month="July" day="08"/>
    <area>Routing</area>
    <workgroup>IDR</workgroup>
    <keyword>Internet-Draft</keyword>
    <abstract>
      <?line 42?>

<t>A Network Resource Partition (NRP) is a subset of the network resources and the associated policies on each of a connected set of links in the underlay network. An NRP could be used as the underlay to support one or a group of enhanced VPN services or RFC 9543 network slice services. For the instantiation of an NRP, NRP-specific information and policy need to be advertised to the network nodes involved in the NRP, so that the NRP-specific state can be created and NRP-specific behavior can be enabled. The mechanism for instantiating NRPs on the involved network elements is called NRP Policy.</t>
      <t>This document specifies the BGP extensions for advertising NRP Policy information to the set of network nodes involved in the NRP. The NRP Policy is advertised using a separate BGP Subsequent Address Family Identifier (SAFI) of the BGP Link-State (BGP-LS) Address Family, which allows to reuse the TLVs defined in BGP-LS without impacting the base BGP and BGP-LS functionality.</t>
    </abstract>
  </front>
  <middle>
    <?line 49?>

<section anchor="intro">
      <name>Introduction</name>
      <t><xref target="RFC9543"/> discusses the general framework, the components, and interfaces for requesting and operating network slices using IETF technologies. <xref target="RFC9543"/> also introduces the concept of the Network Resource Partition (NRP), which is a subset of the buffer/queuing/scheduling resources and associated policies on each of a connected set of links in the underlay network. An NRP can be to support one or a group of RFC 9543 network slice services.</t>
      <t><xref target="I-D.ietf-teas-enhanced-vpn"/> specifies the framework of NRP-based enhanced VPNs and describes the candidate component technologies in different network planes and network layers. Enhanced VPNs aim to deliver VPN services with enhanced characteristics, such as guaranteed resources, latency, jitter, etc., so as to support customers requirements on connectivity services with these enhanced characteristics. RFC 9543 Network Slice is considered as one target use case of enhanced VPNs. An NRP could be used as the underlay of one or a group of enhanced VPN services.</t>
      <t>To meet the requirement of network slice or enhanced VPN services, a number of NRPs can be created, each with a subset of network resources allocated on network nodes and links in a customized topology of the physical network.</t>
      <t>The NRP-specific resource and policy information need to be advertised to the set of network nodes involved in the NRP, so that the NRP-specific state can be created, and NRP-specific behavior can be enabled. Such information may be advertised by a network controller, a BGP route reflector, or a BGP speaker which is responsible for the NRP instantiation. The mechanism for instantiating NRPs on the involved network elements is called NRP Policy <xref target="I-D.ietf-teas-ns-ip-mpls"/>.</t>
      <t>This document specifies the BGP extensions for advertising NRP Policy to the set of network nodes and links. The NRP information is advertised using a separate BGP Subsequent Address Family Identifier (SAFI) of BGP Link-State (BGP-LS) Address Family, this allows to reuse the TLVs defined for BGP-LS without impacting the base BGP and BGP-LS functionality.</t>
      <section anchor="requirements-language">
        <name>Requirements Language</name>
        <t>The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
"<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to be interpreted as
described in BCP 14 <xref target="RFC2119"/> <xref target="RFC8174"/> when, and only when, they
appear in all capitals, as shown here.</t>
        <?line -18?>

</section>
    </section>
    <section anchor="bgp-extensions-for-nrp-policy-advertisement">
      <name>BGP Extensions for NRP Policy Advertisement</name>
      <t>According to <xref target="RFC9543"/>, each NRP consists of a subset of network resources and the associated policies on a set of links in the underlay network. BGP-LS <xref target="RFC9552"/> defines the mechanisms for the advertisement of Node, Link, and Prefix NLRI types and their associated attributes via BGP. The NRP-specific resource and policy information can be described as NRP-specific node and link attributes.</t>
      <t>This document introduces a BGP subsequent address family (SAFI) called "NRP Policy" for the BGP-LS address family. The SAFI value is TBD1. The encoding of the NRP Policy NLRI and the associated attributes are described in the following sub-sections.</t>
      <section anchor="bgp-nrp-policy-nlri">
        <name>BGP NRP Policy NLRI</name>
        <t>The format of the BGP-LS NLRI is reused for the NRP Policy NLRI. And the encoding of BGP-LS NLRI type "NRP-link" as defined in <xref target="I-D.dong-idr-bgp-ls-scalable-nrp"/> is reused for the NRP Policy Link NLRI. The definition of other NRLI Types for NRP Policy NLRI is for further study. The format of NRP Policy Link NLRI is shown as below:</t>
        <figure anchor="ref-to-fig1">
          <name>Encoding of NRP-Policy NLRI</name>
          <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
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |            NLRI Type          |     Total NLRI Length         |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                                                               |
 //                  NRP Policy NLRI (variable)                 //
 |                                                               |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

]]></artwork>
        </figure>
        <figure anchor="ref-to-fig2">
          <name>Encoding of NRP-Policy Link NLRI</name>
          <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                          |
 +                           (8 octets)                          +
 |                                                               |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 //            Local Node Descriptors TLV (variable)            //
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 //            Remote Node Descriptors TLV (variable)           //
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 //               Link Descriptors TLVs (variable)              //
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 //                NRP Descriptors TLV  (variable)              //
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

]]></artwork>
        </figure>
        <t>The encoding and semantics of Protocol-ID, Identifier, Local Node Descriptors, Remote Node Descriptors and the Link Descriptors are the same as defined in <xref target="RFC9552"/>.</t>
        <t>The NRP Descriptors TLV as defined in <xref target="I-D.dong-idr-bgp-ls-scalable-nrp"/> is reused in the NRP Policy NLRI. It contains descriptors of the NRP which the link participates in. This is a mandatory TLV for NRP-Policy Link NLRI. The length of this TLV is variable. The value contains one or more NRP Descriptor sub-TLVs defined in <xref target="I-D.dong-idr-bgp-ls-scalable-nrp"/>.</t>
        <t>Among the NRP Descriptors Sub-TLVs, the NRP ID sub-TLV is mandatory in the NRP Descriptors. There <bcp14>MUST</bcp14> be only one instance of NRP ID Sub-TLV present in the NRP Descriptors.</t>
      </section>
      <section anchor="nrp-policy-attribute">
        <name>NRP Policy Attribute</name>
        <t>The BGP-LS Attribute, when associated with an NRP Policy NLRI, is used for the advertisement of the information of the NRP Policy. The NRP Attribute TLVs as defined in <xref target="I-D.dong-idr-bgp-ls-scalable-nrp"/> are reused for the advertisement of NRP Policy information.</t>
        <t>Specifically, the following NRP Attribute TLVs can be carried in BGP-LS Attribute which is associated with an NRP Policy NLRI.</t>
        <table anchor="ref-to-tab1">
          <name>BGP-LS Attribute TLVs used for NRP Policy</name>
          <thead>
            <tr>
              <th align="left">TLV Code Point</th>
              <th align="left">Description</th>
              <th align="left">Length</th>
            </tr>
          </thead>
          <tbody>
            <tr>
              <td align="left">1089</td>
              <td align="left">Maximum Link Bandwidth</td>
              <td align="left">4</td>
            </tr>
            <tr>
              <td align="left">TBD</td>
              <td align="left">NRP Hierarchy</td>
              <td align="left">4</td>
            </tr>
          </tbody>
        </table>
        <t>The Maximum Link Bandwidth TLV as defined in <xref target="RFC9552"/> is used as an NRP Policy Attribute TLV to indicate the set of link bandwidth to be allocated to an NRP. It is mandatory in the BGP-LS Attribute which is associated with an NRP-Policy NLRI.</t>
        <t>The NRP Hierarchy Attribute TLV as defined in <xref target="I-D.dong-idr-bgp-ls-scalable-nrp"/> is used to indicate the Hierarchy of the NRP. When an NRP is derived from another NRP (called parent NRP), the Parent NRP ID TLV as defined in <xref target="I-D.dong-idr-bgp-ls-scalable-nrp"/>is used to carry the identifier of the parent NRP.</t>
        <t>Other link attributes <bcp14>MAY</bcp14> also be used as NRP Policy Link Attribute TLVs. The details are for further study.</t>
      </section>
    </section>
    <section anchor="nrp-policy-operations">
      <name>NRP Policy Operations</name>
      <t>This section describes the operation of BGP based NRP Policy. BGP is used for the origination and propagation of the NRP Policy information, while the installation and use of NRP Policy are out of the scope of BGP.</t>
      <section anchor="advertisement-of-nrp-policy">
        <name>Advertisement of NRP Policy</name>
        <t>The NRP Policy information used for NRP instantiation can be computed by a network controller, or derived from the NRP Policy information received from a network slice controller, and originated by a BGP speaker. The NRP Policy information for each network node involved in the NRP could be different. In order to control the target nodes to receive a specific NRP Policy NLRI, one or more Node Target extended communities <xref target="I-D.ietf-idr-node-target-ext-comm"/> <bcp14>SHOULD</bcp14> be attached to the NRP Policy NLRI, where each node target identifies the intended nodes for the advertised NRP Policy information.</t>
        <t>If the originator has direct BGP peer relationship with an target node of the NRP Policy, the NRP Policy NLRI can be advertised directly to the node, in such a case, the node target extended community <bcp14>MAY</bcp14> not be attached, and the NO_ADVERTISE community <bcp14>MUST</bcp14> be attached.</t>
      </section>
      <section anchor="reception-of-nrp-policy">
        <name>Reception of NRP Policy</name>
        <t>On reception of an NRP Policy NLRI, a BGP speaker first determines if the NRP Policy is valid and eligible. An NRP Policy is considered valid and eligible if the following checks are passed.</t>
        <t>a. The NRP Policy NLRI and the associated BGP-LS Attribute pass the syntactic validation as described in Section 8.2.2 of <xref target="RFC9552"/>}.
b. The BGP Update message of NRP Policy NLRI contains either a node target extended community which identifies the local node, or a NO_ADVERTISE community. 
c. The NRP Policy Link NLRI identifies a local interface of the network node.
d. The bandwidth value of the Maximum link bandwidth TLV in the BGP-LS Attribute is smaller than the unreserved bandwidth of the interface.</t>
        <t>If the NRP Policy Link NLRI is considered valid and eligible, the BGP speaker performs the decision process for selection of the best route. The selected best route of NRP Policy Link NLRI is used to instantiate the NRP-specific state and behavior on the selected interface of the network node.</t>
        <t>If one or more node targets are present and none of them matches the local BGP identifier, then the NRP Policy NLRI is not usable on the receiver node.</t>
      </section>
      <section anchor="propagation-of-nrp-policy">
        <name>Propagation of NRP Policy</name>
        <t>NRP Policy NLRIs that have the NO_ADVERTISE community attached to them <bcp14>MUST NOT</bcp14> be propagated further. The propagation of NRP Policy NLRIs which are attached with one or more node target extended communities <bcp14>SHOULD</bcp14> follow the rules as specified in <xref target="I-D.ietf-idr-node-target-ext-comm"/>.</t>
      </section>
    </section>
    <section anchor="security-considerations">
      <name>Security Considerations</name>
      <t>The security considerations in <xref target="RFC4271"/> and <xref target="RFC9552"/> apply to this document.</t>
    </section>
    <section anchor="iana-considerations">
      <name>IANA Considerations</name>
      <t>IANA is requested to assign a new code point for SAFI "NRP Policy" under the "Subsequent Address Family Identifiers (SAFI) Parameters" registry.</t>
      <table anchor="ref-to-tab3">
        <name>BGP SAFI Code Point</name>
        <thead>
          <tr>
            <th align="left">Value</th>
            <th align="left">Description</th>
            <th align="left">Reference</th>
          </tr>
        </thead>
        <tbody>
          <tr>
            <td align="left">TBD1</td>
            <td align="left">NRP Policy</td>
            <td align="left">This document</td>
          </tr>
        </tbody>
      </table>
    </section>
    <section anchor="acknowledgements">
      <name>Acknowledgements</name>
      <t>The authors would like to thank XXX for the review and discussion of this document.</t>
    </section>
  </middle>
  <back>
    <references>
      <name>References</name>
      <references anchor="sec-normative-references">
        <name>Normative References</name>
        <reference anchor="RFC9543" target="https://www.rfc-editor.org/info/rfc9543" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9543.xml">
          <front>
            <title>A Framework for Network Slices in Networks Built from IETF Technologies</title>
            <author fullname="A. Farrel" initials="A." role="editor" surname="Farrel"/>
            <author fullname="J. Drake" initials="J." role="editor" surname="Drake"/>
            <author fullname="R. Rokui" initials="R." surname="Rokui"/>
            <author fullname="S. Homma" initials="S." surname="Homma"/>
            <author fullname="K. Makhijani" initials="K." surname="Makhijani"/>
            <author fullname="L. Contreras" initials="L." surname="Contreras"/>
            <author fullname="J. Tantsura" initials="J." surname="Tantsura"/>
            <date month="March" year="2024"/>
            <abstract>
              <t>This document describes network slicing in the context of networks built from IETF technologies. It defines the term "IETF Network Slice" to describe this type of network slice and establishes the general principles of network slicing in the IETF context.</t>
              <t>The document discusses the general framework for requesting and operating IETF Network Slices, the characteristics of an IETF Network Slice, the necessary system components and interfaces, and the mapping of abstract requests to more specific technologies. The document also discusses related considerations with monitoring and security.</t>
              <t>This document also provides definitions of related terms to enable consistent usage in other IETF documents that describe or use aspects of IETF Network Slices.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="9543"/>
          <seriesInfo name="DOI" value="10.17487/RFC9543"/>
        </reference>
        <reference anchor="I-D.ietf-teas-enhanced-vpn" target="https://datatracker.ietf.org/doc/html/draft-ietf-teas-enhanced-vpn-20" xml:base="https://bib.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-teas-enhanced-vpn.xml">
          <front>
            <title>A Framework for Network Resource Partition (NRP) based Enhanced Virtual Private Networks</title>
            <author fullname="Jie Dong" initials="J." surname="Dong">
              <organization>Huawei</organization>
            </author>
            <author fullname="Stewart Bryant" initials="S." surname="Bryant">
              <organization>University of Surrey</organization>
            </author>
            <author fullname="Zhenqiang Li" initials="Z." surname="Li">
              <organization>China Mobile</organization>
            </author>
            <author fullname="Takuya Miyasaka" initials="T." surname="Miyasaka">
              <organization>KDDI Corporation</organization>
            </author>
            <author fullname="Young Lee" initials="Y." surname="Lee">
              <organization>Samsung</organization>
            </author>
            <date day="14" month="June" year="2024"/>
            <abstract>
              <t>This document describes the framework for Network Resource Partition (NRP) based Enhanced Virtual Private Networks (VPNs) to support the needs of applications with specific traffic performance requirements (e.g., low latency, bounded jitter). An NRP represents a subset of network resources and associated policies in the underlay network. NRP-based Enhanced VPNs leverage the VPN and Traffic Engineering (TE) technologies and add characteristics that specific services require beyond those provided by conventional VPNs. Typically, an NRP-based enhanced VPN will be used to underpin network slicing, but could also be of use in its own right providing enhanced connectivity services between customer sites. This document also provides an overview of relevant technologies in different network layers, and identifies some areas for potential new work.</t>
            </abstract>
          </front>
          <seriesInfo name="Internet-Draft" value="draft-ietf-teas-enhanced-vpn-20"/>
        </reference>
        <reference anchor="RFC2119" target="https://www.rfc-editor.org/info/rfc2119" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml">
          <front>
            <title>Key words for use in RFCs to Indicate Requirement Levels</title>
            <author fullname="S. Bradner" initials="S." surname="Bradner"/>
            <date month="March" year="1997"/>
            <abstract>
              <t>In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</t>
            </abstract>
          </front>
          <seriesInfo name="BCP" value="14"/>
          <seriesInfo name="RFC" value="2119"/>
          <seriesInfo name="DOI" value="10.17487/RFC2119"/>
        </reference>
        <reference anchor="RFC8174" target="https://www.rfc-editor.org/info/rfc8174" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml">
          <front>
            <title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</title>
            <author fullname="B. Leiba" initials="B." surname="Leiba"/>
            <date month="May" year="2017"/>
            <abstract>
              <t>RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings.</t>
            </abstract>
          </front>
          <seriesInfo name="BCP" value="14"/>
          <seriesInfo name="RFC" value="8174"/>
          <seriesInfo name="DOI" value="10.17487/RFC8174"/>
        </reference>
        <reference anchor="RFC9552" target="https://www.rfc-editor.org/info/rfc9552" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9552.xml">
          <front>
            <title>Distribution of Link-State and Traffic Engineering Information Using BGP</title>
            <author fullname="K. Talaulikar" initials="K." role="editor" surname="Talaulikar"/>
            <date month="December" year="2023"/>
            <abstract>
              <t>In many environments, a component external to a network is called upon to perform computations based on the network topology and the current state of the connections within the network, including Traffic Engineering (TE) information. This is information typically distributed by IGP routing protocols within the network.</t>
              <t>This document describes a mechanism by which link-state and TE information can be collected from networks and shared with external components using the BGP routing protocol. This is achieved using a BGP Network Layer Reachability Information (NLRI) encoding format. The mechanism applies to physical and virtual (e.g., tunnel) IGP links. The mechanism described is subject to policy control.</t>
              <t>Applications of this technique include Application-Layer Traffic Optimization (ALTO) servers and Path Computation Elements (PCEs).</t>
              <t>This document obsoletes RFC 7752 by completely replacing that document. It makes some small changes and clarifications to the previous specification. This document also obsoletes RFC 9029 by incorporating the updates that it made to RFC 7752.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="9552"/>
          <seriesInfo name="DOI" value="10.17487/RFC9552"/>
        </reference>
        <reference anchor="I-D.dong-idr-bgp-ls-scalable-nrp" target="https://datatracker.ietf.org/doc/html/draft-dong-idr-bgp-ls-scalable-nrp-01" xml:base="https://bib.ietf.org/public/rfc/bibxml3/reference.I-D.dong-idr-bgp-ls-scalable-nrp.xml">
          <front>
            <title>BGP Link State Extensions for Scalable Network Resource Partition</title>
            <author fullname="Jie Dong" initials="J." surname="Dong">
              <organization>Huawei Technologies</organization>
            </author>
            <author fullname="Yongqing Zhu" initials="Y." surname="Zhu">
              <organization>China Telecom</organization>
            </author>
            <author fullname="Zehua Hu" initials="Z." surname="Hu">
              <organization>China Telecom</organization>
            </author>
            <author fullname="Jun Ge" initials="J." surname="Ge">
              <organization>Huawei Technologies</organization>
            </author>
            <author fullname="KaZhang" initials="" surname="KaZhang">
              <organization>Huawei Technologies</organization>
            </author>
            <date day="23" month="April" year="2024"/>
            <abstract>
              <t>Enhanced VPNs aim to deliver VPN services with enhanced characteristics, such as guaranteed resources, latency, jitter, etc., so as to support customers requirements on connectivity services with these enhanced characteristics. Enhanced VPN requires integration between the overlay VPN connectivity and the characteristics provided by the underlay network. A Network Resource Partition (NRP) is a subset of the network resources and associated policies on each of a connected set of links in the underlay network. An NRP could be used as the underlay to support one or a group of enhanced VPN services. The NRP-specific resource information and status needs to be collected from network nodes and reported to the network controller for NRP-specific management and path computation. This document specifies the BGP Link-State (BGP-LS) mechanisms with necessary extensions to advertise the information of NRPs to network controller in a scalable way. The NRP information is advertised using a separate type of BGP-LS NLRI, which allows flexible update of NRP information without impacting the based link state information.</t>
            </abstract>
          </front>
          <seriesInfo name="Internet-Draft" value="draft-dong-idr-bgp-ls-scalable-nrp-01"/>
        </reference>
        <reference anchor="I-D.ietf-idr-node-target-ext-comm" target="https://datatracker.ietf.org/doc/html/draft-ietf-idr-node-target-ext-comm-02" xml:base="https://bib.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-idr-node-target-ext-comm.xml">
          <front>
            <title>BGP Extended Community for Identifying the Target Nodes</title>
            <author fullname="Jie Dong" initials="J." surname="Dong">
              <organization>Huawei Technologies</organization>
            </author>
            <author fullname="Shunwan Zhuang" initials="S." surname="Zhuang">
              <organization>Huawei Technologies</organization>
            </author>
            <author fullname="Gunter Van de Velde" initials="G." surname="Van de Velde">
              <organization>Nokia</organization>
            </author>
            <author fullname="Jeff Tantsura" initials="J." surname="Tantsura">
              <organization>Nvidia</organization>
            </author>
            <date day="4" month="March" year="2024"/>
            <abstract>
              <t>BGP has been used to distribute different types of routing and policy information. In some cases, the information distributed may be only intended for one or a particular group of BGP nodes in the network. Currently BGP does not have a generic mechanism of designating the target nodes of the routing information. This document defines a new type of BGP Extended Community called "Node Target" for this purpose.</t>
            </abstract>
          </front>
          <seriesInfo name="Internet-Draft" value="draft-ietf-idr-node-target-ext-comm-02"/>
        </reference>
        <reference anchor="RFC4271" target="https://www.rfc-editor.org/info/rfc4271" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4271.xml">
          <front>
            <title>A Border Gateway Protocol 4 (BGP-4)</title>
            <author fullname="Y. Rekhter" initials="Y." role="editor" surname="Rekhter"/>
            <author fullname="T. Li" initials="T." role="editor" surname="Li"/>
            <author fullname="S. Hares" initials="S." role="editor" surname="Hares"/>
            <date month="January" year="2006"/>
            <abstract>
              <t>This document discusses the Border Gateway Protocol (BGP), which is an inter-Autonomous System routing protocol.</t>
              <t>The primary function of a BGP speaking system is to exchange network reachability information with other BGP systems. This network reachability information includes information on the list of Autonomous Systems (ASes) that reachability information traverses. This information is sufficient for constructing a graph of AS connectivity for this reachability from which routing loops may be pruned, and, at the AS level, some policy decisions may be enforced.</t>
              <t>BGP-4 provides a set of mechanisms for supporting Classless Inter-Domain Routing (CIDR). These mechanisms include support for advertising a set of destinations as an IP prefix, and eliminating the concept of network "class" within BGP. BGP-4 also introduces mechanisms that allow aggregation of routes, including aggregation of AS paths.</t>
              <t>This document obsoletes RFC 1771. [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="4271"/>
          <seriesInfo name="DOI" value="10.17487/RFC4271"/>
        </reference>
      </references>
      <references anchor="sec-informative-references">
        <name>Informative References</name>
        <reference anchor="I-D.ietf-teas-ns-ip-mpls" target="https://datatracker.ietf.org/doc/html/draft-ietf-teas-ns-ip-mpls-04" xml:base="https://bib.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-teas-ns-ip-mpls.xml">
          <front>
            <title>Realizing Network Slices in IP/MPLS Networks</title>
            <author fullname="Tarek Saad" initials="T." surname="Saad">
              <organization>Cisco Systems Inc.</organization>
            </author>
            <author fullname="Vishnu Pavan Beeram" initials="V. P." surname="Beeram">
              <organization>Juniper Networks</organization>
            </author>
            <author fullname="Jie Dong" initials="J." surname="Dong">
              <organization>Huawei Technologies</organization>
            </author>
            <author fullname="Bin Wen" initials="B." surname="Wen">
              <organization>Comcast</organization>
            </author>
            <author fullname="Daniele Ceccarelli" initials="D." surname="Ceccarelli">
              <organization>Cisco Systems Inc.</organization>
            </author>
            <author fullname="Joel M. Halpern" initials="J. M." surname="Halpern">
              <organization>Ericsson</organization>
            </author>
            <author fullname="Shaofu Peng" initials="S." surname="Peng">
              <organization>ZTE Corporation</organization>
            </author>
            <author fullname="Ran Chen" initials="R." surname="Chen">
              <organization>ZTE Corporation</organization>
            </author>
            <author fullname="Xufeng Liu" initials="X." surname="Liu">
              <organization>IBM Corporation</organization>
            </author>
            <author fullname="Luis M. Contreras" initials="L. M." surname="Contreras">
              <organization>Telefonica</organization>
            </author>
            <author fullname="Reza Rokui" initials="R." surname="Rokui">
              <organization>Ciena</organization>
            </author>
            <author fullname="Luay Jalil" initials="L." surname="Jalil">
              <organization>Verizon</organization>
            </author>
            <date day="28" month="May" year="2024"/>
            <abstract>
              <t>Realizing network slices may require the Service Provider to have the ability to partition a physical network into multiple logical networks of varying sizes, structures, and functions so that each slice can be dedicated to specific services or customers. Multiple network slices can be realized on the same network while ensuring slice elasticity in terms of network resource allocation. This document describes a scalable solution to realize network slicing in IP/MPLS networks by supporting multiple services on top of a single physical network by relying on compliant domains and nodes to provide forwarding treatment (scheduling, drop policy, resource usage) on to packets that carry identifiers that indicate the slicing service that is to be applied to the packets.</t>
            </abstract>
          </front>
          <seriesInfo name="Internet-Draft" value="draft-ietf-teas-ns-ip-mpls-04"/>
        </reference>
      </references>
    </references>
  </back>
  <!-- ##markdown-source:
H4sIAAAAAAAAA81a/XLcthH//2b0Dqj8j90ez5ZsJ7YmTXq25FiJLKmS7Cbt
dDo4EneHiCQYgJRysZVn6bP0ybq7AEiAdyfJjtypPGOJ+NzP3+4CSJJkY1DL
Ohc7bJxdCF1LI8sZOxT1pdLn7EQY1ehUsGMOXbVUJbt/eHL8gB2rXKYLJkv2
4tvjjQGfTLS42MEPBv2ue2OQqbTkBSyeaT6tk0yVs0RmOpnMqqTUVVLRuOTR
o42BmhiVi1qYnY1BU2Xc/oW/4VcKv2ZKL3aYqTPG2MbANJNCGgMUnS0q2GB/
7+zVxmBjICu9w2rdmHr70aPnj7aBNi34DjtRTQ2cbQyQr5lWTQVzdk82Budi
AU0ZfJW10KWok12kFdfiTT1XGrYHIQGrZod9N2K7Cldhlq3vpPANSs94KX/l
KKQd9rrhl0KyM5HOS5WrmRQGxoiCy3yH/STFCEXxlzmNGqWqgE5TayHqHXao
Rmzr6RfshZA/oy5OFM+gO5U1sA+NPxEbLFVNWaNEXs5lyZHclsrvR+zvcx6Q
+T1vGz6CzF9xyjm/Yyo3BqXSBex/gYoFhZXT6Hs0GhEzScL4BHbjKelifLNN
SsM4A7swomZqyuq5YKWbo90cGFFm1MONUakEs8oYGSFwzmAlwdM5TuZAeVmK
FPvderkszw1aPE5vykzonC/8DiM2LsnygeE8YxMYYWAqN/HoWgGBVaU0rFgK
UAZsRMaIG4gSBJ7CrHfHh7CpvpBIMIw5efWSPX/65HHLjgGCRTtkxF7BINwH
tF/zspakXWKDiBrif4mpRCqnMmWtxGEMisM6ISwOWwOBQDt3UGAbQkGWKhMo
hAuVX0CvkwbtYXAkr31Dtx/QVAuWAi2wdAreiELFjaNREzHnFxIYcQNFySe5
yEbsDNYrwEDBbE3BgPSQTcSqk2NSnRWAI8zTK3JRiLI2aBwpz2HBAJ9GDC3r
bA59AFQNDmSOHmEVh3gmfqlFiUBjaHMewmS7VCRUJzNnNzeKzrIYrmVCDTS0
FVi2qLhGSSJRp2jmPzdI8TjLwLwNe8ULmS/YfgaNyIFm90/Hr/YfeF/AaQdg
w8kp6eM+fCcHpw9684fsci7BB0BW6tIgK1qAKdMKZwfvQFJiKktLv12BXUqA
yaZmsqjAWZFYHDzhxu6JmnYjp02ZooR4DjBhpW89vZBZlgv8uoc4rFXW0ED2
/p7Ezyvsev/+D+AJ6AhXVyyTJm2McXqaiVJonrOpBrxDaQ+pGSCrAj8D/Q+J
DIkQP+XoVqhKjRI0RDH2qgrWoK/Iz4zTAEYYVgdIOWIRRTwHD5COeEcXgEgq
qhaOboIwL/wVSDZpplOhHwLBDRDz0KRzkTU50hVj22fDNeuV1wLYjTjltLif
7I6kqKdJLbhJPOwlF1UJYowdsFUoro94gWaVRVBp+QbfSrWceLlDk8wIdrwJ
RKpDdjOJEsUeT26V89KJ0TeBKIQGyvfiDWWBkshEDlFLx3iN3tDRB7CFEUxo
CXaWghmaBp3LsFkDHWCOMKZV4BC2A6xJwQl/kjVMGjJRpyOCVm5C2YPp16oA
ysiGpXYgB4p26pUX4GE9okAwRqwlbdSpz5vpKakPkRPAT4Jh2IiGiq+5noH5
IDKk6Oi98GVuGQ9h2i3j4IhZsFYQC4QNMgHrIc5ao4MlV64DQMDKppiA2qxF
mV5kGlpfIYmFTrgilQCITMnTQO4xyqMJtX7FnbrkrxRPK7TBhffrar4wEiJT
63A2JPVCqN80jNdhxLk2dt82Dn1kCB9+RAw/RasPCS5A+TGxkwVqxtEIBgc4
CuFao74wioBx1KjyaQ7WraCZbAZ7YHd+DupsoROEVaHBwtYE846bODv6nHkF
xIVvYowrTSKrpKhyc3U1uruk4zoFtybYpRehAu4+x7htflEj6zemF8j13eQX
9+5BvA1A8gCqmobPhHc0KAAZVoCGbb55e3q2ObS/2eER/X2y99e3+yd7u/j3
6evxwUH7x8CNOH199PZgt/urm/ny6M2bvcNdOxlaWdQ02Hwz/nHTutHm0fHZ
/tHh+GDTOmRoHVDAOt+m/KXSghJoM/AxzyZjL4//8++tJy4n2d7aeg7B1H48
2/ryCXxczkVpd1MlKNF+gigXA16BD2nCqjwHe65kDdnMEOHazNVlyeaA/aPB
4I//QMn8c4d9NUmrrSdfuwZkOGr0MosaSWbLLUuTrRBXNK3YppVm1N6TdEzv
+Mfo28s9aPzqG/AbwZKtZ998PXA2RJa2Fztl4Ij+7IRMjMrVNAWTIltVUZro
wosNjbCYwbA9vSnSXF+08lumcs5LPDlPtzGPJn+zwNOioWlxk4eMUcQEcBmS
n1tTOgZIlr+ww4OTfVYvqo5YqUNyeV2DpQKEG3YhCbdbWLp9lHNRpTN7sM9o
AUS+FviCPVcVekGm7uJIB3fcQdbUwp3DOIfzm53eN1s5OdHGEy2LOJld8Lyh
VOrsxe6WbYdET5GF+OKgMyeS5gqlB1JEUIj8n7JlhbCKawIziREEhiYAwvh8
jvbxMGjFHBSLyA8RQiGV0rcwmgZLYLJnaQ15CpdAyyDBJaiZTVRcUEe6kiA6
HcxNYkDgmD/gSSFY6rVkoEE6WpAZWlz6UxAFg9FdD/bZGZloz3s9l9g8bTSN
NnWTOQV2klm1IU60IAlMTQTIf8fJ+7ffftsYMPaILf9srWjbXtH22C6wBZ2P
2RP2lH3BvmTP2POPaYMl/pT8zn+wxoeQLmIcZdk12f4zBZHDdh+IcgY5dNv/
Oej4hB+k4+HD5fa+Pdy/4Fqi+T1YGvrw4R3RcQfycGb2fofdAyROapVM5WyL
0Zn+nzf3An9E7wsY3Lz6/zdTK+ZjrWqVqjzZ3/3fmFGQ3l6vvmvWuP+MKSiu
a7NsPu3PXZnzXcgjdokDhSUpxnq2S0GmgprLYIa+xi/IJe6ejhNRKKglbk/I
Z6IDRYKA36PBrEWJz0cHAVVfFp+djpUws30DzLQxcvPKZxltgoDZDWSVWG6n
lAEHXj4MPHC4xhaHa23D501LCqM6CstlXojlDKRNicMTmCVB/77EpTtridOn
/ZpOPLgsjUvq7I5BZmhPN/CLctsKD45TWeE1KSyLiYo09twYZJpxmL4ggl2q
s6QSm9rkNkbTPtJyCL+8LdkxNnVt6XPndYXSfQlR0tm/I7iViGyGOi6Uq+37
kj91Cw/bXggFbjckuGM5kHCwADEC9FKxChUE1b/IiD3xSYVP7mBZtxeDMtvY
OmHlii6hDmtAn5x7+3EJcNs+pJI7zOftIWPZN4gh8hRluktlmD2U6kqjpRqi
O/Vp97eI9SkWjJ7Ty72XC8OVd2FWs6euQIMCajHsVSorSPTnjFxrGd00deO6
e5IbpUmq+kC2/RKx4lhB6fehVSZK74NPViGafkjsj/8d/3StOBQypEfPnsP0
N/wXWTSFda8XYI2XMsPlEIKfuDCNH1D9QSMS+Bqwjet0vvBxPBp6exoCRK75
pE38lgRGgm01GJSwVzYLRGtZw8VK3OtOELytctMTfrQ5noPIMpN4YB4eWhKa
Tdq93Bl2e7IO33ZRAslVrv6xppFEyBtifaeSmPJPxPzGHcFHXHd7dB47Yn8j
XLDCwzMKoSUeNk+1KqDZl6/H7L47ggD0R6+zV4a4ynHbgBD2iUQHNKPrLSzI
dLmwv7Fo97LiOyLyeicu7M34R3sjGlz99Mvn2Dp95Q5hJrfBekU97o/jgqWO
7LWtKo074nHnHr0rQeWH+bNqe5MYIia29pFXaTmTZfBYQquKz9aAboh8dJeb
i+5dRp53qzRG9DAT+cVDbremSYFeR6nlGoLNeD3mhna84kVC5PjxKxEPtqqo
mvq6exiYHRnmetYhVqQisODe1Vx0uYOn0U7EfvPgUmf5aUSwC/JDh6nhxceq
i63uErK98wU4Af1pYIjM3VJE493Npr1EofsJ4gUPWf0x41K4jnIiJOLMLkK3
OBnetaqiaPBACtYML8DRF3GnxO6awIQExwKCuDNvRMO65njd7697lra/pOTG
igJ3dyy0rmucETpiLGtLgTy7NoTvTyN3gMlzhBgJ4qlJY5UQ+KLCGrmZy6oF
3UCiyy4zXMWSN8qANrtT3t55lXQODTq2F+p0Cz1se/yeSwpYEDABpIaCHbY1
w+HRv8a77/ZOzvZP98I5Lm/0E1qPPBH4vMNhQeyNR9YNqvgpVqy4+AJzKrWp
EQCFLuhMXi7jCybnubTPp0QOuqA0fVz2BgUX9svj/bpdDgY8pecWcyuImsAg
PX9c8r5159JLMRhXsTi2gLIB4Di1dDgENPHR9akD7Gej7dE2yirML7Aem1hK
UFhv6WkoK4QxfNYHUWs7vlIRkiIHv8kiXMIQe0tOVae1MrpqXm0aaAnpkpyC
w+FuVe7WbB8h9R8p4mbArHvy1uVEtgBzg32O1subqBBakxBhSCwwcUCH5/5y
CMsbjTjZLdLWFY7AUeD4646+r7W0YXuf7W0cgjACi5VxBniK12kYVFO6NsEi
UuTOHPzLJwFeQdf/VjB2ABLedlx3Nt+lYT7qiXXvG5D09gmDu/lvd7tJbSSp
MBAEVudcy1WU9L6IRtJCBeS0NXhgaHeUiQRnIDUmiKuAEhhEMGsMpnGeZhey
tCXNY9VxnLnEaNVb19h3ICAKcR0u9iJTwfxtMIKlz5QwDbBJnNVftY4Ot7N7
f6iDwEeRZI1sVwdZFz0txFmhNLmg6tc/tggT4xuC8cinnYBUjUbOXzqz94mn
zb6M706j7q5kerL95RbW02ABUQ3Fq8qHtuCOcuQeRI4Pxys2pGZp/CtGVywZ
I2clpVyXQAVIqcJylzyLLiKj20u6IibpbN7msYfxN6FQbvAC45TZhO1n0tR6
4crsdwRWLK6v8ftEUOYF/rO2wIVhYZlLVfuL3S3mSmZnJR9YfJG7VAQ/Dopg
y3RX9/tyF5Lp9LxUl1BNzey7EK9D++gfzJByxlyeC6sXDpjyww8/tHmTFhcS
ZExvD+1b1Baz+iq0b1wnPD0f/Bd0VeQacTEAAA==

-->

</rfc>
