Internet DRAFT - draft-li-spring-tunnel-segment

draft-li-spring-tunnel-segment







Network Working Group                                              Z. Li
Internet-Draft                                                     C. Li
Intended status: Standards Track                                   N. Wu
Expires: October 16, 2021                                         Huawei
                                                          April 14, 2021


                   Tunnel Segment in Segment Routing
                   draft-li-spring-tunnel-segment-02

Abstract

   This document introduces a new type of segment, Tunnel Segment, for
   the segment routing (SR).  Tunnel segment can be used to reduce SID
   stack depth of SR path, span the non-SR domain or provide
   differentiated services.

   Forwarding mechanisms and requirements of control plane and data
   models for tunnel segments are also defined.

Requirements Language

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119 [RFC2119].

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 October 16, 2021.

Copyright Notice

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




Li, et al.              Expires October 16, 2021                [Page 1]

Internet-Draft            Tunnel Segment in SR                April 2021


   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
   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 . . . . . . . . . . . . . . . . . . . . . . . . .   2
   3.  Usecases  . . . . . . . . . . . . . . . . . . . . . . . . . .   3
     3.1.  Reducing SID Stack Depth  . . . . . . . . . . . . . . . .   3
     3.2.  Passing through Non-SR Domain . . . . . . . . . . . . . .   4
     3.3.  Differentiated Services . . . . . . . . . . . . . . . . .   5
   4.  Comparison with Agency Segment  . . . . . . . . . . . . . . .   6
   5.  Forwarding Mechanisms . . . . . . . . . . . . . . . . . . . .   6
   6.  Requirement of Control Plane and Yang Models  . . . . . . . .   7
   7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   7
   8.  Security Considerations . . . . . . . . . . . . . . . . . . .   8
   9.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   8
     9.1.  Normative References  . . . . . . . . . . . . . . . . . .   8
     9.2.  Informative References  . . . . . . . . . . . . . . . . .   8
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   8

1.  Introduction

   Segment Routing (SR), introduced by [RFC8402], leverages the source
   routing paradigm.  A packet can be steered through an ordered list of
   instructions, which are also called segments.  The node segment,
   adjacency segment, etc. have been proposed for different usecases.

   This document introduces a new type of segment, Tunnel Segment, for
   the segment routing.  Tunnel segment can be used to reduce SID stack
   depth of SR path, span the non-SR domain or provide differentiated
   services.  Forwarding mechanisms and requirements of control plane
   and data models for tunnel segments are also defined.

2.  Terminology

   o  SID: Segment ID

   o  SR: Segment Routing

   o  SR Path: Segment Routing Path



Li, et al.              Expires October 16, 2021                [Page 2]

Internet-Draft            Tunnel Segment in SR                April 2021


   o  SR-TE Path: Segment Routing Traffic Engineering Path

   o  MSD: Maximally SID Depth

   The terms "Tunnel Segment" and "Tunnel SID" are the generic names for
   a segment attached to a specific tunnel.  A tunnel segment can be
   used to steer traffic into the corresponding tunnel along the SR
   path.

3.  Usecases

3.1.  Reducing SID Stack Depth

   It is possible that a SR path has to take an explicit path with
   multiple hops instead of the shortest path for the purpose of traffic
   engineering.  As a result, the ingress node has to push lots of
   segments to steer the packet, which could be a challenge for the
   forwarding plane, since the depth of this segment stack may be beyond
   the capability of their forwarding engines.  The tunnel segment
   introduced in this document will be helpful to mitigate the pain in
   these scenarios.

   Taking Figure 1 below as an example, the SR-TE path is created from
   SR-Node-1(ingress) to SR-Node-2(egress).  The original SID stack, {A,
   B, X, E, F, G, H, Y, J, K}, is too overwhelming for the path MSD.
   With help of the tunnel segment, the tunnel from Gateway-Node-1 to
   Gateway-Node-2 can be represented by a dedicated SID, saying Z.  So
   the SR-TE path can be represented as {A, B, X, Z, J, K}. Comparing
   with the original SR-TE path, the SID stack depth is reduced.

   The SR-TE tunnel can be created through two ways:

   1.  Manually configure on ingress node (Gateway-Node-1) and designate
       the SID binding to it.  This binding relationship needs to be
       propagated to PCE/controller or advertised to other nodes in the
       network.

   2.  With the knowledge of all MSD along the path, a PCE/controller
       can calculate SR-TE tunnels using for reduce SID stack depth and
       determine ingress/egress gateway nodes dynamically.  Those SR-TE
       tunnels can be created through PCE initiated style.  The
       corresponding tunnel segment and the binding relationship can be
       propagated to ingress nodes and other nodes if necessary.  As
       shown in Figure 1, ingress (SR-Node-1) can receive update
       messages from PCE/controller about the binding relationship.  And
       SR-Node-1 can calculate the SR-TE path with the SR-TE tunnel
       segment without the help of PCE/controller in a centralized
       manner.



