[Search] [txt|pdfized|bibtex] [Tracker] [Email] [Nits]
Versions: 00                                                            
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 <color, endpoint> 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, <https://www.rfc-editor.org/info/rfc8402>.

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]