Skip to main content

Segment Routing in MPLS-TP Inter-domain Use Cases
draft-hu-mpls-sr-inter-domain-use-cases-00

The information below is for an old version of the document.
Document Type
This is an older version of an Internet-Draft whose latest revision state is "Expired".
Authors fangwei hu , Quan Xiong , Greg Mirsky , Weiqiang Cheng
Last updated 2018-12-09
RFC stream (None)
Formats
Additional resources
Stream Stream state (No stream defined)
Consensus boilerplate Unknown
RFC Editor Note (None)
IESG IESG state I-D Exists
Telechat date (None)
Responsible AD (None)
Send notices to (None)
draft-hu-mpls-sr-inter-domain-use-cases-00
MPLS Workgroup                                                Fangwei Hu
Internet-Draft                                                Quan Xiong
Intended status: Standards Track                             Greg Mirsky
Expires: June 12, 2019                                   ZTE Corporation
                                                          Weiqiang Cheng
                                                            China Mobile
                                                             Dec 9, 2018

           Segment Routing in MPLS-TP Inter-domain Use Cases
               draft-hu-mpls-sr-inter-domain-use-cases-00

Abstract

   This document discusses SR-MPLS-TP inter-domain scenarios and use
   cases, and also SR-MPLS-TP inter-working with MPLS-TP network
   requirement and use cases.

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 June 12, 2019.

Copyright Notice

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

Fangwei Hu, et al.        Expires June 12, 2019                 [Page 1]
Internet-Draft          SR Inter-domain use cases               Dec 2018

   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

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-TP Inter-domain . . . . . . . . . . . . . . . . . . .   3
     3.1.  SR-MPLS-TP Stitching Inter-domain . . . . . . . . . . . .   4
       3.1.1.  Border Node Inter-domain Scenario . . . . . . . . . .   4
       3.1.2.  Border Link Inter-domain Scenario . . . . . . . . . .   5
     3.2.  SR-MPLS-TP Nesting Inter-domain . . . . . . . . . . . . .   6
   4.  SR-MPLS-TP Inter-working with MPLS-TP . . . . . . . . . . . .   7
   5.  Security Considerations . . . . . . . . . . . . . . . . . . .   9
   6.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .   9
   7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   9
   8.  Normative References  . . . . . . . . . . . . . . . . . . . .  10
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  11

1.  Introduction

   Segment Routing (SR) leverages the source routing paradigm.  A node
   steers a packet through an SR Policy instantiated as an ordered list
   of instructions called "segments".  A segment can represent any
   instruction, topological or service based.  A segment can have a
   semantic local to an SR node or global within an SR domain.  SR
   supports per-flow explicit routing while maintaining per-flow state
   only at the ingress nodes to the SR domain.  Segment Routing can be
   instantiated on MPLS data plane or IPv6 data plane.  The former is
   called SR-MPLS [I-D.ietf-spring-segment-routing-mpls] , the latter is
   called SRv6 [I-D.ietf-6man-segment-routing-header].  SR-MPLS
   leverages the MPLS label stack to construct SR path, and SRv6 uses
   the Segment Routing Header to construct SR path.

   [I-D.cheng-spring-mpls-path-segment] provides a path segment to
   support bidirectional path correlation in an AS domain.  A Path
   Segment is defined to unique identify an SR path in a specific
   context.  This document proposes to discuss SR-MPLS-TP inter-domain
   scenarios and use cases, and SR-MPLS-TP inter-working with MPLS-TP
   network requirement and use case.

2.  Conventions used in this document

Fangwei Hu, et al.        Expires June 12, 2019                 [Page 2]
Internet-Draft          SR Inter-domain use cases               Dec 2018

