SPRING Working Group                                           W. Cheng
Internet Draft                                                  L. Gong
Intended status: Standards Track                           China Mobile
Expires: April 27, 2023                                          C. Lin
                                                                 Y. Qiu
                                                                New H3C
                                                                  Y.Wei
                                                                 Huawei
                                                               Ran.Chen
                                                                    ZTE
                                                               R. Liang
                                                        Ruijie Networks
                                                       October 24, 2022



                              SR Policy Group
                   draft-cheng-spring-sr-policy-group-00


Status of this Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six
   months and may be updated, replaced, or obsoleted by other documents
   at any time.  It is inappropriate to use Internet-Drafts as
   reference material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html

   This Internet-Draft will expire on April 27 2023.

Copyright Notice

   Copyright (c) 2021 IETF Trust and the persons identified as the
   document authors. All rights reserved.





Gong, et al.              Expire April, 2023                   [Page 1]


Internet-Draft              SR Policy Group                 October 2022


   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document. Please review these documents
   carefully, as they describe your rights and restrictions with
   respect to this document. Code Components extracted from this
   document must include Simplified BSD License text as described in
   Section 4.e of the Trust Legal Provisions and are provided without
   warranty as described in the Simplified BSD License.

Abstract

   Segment Routing is a source routing paradigm that explicitly
   indicates the forwarding path for packets at the ingress node. An SR
   Policy is associated with one or more candidate paths, and each
   candidate path is either dynamic, explicit or composite. This
   document describes SR policy Group in MPLS and IPv6 environments.



Table of Contents


   1. Introduction ................................................ 2
   2. Terminology ................................................. 3
   3. SR Policy Group ............................................. 4
      3.1. Identification of SR Policy Group ...................... 4
      3.2. Constituent Parent SR policy ........................... 5
      3.3. Steering into SR Policy Group .......................... 6
      3.4. Summary ................................................ 7
   4. SR Policy Group Use Cases ................................... 9
      4.1. SR Policy Group in L3VPN over TE Scenarios ............. 9
   5. IANA Considerations ........................................ 12
   6. Security Considerations .................................... 12
   7. References ................................................. 12
      7.1. Normative References .................................. 12
      7.2. Informative References ................................ 13
   8. Acknowledgments ............................................ 13
   Authors' Addresses ............................................ 14

  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 [RFC9256].
   In order to distribute SR policies to the headend, [I-D.ietf-idr-
   segment-routing-te-policy] specifies a mechanism by using BGP.

Gong, et al.             Expires April, 2023                   [Page 2]