Li, et al.              Expires October 16, 2021                [Page 3]

Internet-Draft            Tunnel Segment in SR                April 2021


  SID stack       +------------+
{A, B, X, Z, J, K}|    PCE/    |
   +--------------| Controller |
   |              +------------+
   |                 ^ Tunnel Binding
   |                 | SID (Z)
   |                 |          .-----.
   |                 |         (       )
   V                 V     .--(         )--.
+------+       +-------+  (                 )  +-------+        +------+
|  SR  |_(...)_|Gateway|_(     SR Network    )_|Gateway|_(...)_ |  SR  |
|Node 1| (...) |Node-1 | ( ================> ) |Node-2 | (...)  |Node 2|
+------+       +-------+  (   SR-TE Tunnel  )  +-------+        +------+
                           '--(         )--'
                               (       )
                                '-----'

         {A,B}    {X}         {E, F, G, H}        {Y}    {J,K}

             Figure 1 Usecase for Reducing SID Stack Depth




3.2.  Passing through Non-SR Domain

   The tunnel segment can also be used in those scenarios that traffic
   has to pass through non-SR domains.  In another word, tunnel segment
   can be used to connect SR islands.

   As shown in Figure 2, traffic from SR-Node-1 to SR-Node-2 has to pass
   through a traditional IP/MPLS network.  Usually a RSVP-TE tunnel or
   IP tunnel will be created between two gateway nodes.  By allocating
   SID for this tunnel, saying Z, the SR path from SR-Node-1 to SR-
   Node-2 can be represented as {A, B, X, Z, J, K}.

   In this scenario, the RSVP-TE tunnel or IP tunnel can be involved
   into SR networks through two ways:

   1.  Manually configure on ingress node (Gateway-Node-1) and designate
       the SID binding to it.  This binding relationship needs to be
       propagated to PCE/controller or advertised to other nodes in the
       network.

   2.  With the knowledge of topology of non-SR domain, a PCE/controller
       can calculate RSVP-TE tunnels or IP tunnels and determine
       ingress/egress gateway nodes dynamically.  Those RSVP-TE tunnels
       or IP tunnels can be created through PCE initiated style.  The



Li, et al.              Expires October 16, 2021                [Page 4]

Internet-Draft            Tunnel Segment in SR                April 2021


       corresponding tunnel segment and the binding relationship can be
       propagated to ingress nodes and other nodes if necessary.  As
       shown in Figure 2, ingress (SR-Node-1) can receive update
       messages from PCE/controller about the binding relationship.  And
       SR-Node-1 can calculate the SR-TE path which can pass through
       non-SR domain without the help of PCE/controller in a centralized
       manner.

  SID stack       +------------+
{A, B, X, Z, J, K}|    PCE/    |
   +--------------| Controller |
   |              +------------+
   |                 ^ Tunnel Binding
   |                 | SID (Z)
   |                 |          .-----.
   |                 |         (       )
   V                 V     .--(         )--.
+------+       +-------+  (                 )  +-------+        +------+
|  SR  |_(...)_|Gateway|_(  IP/MPLS Network  )_|Gateway|_(...)_ |  SR  |
|Node 1| (...) |Node-1 | ( ================> ) |Node-2 | (...)  |Node 2|
+------+       +-------+  (MPLS TE/IP Tunnel)  +-------+        +------+
                           '--(         )--'
                               (       )
                                '-----'

         {A,B}    {X}         {E, F, G, H}        {Y}    {J,K}

        Figure 2 Usecase for Passing through Non-SR Domain


3.3.  Differentiated Services

   It is necessary to create multiple tunnels between the same pair of
   gateway nodes to support different services, since different tunnels
   can have different attributes.  As a result, different SIDs have to
   be assigned per tunnel.  Then an End-to-End SR path can choose
   different SIDs at ingress according to the service requirement when
   passing through the network between gateway nodes.

   As depicted in Figure 3, two RSVP-TE tunnels, say RSVP-TE-tunnel1 and
   RSVP-TE-tunnel2, are created in MPLS network to provide different
   bandwidth guarantee services.  And two SIDs, Z1 and Z2, are allocated
   and mapped to these two tunnels separately.  These two SIDs can be
   utilized by a PCE/controller when defining the SR path at ingress.
   Since different traffic will transport through different tunnels,
   differentiated services can be guaranteed.





Li, et al.              Expires October 16, 2021                [Page 5]

