BGP SR Policy Extensions for Network Resource Partition

The concept of Segment Routing (SR) policy is defined in . An SR Policy is a set of candidate paths, each consisting of one or more segment lists. The head end of an SR Policy may learn multiple candidate paths for an SR Policy. The header of a packet steered in an SR Policy is augmented with an ordered list of segments associated with that SR Policy. The BGP extensions to distribute SR Policy candidate paths is defined in . discusses the general framework, components, and interfaces for requesting and operating network slices using IETF technologies. It also introduces the concept Network Resource Partition (NRP), which is a subset of the resources and associated policies in the underlay network. The network slices defined in can be realized by mapping one or more connectivity constructs to an NRP. describes the framework and the candidate component technologies for providing enhanced VPN services based on VPN and Traffic Engineering (TE) technologies. Enhanced VPN (VPN+) can be used for the realization of network slice services defined in . As described in , one scalable data plane approach to support network slicing is to carry a dedicated NRP ID in the data packet to identify the NRP the packet belongs to, so that the packet can be processed and forwarded using the subset of network resources allocated to the NRP. In networks where there are multiple NRPs, an SR Policy may be associated with a particular NRP. The association between SR Policy and NRP needs to be specified, so that for service traffic which is steered into the SR Policy, the header of the packets can be augmented with the information associated with the NRP. The association between an SR Policy and an NRP is described in . An SR Policy candidate path can be distributed using BGP SR Policy. This document defines the extensions to BGP SR policy to specify the control plane NRP ID that is associated with the SR Policy candidate path.

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 BCP14 when, and only when, they appear in all capitals, as shown here.

In order to specify the NRP the candidate path of SR policy is associated with, a new sub-TLV called "NRP" sub-TLV is defined in the BGP Tunnel Encapsulation Attribute . The NRP sub-TLV can be carried in the BGP Tunnel Encapsulation Attribute with the tunnel type set to SR Policy. The use of the NRP sub-TLV in other tunnel types is outside the scope of this document. The NRP sub-TLV has the following format:

where: Type: 123 (assigned by IANA) Length: 6 octets. Flags: 1-octet flag field. None is defined at this stage. The flags SHOULD be set to zero on transmission and MUST be ignored on receipt. Reserved: 1 octet of reserved bits. It SHOULD be set to zero on transmission and MUST be ignored on receipt. NRP ID: A 32-bit domain significant identifier which is used to identify an NRP in the control plane. The values of 0 and 0xFFFFFFFF are reserved. The validation of an SR Policy NLRI with the NRP Sub-TLV in the BGP tunnel encapsulation attribute follows the procedures in section 4.2 of , augmented by the validation procedures described in this document. When the NRP sub-TLV is carried in the BGP Tunnel Encapsulation Attribute associated with an SR Policy NLRI, a segment list of the candidate path is considered invalid if the headend node of the SR Policy determines that the set of network resources corresponding to the control plane NRP ID on network segments identified by the segment list do not exist. The detailed mechanisms for NRP resource validation are out of the scope of this document. The encoding structure of BGP SR Policy with the NRP sub-TLV is expressed as below:

Attributes: Tunnel Encaps Attribute (23) Tunnel Type: SR Policy (15) Binding SID SRv6 Binding SID Preference Priority Policy Name Policy Candidate Path Name Explicit NULL Label Policy (ENLP) NRP Segment List Weight Segment Segment ... ... Figure 2. SR Policy Encoding with NRP sub-TLV]]>

When a candidate path of SR Policy is instantiated within an NRP, and a network-wide data plane NRP Selector ID is used for identifying the resources of the NRP, the originating node of SR Policy SHOULD include the NRP sub-TLV in the BGP Tunnel Encapsulation Attribute of the BGP SR Policy. The setting of other fields and attributes in BGP SR Policy SHOULD follow the mechanism as defined in . On reception of an SR Policy NLRI, a BGP speaker determines if it is acceptable and usable according to the rules defined in Section 4.2 of and section 2 of this document. If the SR Policy candidate path selected as the best candidate path is associated with an NRP, the headend node of the SR Policy SHOULD map the NRP ID to the data plane NRP Selector ID, then encapsulate both the NRP Selector ID and the segment list of the selected candidate path in the header of packets which are steered to the SR Policy. For SR Policy with IPv6 data plane, the data plane NRP Selector ID can be the same as the NRP ID, and the approach to encapsulate the NRP Selector ID in IPv6 Hop-by-Hop Options header is defined in . For SR Policy with MPLS data plane, the mechanisms of mapping and encapsulation of the NRP Selector ID in the packet would based on the framework defined in . Although the proposed mechanism allows that different candidate paths in one SR policy be associated with different NRPs, in normal network scenarios it is considered that the association between an SR Policy and NRP is consistent, in such case all candidate paths of one SR policy SHOULD be associated with the same NRP.

The error handling of the BGP Update messages for BGP SR Policy SAFI with the NRP extensions defined in this document follows the procedures in section 5 of . The NRP sub-TLV is optional and MUST NOT appear more than once for one SR Policy candidate path. The NRP sub-TLV is considered malformed if its format does not match the above description. If the NRP sub-TLV appears more than once, or its format is considered malformed, the associated BGP SR Policy NLRI is considered malformed and the "treat-as-withdraw" strategy of MUST be applied.

The mechanism specified in this document adds additional information to the SR Policy candidate paths. In order to steer traffic into different NRPs using SR Policy, the SR Policies used for different NRPs need to be different. As the number of NRP increases, the number of SR Policies would also increase accordingly. When BGP is used for distributing SR Policy candidate paths, the amount of control plane information exchanged between the network controller and the headend nodes would also increase. However, since the SR Policies candidate paths distributed in BGP are only installed by the corresponding headend nodes, the impacts to the BGP control plane are considered acceptable.

The security considerations of BGP and BGP SR policy apply to this document. The NRP sub-TLV provides a control plane NRP ID that is linked to the NRP identifier (denoted as NRP Selector ID) that may be carried in IPv6 Hop-by-Hop options header or used in the encapsulation of MPLS. As the NRP Selector ID can impact packet forwarding in a network so care should be taken to protect this mission-critical or commercially sensitive information during provisioning, query and report of the control plane NRP ID in BGP.

IANA has assigned the sub-TLV type as defined in Section 2 from "BGP Tunnel Encapsulation Attribute sub-TLVs" registry.

The authors would like to thank Guoqi Xu, Lei Bao, Haibo Wang, Shunwan Zhuang and Susan Hares for their review and discussion of this document.