Internet-Draft BGP SR Policy for NRP March 2022
Dong, et al. Expires 5 September 2022 [Page]
IDR Working Group
Intended Status:
Standards Track
J. Dong
Huawei Technologies
Z. Hu
Huawei Technologies
R. Pang
China Unicom

BGP SR Policy Extensions for Network Resource Partition


Segment Routing (SR) Policy is a set of candidate paths, each consisting of one or more segment lists and the associated information. The header of a packet steered in an SR Policy is augmented with an ordered list of segments associated with that SR Policy. A Network Resource Partition (NRP) is a set of network resources allocated in the network which can be used to instantiate a virtual transport network (VTN) for one or a group service traffic. In scenarios where multiple Network Resource Partitions (NRPs) exist in the network, the NRP in which an SR policy is instantiated may also need to be specified, so that the header of the packet can be augmented with the information associated with the NRP. An SR Policy candidate path can be distributed using BGP SR Policy. This document defines extensions to BGP SR policy to specify the NRP in which the SR policy is instantiated.

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

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 5 September 2022.

Table of Contents

1. Introduction

The concept of Segment Routing (SR) policy is defined in [I-D.ietf-spring-segment-routing-policy]. 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 [I-D.ietf-idr-segment-routing-te-policy].

The concept of Virtual Transport Network (VTN) is introduced in [I-D.ietf-teas-enhanced-vpn]. A VTN is a virtual underlay network which has customized network topology and a set of dedicated or shared network resources. In a network, multiple VTNs may be created to meet different service requirements, and services can be mapped to the same or different VTNs. [I-D.ietf-teas-ietf-network-slices] introduces the concept Network Resource Partition (NRP) as a set of network resources that are available to carry traffic and meet the SLOs and SLEs. In the context of network slicing, an NRP can be used to instantiate a VTN for one or a group of IETF network slice services. As described in [I-D.dong-teas-nrp-scalability], one scalable data plane approach is to carry a global 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 network resources allocated to the NRP.

In networks where multiple NRPs exist, the identifier of NRP in which the SR policy is instantiated need to be specified, so that at the ingress node of SR policy, the header of data packet can also be augmented with the identifier of the NRP. This document defines the BGP extensions to specify the NRP ID associated with a candidate path of SR policy.

2. Specification of Requirements

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].

3. NRP Identifier of SR Policy

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 [RFC9012]. The NRP sub-TLV can be carried in the BGP Tunnel Encapsulation Attribute with the tunnel type set to SR Policy.

The NRP sub-TLV is optional and MUST NOT appear more than once for one SR Policy candidate path. If the NRP sub-TLV appears more than once, the associated BGP SR Policy NLRI is considered malformed and the "treat-as-withdraw" strategy of [RFC7606] is applied.

The NRP sub-TLV has the following format:

    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      |   Length      |     Flags     |   RESERVED    |
   |                         NRP ID (4 octets)                     |
                      Figure 1. NRP Sub-TLV


The encoding structure of BGP SR Policy with the NRP sub-TLV is expressed as below:

         SR Policy SAFI NLRI: <Distinguisher, Policy-Color, Endpoint>
            Tunnel Encaps Attribute (23)
               Tunnel Type: SR Policy
                   Binding SID
                   Policy Name
                   Explicit NULL Label Policy (ENLP)
                   Segment List

4. Procedures

When a candidate path of SR policy is instantiated with a specific NRP, the originating node of SR policy SHOULD include the NRP ID in the BGP Tunnel Encapsulation Attribute of the BGP SR policy. The setting of other fields and attributes in BGP SR policy SHOULD follows the mechanism as defined in [I-D.ietf-idr-segment-routing-te-policy].

When a BGP speaker receives an SR Policy which is acceptable and usable according to the rules as defined in [I-D.ietf-idr-segment-routing-te-policy], and the SR Policy candidate path selected as the best candidate path is associated with an NRP, the receiver node of the SR policy SHOULD encapsulate the NRP ID in the header of packets steered to the SR Policy. For SR Policy with IPv6 data plane, the approach is to encapsulate the NRP ID in IPv6 Hop-by-Hop extension header using the mechanism as defined in [I-D.dong-6man-enhanced-vpn-vtn-id]. For SR Policy with MPLS data plane, one possible mechanism to encapsulate the NRP ID to the packet is 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.

5. Security Considerations

The security considerations of BGP and BGP SR policy apply to this document.

6. IANA Considerations

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

      Value     Description                     Reference
       123        NRP                         This document

7. Acknowledgments

The authors would like to thank Guoqi Xu, Lei Bao and Haibo Wang for the review and discussion of this document.

8. References

8.1. Normative References

Dong, J., Li, Z., Gong, L., Yang, G., Guichard, J. N., Mishra, G., Qin, F., Saad, T., and V. P. Beeram, "Scalability Considerations for Network Resource Partition", Work in Progress, Internet-Draft, draft-dong-teas-nrp-scalability-01, , <>.
Previdi, S., Filsfils, C., Talaulikar, K., Mattes, P., Jain, D., and S. Lin, "Advertising Segment Routing Policies in BGP", Work in Progress, Internet-Draft, draft-ietf-idr-segment-routing-te-policy-14, , <>.
Filsfils, C., Talaulikar, K., Voyer, D., Bogdanov, A., and P. Mattes, "Segment Routing Policy Architecture", Work in Progress, Internet-Draft, draft-ietf-spring-segment-routing-policy-18, , <>.
Dong, J., Bryant, S., Li, Z., Miyasaka, T., and Y. Lee, "A Framework for Enhanced Virtual Private Network (VPN+) Services", Work in Progress, Internet-Draft, draft-ietf-teas-enhanced-vpn-09, , <>.
Farrel, A., Gray, E., Drake, J., Rokui, R., Homma, S., Makhijani, K., Contreras, L. M., and J. Tantsura, "Framework for IETF Network Slices", Work in Progress, Internet-Draft, draft-ietf-teas-ietf-network-slices-05, , <>.
Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, , <>.
Chen, E., Ed., Scudder, J., Ed., Mohapatra, P., and K. Patel, "Revised Error Handling for BGP UPDATE Messages", RFC 7606, DOI 10.17487/RFC7606, , <>.
Patel, K., Van de Velde, G., Sangli, S., and J. Scudder, "The BGP Tunnel Encapsulation Attribute", RFC 9012, DOI 10.17487/RFC9012, , <>.

8.2. Informative References

Dong, J., Li, Z., Xie, C., Ma, C., and G. Mishra, "Carrying Virtual Transport Network (VTN) Identifier in IPv6 Extension Header", Work in Progress, Internet-Draft, draft-dong-6man-enhanced-vpn-vtn-id-06, , <>.
Li, Z. and J. Dong, "Carrying Virtual Transport Network Identifier in MPLS Packet", Work in Progress, Internet-Draft, draft-li-mpls-enhanced-vpn-vtn-id-01, , <>.

Authors' Addresses

Jie Dong
Huawei Technologies
Zhibo Hu
Huawei Technologies
Ran Pang
China Unicom