2.1.  Terminology

   A->B SID list: The SID List from SR node A to SR node B.

   AS: Autonomous Systems.

   BSID: Binding SID.

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

   MPLS-TP: MPLS transport profile.

   s-Path: Sub-path path segment.

   SR: Segment routing.

   SR-MPLS: Segment routing with MPLS data plane.

   SR-MPLS-TP: Segment routing transport Profile with MPLS data plane.

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-TP Inter-domain

   There are two SR-MPLS-TP inter-domain models defined in this
   document: stitching inter-domain model and nesting inter-domain
   model.  The stitching inter-domain model is that the end-to-end SR
   path segment are split into multiple domain path segments.  Each SR-
   MPLS-TP domain has its domain path segment.  The domain path segment
   is valid in its own domain, and the border nodes maintain the
   forwarding entries of its domain path segment mapping to other domain
   path segment.  There are two scenarios for stitching SR-MPLS-TP
   inter-domain: border node inter-domain(section 3.1.1) and border link
   inter-domain scenarios(section 3.1.2).

   The nesting inter-domain model is that an e-Path segment is used to
   indicate the end-to-end bidirectional path tunnel, and a s-Path is
   used to indicate the domain bidirectional path tunnel.  The e-path
   segment is encapsulated in the ingress nodes, and decapsulated in the
   egress nodes.  The transmit nodes, even the border nodes of domains,
   do not aware of the e-path segment(section 3.2 for details).  The

Fangwei Hu, et al.        Expires June 12, 2019                 [Page 3]
Internet-Draft          SR Inter-domain use cases               Dec 2018

   s-Path are encapsulated and decapsualted in the border nodes of its
   domain.

3.1.  SR-MPLS-TP Stitching Inter-domain

