SPRING J. Dong Internet-Draft Huawei Technologies Intended status: Standards Track R. Pang Expires: 29 December 2024 China Unicom K. Zhang Huawei Technologies 27 June 2024 Associating Segment Routing (SR) Policy with Network Resource Partition (NRP) draft-dong-spring-sr-policy-with-nrp-00 Abstract Segment Routing (SR) Policy is a set of candidate paths, each consisting of one or more segment lists and the associated information. A Network Resource Partition (NRP) is a subset of the network resources and associated policies in the underlay network, which can be used to support one or a group of Enhanced VPN or RFC 9543 network slice services. In SR networks where there are multiple NRPs, an SR Policy may be associated with a particular NRP. Within an NRP, SR Policy can be used for forwarding traffic which is mapped to the NRP, so that the traffic can be provided with the subset of network resources and policy of the NRP for guaranteed performance. The association between SR Policy and NRP needs to be specified. This document defines extensions to the SR Policy Architecture to allow the association of the SR Policy candidate paths with NRPs. 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 29 December 2024. Dong, et al. Expires 29 December 2024 [Page 1] Internet-Draft SR Policy with NRP June 2024 Copyright Notice Copyright (c) 2024 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 . . . . . . . . . . . . . . . . . . 4 2. Associating SR Policy with NRP . . . . . . . . . . . . . . . 4 2.1. Updated SR Policy Information Model . . . . . . . . . . . 4 2.2. Packet Forwarding using SR Policy with NRP . . . . . . . 5 3. Security Considerations . . . . . . . . . . . . . . . . . . . 6 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 6.1. Normative References . . . . . . . . . . . . . . . . . . 6 6.2. Informative References . . . . . . . . . . . . . . . . . 7 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 1. Introduction The concept and architecture of Segment Routing (SR) Policy is defined in [RFC9256]. An SR Policy is a set of candidate paths, each consisting of one or more segment lists. The head end node 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. Dong, et al. Expires 29 December 2024 [Page 2] Internet-Draft SR Policy with NRP June 2024 [RFC9543] introduces the concept and the characteristics of network slice built using IETF technologies, and describes a general framework for RFC 9543 network slice management and operation. [I-D.ietf-teas-enhanced-vpn] describes the framework and the candidate component technologies for delivering enhanced VPN services. Enhanced VPN can be used for the realization of RFC 9543 network slices. [RFC9543] also introduces the concept Network Resource Partition (NRP), which is a subset of the network resources and associated policies in the underlay network. An NRP can be used to support one or a group of enhanced VPN or RFC 9543 network slice services. In SR networks, an NRP can be realized using NRP-specific resource- aware segments as defined in [I-D.ietf-spring-resource-aware-segments] and [I-D.ietf-spring-sr-for-enhanced-vpn]. With this approach, a separate set of resource-aware SIDs need to be assigned for each NRP. For network scenarios where the number of NRP is large, [I-D.ietf-teas-nrp-scalability] suggests to introduce a dedicated NRP ID in the data packet. The data plane NRP ID is a network-wide identifier which can be used by network nodes to identify the set of network resources allocated to the NRP. This is considered as a scalable approach for realizing NRP, as the number of SR SIDs will not be proportional to the number of NRPs. The mechanisms for encapsulating NRP ID in data packet are out of the scope of this document and are specified in separate documents. The encapsulation of NRP information in IPv6 data plane is specified in [I-D.ietf-6man-enhanced-vpn-vtn-id], and the encapsulation of NRP information in MPLS data plane is specified in [I-D.li-mpls-enhanced-vpn-vtn-id]. In SR networks where there are multiple NRPs, an SR Policy may need to be associated with a particular NRP. Within the NRP, the SR Policy can be used for steering and forwarding traffic which is mapped to the NRP, so that the traffic can be forwarded along the selected path using the subset of network resources and policy of the NRP for guaranteed performance. For NRPs built with resource-aware segments, the association of SR Policy with NRP can be achieved by using NRP-specific resource-aware SIDs to construct the segment lists of the SR Policy. For NRPs built using dedicated data plane NRP ID, normal SR SIDs will be used for the segment lists of SR Policy, then the association between SR Policy and NRP needs to be specified explicitly. This document defines extensions to the SR Policy Architecture for associating SR Policy with NRP. Dong, et al. Expires 29 December 2024 [Page 3] Internet-Draft SR Policy with NRP June 2024 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. Associating SR Policy with NRP As defined in [RFC9256], an SR Policy is associated with one or more candidate paths. A candidate path is the unit for signaling of an SR Policy to a headend via protocol extensions like the Path Computation Element Communication Protocol (PCEP) [RFC8664] [I-D.ietf-pce-segment-routing-policy-cp] or BGP SR Policy [I-D.ietf-idr-sr-policy-safi]. A candidate path consists of one or multiple segment lists. The segment lists are used for load balancing. The association between SR Policy and NRP is specified at the candidate path level. For an SR Policy associated with NRP, each of its candidate path needs to be associated with an NRP. The NRP ID is used to indicate the NRP to which the SR Policy candidate path is associated with. All the segment lists of the candidate path are associated with the same NRP. The protocol extensions for signaling of the SR Policy associated with NRP are described in [I-D.ietf-idr-sr-policy-safi] and [I-D.dong-pce-pcep-nrp], and the mechanism for advertising the status of SR Policy which is associated with NRP is described in [I-D.chen-idr-bgp-ls-sr-policy-nrp]. 2.1. Updated SR Policy Information Model The information model of SR Policy associated with NRP can be shown as below: Dong, et al. Expires 29 December 2024 [Page 4] Internet-Draft SR Policy with NRP June 2024 SR Policy POL1: Binding SID Candidate Path CP1 Preference Priority NRP Segment List 1 Weight W1 Segments Segment List 2 Weight W2 Segments Candidate Path CP2 Preference Priority NRP Segment List 3 Weight W3 Segments Segment List 4 Weight W4 Segments ... Figure 1: Information Model of SR Policy with NRP Although the proposed information model allows that different candidate paths of one SR policy be associated with different NRPs, in most network scenarios it is considered that the association between an SR Policy and NRP is consistent, in such case all the candidate paths of one SR policy SHOULD be associated with the same NRP. 2.2. Packet Forwarding using SR Policy with NRP The mechanism of steering packets into SR Policy as described in section 8 of [RFC9256] applies to SR Policy associated with NRP. This section describes the packet forwarding behavior using SR Policy with NRP. 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 encapsulate both the segment list and the associated NRP ID of the selected candidate path in the header of packets which are steered to the SR Policy. The segment list is used to instruct the path the packets need to traverse, and the NRP ID is used by each node along the path to identify the set of local network resources allocated to the NRP for the processing of the packet. Dong, et al. Expires 29 December 2024 [Page 5] Internet-Draft SR Policy with NRP June 2024 For SR Policy with IPv6 data plane, the approach to encapsulate the NRP ID into the IPv6 header of the data packet is defined in [I-D.ietf-6man-enhanced-vpn-vtn-id]. For SR Policy with MPLS data plane, one approach to encapsulate the NRP ID to the data packet is defined in [I-D.li-mpls-enhanced-vpn-vtn-id]. 3. Security Considerations This document introduces no additional security vulnerabilities in addition to the ones as described in [RFC9256]. 4. IANA Considerations This document has no IANA actions. 5. Acknowledgements The authors would like to thank XXX for the review and discussion of this document. 6. References 6.1. Normative References [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, . [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, . [I-D.ietf-teas-enhanced-vpn] Dong, J., Bryant, S., Li, Z., Miyasaka, T., and Y. Lee, "A Framework for Network Resource Partition (NRP) based Enhanced Virtual Private Networks", Work in Progress, Internet-Draft, draft-ietf-teas-enhanced-vpn-20, 14 June 2024, . Dong, et al. Expires 29 December 2024 [Page 6] Internet-Draft SR Policy with NRP June 2024 [I-D.ietf-spring-resource-aware-segments] Dong, J., Miyasaka, T., Zhu, Y., Qin, F., and Z. Li, "Introducing Resource Awareness to SR Segments", Work in Progress, Internet-Draft, draft-ietf-spring-resource- aware-segments-09, 6 May 2024, . [I-D.ietf-spring-sr-for-enhanced-vpn] Dong, J., Miyasaka, T., Zhu, Y., Qin, F., and Z. Li, "Segment Routing based Network Resource Partition (NRP) for Enhanced VPN", Work in Progress, Internet-Draft, draft-ietf-spring-sr-for-enhanced-vpn-07, 3 March 2024, . [I-D.ietf-teas-nrp-scalability] Dong, J., Li, Z., Gong, L., Yang, G., and G. S. Mishra, "Scalability Considerations for Network Resource Partition", Work in Progress, Internet-Draft, draft-ietf- teas-nrp-scalability-04, 4 March 2024, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . 6.2. Informative References [I-D.ietf-6man-enhanced-vpn-vtn-id] Dong, J., Li, Z., Xie, C., Ma, C., and G. S. Mishra, "Carrying Network Resource Partition (NRP) Information in IPv6 Extension Header", Work in Progress, Internet-Draft, draft-ietf-6man-enhanced-vpn-vtn-id-06, 20 February 2024, . Dong, et al. Expires 29 December 2024 [Page 7] Internet-Draft SR Policy with NRP June 2024 [I-D.li-mpls-enhanced-vpn-vtn-id] Li, Z. and J. Dong, "Carrying Virtual Transport Network (VTN) Information in MPLS Packet", Work in Progress, Internet-Draft, draft-li-mpls-enhanced-vpn-vtn-id-03, 16 October 2022, . [RFC8664] Sivabalan, S., Filsfils, C., Tantsura, J., Henderickx, W., and J. Hardwick, "Path Computation Element Communication Protocol (PCEP) Extensions for Segment Routing", RFC 8664, DOI 10.17487/RFC8664, December 2019, . [I-D.ietf-pce-segment-routing-policy-cp] Koldychev, M., Sivabalan, S., Barth, C., Peng, S., and H. Bidgoli, "Path Computation Element Communication Protocol (PCEP) Extensions for Segment Routing (SR) Policy Candidate Paths", Work in Progress, Internet-Draft, draft- ietf-pce-segment-routing-policy-cp-17, 25 June 2024, . [I-D.ietf-idr-sr-policy-safi] Previdi, S., Filsfils, C., Talaulikar, K., Mattes, P., and D. Jain, "Advertising Segment Routing Policies in BGP", Work in Progress, Internet-Draft, draft-ietf-idr-sr- policy-safi-04, 30 April 2024, . [I-D.dong-pce-pcep-nrp] Dong, J., Fang, S., Xiong, Q., Peng, S., Han, L., Wang, M., Beeram, V. P., and T. Saad, "Path Computation Element Communication Protocol (PCEP) Extensions for Network Resource Partition (NRP)", Work in Progress, Internet- Draft, draft-dong-pce-pcep-nrp-01, 23 October 2023, . [I-D.chen-idr-bgp-ls-sr-policy-nrp] Chen, R., Dong, J., Zhao, D., Gong, L., Zhu, Y., and R. Pang, "SR Policies Extensions for Network Resource Partition in BGP-LS", Work in Progress, Internet-Draft, draft-chen-idr-bgp-ls-sr-policy-nrp-08, 17 May 2024, . Dong, et al. Expires 29 December 2024 [Page 8] Internet-Draft SR Policy with NRP June 2024 Authors' Addresses Jie Dong Huawei Technologies Beijing China Email: jie.dong@huawei.com Ran Pang China Unicom Beijing China Email: pangran@chinaunicom.cn Ka Zhang Huawei Technologies Beijing China Email: zhangka@huawei.com Dong, et al. Expires 29 December 2024 [Page 9]