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, . [RFC4360] Sangli, S., Tappan, D., and Y. Rekhter, "BGP Extended Communities Attribute", RFC 4360, DOI 10.17487/RFC4360, February 2006, . [RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, "Multiprotocol Extensions for BGP-4", RFC 4760, DOI 10.17487/RFC4760, January 2007, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [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, . [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, . 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, . [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, . [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, . 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]