3.1.1.  Border Node Inter-domain Scenario

   The following figure shows the border node inter-domain scenario.  SR
   node X and SR node Y are the border nodes of two different Autonomous
   Systems.  The Path labels (Path1, Path2, Path3, Path1',Path2' and
   Path3') [I-D.cheng-spring-mpls-path-segment] are used for inter-
   domain bidirectional tunnel indication.  Path 1, Path 2 and Path3 are
   used for the forwarding path from A to Z, and Path1', Path2' and
   Path3' are used for the reverse path (from Z to A).  The border nodes
   should install the following MPLS data entries for Path labels:

     incoming label: Path Label
        outgoing label: the SID list of the next AS domain + next Path label

   Taking figure 1 as the example, the border node X installs the MPLS
   data entries:

        incoming label: Path1
           outgoing label: X-Y SID list + Path 2

   The ingress SR node A encapsulates the data packet with Path1 label
   and A-X SID list.  The data packet forwards to SR node X according to
   the A-X SID list.  Node X encapsulates the Path2 label and X-Y SID
   list based on the above forwarding entry.  The data packet forwards
   to node Y and even to destination SR node Z based on the same
   forwarding procedure.  The egress node Z pops the path label and
   reverses back the data packet to the node Y.  Node Y encapsulates the
   Path3' label and Y-X SID list and forwards the packet to node X, and
   X sends back to the ingress node based on the same forwarding
   procedure.

Fangwei Hu, et al.        Expires June 12, 2019                 [Page 4]
Internet-Draft          SR Inter-domain use cases               Dec 2018

      ..................   .................   ....................
      .                .   .               .   .                  .
      .                .   .               .   .                  .
  +-----+             +-----+             +-----+              +-----+
  |  A  |             |  X  |             |  Y  |              |  Z  |
  +-----+             +-----+             +-----+              +-----+
      .                .   .               .   .                 .
      .       AS 1     .   .      AS2      .   .    AS3          .
      ..................   .................   ...................

    Node A               Node X             Node Y
+-------------+     +-------------+     +-------------+
|A-X SID list |     |X-Y SID list |     |Y-Z SID list |        Node Z
+-------------+     +-------------+     +-------------+    +--------------+
|    Path1    |----\|    Path2    |----\|    Path3    |---\|   Payload    |
+-------------+----/+-------------+----/+-------------+---/+--------------+
|  Payload    |     |   Payload   |     |  Payload    |
+-------------+     +-------------+     +-------------+

           Figure 1: Stitching Border Node Inter-Domain Scenario

3.1.2.  Border Link Inter-domain Scenario

   Figure 2 is the border link inter-domain scenario.  All the SR nodes
   belong to one AS in this scenario.  The border nodes of different
   Autonomous Systems are connected with direct physical or logical
   links.  The Path labels are not only assigned to the Autonomous
   System, they are assigned to the links of the two ASes, for example,
   the Path 2 (Path 2') and Path 4(Path 4') are assigned to the links
   between AS1 and AS2, and between AS2 and AS3 respectively.

   Ingress SR node A encapsulates the data packet with Path1 and A-B SID
   list.  The data packet forwards to SR node B according to the A-B SID
   list.  Node B encapsulates Path2 and the inter-domain link
   label(label B-C) according to the forwarding entry, and forwards the
   packet to Node C.  SR node C forwards the packet to node X, then to
   Y.  The data packet forwards the destination SR node Z according to
   the same forwarding procedure.

   The border nodes should install the following MPLS data entries for
   Path labels:

     incoming label: Path Label
        outgoing label: the SID list of the next AS domain + next Path label

   If the border node belongs to the outgoing AS domain for the data
   packet, the SID-List is the label assigned to the link between two

Fangwei Hu, et al.        Expires June 12, 2019                 [Page 5]
Internet-Draft          SR Inter-domain use cases               Dec 2018

   border nodes of different AS domains for the border link inter-domain
   scenario.  The procedure of assigning and processing that link label
   is out of scope.

   ....................   ....................    .....................
   .                  .   .                  .    .                   .
   .                  .   .                  .    .                   .
   .+---+       +---+ .   . +---+      +---+ .    .+---+      +----+  .
   .| A |-------| B |------ | C |------| X |-------| Y |------| Z  |  .
   .+---+       +---+ .   . +---+      +---+ .    .+---+      +----+  .
   .                  .   .                  .    .                   .
   .     AS 1         .   .       AS2        .    .       AS3         .
   ....................   ....................    .....................

       Node A              Node B              Node C
   +-------------+     +-------------+     +-------------+
   |A-B SID list |     | Label B->C  |     |C->X SID list|
   +-------------+     +-------------+     +-------------+
   |     Path1   |----\|     Path2   |----\|     Path3   |----\
   +-------------+----/+-------------+----/+-------------+----/
   |  Payload    |     |   Payload   |     |  Payload    |
   +-------------+     +-------------+     +-------------+

      Node X               Node Y
   +-------------+     +-------------+
   | Label X->Y  |     |Y->Z SID list|         Node Z
   +-------------+     +-------------+     +--------------+
   |    Path4    |----\|    Path5    |----\|   Payload    |
   +-------------+----/+-------------+----/+--------------+
   |   Payload   |     |  Payload    |
   +-------------+     +-------------+

           Figure 2: Stitching Border Link Inter-Domain Scenario

3.2.  SR-MPLS-TP Nesting Inter-domain

   Figure 3 shows the SR-MPLS-TP nesting inter-domain scenario.  The
   e-Path(A->Z) is used to indicate the end-to-end bidirectional tunnel.
   The s-Path is used to indicate its domain sub-path bidirectional
   tunnel.  The e-Path, s-Path and SR list are encapsulated in the
   ingress node.  In order to reduce the label stacks, the binding
   SID([RFC8402]) is recommended to be used to replace the SR list of
   each domain.  As the figure 3 shows, B-SID(X,Y) is used to replace
   the X-Y SID list.  Ingress node A pushes e-Path(A->Z), B-SID(Y->Z),

Fangwei Hu, et al.        Expires June 12, 2019                 [Page 6]
Internet-Draft          SR Inter-domain use cases               Dec 2018

   B-SID(X-Y), s-Path(A->X) and A-X SID list in turn.  When the packet
   is received in node X, the s-Path(A-X) and X-Y SID list are popped, a
   new s-Path(X->Y) is pushed, and BSID(X->Y) is replaced by X-Y SID
   list to indicate the packet being forwarded from node X to node Y.

   The e-Path can be global unique or local label.  If the e-Path is
   global unique, it occupies the SRGB block of each domain.  While if
   the e-Path is a local label, it is required the controller(PCE) or
   super controller( or hierarchical PCE) to assign the label to ensure
   that ingress(A) and egress node(Z) can recognize it and there is no
   SID confliction in the ingress and egress domains.

      ..................   .................   ....................
      .                .   .               .   .                  .
      .                .   .               .   .                  .
  +-----+             +-----+             +-----+              +-----+
  |  A  |             |  X  |             |  Y  |              |  Z  |
  +-----+             +-----+             +-----+              +-----+
      .                .   .               .   .                 .
      .       AS 1     .   .      AS2      .   .    AS3          .
      ..................   .................   ...................

    Node A
+-------------+
|A-X SID list |         Node X
+-------------+     +-------------+
|s-Path(A->X) |     |X-Y SID list |         Node Y
+-------------+     +-------------+     +-------------+
|B-SID (X->Y) |     |s-Path(X->Y) |     |X-Y SID list |
+-------------+     +-------------+     +-------------+
|B-SID( Y->Z) |     |B-SID( Y->Z) |     |s-Path(Y->Z) |        Node Z
+-------------+     +-------------+     +-------------+     +-------------+
|e-Path(A->Z) |     |e-Path(A->Z) |     |e-Path(A->Z) |     |e-Path(A->Z) |
+-------------+     +-------------+     +-------------+     +-------------+
|  Payload    |     |   Payload   |     |  Payload    |     |  Payload    |
+-------------+     +-------------+     +-------------+     +-------------+

                  Figure 3: Nesting Inter-Domain Scenario

4.  SR-MPLS-TP Inter-working with MPLS-TP

   It is a common requirement that SR-MPLS-TP needs to inter-work with
   MPLS-TP when SR is incrementally deployed in the MPLS-TP domain.

   Figure 4 shows the stitching SR-MPLS-TP inter-working with MPLS-TP,
   the left part is SR-MPLS-TP network, and the right part is MPLS-TP

Fangwei Hu, et al.        Expires June 12, 2019                 [Page 7]
Internet-Draft          SR Inter-domain use cases               Dec 2018

   network.  The Path label is used for the bidirectional tunnel
   indication in SR-MPLS-TP network.  The Border nodes of SR-MPLS-TP
   network should map the Path label to the corresponding MPLS-TP label
   for bidirectional tunnel indication in MPLS-TP network.

     ................................    ..................................
.                              .    .                                .
.+---+       +---+       +---+ .    . +---+       +---+      +----+  .
.| A |-------| B |------ | C |-.----.-| U |-------| V |------| W  |  .
.+-+-+       +-+-+       +---+ .    . +---+       +-+-+      +-+--+  .
.  |           |               .    .               |          |     .
.  |           |               .    .               |          |
.+-+-+       +-+-+       +---+ .    . +---+       +-+-+      +-+--+  .
.| D |-------| E |------ | F |-.----.-| X |-------| Y |------| Z  |  .
.+---+       +---+       +---+ .    . +---+       +---+      +----+  .
.                              .    .                                .
.    SR-MPLS-TP  domain        .    .      MPLS-TP domain            .
................................    ..................................

|<----------SID List----------->|<--------------MPLS-TP label------->|
|<--------Path label----------->|
|<---------------------------VPN Service---------------------------->|

         Figure 4: Stitching SR-MPLS-TP inter-working with MPLS-TP

   Figure 5 is the nesting SR-MPLS-TP inter-working with MPLS-TP
   scenario.  The difference with stitching SR-MPLS-TP inter-working
   with MPLS-TP is that the Path label is end-to-end encapsulation in
   the packet from SR-MPLS-TP domain to MPLS-TP domain.

Fangwei Hu, et al.        Expires June 12, 2019                 [Page 8]
Internet-Draft          SR Inter-domain use cases               Dec 2018

  ................................    ..................................
  .                              .    .                                .
  .+---+       +---+       +---+ .    . +---+       +---+      +----+  .
  .| A |-------| B |------ | C |-.----.-| U |-------| V |------| W  |  .
  .+-+-+       +-+-+       +---+ .    . +---+       +-+-+      +-+--+  .
  .  |           |               .    .               |          |     .
  .  |           |               .    .               |          |
  .+-+-+       +-+-+       +---+ .    . +---+       +-+-+      +-+--+  .
  .| D |-------| E |------ | F |-.----.-| X |-------| Y |------| Z  |  .
  .+---+       +---+       +---+ .    . +---+       +---+      +----+  .
  .                              .    .                                .
  .    SR-MPLS-TP  domain        .    .      MPLS-TP domain            .
  ................................    ..................................

  |<----------SID List----------->|<--------------MPLS-TP label------->|
  |<---------------------------Path label----------------------------->|
  |<---------------------------VPN Service---------------------------->|

          Figure 5: nesting SR-MPLS-TP inter-working with MPLS-TP

   The requirement of the SR-MPLS-TP inter-working with MPLS-TP is as
   following:

   o  It is required to establish the end-to-end VPN service through SR-
      MPLS-TP domain and MPLS-TP domain;

   o  The Path Label is required to carried through SR-MPLS-TP and MPLS-
      TP domain in nesting SR-MPLS-TP inter-working with MPLS-TP model.

   o  The border nodes of MPLS-TP network could understand and process
      the path segment from SR-MPLS-TP network.

   o  The border nodes in MPLS-TP could understand and process MPLS SID
      sent from MPLS-SR-TP domain

   o  The border nodes in SR-MPLS-TP network could understand and
      process the MPLS-TP labels sent from MPLS-TP domain;

5.  Security Considerations

6.  Acknowledgements

7.  IANA Considerations

Fangwei Hu, et al.        Expires June 12, 2019                 [Page 9]
Internet-Draft          SR Inter-domain use cases               Dec 2018

8.  Normative References

   [I-D.cheng-spring-mpls-path-segment]
              Cheng, W., Wang, L., Li, H., Chen, M., Gandhi, R., Zigler,
              R., and S. Zhan, "Path Segment in MPLS Based Segment
              Routing Network", draft-cheng-spring-mpls-path-segment-03
              (work in progress), October 2018.

   [I-D.ietf-6man-segment-routing-header]
              Filsfils, C., Previdi, S., Leddy, J., Matsushima, S., and
              d. daniel.voyer@bell.ca, "IPv6 Segment Routing Header
              (SRH)", draft-ietf-6man-segment-routing-header-15 (work in
              progress), October 2018.

   [I-D.ietf-pce-association-group]
              Minei, I., Crabbe, E., Sivabalan, S., Ananthakrishnan, H.,
              Dhody, D., and Y. Tanaka, "PCEP Extensions for
              Establishing Relationships Between Sets of LSPs", draft-
              ietf-pce-association-group-06 (work in progress), June
              2018.

   [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-17
              (work in progress), December 2018.

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

   [RFC7551]  Zhang, F., Ed., Jing, R., and R. Gandhi, Ed., "RSVP-TE
              Extensions for Associated Bidirectional Label Switched
              Paths (LSPs)", RFC 7551, DOI 10.17487/RFC7551, May 2015,
              <https://www.rfc-editor.org/info/rfc7551>.

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

   [RFC8231]  Crabbe, E., Minei, I., Medved, J., and R. Varga, "Path
              Computation Element Communication Protocol (PCEP)
              Extensions for Stateful PCE", RFC 8231,
              DOI 10.17487/RFC8231, September 2017,
              <https://www.rfc-editor.org/info/rfc8231>.

Fangwei Hu, et al.        Expires June 12, 2019                [Page 10]
Internet-Draft          SR Inter-domain use cases               Dec 2018

   [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

   Fangwei Hu
   ZTE Corporation
   No.889 Bibo Rd
   Shanghai  201203
   China

   Phone: +86 21 68896273
   Email: hu.fangwei@zte.com.cn

   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

Fangwei Hu, et al.        Expires June 12, 2019                [Page 11]