[Docs] [txt|pdf|xml|html] [Tracker] [Email] [Nits]

Versions: 00

MPLS                                                          Quan Xiong
Internet-Draft                                               Greg Mirsky
Intended status: Standards Track                         ZTE Corporation
Expires: January 4, 2020                                  Weiqiang Cheng
                                                            China Mobile
                                                            July 3, 2019


        The Use of Path Segment in SR-MPLS and MPLS Interworking
         draft-xiong-mpls-path-segment-sr-mpls-interworking-00

Abstract

   This document discusses the SR-MPLS and MPLS interworking scenarios
   and proposes the solution with the use of Path Segment.

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 January 4, 2020.

Copyright Notice

   Copyright (c) 2019 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
   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.




Quan Xiong, et al.       Expires January 4, 2020                [Page 1]


Internet-DraThe Use of Path Segment in SR-MPLS and MPLS Inter  July 2019


Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Conventions used in this document . . . . . . . . . . . . . .   2
     2.1.  Terminology . . . . . . . . . . . . . . . . . . . . . . .   3
     2.2.  Requirements Language . . . . . . . . . . . . . . . . . .   3
   3.  SR-MPLS Interworking with MPLS  . . . . . . . . . . . . . . .   3
     3.1.  Stitching interworking with i-Path  . . . . . . . . . . .   4
     3.2.  Nesting interworking with e-Path  . . . . . . . . . . . .   5
   4.  Security Considerations . . . . . . . . . . . . . . . . . . .   6
   5.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .   6
   6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   6
   7.  Normative References  . . . . . . . . . . . . . . . . . . . .   6
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   7

1.  Introduction

   Segment Routing (SR) leverages the source routing paradigm.  A node
   steers a packet through a SR Policy instantiated as an ordered list
   of instructions called "segments".  SR supports per-flow explicit
   routing while maintaining per-flow state only at the ingress nodes of
   the SR domain.  Segment Routing can be instantiated on MPLS data
   plane which is referred to as SR-MPLS
   [I-D.ietf-spring-segment-routing-mpls].  SR-MPLS leverages the MPLS
   label stack to construct the SR path.

   In some scenarios, for example, mobile backhaul transport network, it
   is required to provide end-to-end bidirectional tunnel across
   multiple domains.  IP/MPLS technology can be deployed in these
   domains which may be access network, aggregation network or core
   network under the control of a single operator.  With the SR
   architecture, the IP/MPLS may be upgraded to support the SR-MPLS
   technology.  There are requirements to support the interworking
   between MPLS and SR-MPLS neworks at the boundaries and provide end-
   to-end bidirectional service.

   [I-D.ietf-spring-mpls-path-segment] defined a Path Segment identifier
   to support SR path PM, end-to-end 1+1 SR path protection and
   bidirectional SR paths correlation.  This document discusses the
   interworking scenarios between SR-MPLS and MPLS networks and proposes
   the solution with the use of Path Segment.

2.  Conventions used in this document








Quan Xiong, et al.       Expires January 4, 2020                [Page 2]


Internet-DraThe Use of Path Segment in SR-MPLS and MPLS Inter  July 2019


2.1.  Terminology

   ABR: Area Border Routers.  Routers used to connect two IGP areas
   (areas in OSPF or levels in IS-IS).

   AS: Autonomous System.  An Autonomous System is composed by one or
   more IGP area.

   ASBR: Autonomous System Border Router.  Router used to connect
   together ASes of the same or different service providers via one or
   more inter-AS links.

   Border Node: Two IGP areas interconnects with an ABR.

   Border Link: Two ASes interconnects with an ASBR.

   Domains:Autonomous System (AS) or IGP Area.  An Autonomous System is
   composed by one or more IGP area.

   e-Path: End-to-end Path segment.

   IGP: Interior Gateway Protocol.

   i-Path/i-PSID: Inter-domain Path Segment.

   PM: Performance Measurement.

   SR: Segment Routing.

   SR-MPLS: Segment Routing with MPLS data plane.

   s-Path: Sub-path Path Segment.

   VPN: Virtual Private Network.

