SPRING Working Group W. Jiang Internet-Draft W. Cheng Intended status: Standards Track China Mobile Expires: September 7, 2022 C. Lin Y. Qiu New H3C Technologies March 7, 2022 Use Cases for SR Policy Group draft-jiang-spring-sr-policy-group-use-cases-00 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 either dynamic, explicit or composite. This document illustrates some use cases for SR policy group composite candidate path in MPLS and IPv6 environment. 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 September 7, 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 Jiang, et al. Expires September 7, 2022 [Page 1] Internet-Draft SR Policy Group March 2022 to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. SR Policy Group . . . . . . . . . . . . . . . . . . . . . . . 3 4. Steering into An SR Policy Group . . . . . . . . . . . . . . 4 5. On-demand SR Policy Group . . . . . . . . . . . . . . . . . . 5 6. SR Policy Group Use Cases . . . . . . . . . . . . . . . . . . 5 6.1. SR Policy Group in L3VPN over TE Scenarios . . . . . . . 5 6.2. SR Policy Group in Cloud Backbone Acceleration Scenarios 6 6.3. SR Policy Group in the L2VPN Network Scenarios . . . . . 7 6.4. SR Policy Group in the Application-aware Scenarios . . . 8 6.5. Application of ODN SR Policy Group in Trusted Network Scenarios . . . . . . . . . . . . . . . . . . . . . . . . 9 6.6. Best-effort Forwarding Scenarios when SR Policy Becomes Unavailable . . . . . . . . . . . . . . . . . . . . . . . 11 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 8. Security Considerations . . . . . . . . . . . . . . . . . . . 11 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 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. 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. Jiang, et al. Expires September 7, 2022 [Page 2] Internet-Draft SR Policy Group March 2022 This document illustrates some use cases for SR policy group composite candidate path in MPLS and IPv6 environment. 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: SR policy group: An SR policy which contains a group of constituent SR policies. An SR policy group represents a composite candidate path. 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 SR policy group: An SR policy group dynamically created through ODN. 3. SR Policy Group An SR policy group is specified as a group of its constituent SR policies. It 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 MUST be identical, and the colors of each of the constituent SR policies and the parent SR policy MUST be different. SR policy group and its constituent SR policies follow the same criteria: o The endpoints of the constituent SR policies and its SR policy group MUST be identical. o The colors of each of the constituent SR policies and its SR policy group MUST be different. o The constituent SR policies MUST NOT contain SR policy groups. As a special SR policy, SR policy group also has color attribute, which is identified by on the headend. Jiang, et al. Expires September 7, 2022 [Page 3] Internet-Draft SR Policy Group March 2022 An 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 SR Policy Group A headend can steer a packet flow into a valid SR policy group in various ways: o Per-flow Steering: Specify the mapping relationship between color and flow characteristics (such as DSCP) for SR policy group, and create a policy group that binds a destination IP address to the SR policy group. 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 SR policy group. The device will use the matching SR policy to forward the packet. The device obtains an SR policy group for traffic steering as follows: * Matches the destination IP/IPv6 address in a packet with an SR policy group. * Searches for an SR policy group 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 SR policy group. 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 an internal per-packet forwarding-class variable. According to the forwarding-class variable the ingress node selects the matching SR policy in the SR policy group. o Policy-based Steering: incoming packets match a routing policy that directs them on an SR policy group. 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 SR policy group, forward the incoming packets through the matched SR policy. If an SR policy group 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. Jiang, et al. Expires September 7, 2022 [Page 4] Internet-Draft SR Policy Group March 2022 5. On-demand SR Policy Group 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, SR policy groups can be automatically created through ODN to establish the dynamic mapping between service types and SR policy groups, which can greatly reduce the workload of configuration. Create the ODN template of SR policy group 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 SR policy group, and the color value of the ODN template is used as the color attribute of the SR policy group to generate an SR policy group. After the SR policy group 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. SR Policy Group Use Cases The use cases described in this section do not constitute an exhaustive list of all the possible scenarios: this section only includes some of the most common envisioned deployment models for SR policy group. 6.1. SR Policy Group 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 SR policy group. 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. Jiang, et al. Expires September 7, 2022 [Page 5] Internet-Draft SR Policy Group March 2022 +----+ +--| P3 |--+ | +----+ | | | +-----+ +-----+ +----+ +----+ +-----+ +-----+ | CE1 |---| PE1 |---| P1 |----| P2 |----| PE2 |---| CE2 | +-----+ +-----+ +----+ +----+ +-----+ +-----+ | | |<===========================>| SR Policy Group Figure 1 It is assumed that in this network, the policy group 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. SR Policy Group 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 SR policy group on the core of the cloud backbone network to prevent network congestion. There are multiple SR policies in the SR policy group. 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. Jiang, et al. Expires September 7, 2022 [Page 6] Internet-Draft SR Policy Group March 2022 ................................... . Backbone . . +--------+ . . | Public | . . +--------| Cloud |-----------+ . . | +--------+ | . +--------+ . | | . +--------+ | Public |---+ . | | . +---| Public | | Cloud | |_+----+ +----+ +----+ +----+_| | Cloud | +--------+ | PE |----| P |-----| P |----| PE | +--------+ |-+----+ +----+ +----+ +----+-| +--------+ | . | | . | +--------+ |Private |---+ . | +----+ | . +---|Private | | Cloud | . +--| P |--+ . | Cloud | +--------+ . +----+ . +--------+ . |<=============>| . . SR Policy group . ................................... Figure 2 Through the SR policy group, different forwarding paths can be introduced based on the DSCP value in the IP/IPv6 packet header. First, create an SR policy group and assign color identification to the SR policy group. Then, configure multiple SR policies into one SR policy group in the headend, specify the mapping relationship between each SR policy and DSCP value in the SR policy group, and then bind the service type to the specified SR policy group. In this way, when the headend receives traffic, it first matches to the SR policy group according to the next hop and color of the route, and then finds the mapped SR policy in the corresponding group according to the DSCP value carried in the IP/IPv6 packet header. DSCP based steering is suitable for differentiating services at the source and specifying different DSCP value scenarios. 6.3. SR Policy Group 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 SR policy group. Different services can be forwarded into different paths. Jiang, et al. Expires September 7, 2022 [Page 7] Internet-Draft SR Policy Group March 2022 +----+ +---| P1 |---+ | +----+ | +-----+ +-----+ | | +-----+ +-----+ | CE1 |---| PE1 |---| |---| PE2 |---| CE2 | +-----+ +-----+ | | +-----+ +-----+ | +----+ | +---| P2 |---+ | +----+ | |<========================>| SR Policy Group 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 SR policy group. 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. SR Policy Group 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 SRv6 policy to transmit the data packets (e.g., low latency path) to meet the SLA requirements and service chain in order to improve the service quality. As shown in Figure 4 below, the policy group 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. Jiang, et al. Expires September 7, 2022 [Page 8] Internet-Draft SR Policy Group March 2022 +------+ +-----------+ +------+ | APP1 | /=====| Policy-A |=====\ | APP1 | +------+ / +-----------+ \ +------+ +------+ +-------+ +-----------+ +--------+ +------+ | APP2 |---| PE |====| Policy-B |===| PE |---| APP2 | +------+ +-------+ +-----------+ +--------+ +------+ +------+ \ +-----------+ / +------+ | APP3 | \=====| Policy-C |=====/ | APP3 | +------+ +-----------+ +------+ |<============================>| SR Policy Group Figure 4 6.5. Application of ODN SR Policy Group 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 September 7, 2022 [Page 9] Internet-Draft SR Policy Group March 2022 ---------- / \ | APP Server | \ / ---------- | | +----------+ | | +----------------| Device-E |---------------+ ===== | | | | ^ S | +----------+ | | R | Trustworthiness level =7 | | | | | | p | | | | o +----------+ +----------+ +----------+ | l | | | | | | | i | Device-B | | Device-C | | Device-D | | c | | | | | | | y +----------+ +----------+ +----------+ | Trustworthiness level =1 | Trustworthiness level =3 | g | Trustworthiness level =3 | | r | | | | o | +----------+ | | u +----------------| |---------------+ V p | 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 an SR policy group (C1, E) according to the ODN template of color C1. Jiang, et al. Expires September 7, 2022 [Page 10] Internet-Draft SR Policy Group March 2022 The composition SR policy of SR policy group is also generated according to ODN template. DSCP1 is mapped to color C2. After creating an SR policy group (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 SR policy group 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 SR policy group, 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 an best- effort forwarding path in the SR policy group. When all specified candidate paths are invalid, or the mapping relationship corresponding to their service type is not matched in the SR policy group, select the default best-effort path forwarding. 7. IANA Considerations This document has no IANA actions. 8. Security Considerations This document presents use cases to be considered by the deployment of SR Policy. It does not introduce any security considerations. 9. References [I-D.ietf-idr-segment-routing-te-policy] Previdi, S., Filsfils, C., Talaulikar, Ed., K., Mattes, P., Jain, D., and S. Lin, "Advertising Segment Routing Policies in BGP", draft-ietf-idr-segment-routing-te- policy-14 (work in progress), November 2021. Jiang, et al. Expires September 7, 2022 [Page 11] Internet-Draft SR Policy Group March 2022 [I-D.ietf-spring-segment-routing-policy] Filsfils, C., Talaulikar, Ed., K., Voyer, D., Bogdanov, A., and P. Mattes, "Segment Routing Policy Architecture", draft-ietf-spring-segment-routing-policy-18 (work in progress), February 2022. [I-D.lin-opsec-trustroute-problem-statement] Lin, T., Li, H., Shi, X., Yin, X., and W. Chen, "Problem Statement and Use Cases of Trustworthiness-based Routing", draft-lin-opsec-trustroute-problem-statement-01 (work in progress), December 2021. [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, . 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 September 7, 2022 [Page 12]