SPRING Working Group W. Jiang Internet Draft W. Cheng Intended status: Standards Track China Mobile Expires: January 10, 2023 C. Lin Y. Qiu New H3C Technologies July 9, 2022 Use Cases for Parent SR Policy draft-jiang-spring-parent-sr-policy-use-cases-00 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), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. 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." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html This Internet-Draft will expire on January 10 2023. 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 (http://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 Simplified BSD License text as described in Jiang, et al. Expire January, 2023 [Page 1] Internet-Draft Parent SR Policy July 2022 Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Abstract Segment Routing is a source routing paradigm that explicitly indicates the forwarding path for packets at the ingress node. An SR Policy is associated with one or more candidate paths, and each candidate path is dynamic, explicit or composite. This document illustrates some use cases for parent SR policy in MPLS and IPv6 environment. Table of Contents 1. Introduction ................................................ 2 2. Terminology ................................................. 3 3. Parent SR Policy ............................................ 3 4. Steering into an parent SR Policy ........................... 4 5. On-demand parent SR Policy .................................. 5 6. Parent SR Policy Use Cases .................................. 5 6.1. Parent SR Policy in L3VPN over TE Scenarios ............. 6 6.2. Parent SR Policy in Cloud Backbone Acceleration Scenarios 6 6.3. Parent SR Policy in the L2VPN Network Scenarios ......... 8 6.4. Parent SR Policy in the Application-aware Scenarios ..... 8 6.5. Application of ODN parent SR Policy in Trusted Network Scenarios ................................................... 9 6.6. Best-effort Forwarding Scenarios when SR Policy Becomes Unavailable ................................................ 11 7. Implementation Status ...................................... 11 8. IANA Considerations ........................................ 11 9. Security Considerations .................................... 12 10. References ................................................ 12 10.1. Normative References ................................. 12 10.2. Informative References ............................... 12 11. Acknowledgments ........................................... 12 Authors' Addresses ............................................ 13 1. Introduction Segment routing (SR) [RFC8402] is a source routing paradigm that explicitly indicates the forwarding path for packets at the ingress node. The ingress node steers packets into a specific path according to the Segment Routing Policy (SR Policy) as defined in [I-D.ietf- spring-segment-routing-policy]. In order to distribute SR policies to the headend, [I-D.ietf-idr-segment-routing-te-policy] specifies a mechanism by using BGP. Jiang, et al. Expires January, 2023 [Page 2] Internet-Draft Parent SR Policy July 2022 An SR Policy is associated with one or more candidate paths. A composite candidate path acts as a container for grouping SR Policies. As described in section 2.2 in [I-D.ietf-spring-segment- routing-policy], the composite candidate path construct enables combination of SR Policies, each with explicit candidate paths and/or dynamic candidate paths with potentially different optimization objectives and constraints, for load-balanced steering of packet flows over its constituent SR Policies. For service-class based steering, and in the best-effort forwarding scenario when SR policy becomes unavailable, packets are also forwarded over the constituent SR policies of composite candidate path. For convenience, the composite candidate path formed by the combination of SR policies is called parent SR policy. In [I-D.ietf- spring-segment-routing-policy], there is no use case about SR policy composite candidate path. This document illustrates some use cases for parent SR policy in MPLS and IPv6 environment to provide best practice cases for operators. 2. Terminology The definitions of the basic terms are identical to those found in Alternate Marking [RFC8402]. The important new terms that need to be explained are listed below: Parent SR policy: According to [I-D.ietf- spring-segment-routing-policy],a parent SR policy represents a composite candidate path that acts as a container for grouping SR policies. ODN: On-demand Next-Hop. ODN SR policy: Preconfigure an ODN template specified color. When the device receives a BGP route, if the color extended attribute value of the BGP route is the same as the color value of an ODN template, the device can automatically create an SR policy. ODN parent SR policy: A parent SR policy dynamically created through ODN. 3. Parent SR Policy An SR Policy is associated with one or more candidate paths. According to [I-D.ietf-spring-segment-routing-policy],a parent SR Policy is the composite candidate path that acts as a container for grouping SR policies. The parent SR Policy is valid when it has at least one valid constituent SR policy. As defined in [I-D.ietf-spring-segment-routing-policy], the endpoints of the constituent SR Policies and the parent SR Policy Jiang, et al. Expires January, 2023 [Page 3] Internet-Draft Parent SR Policy July 2022 MUST be identical, and the colors of each of the constituent SR Policies and the parent SR Policy MUST be different. Parent SR policy and its constituent SR Policies follow the same criteria: The endpoints of the constituent SR Policies and its parent SR Policy MUST be identical The colors of each of the constituent SR Policies and its parent SR Policy MUST be different The constituent SR Policies MUST NOT contain parent SR policy As a special SR policy, parent SR policy also has color attribute, which is identified by on the headend. A parent SR policy can be generated by static configuration or a centralized controller distribution, also can be generated based on the on-demand SR policy optimization template dynamically. 4. Steering into an parent SR Policy A headend can steer a packet flow into a valid parent SR Policy in various ways: o Per-flow Steering: Specify the mapping relationship between color and flow characteristics (such as DSCP) for parent SR policy, and create a parent policy that binds a destination IP address. Upon receiving a packet with the specified destination address, the device searches for the SR policy containing the color value mapped to the flow characteristics of the packet in the parent SR policy. The device will use the matching SR policy to forward the packet. The device obtains a parent SR policy for traffic steering as follows: * Matches the destination IP/IPv6 address in a packet with a parent SR policy. * Searches for a parent SR policy with color and endpoint address matching the color extended community attribute and next hop in a BGP route, and recurses the BGP route to the parent SR policy. The Ingress node can match flow characteristics in its ingress interfaces (upon any field such as Ethernet destination/source/VLAN/TOS or IP destination/source/DSCP or transport ports or application attribute etc.) and color them with Jiang, et al. Expires January, 2023 [Page 4] Internet-Draft Parent SR Policy July 2022 an internal per-packet forwarding-class variable. According to the forwarding-class variable the ingress node selects the matching SR policy in the parent SR policy. o Policy-based Steering: incoming packets match a routing policy that directs them on a parent SR policy. Parse the flow characteristics (such as DSCP/802.1p value) from the packet header, find its corresponding color, and then match it to an SR policy in the parent SR policy, forward the incoming packets through the matched SR policy. If a parent SR policy has at least one valid constituent SR Policy of specified color, flow load-balance steer over its valid constituent SR policies with the same color. When all constituent SR policies of specified color are invalid, packets are forwarded based on a default SR policy preconfigured. 5. On-demand parent SR Policy SR policies are generally generated by manual static configuration or distributed by centralized controller. Manual configuration may be troublesome, especially when many SR policies need to be configured. The controller mode may also not be suitable for operators who need to make full use of distributed intelligence. In scenarios that distinguish service forwarding paths based on DSCP value and 802.1p priority, parent SR policies can be automatically created through ODN to establish the dynamic mapping between service types and parent SR policies, which can greatly reduce the workload of configuration. Create the ODN template of parent SR policy in the headend. When the device receives a BGP route, if the color extended community attribute carried by the BGP route is the same as the color value of the ODN template, the next hop address of the BGP route is used as the destination endpoint address of the parent SR policy, and the color value of the ODN template is used as the color attribute of the parent SR policy to generate an parent SR policy. After the parent SR policy is created by ODN, its constituent SR policy is usually generated by ODN. ODN SR policy dynamically generates candidate paths through affinity attributes, flex-algo algorithm or PCE calculation. 6. Parent SR Policy Use Cases The use cases described in this section do not constitute an exhaustive list of all the possible scenarios: this section only Jiang, et al. Expires January, 2023 [Page 5] Internet-Draft Parent SR Policy July 2022 includes some of the most common envisioned deployment models for parent SR policy. 6.1. Parent SR Policy in L3VPN over TE Scenarios In Figure 1, CE1 and CE2 belong to the same L3VPN and access the public network through PE1 and PE2 respectively. There are many kinds of traffic between CE1 and CE2. When the ordinary traffic is too large, the forwarding of important traffic will be affected. In order to ensure the forwarding quality of important services, the steering based on Forwarding class can be configured using parent SR policy. After the steering based on forwarding class is configured, the traffic of different service levels will be carried by the specified SR policy tunnel, which can effectively ensure the forwarding quality of important services with high service levels. +----+ +--| P3 |--+ | +----+ | | | +-----+ +-----+ +----+ +----+ +-----+ +-----+ | CE1 |---| PE1 |---| P1 |----| P2 |----| PE2 |---| CE2 | +-----+ +-----+ +----+ +----+ +-----+ +-----+ | | |<===========================>| Parent SR Policy Figure 1 It is assumed that in this network, the parent policy contains three constituent policies: Policy-A, Policy-B and Policy-C. Services with different forwarding class will carry different DSCP values in the packet. Identify the customer's service through DSCP on PE1. The voice traffic of VIP customers is forwarded according to the path of low-delay Policy-A, other traffic of VIP customers is forwarded according to the path of Policy-B, and all businesses of non VIP customers are carried by Policy-C. 6.2. Parent SR Policy in Cloud Backbone Acceleration Scenarios As shown in Figure 2, multiple cloud data centers are interconnected through cloud backbone networks. In the public cloud, there are different SLA requirements for different service types, such as voice service and cloud disk. Deploy a static parent SR policy on Jiang, et al. Expires January, 2023 [Page 6] Internet-Draft Parent SR Policy July 2022 the core of the cloud backbone network to prevent network congestion. There are multiple SR policies in the parent SR policy. In order to ensure the service quality of different types of services, the service types are distinguished by flow classification, then different services are mapped to different DSCP value, and finally the traffic of different DSCP is imported into different SR policies. ................................... . Backbone . . +--------+ . . | Public | . . +--------| Cloud |-----------+ . . | +--------+ | . +--------+ . | | . +--------+ | Public |---+ . | | . +---| Public | | Cloud | |-+----+ +----+ +----+ +----+-| | Cloud | +--------+ | PE |----| P |-----| P |----| PE | +--------+ |-+----+ +----+ +----+ +----+-| +--------+ | . | | . | +--------+ |Private |---+ . | +----+ | . +---|Private | | Cloud | . +--| P |--+ . | Cloud | +--------+ . +----+ . +--------+ . |<------------->| . . Parent SR Policy . ................................... Figure 2 Through the parent SR policy, different forwarding paths can be introduced based on the DSCP value in the IP/IPv6 packet header. First, create a parent SR policy and assign color identification to the parent SR policy. Then, configure multiple SR policies into one parent SR policy in the headend, specify the mapping relationship between each SR policy and DSCP value in the parent SR policy, and then bind the service type to the specified parent SR policy. In this way, when the headend receives traffic, it first matches to the parent SR policy according to the next hop and color of the route, and then finds the mapped SR policy in the corresponding parent policy according to the DSCP value carried in the IP/IPv6 packet header. Jiang, et al. Expires January, 2023 [Page 7] Internet-Draft Parent SR Policy July 2022 DSCP based steering is suitable for differentiating services at the source and specifying different DSCP value scenarios. 6.3. Parent SR Policy in the L2VPN Network Scenarios Similar to the DSCP-based steering scenario, in the layer 2 access network and L2VPN network, the service types are distinguished by the 802.1p priority in the packet header, and the 802.1p priority is mapped to color in the parent SR policy. Different services can be forwarded into different paths. +----+ +---| P1 |---+ | +----+ | +-----+ +-----+ | | +-----+ +-----+ | CE1 |---| PE1 |---| |---| PE2 |---| CE2 | +-----+ +-----+ | | +-----+ +-----+ | +----+ | +---| P2 |---+ | +----+ | |<========================>| Parent SR Policy Figure 3 As shown in Figure 3, CE1 and CE2 belong to the same VPLS and are connected to the MPLS backbone network through PE1 and PE2 respectively. Establish two MPLS-SR policy tunnels Policy-A and Policy-B between PE1 and PE2 to carry this VPLS service. Policy-A and Policy-B are the constituent policies of parent SR policy. Two SR policy tunnels correspond to two different priorities. The VPLS access end classifies the traffic flow, trusts the priority of 802.1p, and introduces the services of VPLS leased line users and non-leased line users into different SR policy according to different priorities. 6.4. Parent SR Policy in the Application-aware Scenarios By carrying the application attribute (including APP ID and APP parameters) through data packets, i.e., the delivery of application- aware information and ensuring the security and reliability of application-aware information, the network senses the application groups' requirements and provides high-quality differentiated services according to the demand of the applications. And when the network transmits the data packets, it matches the SR policy according to the application attribute in the data packets and selects the corresponding path of constituent SR policy to transmit the data packets (e.g., low latency path) to meet the SLA Jiang, et al. Expires January, 2023 [Page 8] Internet-Draft Parent SR Policy July 2022 requirements and service chain in order to improve the service quality. As shown in Figure 4 below, the parent policy contains three constituent SR policies: Policy-A, Policy-B and Policy-C. The data packets of APP1 are forwarded by Policy-A, the data packets of APP2 are forwarded by Policy-B, and the data packets of APP3 are forwarded by Policy-C. +------+ +-----------+ +------+ | APP1 | /=====| Policy-A |=====\ | APP1 | +------+ / +-----------+ \ +------+ +------+ +-------+ +-----------+ +--------+ +------+ | APP2 |---| PE |====| Policy-B |===| PE |---| APP2 | +------+ +-------+ +-----------+ +--------+ +------+ +------+ \ +-----------+ / +------+ | APP3 | \=====| Policy-C |=====/ | APP3 | +------+ +-----------+ +------+ |<---------------------------->| Parent SR Policy Figure 4 6.5. Application of ODN parent SR Policy in Trusted Network Scenarios Section 3 of [I-D.lin-opsec-trustroute-problem-statement] introduces the use case of trusted network. By dynamically creating SR policy through ODN, automatic steering traffic according to security level can be realized. From the perspective of security and trustworthiness, the security levels for users with different security requirements and the trustworthiness levels of the network transmission devices can be determined according to their performance and reliability. Different forwarding paths are provided for packets with different security levels. Jiang, et al. Expires January, 2023 [Page 9] Internet-Draft Parent SR Policy July 2022 ---------- / \ | APP Server | \ / ---------- | | +----------+ | | +----------------| Device-E |---------------+ ===== | | | | ^ P | +----------+ | | a | Trustworthiness level =7 | | r | | | | e | | | | n | | | | t +----------+ +----------+ +----------+ | | | | | | | | S | Device-B | | Device-C | | Device-D | | R | | | | | | | +----------+ +----------+ +----------+ | P Trustworthiness level =1 | Trustworthiness level =3 | o | Trustworthiness level =3 | | l | | | | i | +----------+ | | c +----------------| |---------------+ V y | Device-A | ===== +---------------| |---------------+ | +----------+ | | Trustworthiness level =7 | | | | | | | +----------+ +----------+ +----------+ | User-1 | | User-2 | | User-3 | +----------+ +----------+ +----------+ security level =1 security level =2 security level =3 Figure 5 As shown in Figure 5, the trustworthiness level is configured on each network transmission device. Device-E colors the advertised BGP routes through the color extended community attribute, and different services correspond to different colors. When Device-A receives a BGP route with color C1 and endpoint E, device a will automatically generate a parent SR policy (C1, E) according to the ODN template of color C1. Jiang, et al. Expires January, 2023 [Page 10] Internet-Draft Parent SR Policy July 2022 The composition SR policy of parent SR policy is also generated according to ODN template. DSCP1 is mapped to color C2. After creating a parent SR policy (C1, E), Device-A generates an ODN SR policy (C2, E) according to the mapping relationship between DSCP and color (DSCP1->C2). Services with different security levels use different DSCPs. When the user generates a service packet, it carries the corresponding DSCP value (DSCP1) on the IPv6 packet header, and sends it to the Device-A. After receiving the service packet, the service packet is steered according to SR policy (C2, E). 6.6. Best-effort Forwarding Scenarios when SR Policy Becomes Unavailable When all the constituent SR policies in the parent SR policy are not valid, or all the selected paths of the SR policy are unavailable, the service traffic will not be forwarded according to the specified path. At this time, the best-effort forwarding path can be configured for the parent SR policy, and the endpoints through which traffic forwarding must pass can be designed in the best-effort forwarding path. During network deployment, the best-effort forwarding path can be a default SR policy or an SR BE forwarding path. Specify a best-effort forwarding path in the parent SR policy. When all specified candidate paths are invalid, or the mapping relationship corresponding to their service type is not matched in the parent SR policy, select the default best-effort path forwarding. 7. Implementation Status In November 2021, by configuring the parent SR Policy defined in this document, China Mobile has successfully verified the composite candidate path that acts as a container for grouping SR Policies on the device and controller. Hardware implementation in H3C CR16010H-FA and CR19000-8 running Comware China mobile IP Network Controller 8. IANA Considerations This document has no IANA actions. Jiang, et al. Expires January, 2023 [Page 11] Internet-Draft Parent SR Policy July 2022 9. Security Considerations This document presents use cases to be considered by the deployment of SR Policy. It does not introduce any security considerations. 10. References 10.1. Normative References [I-D.ietf-spring-segment-routing-policy] Filsfils, C., Talaulikar, K., Voyer, D., Bogdanov, A., and P. Mattes, "Segment Routing Policy Architecture", draft-ietf-spring-segment- routing-policy-22 (work in progress), March 2022. [I-D.ietf-idr-segment-routing-te-policy] Previdi, S., Filsfils, C., Talaulikar, K., Mattes, P., Rosen, E., Jain, D., and S. Lin, "Advertising Segment Routing Policies in BGP", draft- ietf-idr-segment-routing-te-policy-18 (work in progress), June 2022. [I-D.lin-opsec-trustroute-problem-statement] Lin, T., Li, H., Shi, X., Yin, X., Chen, W., "Problem Statement and Use Cases of Trustworthiness-based Routing", draft-lin-opsec- trustroute-problem-statement-02 (work in progress), June 2022. [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., Decraene, B., Litkowski, S., and R. Shakir, "Segment Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, July 2018, . 10.2. Informative References TBD 11. Acknowledgments The authors would like to thank the following for their valuable contributions of this document: TBD Jiang, et al. Expires January, 2023 [Page 12] Internet-Draft Parent SR Policy July 2022 Authors' Addresses Wenying Jiang China Mobile Email: jiangwenying@chinamobile.com Weiqiang Cheng China Mobile Email: chengweiqiang@chinamobile.com Changwang Lin New H3C Technologies Email: linchangwang.04414@h3c.com Yuanxiang Qiu New H3C Technologies Email: qiuyuanxiang@h3c.com Jiang, et al. Expires January, 2023 [Page 13]