2.2.  Requirements Language

   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.

3.  SR-MPLS Interworking with MPLS

   It is required to establish the end-to-end VPN service across the
   access network, aggregation network and core network.  For example,
   SR-MPLS may be deployed in access and core network and MPLS may be



Quan Xiong, et al.       Expires January 4, 2020                [Page 3]


Internet-DraThe Use of Path Segment in SR-MPLS and MPLS Inter  July 2019


   deployed in aggregation network.  The network interworking should be
   taken into account in deployment are the following:

   o  Border Node or Border Link

   o  Stitching Model or Nesting Model

   o  End-to-End OAM or Per-domain OAM

   The domains of the networks may be IGP Areas or ASes.  The SR-MPLS
   and MPLS networks can be interconnect with border node between IGP
   Areas or border link between ASes.  This document takes IGP Areas
   domains for example.  MPLS domain can be deployed between two SR-MPLS
   domains as Figure 1 shown.  The packets being transmitted along the
   SR path in SR-MPLS domains by using the SID list at the ingress node.
   And the path in MPLS domains can be pre-configuration either via NMS
   or via the MPLS control plane signaling.


                  B                     E                      X
               +     +              .       .               +      +
            +           +         .           .          +            +
         +                 +    .               .     +                  +
      A        SR-MPLS       C        MPLS         G       SR-MPLS          Z
         +      IGP 1      +    .     IGP 2     .     +      IGP 3       +
            +           +         .           .          +            +
               +     +              .      .                +      +
                  D                     F                       Y

         |<---Access Network--->|<-Aggregation Network->|<----Core Network---->|



             Figure 1: SR-MPLS and MPLS interworking Scenario

   The VPN service across the SR-MPLS and MPLS domains is an end-to-end
   bidirectional path.  In the SR-MPLS network, a Path Segment uniquely
   identifies an SR path and can be used for bidirectional path.  This
   document proposed the solution of Path Segment used in interworking
   scenario including the stitching and nesting models.

3.1.  Stitching interworking with i-Path

   It is a common requirement that SR-MPLS needs to interwork with MPLS
   when SR is incrementally being deployed in the MPLS domain.  Figure 2
   shows the stitching model of SR-MPLS inter-working with MPLS.





Quan Xiong, et al.       Expires January 4, 2020                [Page 4]


Internet-DraThe Use of Path Segment in SR-MPLS and MPLS Inter  July 2019


   The end-to-end bidirectional path acrossing the SR-MPLS and MPLS
   network being split into multiple segments.  And each segment can be
   identified by an inter-domain path segment (i-Path or i-PSID) as
   defined in draft-xiong-spring-path-segment-sr-inter-domain.  The
   i-Pathis valid in the corresponding domain and the border nodes
   maintain the forwarding entries of that i-Path segment binding the
   next i-Path and the related labels, e.g, SID list or MPLS labels.  In
   the headend node, the i-Path can correlate the inter-domain path of
   reverse direction and bind the two unidirectional paths.


         +-----------------+  ................  +-----------------+
         |        +---+    |  .    +---+     .  |    +---+        |
         |        | B |    |  .    | E |     .  |    | X |        |
         |        +---+    |  .    +---+     .  |    +---+        |
         |      /       \  |  .  /       \   .  |  /       \      |
         | +---+ SR-MPLS +-----+    MPLS   +-----+  SR-MPLS +---+ |
         | | A | domain1 |  C  |  domain2  |  G  |  domain3 | Z | |
         | +---+         +-----+           +-----+          +---+ |
         |      \      /   |  .  \      /    .  |  \       /      |
         |       +---+     |  .   +---+      .  |    +---+        |
         |       | D |     |  .   | F |      .  |    | Y |        |
         |       +---+     |  .   +---+      .  |    +---+        |
         +-----------------+  ................  +-----------------+

        |<----SID List---->|<--- MPLS Label--->|<----SID List---->|
        |<-----i-Path----->|<------i-Path----->|<-----i-Path----->|
        |<----------------------VPN Service---------------------->|


         Figure 2: SR-MPLS and MPLS interworking with Path Segment

