



Inter-Domain Routing                                          Z. Li, Ed.
Internet-Draft                                                R. Hu, Ed.
Intended status: Standards Track                            China Mobile
Expires: 19 August 2026                                 15 February 2026


             BGP Extensions for Network Resource Partition
                        draft-li-idr-bgp-nrp-00

Abstract

   Existing approaches bind a Segment Routing (SR) Policy to a Network
   Resource Partition (NRP) on a one-to-one basis, which lacks
   flexibility and introduces significant operational overhead as the
   number of NRPs scales, especially when the NRPs share the same SR
   Policy path.

   This document defines BGP extensions to advertise NRP identifier (NRP
   ID) information between network nodes, which decouples SR Policy from
   NRP, allowing multiple NRPs to share a common SR Policy path and thus
   avoiding linear growth of SR Policies.

   This design reduces operational complexity and is also applicable to
   SR Best Effort (SR BE) scenario.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at https://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on 19 August 2026.

Copyright Notice

   Copyright (c) 2026 IETF Trust and the persons identified as the
   document authors.  All rights reserved.





Li & Hu                  Expires 19 August 2026                 [Page 1]

Internet-Draft           BGP Extensions for NRP            February 2026


   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents (https://trustee.ietf.org/
   license-info) in effect on the date of publication of this document.
   Please review these documents carefully, as they describe your rights
   and restrictions with respect to this document.  Code Components
   extracted from this document must include Revised BSD License text as
   described in Section 4.e of the Trust Legal Provisions and are
   provided without warranty as described in the Revised BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
     1.1.  Requirements Language . . . . . . . . . . . . . . . . . .   3
   2.  BGP Extended Communities Attribute for NRP ID . . . . . . . .   3
   3.  Route Advertisement . . . . . . . . . . . . . . . . . . . . .   4
   4.  Traffic Forwarding  . . . . . . . . . . . . . . . . . . . . .   4
   5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   5
   6.  Security Considerations . . . . . . . . . . . . . . . . . . .   6
   7.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   6
     7.1.  Normative References  . . . . . . . . . . . . . . . . . .   6
     7.2.  Informative References  . . . . . . . . . . . . . . . . .   6
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   7

1.  Introduction

   In 5G and future heterogeneous network scenarios, network slicing
   serves as the core technology for supporting differentiated services.
   Network Resource Partition (NRP), which underpins network slicing at
   the underlying layer, is officially defined in [RFC9543] .  [RFC9543]
   explicitly delineates the core positioning and operational framework
   of NRP; through the logical partitioning of physical network
   resources, NRP achieves the guarantee and isolation of resource
   allocation and Quality of Service (QoS) for diverse services, and can
   thus meet differentiated service level objectives such as low latency
   and high reliability.  NRP and network slicing are conceptually
   equivalent throughout this document.

   [I-D.ietf-idr-sr-policy-nrp] binds NRPs to Segment Routing (SR)
   Policies [RFC9256].  In this approach, one SR Policy corresponds to
   one NRP, and the NRP identifier (NRP ID) associated with the SR
   Policy is distributed together when the SR Policy is created, via the
   extended BGP SR Policy protocol [RFC9830].  Since the paths of SR
   Policies cannot be shared among multiple network slices, this
   solution lacks flexibility.  As the number of network slices in the
   network increases, the number of SR Policies needs to be expanded
   accordingly, imposing heavy burdens on network maintenance.





Li & Hu                  Expires 19 August 2026                 [Page 2]

Internet-Draft           BGP Extensions for NRP            February 2026


   To address the aforementioned drawbacks, this document introduces NRP
   ID Extended Communities Attribute to the BGP protocol [RFC4760],
   which decouples SR Policies from NRPs.  In this way, network elements
   can advertise network slice information to each other while
   exchanging routes through the BGP protocol, enabling automatic
   traffic steering to the corresponding network slices.  Meanwhile,
   this document supports the sharing of a common SR Policy path by
   multiple network slices.  When the number of network slices in the
   network grows, the number of SR Policies does not need to increase in
   a one-to-one ratio, thus reducing the complexity of network
   maintenance.

   Owing to the decoupling of SR Policies and network slices, the
   approach introduced in this document is also applicable to the SR
   Best Effort (BE) scenarios where SR Policies are not deployed.

1.1.  Requirements Language

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
   "OPTIONAL" in this document are to be interpreted as described in BCP
   14 [RFC2119] [RFC8174] when, and only when, they appear in all
   capitals, as shown here.

