Internet DRAFT - draft-geng-srv6ops-traffic-steering-to-srv6

draft-geng-srv6ops-traffic-steering-to-srv6



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<B,C,D> /                                        \
              +-/------+       BGP Route            +------\-+
                |RouterA |     <----------------      |RouterD | EndPoint: 4::4
              +-\------+                            +------/-+
   SRv6 Policy 2:  \                                        /
   BSID<2000::1>    \                                      /
   Color 200       +-\-------+                    +-------/-+
   Endpoint 4::4   |RouterE  |--------------------|RouterF  |
   SID List<E,F,D> +---------+                    +---------+
                  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<B,C,D> /                |                       \
              +-/------+          |                 +------\-+
                |RouterA | <--------+                 |RouterD | EndPoint: 4::4
              +-\------+                            +------/-+
   SRv6 Policy 2:  \                                        /
   BSID<2000::1>    \                                      /
   Color 200       +-\-------+                    +-------/-+
   Endpoint 4::4   |RouterE  |--------------------|RouterF  |
   SID List<E,F,D> +---------+                    +---------+
                       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, <https://datatracker.ietf.org/doc/rfc9256>











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]