3.2.  Nesting interworking with e-Path

   Figure 3 displays the nesting model of SR-MPLS and MPLS interworking.
   Compared with stitching model, the path segment presents end-to-end
   encapsulation in the packet from SR-MPLS domain to MPLS domain.  As
   described in [I-D.ietf-spring-mpls-path-segment], an end-to-end path
   segment, also referred to as e-Path, is used to indicate the end-to-
   end path, and an s-Path is used to indicate the intra-domain path.The
   e-Path is encapsulated at the ingress nodes and decapsulated at the
   egress nodes.  The transit nodes, even the border nodes of domains,
   are not aware of the e-Path segment.  The s-Path can be used as
   stitching label to correlate the two domains.  The use of the binding
   SID [RFC8402] is also recommended to reduce the size of lable stack.






Quan Xiong, et al.       Expires January 4, 2020                [Page 5]


Internet-DraThe Use of Path Segment in SR-MPLS and MPLS Inter  July 2019


         +-----------------+  ................  +-----------------+
         |        +---+    |  .    +---+     .  |    +---+        |
         |        | B |    |  .    | E |     .  |    | X |        |
         |        +---+    |  .    +---+     .  |    +---+        |
         |      /       \  |  .  /       \   .  |  /      \       |
         | +---+ SR-MPLS +-----+  MPLS     +-----+  SR-MPLS +---+ |
         | | A | domain1 |  C  |  domain2  |  G  |  domain3 | Z | |
         | +---+         +-----+           +-----+          +---+ |
         |      \      /   |  .  \      /    .  |  \       /      |
         |       +---+     |  .   +---+      .  |    +---+        |
         |       | D |     |  .   | F |      .  |    | Y |        |
         |       +---+     |  .   +---+      .  |    +---+        |
         +-----------------+  ................  +-----------------+

        |<----SID List---->|<--   MPLS Label-->|<----SID List---->|
        |<-----s-Path----->|<------s-Path----->|<-----s-Path----->|
        |<------------------------e-Path------------------------->|
        |<----------------------VPN Service---------------------->|



             Figure 3: Nesting SR-MPLS inter-working with MPLS

4.  Security Considerations

   TBA

5.  Acknowledgements

   TBA

6.  IANA Considerations

   TBA

7.  Normative References

   [I-D.ietf-spring-mpls-path-segment]
              Cheng, W., Li, H., Chen, M., Gandhi, R., and R. Zigler,
              "Path Segment in MPLS Based Segment Routing Network",
              draft-ietf-spring-mpls-path-segment-00 (work in progress),
              March 2019.

   [I-D.ietf-spring-segment-routing-mpls]
              Bashandy, A., Filsfils, C., Previdi, S., Decraene, B.,
              Litkowski, S., and R. Shakir, "Segment Routing with MPLS
              data plane", draft-ietf-spring-segment-routing-mpls-22
              (work in progress), May 2019.



Quan Xiong, et al.       Expires January 4, 2020                [Page 6]


Internet-DraThe Use of Path Segment in SR-MPLS and MPLS Inter  July 2019


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

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <https://www.rfc-editor.org/info/rfc8174>.

   [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

   Quan Xiong
   ZTE Corporation
   No.6 Huashi Park Rd
   Wuhan, Hubei  430223
   China

   Phone: +86 27 83531060
   Email: xiong.quan@zte.com.cn


   Greg Mirsky
   ZTE Corporation
   USA

   Email: gregimirsky@gmail.com


   Weiqiang Cheng
   China Mobile
   Beijing
   China

   Email: chengweiqiang@chinamobile.com












Quan Xiong, et al.       Expires January 4, 2020                [Page 7]


Html markup produced by rfcmarkup 1.129c, available from https://tools.ietf.org/tools/rfcmarkup/