2.  BGP Extended Communities Attribute for NRP ID

   To support automatic traffic steering to NRP, and decouple NRP from
   SR Policy, this document proposes to use BGP Extended Communities
   Attribute [RFC4360] to carry NRP ID , thereby enabling the
   associative mapping between routes and NRPs.  This BGP Extended
   Communities Attribute is a Transitive Opaque Extended Community,
   designated as NRP ID Extended Communities Attribute.  Its detailed
   encoding structure is as follows:

        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 high(0x03)|   Type low(*)   |      Reserved(2 octets)     |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                           NRP ID(4 octets)                    |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

              Figure 1: NRP ID Extended Communities Attribute

   Where:

   Type high(1 octet): The value of this field is 0x03, which indicates
   it is transitive.



Li & Hu                  Expires 19 August 2026                 [Page 3]

Internet-Draft           BGP Extensions for NRP            February 2026


   Type low(1 octet): The value of this field is to be assigned by IANA,
   together with Type High, indicating that this Extended Communities
   Attribute is the NRP ID Extended Communities Attribute, which carries
   the NRP ID in the value field.

   Reserved(2 octets): reserved for future extension.  This field SHOULD
   be set to zero on transmission and MUST be ignored on receipt.

   NRP ID (4 octets): carry the unique identifier of a NRP.

3.  Route Advertisement

   The route advertisement process involves only the headend node and
   the endpoint node of NRP traffic.  The two nodes complete the
   advertisement and association of NRP ID through the BGP protocol with
   NRP ID Extended Communities Attribute.

   As the initiator of BGP routes, the headend node or the the endpoint
   node constructs BGP messages that contain route information and NRP
   ID according to service requirements.  For Traffic Engineering (TE)
   mode, Color information needs to be additionally carried in BGP
   messages (within Color Extended Community [RFC9012] ), which is used
   to map to the corresponding SR Policy.  For Best Effort (BE) mode,
   only route information and NRP ID need to be carried.

   When BGP speaker generates BGP update messages with network slice
   information, it needs to carry the NRP ID in the NRP ID Extended
   Communities Attribute in accordance with the format defined in
   Chapter 2 of this document.

   After receiving such BGP update messages, the BGP speaker recognizes
   the NRP ID Extended Communities Attribute by the values of Type high
   and Type low.  It MUST ignore the value of the Reserved field and
   extract the network slice identifier (i.e., NRP ID) from the NRP ID
   field.  The generated Routing Information Base (RIB) and Forwarding
   Information Base (FIB) MUST include the NRP ID to maintain the
   association between routes and corresponding NRPs, ensuring the
   correct forwarding and management of routes.  The specific data
   structure used to associate the routes and the NRPs is is
   implementation-specific and thus out of the scope of this document.

4.  Traffic Forwarding

   The traffic forwarding process involves the headend node,
   intermediate nodes, and the endpoint node.






Li & Hu                  Expires 19 August 2026                 [Page 4]

Internet-Draft           BGP Extensions for NRP            February 2026


   Headend Node: When the headend node receives a packet matching the
   BGP route corresponding to the target slice, it MUST extract the NRP
   ID associated with the route, and encapsulate the packet accordingly
   (for example, encapsulate the NRP ID into the source IP field of the
   packet or the IPv6 extension header).  The encapsulated packet is
   then forwarded to the forwarding path corresponding to the NRP ID
   (such as a VLAN with bandwidth guarantee).  In TE mode, the packet is
   encapsulated in accordance with the matching SR Policy together with
   the NRP ID, and the encapsulated packet is forwarded based on the SR
   Policy with resources guaranteed according to the NRP ID.

   Intermediate Node: After receiving a packet with NRP ID, the
   intermediate node needs to perform corresponding operations based on
   the destination IP address and NRP ID in the packet.  First, it needs
   to determine the Layer 3 egress interface: extract the destination IP
   address of the packet, look up the local FIB table, and determine the
   Layer 3 egress interface of the packet according to the route
   matching result to complete basic route forwarding.  If the
   destination IP address of the packet is a SID, the packet is
   forwarded based on the functional behavior of the SID.  At the same
   time, the intermediate node extracts the NRP ID from the packet and
   forwards the packet to the corresponding network slice resources in
   the determined Layer 3 egress interface (such as slice sub-
   interfaces, slice queues, etc.) according to the locally configured
   mapping between NRP ID and network slice resources.  Through these
   network slice resources, the packet reaches the next-hop node,
   thereby realizing resource guarantee and forwarding of slice traffic.

   Endpoint Node: After receiving a packet with NRP ID, the endpoint
   node decapsulates the packet, i.e., strips the outer packet header
   containing the NRP ID, and forwards the inner packet accordingly.  In
   TE mode, the received packet is with SR Policy encapsulation, the
   endpoint node strips the outer packet header corresponding to the SR
   Policy encapsulation and processes the inner packet based on the
   functional behavior of the SID in the destination field of the
   stripped outer header.