Internet-Draft            Tunnel Segment in SR                April 2021


  SID stack
{A, B, X, Z1, J, K}+------------+
{A, B, X, Z2, J, K}|    PCE/    |
   +---------------| Controller |
   |               +------------+
   |                 ^ Tunnel Binding
   |                 | SID (Z)
   |                 |          .-----.
   |                 |         (       )
   V                 V     .--(         )--.
+------+       +-------+  (MPLS TE Tunnel 1 )  +-------+        +------+
|  SR  |_(...)_|Gateway|_( ================> )_|Gateway|_(...)_ |  SR  |
|Node 1| (...) |Node-1 | ( ================> ) |Node-2 | (...)  |Node 2|
+------+       +-------+  (MPLS TE Tunnel 2 )  +-------+        +------+
                           '--(         )--'
                               (       )
                                '-----'

         {A,B}    {X}         {E, F, G, H}        {Y}    {J,K}

        Figure 3 Usecase for Differentiated Services


4.  Comparison with Agency Segment

   As described in [RFC8402], a tunnel can be represented by an Adj-SID
   or as a Forwarding Adjacency.  One obvious benefit of the method is
   to unify the process.  But it may be necessary to differentiate a
   tunnel segment from other adjacency segment in some scenarios since
   there are more attributes attached to a tunnel.

   By introducing the tunnel segment, this document expects not only to
   inform the binding relationship between a tunnel and a SID but also
   to learn tunnel information as much as possible.  For example, it
   will be helpful for SR-capable nodes to know the detail of an
   explicit path that passes through non-SR networks.

   In addition, one tunnel will need an IP address if handled as an
   adjacency (a borrowed IP address at least).  While a tunnel binding
   to a Tunnel-SID does not have to contain an IP address, only an
   ingress node and an egress node is enough.

5.  Forwarding Mechanisms

   In the gateway node, when received the packet with the tunnel segment
   SID as the topmost SID, it will use the forwarding mechanism shown in
   the following figure to steering the traffic to the corresponding
   tunnel.



Li, et al.              Expires October 16, 2021                [Page 6]

Internet-Draft            Tunnel Segment in SR                April 2021


   +--------+    +------------------------+
   |   SID  |--->| Tunnel Forwarding Info |
   +--------+    +------------------------+

     SID: Segment ID

   Figure 4 Forwarding Mechanisms for Tunnel Segment

6.  Requirement of Control Plane and Yang Models

   According to the procedures of the above usecases, following
   requirements of control plane and Yang models for Tunnel Segment are
   proposed:

   o  REQ 01: IGP extensions SHOULD be introduced to advertise the
      binding relationship between a SID/label and the corresponding
      tunnel.  Attributes of the tunnel MAY be carried optionally.

   o  REQ 02: BGP Link-State extension SHOULD be introduced to advertise
      the binding relationship between a label and the corresponding
      tunnel.  Attributes of the tunnel MAY be carried optionally.

   o  REQ 03: PCEP extensions SHOULD be introduced to advertise the
      binding relationship between a SID/label and the corresponding
      tunnel from a PCC to a PCE.  Attributes of the tunnel MAY be
      carried optionally.

   o  REQ 04: PCE SHOULD support initiated IP tunnel.

   o  REQ 05: PCE SHOULD support to allocate SID/label for the
      corresponding tunnel dynamically.

   o  REQ 06: PCEP extensions SHOULD be introduced to distribute the
      binding relationship between a SID/label and the corresponding
      tunnel from a PCE to a PCC.  Attributes of the tunnel MAY be
      carried optionally.

   o  REQ 07: An I2RS interface SHOULD be available for allocating SID/
      label to the corresponding tunnel.  And augmentation on segment
      routing YANG models SHOULD be introduced.

7.  IANA Considerations

   This document makes no request of IANA.







Li, et al.              Expires October 16, 2021                [Page 7]

Internet-Draft            Tunnel Segment in SR                April 2021


8.  Security Considerations

   This document does not introduce new security threat.

9.  References

9.1.  Normative References

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

9.2.  Informative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/info/rfc2119>.

Authors' Addresses

   Zhenbin Li
   Huawei
   Huawei Bld., No.156 Beiqing Rd.
   Beijing  100095
   China

   Email: lizhenbin@huawei.com


   Cheng Li
   Huawei
   Huawei Campus, No. 156 Beiqing Rd.
   Beijing  100095
   China

   Email: c.l@huawei.com


   Nan Wu
   Huawei
   Huawei Bld., No.156 Beiqing Rd.
   Beijing  100095
   China

   Email: eric.wu@huawei.com




Li, et al.              Expires October 16, 2021                [Page 8]