Internet-Draft              SR Policy Group                 October 2022


   An SR Policy is associated with one or more candidate paths. A
   composite candidate path acts as a container for grouping SR
   Policies. As described in [RFC9256], 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
   convenience, the composite candidate path formed by the combination
   of SR policies is called Parent SR policy in [I-D.jiang-spring-
   parent-sr-policy-use-cases].

   This document describes SR Policy Group in MPLS and IPv6
   environments.

  2. Terminology

   The definitions of the basic terms are identical to those found in
   Segment Routing Architecture [RFC8402], Segment Routing Policy
   Architecture [RFC9256].

   SR policy  As described in [RFC9256], the general concept of SR
   Policy provides a framework that enables the instantiation of an
   ordered list of segments on a node for implementing a source routing
   policy for the steering of traffic for a specific purpose (e.g., for
   a specific Service Level Agreement (SLA)) from that node. An SR
   Policy is a forwarding path that meets the specified forwarding
   requirements.

   Parent SR Policy A Parent SR Policy represents a composite candidate
   path, which is a group of SR policies that meet different service
   objectives and have the same destination endpoint address. As
   described in [RFC9256],the following criteria apply for inclusion of
   constituent SR Policies using a composite candidatepath under a
   parent SR Policy:

   *  The endpoints of the constituent SR Policies and the parent SR
   Policy MUST be identical.

   *  The colors of each of the constituent SR Policies and the parent
   SR Policy MUST be different.

   *  The constituent SR Policies MUST NOT use composite candidate
   paths.

   Different flows(match flows in its ingress interfaces (upon any

   field such as Ethernet destination/source/VLAN/TOS or IP


Gong, et al.             Expires April, 2023                   [Page 3]


Internet-Draft              SR Policy Group                 October 2022


   destination/source/Differentiated Services Code Point (DSCP), or

   transport ports etc.) bound to the same endpoint, and color them
   with an internal per-packet forwarding-class variable, which are
   steered on different constituent SR Policies.

   SR Policy Group: An SR policy Group represents a set of paths with
   different forwarding requirements. It is composited by different
   parent SR policies which have the same color but different
   destiontion endpoints. It establish the mapping relationship between
   the flow characteristics and the color value of the SR Policy, and
   guide the flows with different SLA requirements to the SR Policy
   with different colors.

  3. SR Policy Group

   SR Policy Group provides a framework that enables the instantiation
   of a set of paths to different destination endpoints with the same
   service forwarding model.It implements a source routing policy to
   steer the service traffic from different source endpoints for a
   specific purpose (e.g., for a specific SLA).

   Referring to RFC9256 and [I-D.jiang-spring-parent-sr-policy-use-
   cases], the Parent SR policy represents a composite candidate path,
   which is a group of SR policies with the same destination endpoint
   address. The Ingress node specifies the service characteristics and
   maps different services to different colors. In the Parent SR policy,
   configure multiple constituent SR policies. The services with
   different characteristics are forwarded through the constituent SR
   policies of different colors. Based on the Parent SR policy, a SR
   Policy Group can be built using Parent SR Policy.

   This section defines the key aspects and constituents of an SR
   Policy Group.

3.1. Identification of SR Policy Group

   An SR Policy Group MUST be identified through a color attribute.

   According to the service quality requirements, a unified service
   forwarding model is planned for nodes to determine the forwarding
   path of service flow. The traffic with the same service forwarding
   model from different source endpoints to different destination
   endpoints uses the same SR Policy Group.

   The color is an unsigned non-zero 32-bit integer value that
   associates the SR Policy Group with a service forwarding model (e.g.,


Gong, et al.             Expires April, 2023                   [Page 4]


Internet-Draft              SR Policy Group                 October 2022


   A set of SLA attributes). Different service qualities use different
   Color values.

   The color value identifying the SR Policy Group corresponds to the
   Color attribute of the BGP route published by the endpoint. The
   destination endpoint publishes the BGP route and indicates which SR
   Policy Group path the header node should use to send packets to it
   through the Color attribute in the route.

   In the Policy Group, establish the mapping relationship between the
   flow characteristics and the color value of the SR Policy path, and
   guide the business flows with different SLA requirements to the SR
   Policy path with different colors.



3.2. Constituent Parent SR policy

   An SR Policy Group is associated with one or more constituent Parent
   SR Policies. Referring to RFC9256, the Parent SR policy is a group
   of SR policies with the same destination endpoint address.

   The hierarchical relationship between SR policy group, Parent SR
   policy and SR policy is shown in the figure below.

                             Service forwarding
          Service            model to specified           Path of
       forwarding model     destination endpoint      specified service
     +-----------------+    +------------------+     +-------------------+
     |                 |    |                  |     |                   |
     | SR Policy Group |--->| Parent SR Policy |---->|    SR policy      |
     |    (Color)      |    |(Color, Endpoint) |     | (Service path's   |
     |                 |    |                  |     |  Color, Endpoint) |
     +-----------------+    +------------------+     +-------------------+
                               Figure 1

   The parent SR policy can be generated through static configuration,
   or dynamically generated when the destination endpoint accesses
   based on the service forwarding requirements specified by the SR
   policy group.

   The following criteria apply for inclusion of constituent Parent SR
   Policies under a SR Policy Group:

      A SR Policy Group contains one or more Parent SR policies.

      The colors of SR Policy group and its each constituent Parent SR
      Policy MUST be identical.

Gong, et al.             Expires April, 2023                   [Page 5]


Internet-Draft              SR Policy Group                 October 2022


      The colors of SR Policy group and its each constituent SR Policy
      of echo constituent Parent SR Policies MUST be different.

      The destination endpoint addresses of the Parent SR policy in the
      SR policy group can be the same or different.

      There can only be one Parent SR Policy with the same source end
      and the same destination end in the SR Policy group.

3.3. Steering into SR Policy Group

   The process of guiding traffic forwarding through the SR Policy
   Group is as follows:

      The destination endpoint publishes a BGP route with the specified
      Color extended community attribute.

      Get the color extended community attribute in the received BGP
      route.

      Match the color attribute value of the received BGP route with the
      SR Policy Group.

      Searches for a SR Policy Group with color matching the color
      extended community attribute.

      Searches for a Parent SR Policy with endpoint address matching the
      next hop in the BGP route, and recurses the BGP route to the
      parent SR policy.

   The Ingress node can match flow characteristics in its ingress
   interfaces (upon any field such as Ethernet
   destination/source/VLAN/TOS or IP destination/source/DSCP or
   transport ports or application attribute etc.) and color them with
   an internal per-packet forwarding-class variable. According to the
   forwarding-class variable the ingress node selects a matching SR
   policy in the Parent SR policy.

   An SR Policy Group can be instantiated with SR Policies which are
   associated with different set of network resources (i.e. NRPs),
   based on SR policy group, it is also a network slice deployment
   scheme for single user and multiple services. When different
   services are forwarded through different SR policy paths, different
   network resources can be used. After associating the SR policy with
   the network slice, different network slices can be used for
   forwarding different traffic of the same user.



Gong, et al.             Expires April, 2023                   [Page 6]


Internet-Draft              SR Policy Group                 October 2022


3.4. Summary

   In summary, the information model is the following:

     SR Policy Group PG-1 <Color = 1>

       Parent SR Policy PP-1<Color = 1, Endpoint = E1>

         Service Service-1 mapping-to color 100

         Service Service-2 mapping-to color 200

         Service Service-3 mapping-to color 300

           SR Policy POL1  <Headend = H1, Color = 100, Endpoint = E1>
              Candidate Path CP1  <Protocol-Origin = 20, Originator =
              64511:192.0.2.1, Discriminator = 1>
              Preference  200
              Priority  10
               Segment List 1  <SID11...SID1i>

           SR Policy POL2  <Headend = H1, Color = 200, Endpoint = E1>
              Candidate Path CP1  <Protocol-Origin = 20, Originator =
              64511:192.0.2.1, Discriminator = 2>
              Preference  200
              Priority  10
                Segment List 1  <SID21...SID2i>

           SR Policy POL3  <Headend = H1, Color = 300, Endpoint = E1>
              Candidate Path CP1  <Protocol-Origin = 20, Originator =
              64511:192.0.2.1, Discriminator = 3>
              Preference  200
              Priority  10
                Segment List 1  <SID31...SID3i>

       Parent SR Policy PP-2<Color = 1, Endpoint = E2>

         Service Service-1 mapping-to color 100

         Service Service-2 mapping-to color 200


Gong, et al.             Expires April, 2023                   [Page 7]


Internet-Draft              SR Policy Group                 October 2022


         Service Service-3 mapping-to color 300

           SR Policy POL4  <Headend = H1, Color = 100, Endpoint = E2>
              Candidate Path CP1  <Protocol-Origin = 20, Originator =
              64511:192.0.2.1, Discriminator = 4>
              Preference  200
              Priority  10
               Segment List 1  <SID41...SID4i>

          SR Policy POL5  <Headend = H1, Color = 200, Endpoint = E2>
              Candidate Path CP1  <Protocol-Origin = 20, Originator =
              64511:192.0.2.1, Discriminator = 5>
              Preference  200
              Priority  10
                Segment List 1  <SID51...SID5i>

           SR Policy POL6  <Headend = H1, Color = 300, Endpoint = E1>
              Candidate Path CP1  <Protocol-Origin = 20, Originator =
              64511:192.0.2.1, Discriminator = 6>
              Preference  200
              Priority  10
                Segment List 1  <SID61...SID6i>


   The SR Policy Group PG-1 is identified by color. It has two
   constituent Parent SR Policies: PP-1 and PP-2.  Each is identified
   by a tuple <Headend, Color, Endpoint>.

   The SR Parent Policy PP-1 is identified by the tuple <Headend = H1,
   Color = 1, Endpoint = E1>. It has three constituent SR Policies: SR
   Policy POL1 SR Policy POL2 and SR Policy POL3.

   The SR Policy POL1 is identified by the tuple <Headend = H1,Color =
   100, Endpoint = E1>.  It has one candidate paths: CP1.

   The SR Policy POL2 is identified by the tuple <Headend = H1,Color =
   200, Endpoint = E1>.  It has one candidate paths: CP1.

   The SR Policy POL3 is identified by the tuple <Headend = H1,Color =
   300, Endpoint = E1>.  It has one candidate paths: CP1.



Gong, et al.             Expires April, 2023                   [Page 8]


Internet-Draft              SR Policy Group                 October 2022


   The SR Parent Policy PP-2 is identified by the tuple <Headend = H1,
   Color = 1, Endpoint = E2>. It has three constituent SR Policies: SR
   Policy POL4 SR Policy POL5 and SR Policy POL6.

   The SR Policy POL4 is identified by the tuple <Headend = H1,Color =
   100, Endpoint = E2>.  It has one candidate paths: CP1.

   The SR Policy POL2 is identified by the tuple <Headend = H1,Color =
   200, Endpoint = E2>.  It has one candidate paths: CP1.

   The SR Policy POL6 is identified by the tuple <Headend = H1,Color =
   300, Endpoint = E2>.  It has one candidate paths: CP1.



   According to the service forwarding quality requirements, three
   forwarding paths, Color 100, Color 200 and Color 300, are planned in
   advance.

   The service forwarding model of PP-1 is adopted for the destination
   endpoint E1. According to service characteristics. Services to E1
   are divided into three categories: service-1, service-2 and service-
   3. The service-1 service is forwarded according to the SR Policy
   POL1 path of Color 100. The service-2 service is forwarded according
   to the SR Policy POL2 path of Color 200. The services of service-3
   are forwarded according to the SR Policy POL3 path of Color 300.

   The destination endpoint E2 also uses the same service forwarding
   model. The traffic to E1 is differentiated in the same way, and the
   traffic is sent to E2 according to the SR policy path of Color 100,
   200, and 300.

  4. SR Policy Group Use Cases

4.1. SR Policy Group in L3VPN over TE Scenarios

   In the L3VPN over TE application scenario shown in Figure 2, VPN
   users are connected to the SRv6 network. Controller defines SR
   Policy Group for each VPN tenant. Different VPNs use different SR
   Policy Groups with different colors. The Ingress node generates
   different Parent SRv6 policies as required according to the
   destination endpoint address dynamically. Since user's traffic of
   different services between two endpoints has different requirements
   for forwarding quality, identify the service type according to the
   DSCP of the packet, and steer the flow to the corresponding SR
   Policy, which is forwarded through different network slices. The
   path constituting the SR Policy is calculated by the controller and
   distributed to the Ingress node.

Gong, et al.             Expires April, 2023                   [Page 9]


Internet-Draft              SR Policy Group                 October 2022


                         +------------+
                         | Controller |
                         +------------+
                     /                    \
                    /                      \
     .----.        /                        \         .----.
    ( VPN1 )\     /                          \      /( VPN1 )
     '----'  \ +---+     +---+     +---+     +---+ /  '----'
               + A +-----+ B +-----+ C +-----+ D +
              /+-+-+     +-+-+     +-+-+     +-+-+
     .----.  /   |         |         |         |
    ( VPN2 )/    |         |         |         |      .----.
     '----'      |         |         |         |    /( VPN1 )
               +-+-+     +-+-+     +-+-+     +-+-+ /  '----'
               + E |-----+ F +-----+ G +-----+ H +
     .----.  / +---+     +---+     +-+-+     +---+ \  .----.
    ( VPN1 )/                                       \( VPN2 )
     '----'                                           '----'
             Figure 2 L3VPN over TE application scenario

   VPN1 uses SR Policy group 1 identified by Color 100. Plan the
   forwarding path for VPN1 traffic, and allocate different sets of
   network resources for network slices as blow:

      Slice 1: Voice service of VIP users. Low delay forwarding is
      required, and the DSCP range of the packet is 1~10. The controller
      calculates the low delay path for the voice traffic of VIP users,
      and maps the DSCP 1~10 to Color 500. The voice traffic of VIP
      users is forwarded through the constituent SR policy (Color 500)
      of the Parent SRv6 Policy (Color 100) corresponding to VPN1.

      Slice 2: Other services of VIP users. The DSCP range of the packet
      is 11~20, and low delay is not required. However, compared with
      the packet of ordinary users, the traffic of VIP users should be
      forwarded first. The controller calculates the SR Policy path and
      maps the DSCP 11~20 to Color 501. Other traffic of VIP users are
      forwarded along the constituent SR policy (Color 501) of the
      Parent SRv6 policy (color 100) corresponding to VPN1.

      Slice 3: Services of ordinary users. Low latency forwarding and
      priority forwarding are not required. The controller calculates
      the SR Policy path and maps all DSCP values outside the range of 1
      to 20 to Color 502. The service traffic of ordinary users are
      forwarded along the constituent SR policy (Color 502) of the
      Parent SRv6 policy (color 100) corresponding to VPN1.




Gong, et al.             Expires April, 2023                  [Page 10]


Internet-Draft              SR Policy Group                 October 2022


                          SRv6 Network
                       .-------------------.
         .-------.     |                   |      .-------.
        /         \ <==|======Slice-1======|==>  /         \
       (   VPN1    )<==|======Slice-2======|==> (    VPN1   )
        \         / <==|======Slice-3======|==>  \         /
         '-------'     |                   |      '-------'
                       | SR Policy Group 1 |
                       |   (Color 100)     |
                       '-------------------'

           Figure 4 SR Policy Group for VPN1

   The traffic of VPN1 from A to D of Slice 1 will be forwarded based
   on the SR policy (Headend=A, Color=500, Endpoint=D) of Parent SR
   policy (Color=100, Endpoint=D) of SR Policy Group1.

   Similarly the traffic of VPN1 from A to H of Slice 1 will be
   forwarded based on the SR policy (Headend=A, Color=500, Endpoint=H)
   of Parent SR policy (Color=100, Endpoint=H) of SR Policy Group1.

   VPN2 uses SR Policy Group 2 identified by Color 101. Plan the
   forwarding path for VPN2 traffic. Different sets of network resources
   are further allocated for the network slices as blow:

      Slice 4: Voice service. Low latency forwarding is required. The
      DSCP range of the packet is 1 to 10. The controller calculates the
      low delay path for voice service and maps the DSCP 1~10 to Color
      600. The voice traffic is forwarded through the constituent SR
      policy (Color 600) of the Parent SRv6 Policy (color 101)
      corresponding to VPN2.

      Slice 5: Non voice services. No special forwarding quality
      requirements. The controller calculates the SR Policy path and
      maps all DSCP values outside the range of 1 to 10 to Color 601.
      Non voice service messages are forwarded along the constituent SR
      policy (Color 601) of the Parent SR policy (color 101)
      corresponding to VPN2.










Gong, et al.             Expires April, 2023                  [Page 11]


Internet-Draft              SR Policy Group                 October 2022


                          SRv6 Network
                       .-------------------.
         .-------.     |                   |      .-------.
        /         \ <==|======Slice-4======|==>  /         \
       (   VPN2    )   |                   |    (    VPN2   )
        \         / <==|======Slice-5======|==>  \         /
         '-------'     |                   |      '-------'
                       | SR Policy Group 2 |
                       |   (Color 101)     |
                       '-------------------'
           Figure 5 SR Policy Group for VPN2

   The traffic of VPN2 from A to H of Slice 4 will be forwarded based
   on the SR policy (Headend=A, Color=600, Endpoint=H) of Parent SR
   policy (Color=101, Endpoint=H) of SR Policy Group2.

   Because there are many access endpoints and each endpoint may act as
   an entry node, compared with the traditional method of distributing
   service forwarding policies on each Ingress node, the above SR
   Policy Group can greatly simplify the configuration of VPN access
   endpoints and effectively improve the efficiency of network
   deployment and operation and maintenance.

  5. IANA Considerations

   This document has no IANA actions.

  6. Security Considerations

   This document presents use cases to be considered by the deployment
   of SR Policy. It does not introduce any security considerations.

7. References

7.1. Normative References

   [RFC9256] Filsfils, C., Talaulikar, K., Voyer, D., Bogdanov, A., and
             P. Mattes, "Segment Routing Policy Architecture", RFC9256,
             DOI 10.17487/RFC9256, July 2022, <https://www.rfc-
             editor.org/info/rfc9256>.

   [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>.




Gong, et al.             Expires April, 2023                  [Page 12]


Internet-Draft              SR Policy Group                 October 2022


   [I-D.ietf-idr-segment-routing-te-policy] Previdi, S., Filsfils, C.,
             Talaulikar, K., Mattes, P., Rosen, E., Jain, D., and S.
             Lin, "Advertising Segment Routing Policies in BGP", draft-
             ietf-idr-segment-routing-te-policy-18 (work in progress),
             June 2022.

   [I-D.jiang-spring-parent-sr-policy-use-cases] Jiang, W., Cheng, W.,
             Lin, C. and Qiu, Y., "Use Cases for Parent SR Policy",
             draft-jiang-spring-parent-sr-policy-use-cases-00 (work in
             progress), July 2022.

7.2. Informative References

   TBD

  8. Acknowledgments

   The authors would like to thank the following for their valuable
   contributions of this document:

   TBD



























Gong, et al.             Expires April, 2023                  [Page 13]


Internet-Draft              SR Policy Group                 October 2022


Authors' Addresses


   Weiqiang Cheng
   China Mobile

   Email: chengweiqiang@chinamobile.com

   Liyan Gong
   China Mobile

   Email: gongliyan@chinamobile.com

   Changwang Lin
   New H3C Technologies

   Email: linchangwang.04414@h3c.com

   Yuanxiang Qiu
   New H3C Technologies

   Email: qiuyuanxiang@h3c.com

   YaWei Zhang
   Huawei Technologies

   Email: zhangyawei@huawei.com

   Ran Chen
   ZTE Corporation

   Email: chen.ran@zte.com.cn

   Yanrong Liang
   Ruijie Networks

   Email: liangyanrong@ruijie.com.cn






Gong, et al.             Expires April, 2023                  [Page 14]


Internet-Draft              SR Policy Group                 October 2022

















































Gong, et al.             Expires April, 2023                  [Page 15]