5.  IANA Considerations

   IANA is requested to assign the following code point from the
   subregistry of "BGP Transitive Extended Community Types" in the
   registry of "Border Gateway Protocol (BGP) Extended Communities" :

       +============+========================+============================+
       | Code Point |       Description      |         Reference          |
       +============+========================+============================+
       |    TBD1    |         NRP ID         |       This document        |
       +------------+------------------------+----------------------------+



Li & Hu                  Expires 19 August 2026                 [Page 5]

Internet-Draft           BGP Extensions for NRP            February 2026


               Figure 2: Code Point for the BGP message


6.  Security Considerations

   The security considerations specified in [RFC4360]、[RFC9543] and
   [RFC9012] apply to this document.  This document introduces no new
   security considerations.

7.  References

7.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/info/rfc2119>.

   [RFC4360]  Sangli, S., Tappan, D., and Y. Rekhter, "BGP Extended
              Communities Attribute", RFC 4360, DOI 10.17487/RFC4360,
              February 2006, <https://www.rfc-editor.org/info/rfc4360>.

   [RFC4760]  Bates, T., Chandra, R., Katz, D., and Y. Rekhter,
              "Multiprotocol Extensions for BGP-4", RFC 4760,
              DOI 10.17487/RFC4760, January 2007,
              <https://www.rfc-editor.org/info/rfc4760>.

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <https://www.rfc-editor.org/info/rfc8174>.

   [RFC9012]  Patel, K., Van de Velde, G., Sangli, S., and J. Scudder,
              "The BGP Tunnel Encapsulation Attribute", RFC 9012,
              DOI 10.17487/RFC9012, April 2021,
              <https://www.rfc-editor.org/info/rfc9012>.

   [RFC9543]  Farrel, A., Ed., Drake, J., Ed., Rokui, R., Homma, S.,
              Makhijani, K., Contreras, L., and J. Tantsura, "A
              Framework for Network Slices in Networks Built from IETF
              Technologies", RFC 9543, DOI 10.17487/RFC9543, March 2024,
              <https://www.rfc-editor.org/info/rfc9543>.

7.2.  Informative References








Li & Hu                  Expires 19 August 2026                 [Page 6]

Internet-Draft           BGP Extensions for NRP            February 2026


   [I-D.ietf-idr-sr-policy-nrp]
              Dong, J., Hu, Z., and R. Pang, "BGP SR Policy Extensions
              for Network Resource Partition", Work in Progress,
              Internet-Draft, draft-ietf-idr-sr-policy-nrp-07, 11
              February 2026, <https://datatracker.ietf.org/doc/html/
              draft-ietf-idr-sr-policy-nrp-07>.

   [RFC9256]  Filsfils, C., Talaulikar, K., Ed., Voyer, D., Bogdanov,
              A., and P. Mattes, "Segment Routing Policy Architecture",
              RFC 9256, DOI 10.17487/RFC9256, July 2022,
              <https://www.rfc-editor.org/info/rfc9256>.

   [RFC9830]  Previdi, S., Filsfils, C., Talaulikar, K., Ed., Mattes,
              P., and D. Jain, "Advertising Segment Routing Policies in
              BGP", RFC 9830, DOI 10.17487/RFC9830, September 2025,
              <https://www.rfc-editor.org/info/rfc9830>.

Authors' Addresses

   Zhenqiang Li (editor)
   China Mobile
   29 Finance Avenue, Xicheng District
   Beijing
   China
   Email: lizhenqiang@chinamobile.com


   Ruiqian Hu (editor)
   China Mobile
   10 Manbai Road, Changping District, Changping District
   BeiJing
   China
   Email: huruiqian@chinamobile.com


















Li & Hu                  Expires 19 August 2026                 [Page 7]
