IDR Working Group J. Dong Internet-Draft Z. Hu Intended status: Standards Track Huawei Technologies Expires: 12 January 2023 R. Pang China Unicom 11 July 2022 BGP SR Policy Extensions for Network Resource Partition draft-dong-idr-sr-policy-nrp-01 Abstract 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 collection of network resources allocated in the network which can be used to support one or a group of IETF network slice services. 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. An SR Policy candidate path can be distributed using BGP SR Policy. This document defines the extensions to BGP SR policy to specify the NRP which the SR Policy candidate path is associated with. 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 12 January 2023. Dong, et al. Expires 12 January 2023 [Page 1] Internet-Draft BGP SR Policy for NRP July 2022 Copyright Notice Copyright (c) 2022 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. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 2. NRP Identifier of SR Policy . . . . . . . . . . . . . . . . . 3 3. Procedures . . . . . . . . . . . . . . . . . . . . . . . . . 5 4. Security Considerations . . . . . . . . . . . . . . . . . . . 5 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 5 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 5 7.1. Normative References . . . . . . . . . . . . . . . . . . 5 7.2. Informative References . . . . . . . . . . . . . . . . . 7 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 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]. [I-D.ietf-teas-ietf-network-slices] introduces the concept and the characteristics of IETF network slice, and describes a general framework for IETF network slice management and operation. It also introduces the concept Network Resource Partition (NRP), which is a collection of resources identified in the underlay network. IETF network slice can be realized by mapping a set of connectivity constructs to a network resource partition (NRP). [I-D.ietf-teas-enhanced-vpn] describes the framework and the candidate component technologies for providing enhanced VPN (VPN+) Dong, et al. Expires 12 January 2023 [Page 2] Internet-Draft BGP SR Policy for NRP July 2022 services based on VPN and Traffic Engineering (TE) technologies. Enhanced VPN (VPN+) can be used for the realization of IETF network slices. In the context of network slicing, an NRP is considered as an instantiation of the VTN as defined in [I-D.ietf-teas-enhanced-vpn]. As described in [I-D.dong-teas-nrp-scalability], one scalable data plane approach 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 set 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. An SR Policy candidate path can be distributed using BGP SR Policy. This document defines the extensions to BGP SR policy to specify the NRP which the SR Policy candidate path is associated with. 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 BCP14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. 2. 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: Dong, et al. Expires 12 January 2023 [Page 3] Internet-Draft BGP SR Policy for NRP July 2022 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 where: * Type: 123 * Length: 6 * 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 a NRP. Value 0 and 0xFFFFFFFF are reserved. The encoding structure of BGP SR Policy with the NRP sub-TLV is expressed as below: SR Policy SAFI NLRI: Attributes: Tunnel Encaps Attribute (23) Tunnel Type: SR Policy Binding SID Preference Priority Policy Name Explicit NULL Label Policy (ENLP) NRP Segment List Weight Segment Segment ... ... Dong, et al. Expires 12 January 2023 [Page 4] Internet-Draft BGP SR Policy for NRP July 2022 3. Procedures When a candidate path of SR Policy is instantiated with a specific 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 [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 which are 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 Options header using the mechanism as defined in [I-D.ietf-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 [I-D.li-mpls-enhanced-vpn-vtn-id]. 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. 4. Security Considerations The security considerations of BGP and BGP SR policy apply to this document. 5. 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 6. Acknowledgments The authors would like to thank Guoqi Xu, Lei Bao, Haibo Wang and Shunwan Zhuang for their review and discussion of this document. 7. References 7.1. Normative References Dong, et al. Expires 12 January 2023 [Page 5] Internet-Draft BGP SR Policy for NRP July 2022 [I-D.ietf-idr-segment-routing-te-policy] 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-18, 16 June 2022, . [I-D.ietf-spring-segment-routing-policy] 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-22, 22 March 2022, . [I-D.ietf-teas-enhanced-vpn] 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-10, 6 March 2022, . [I-D.ietf-teas-ietf-network-slices] Farrel, A., 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-12, 30 June 2022, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC7606] Chen, E., Ed., Scudder, J., Ed., Mohapatra, P., and K. Patel, "Revised Error Handling for BGP UPDATE Messages", RFC 7606, DOI 10.17487/RFC7606, August 2015, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . Dong, et al. Expires 12 January 2023 [Page 6] Internet-Draft BGP SR Policy for NRP July 2022 [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, . 7.2. Informative References [I-D.dong-teas-nrp-scalability] 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-02, 16 May 2022, . [I-D.ietf-6man-enhanced-vpn-vtn-id] 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-ietf-6man-enhanced-vpn-vtn-id-00, 5 March 2022, . [I-D.li-mpls-enhanced-vpn-vtn-id] 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-02, 7 March 2022, . Authors' Addresses Jie Dong Huawei Technologies Email: jie.dong@huawei.com Zhibo Hu Huawei Technologies Email: huzhibo@huawei.com Ran Pang China Unicom Email: pangran@chinaunicom.cn Dong, et al. Expires 12 January 2023 [Page 7]