| Internet-Draft | BGP Extensions for NRP | February 2026 |
| Li & Hu | Expires 19 August 2026 | [Page] |
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.¶
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 (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved.¶
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.¶
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.¶
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.¶
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.¶
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) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Where:¶
Type high(1 octet): The value of this field is 0x03, which indicates it is transitive.¶
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.¶
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.¶
The traffic forwarding process involves the headend node, intermediate nodes, and the endpoint node.¶
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.¶
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 |
+------------+------------------------+----------------------------+
The security considerations specified in [RFC4360]、[RFC9543] and [RFC9012] apply to this document. This document introduces no new security considerations.¶