Network Working Group Gary Geng Internet Draft Tencent Intended status: Informational Y. Liu Expires: September 3, 2024 China Mobile C. Xie China Telecom C. Lin New H3C Technologies March 4, 2024 Best practices for traffic steering to SRv6 draft-geng-srv6ops-traffic-steering-to-srv6-00 Abstract This document primarily describes the traffic steering towards SRv6- BE and SRv6-TE respectively, providing an overview of the main traffic steering methods for these two approaches. Furthermore, it discusses the recommended traffic steering methods for various typical scenarios. 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 3, 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 (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 lin, et al. Expire September 3, 2024 [Page 1] Internet-Draft Best practices for traffic steering to SRv6 March 2024 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...................................................3 1.1. Conventions and Terminology...............................3 2. Steering to SRv6...............................................3 2.1. Steering to SRv6 based on destination address.............3 2.2. Steering to SRv6 based on flow characteristics............5 3. UseCase........................................................6 3.1. Traffic steering based on destination address.............7 3.1.1. BSID-based Traffic Steering..........................7 3.1.2. Color-based Traffic Steering ........................7 3.1.3. IGP-Shortcut Traffic Steering .......................7 3.2. Traffic steering based on flow characteristics............8 3.2.1. Dscp-based Traffic Steering .........................8 3.2.2. 802.1p-based Traffic Steering........................8 3.2.3. Service-class-based Traffic Steering.................9 3.2.4. Te-class-based Traffic Steering .....................9 3.2.5. Traffic steering via BGP-FlowSpec ..................10 4. Security Considerations.......................................11 5. IANA Considerations...........................................11 6. References....................................................11 6.1. Normative References ....................................11 Authors' Addresses...............................................12 lin, et al. Expires September 3, 2024 [Page 2] Internet-Draft Best practices for traffic steering to SRv6 March 2024 1. Introduction The general purpose of traffic steering is to optimize the allocation and transmission of network resources, ensure a balanced distribution of network traffic, improve network performance, reduce congestion, and increase available bandwidth to provide users with a better network experience. This document initially describes the traffic steering towards SRv6- BE and SRv6-TE respectively, and outlines the main traffic steering methods for these two approaches. Finally, it discusses the recommended traffic steering methods for various typical scenarios. 1.1. Conventions and Terminology 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. Steering to SRv6 Steering to SRv6 can be categorized into two types: Steering based on destination address and Steering based on flow characteristics. The means of traffic steering in SRv6 include using static routing for traffic steering, employing PBR (Policy-Based Routing) policies for traffic steering, distributing routes through BGP (Border Gateway Protocol) for traffic steering, utilizing BGP-Flowspec to publish rules for traffic steering, and utilizing IGP-Shortcut for traffic steering. 2.1. Steering to SRv6 based on destination address Traffic can typically be steered based on the destination address by matching traffic destination address via static routing or utilizing Policy-Based Routing (PBR). 1)Steering traffic to SRv6 via static routing: ipv6 route-static {x:x::x:x/xx} {y:y::y:y} Steering traffic based on the destination address with static routing. Where {y:y::y:y} represents an SRv6 SID, which can be a DT4/DT6 address, indicating traffic steering into an L3VPN; lin, et al. Expires September 3, 2024 [Page 3] Internet-Draft Best practices for traffic steering to SRv6 March 2024 If {y:y::y:y} is a BSID address, it represents traffic steering into an SRv6 TE Policy; ipv6 route-static {x:x::x:x/xx} color {color} end-point ipv6 {end- point} Through the above static route configuration, for matched destination addresses, traffic color and end-point can be specified, and associated with an SRv6 TE Policy, enabling traffic steering into the SRv6 TE Policy. 2) Steering traffic to SRv6 via PBR: ipv6 policy-based-route srv6 permit node 0 if-match acl 2000 apply next-hop y:y::y:y Steering traffic based on the destination address using PBR. Similarly, if {y:y::y:y} represents a DT4/DT6 address, it indicates traffic steering into an L3VPN; If {y:y::y:y} is a BSID address, it signifies traffic steering into an SRv6 TE Policy; When using PBR for traffic steering, for matched destination addresses, specifying traffic color and end-point, and associating with an SRv6 TE Policy, can effectively steer traffic into the SRv6 TE Policy. 3) Steering traffic to SRv6 via BGP-FlowSpec: By deploying BGP-FlowSpec rules from the controller, traffic matching specific destination addresses can be steered. Once matched, BGP-FlowSpec can specify the next-hop address as a DT4/DT6 address to route the traffic into an L3VPN. Alternatively, specifying the next-hop address as a BSID address can direct the traffic into an SRv6 TE Policy. 4) Steering traffic to SRv6 via IGP shortcut: IGP shortcut, also known as the automatic traffic announcement feature of an IGP, treats an SRv6 TE Policy as a direct link between lin, et al. Expires September 3, 2024 [Page 4] Internet-Draft Best practices for traffic steering to SRv6 March 2024 the endpoints for announcement purposes. During route calculation, if the destination address of the traffic corresponds to the tunnel's destination address, the traffic is steered into the SRv6 TE Policy. 2.2. Steering to SRv6 based on flow characteristics Identifying traffic based on specific flow characteristics and steering traffic according to these characteristics. Flow characteristics include Layer 2 attribute 802.1p, Layer 3 IP feature DSCP value, as well as service-level attributes such as service class and TE class ID. 1) Steering Traffic to SRv6 via PBR Based on Traffic Characteristics ipv6 policy-based-route srv6 permit node 0 if-match acl 2000 apply next-hop y:y::y:y # By specifying traffic characteristics in the ACL to match traffic and then designating the next-hop for the traffic as the SRv6 next- hop address or BSID address, traffic can be directed to SRv6 BE or SRv6 TE policy. 2)Steering traffic via BGP flowspec By using flowspec, specify the next-hop address in the route attributes as the BSID of the SRv6 TE Policy, in order to steering the traffic associated with this route to the destination of the SRv6 TE Policy. By using flowspec, specify the next-hop address in the route attributes as the BSID of the SRv6 TE Policy, in order to steering the traffic associated with this route to the destination of the SRv6 TE Policy. 3) Steering to SRv6 TE via Tunnel-Policy First, based on the traffic destination address, tunnel policies are matched and associated with an SRv6 TE Policy-Group. The Policy- Group contains multiple policies, each with a different color value. A specific traffic characteristic is then mapped to different color values, and based on the color value, corresponding SR Policies are found within the Policy-Group to direct the traffic to the SR TE lin, et al. Expires September 3, 2024 [Page 5] Internet-Draft Best practices for traffic steering to SRv6 March 2024 Policy. Typically, the characteristics used to map traffic to different colors include DSCP values, Dot1P values, TE Class IDs, service classes, and others. 3. UseCase SRv6 BE(Best Effort), is a method of forwarding traffic without strict quality of service guarantees. It allows for the flexible and efficient forwarding of packets, prioritizing simplicity and scalability. This approach is well-suited for scenarios where fine- grained traffic control is not necessary and where best effort delivery meets the requirements of the network. Traffic engineering technology calculates and arranges the forwarding paths of traffic to optimize network resource utilization and improve bandwidth efficiency. Additionally, this technology ensures reliable service quality for business operations and prevents all business traffic from competing for resources on the shortest path. Therefore, deploying and utilizing traffic engineering in SRv6 networks has become a necessary requirement for the promotion and development of SRv6 technology. The traffic engineering technology based on SRv6 is referred to as SRv6 TE. As shown in Figure 1, SRv6 Policy 1 has a BSID of 1000::1, Color 100, and Endpoint 4::4, with a forwarding path of B->C->D. SRv6 Policy 2 has a BSID of 2000::1, Color 200, and Endpoint 4::4, with a forwarding path of E->F->D. SRv6 Policy 1: +---------+ +---------+ BSID<1000::1> |RouterB |--------------------|RouterC | Color 100 +-/-------+ +-------\-+ Endpoint 4::4 / \ SID List / \ +-/------+ BGP Route +------\-+ |RouterA | <---------------- |RouterD | EndPoint: 4::4 +-\------+ +------/-+ SRv6 Policy 2: \ / BSID<2000::1> \ / Color 200 +-\-------+ +-------/-+ Endpoint 4::4 |RouterE |--------------------|RouterF | SID List +---------+ +---------+ Figure 1. SRv6 Traffic Steering Network Diagram lin, et al. Expires September 3, 2024 [Page 6] Internet-Draft Best practices for traffic steering to SRv6 March 2024 3.1. Traffic steering based on destination address 3.1.1. BSID-based Traffic Steering When a device receives a packet with a destination IPv6 address matching the BSID of an SRv6 TE Policy, the packet will be forwarded according to the corresponding SRv6 TE Policy. BSID-based traffic steering is commonly used in BSID stitching scenarios, where the BSID of another SRv6 TE Policy is added to the SID list of one SRv6 TE Policy. This helps reduce the length of the SRH header in the packet during the forwarding process, enabling seamless stitching between different SRv6 TE Policies or between an SRv6 TE Policy and an SR-MPLS TE Policy. As shown in Figure 1, when the destination address of traffic is specified as BSID 1000::1 of SRv6 Policy 1, the traffic will be forwarded along the path defined by SRv6 TE Policy 1. If the destination address is specified as BSID 2000::1 of SRv6 Policy 2, the traffic will be forwarded along the path defined by SRv6 TE Policy 2. 3.1.2. Color-based Traffic Steering Color-based traffic steering is one of the fundamental methods used in SRv6 TE Policy. This approach leverages the BGP route's extended community attribute called Color and the destination address to match the Color and End-point address in the SRv6 TE Policy. Typically, if there is an SRv6 TE Policy on the device with the same Color and End-point address as the Color extended community attribute and next-hop address of the BGP route, the BGP route will be steered to that SRv6 TE Policy. When the device receives a packet that matches the BGP route, it is forwarded through the SRv6 TE Policy. As shown in Figure 1, the BGP protocol advertises the prefix routes that require traffic steering, such as specifying the Color attribute of route 1::1/128 as 100 and the next-hop attribute as 4::4, and specifying the Color attribute of route 2::2/128 as 200 and the next-hop attribute as 4::4. Therefore, for traffic with a destination address of 1::1, it will be forwarded along the path defined by SRv6 TE Policy 1, while for traffic with a destination address of 2::2, it will be forwarded along the path defined by SRv6 TE Policy 2. 3.1.3. IGP-Shortcut Traffic Steering When using IGP-shortcut for traffic steering based on the destination address, the routing table information for traffic lin, et al. Expires September 3, 2024 [Page 7] Internet-Draft Best practices for traffic steering to SRv6 March 2024 steering is no longer published by the BGP protocol. Instead, it is automatically generated on the head-end device A based on the SRv6 TE Policy. In the scenario illustrated in Figure 1, enabling the IGP-shortcut feature causes the head-end node to automatically generate a route for 4::4/128 and set the egress interface to point to the SRv6 TE Policy when the SRv6 TE Policy status is Up. In the event that the SRv6 TE Policy status changes to Down, the automatically generated route pointing to the SRv6 TE Policy is withdrawn and replaced with forwarding based on SRv6 BE. 3.2. Traffic steering based on flow characteristics 3.2.1. Dscp-based Traffic Steering The basic principle of DSCP-based traffic steering is to route the packets to the corresponding SRv6 TE Policy based on the DSCP (Differentiated Services Code Point) value of the packet. This traffic steering method requires the deployment of SRv6 TE Policy groups and the redirection of traffic to these SRv6 TE Policy groups. After that, specific DSCP values are mapped to corresponding SRv6 TE Policy groups to steer the packets to the desired SRv6 TE Policy. As shown in Figure 1, the BGP protocol advertises the prefix routes that require traffic steering, specifying the next-hop attribute of route 1::1/128 as 4::4 but not specifying the Color attribute. On device A, an SRv6 TE Policy group is created with an End-point address of device D's address 4::4. Within the SRv6 TE Policy group, a Color and DSCP mapping relationship is defined, where DSCP 10 maps to Color 100 and DSCP 20 maps to Color 200. Subsequently, a tunnel policy is configured on source node A, binding the SRv6 TE Policy group with the destination address 2.2.2.2. This arrangement ensures that for traffic with a destination address of 1::1, if the DSCP value is 10, it will be forwarded along the path defined by SRv6 TE Policy 1; if the DSCP value is 20, it will be forwarded along the path defined by SRv6 TE Policy 2. 3.2.2. 802.1p-based Traffic Steering The basic principle of 802.1p-based traffic steering is to route the packets to the corresponding SRv6 TE Policy based on the 802.1p (Priority) value of the packet. This traffic steering method requires the prior deployment of SRv6 TE Policy groups and the redirection of traffic to these SRv6 TE Policy groups. Subsequently, based on the mapping rules within the SRv6 TE Policy groups, packets with specific 802.1p values are steered to the corresponding SRv6 TE Policy. lin, et al. Expires September 3, 2024 [Page 8] Internet-Draft Best practices for traffic steering to SRv6 March 2024 As shown in Figure 1, the BGP protocol advertises the prefix routes that require traffic steering, specifying the next-hop attribute of route 1::1/128 as 4::4 but not specifying the Color attribute. On device A, an SRv6 TE Policy group is created with an End-point address of device D's address 4::4. Within the SRv6 TE Policy group, a Color and 802.1p mapping relationship is defined, where 802.1p 10 maps to Color 100 and 802.1p 20 maps to Color 200. Subsequently, a tunnel policy is configured on source node A, binding the SRv6 TE Policy group with the destination address 2.2.2.2. This setup ensures that for traffic with a destination address of 1::1, if the 802.1p value is 10, it will be forwarded along the path defined by SRv6 TE Policy 1; if the 802.1p value is 20, it will be forwarded along the path defined by SRv6 TE Policy 2. 3.2.3. Service-class-based Traffic Steering To ensure that all traffic packets can be steered, even if they do not carry DSCP or Dot1p information, the device introduces a local identification called "service-class" to distinguish different classes of service traffic. Both service-class-based traffic steering and CBTS-based traffic steering are achieved through the service-class identifier. However, service-class-based traffic steering requires the traffic to first enter the SRv6 TE Policy group, and then, based on the mapping rules within the SRv6 TE Policy group, specific packets with service-class identifiers are redirected to the corresponding SRv6 TE Policy. As shown in Figure 1, the BGP protocol advertises the prefix routes that require traffic steering, specifying the next-hop attribute of route 1::1/128 as 4::4 but not specifying the Color attribute. On device A, an SRv6 TE Policy group is created with an End-point address of device D's address 4::4. Within the SRv6 TE Policy group, a Color and service-class mapping relationship is defined, where service-class 1 maps to Color 100 and service-class 2 maps to Color 200. Subsequently, a tunnel policy is configured on source node A, binding the SRv6 TE Policy group with the destination address 2.2.2.2. This setup ensures that for traffic with a destination address of 1::1, if the service-class value is 1, it will be forwarded along the path defined by SRv6 TE Policy 1; if the service-class value is 2, it will be forwarded along the path defined by SRv6 TE Policy 2. 3.2.4. Te-class-based Traffic Steering Due to the limited length of the local identifier "service-class," with the maximum supported value for most devices being 15 and typically not exceeding 127, it cannot effectively differentiate a lin, et al. Expires September 3, 2024 [Page 9] Internet-Draft Best practices for traffic steering to SRv6 March 2024 vast number of services. Therefore, H3C has introduced the use of "TE class ID" as another local identifier. The TE class ID can have a maximum value of 65535, supporting a more diverse range of traffic types. The basic principle of TE class ID-based traffic steering is to route the packets to the corresponding SRv6 TE Policy based on the TE class ID identifier. This traffic steering method requires the prior deployment of SRv6 TE Policy groups and the redirection of traffic to these SRv6 TE Policy groups. Then, based on the mapping rules within the SRv6 TE Policy groups, packets marked with specific TE class ID values are steered to the corresponding SRv6 TE Policy. As shown in Figure 1, the BGP protocol advertises the prefix routes that require traffic steering, specifying the next-hop attribute of route 1::1/128 as 4::4 but not specifying the Color attribute. On device A, an SRv6 TE Policy group is created with an End-point address of device D's address 4::4. Within the SRv6 TE Policy group, a te-class and service-class mapping relationship is defined, where te-class 1 maps to Color 100 and te-class 2 maps to Color 200. Subsequently, a tunnel policy is configured on source node A, binding the SRv6 TE Policy group with the destination address 2.2.2.2. This setup ensures that for traffic with a destination address of 1::1, if the te-class value is 1, it will be forwarded along the path defined by SRv6 TE Policy 1; if the te-class value is 2, it will be forwarded along the path defined by SRv6 TE Policy 2. 3.2.5. Traffic steering via BGP-FlowSpec In the scenario illustrated in Figure 2, where a controller is present in the network, fine-grained traffic scheduling can be achieved by the controller distributing traffic steering rules. The controller utilizes BGP Flow-Spec (FS) to distribute rules to the head-end node. These rules can be matched based on the destination address or flow characteristics. By setting the action after matching, the controller can specify the Color attribute and next- hop address for the traffic, thereby achieving traffic steering. BGP FlowSpec enables global traffic scheduling with flexibility. lin, et al. Expires September 3, 2024 [Page 10] Internet-Draft Best practices for traffic steering to SRv6 March 2024 +------------------+ | Controller | +------------------+ | FlowSpec route to Ingress: | NLRI: Filter Rules FS Color: 100/200 | Nexthop: 4::4 SRv6 Policy 1: +---------+ | +---------+ BSID<1000::1> |RouterB |------)-------------|RouterC | Color 100 +-/-------+ | +-------\-+ Endpoint 4::4 / | \ SID List / | \ +-/------+ | +------\-+ |RouterA | <--------+ |RouterD | EndPoint: 4::4 +-\------+ +------/-+ SRv6 Policy 2: \ / BSID<2000::1> \ / Color 200 +-\-------+ +-------/-+ Endpoint 4::4 |RouterE |--------------------|RouterF | SID List +---------+ +---------+ Figure . Steering by BGP FlowSpec 4. Security Considerations TBD. 5. IANA Considerations This document makes no request of IANA. 6. References 6.1. Normative References [rfc9256] C. Filsfils, "Segment Routing Policy Architecture ", July 2022, lin, et al. Expires September 3, 2024 [Page 11] Internet-Draft Best practices for traffic steering to SRv6 March 2024 Authors' Addresses Gary Geng Tencent China Email: garygeng@tencent.com Yisong Liu China Mobile China Email: liuyisong@chinamobile.com Chongfeng Xie China Telecom Beiqijia Town, Changping District Beijing 102209 China Email: xiechf@chinatelecom.cn Changwang Lin New H3C Technologies Beijing 102209 China Email: linchangwang.04414@h3c.com lin, et al. Expires September 3, 2024 [Page 12]