Inter-domain Use Cases of Segment Routing with MPLS Data Plane for Transport Network
draft-hu-mpls-sr-inter-domain-use-cases-01

Document Type Active Internet-Draft (individual)
Last updated 2019-03-10
Stream (None)
Intended RFC status (None)
Formats plain text xml pdf html bibtex
Stream Stream state (No stream defined)
Consensus Boilerplate Unknown
RFC Editor Note (None)
IESG IESG state I-D Exists
Telechat date
Responsible AD (None)
Send notices to (None)
MPLS Workgroup                                                Quan Xiong
Internet-Draft                                               Greg Mirsky
Intended status: Standards Track                         ZTE Corporation
Expires: September 11, 2019                                   Fangwei Hu
                                                              Individual
                                                          Weiqiang Cheng
                                                            China Mobile
                                                          March 10, 2019

   Inter-domain Use Cases of Segment Routing with MPLS Data Plane for
                           Transport Network
               draft-hu-mpls-sr-inter-domain-use-cases-01

Abstract

   This document discusses the inter-domain scenarios for Transport
   Profile of SR-MPLS (SR-MPLS-TP), including SR-MPLS-TP inter-working
   with MPLS-TP network.

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 11, 2019.

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

Quan Xiong, et al.     Expires September 11, 2019               [Page 1]
Internet-Draft      SR-MPLS-TP Inter-domain use cases         March 2019

   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.  Conventions used in this document . . . . . . . . . . . . . .   3
     2.1.  Terminology . . . . . . . . . . . . . . . . . . . . . . .   3
     2.2.  Requirements Language . . . . . . . . . . . . . . . . . .   3
   3.  Transport Profile in SR-MPLS  . . . . . . . . . . . . . . . .   3
   4.  SR-MPLS-TP Inter-domain . . . . . . . . . . . . . . . . . . .   4
     4.1.  SR-MPLS-TP Stitching Inter-domain . . . . . . . . . . . .   4
       4.1.1.  Inter-domain Path Segment . . . . . . . . . . . . . .   4
       4.1.2.  Border Node Inter-domain Scenario . . . . . . . . . .   5
       4.1.3.  Border Link Inter-domain Scenario . . . . . . . . . .   5
     4.2.  SR-MPLS-TP Nesting Inter-domain . . . . . . . . . . . . .   7
   5.  SR-MPLS-TP Inter-working with MPLS-TP . . . . . . . . . . . .   8
   6.  Security Considerations . . . . . . . . . . . . . . . . . . .  10
   7.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .  10
   8.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  10
   9.  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 of the SR domain.  Segment Routing can be
   instantiated on MPLS data plane or IPv6 data plane.  The former is
   referred to as SR-MPLS [I-D.ietf-spring-segment-routing-mpls], the
   latter is SRv6 [I-D.ietf-6man-segment-routing-header].  SR-MPLS
   leverages the MPLS label stack to construct the SR path, and SRv6
   uses the Segment Routing Header to construct the SR path.

   [I-D.cheng-spring-mpls-path-segment] defines a Path Segment
   identifier to support bidirectional path correlation for transport
   network.  This document defines an inter-domain path segment and
   discusses the inter-domain use cases in the context of the Transport
   Profile of SR-MPLS, referred to in this document as SR-MPLS-TP, and
   describes the use case related to SR-MPLS-TP inter-working with the
   MPLS-TP network.

Quan Xiong, et al.     Expires September 11, 2019               [Page 2]
Internet-Draft      SR-MPLS-TP Inter-domain use cases         March 2019

2.  Conventions used in this document

2.1.  Terminology

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

   B-SID: Binding SID.

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

   MPLS-TP: MPLS Transport Profile.

   s-Path: Sub-path Path Segment.

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

   SR: Segment Routing.

   SR-MPLS: Segment Routing with MPLS data plane.

   SR-MPLS-TP: Transport Profile of SR-MPLS.

   Border node inter-domain: Two domains interconnects with an edge node
   which belongs to both domains.

   Border link inter-domain: Two domains interconnects with an inter-
   link which connects the edge node in each domain.

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.  Transport Profile in SR-MPLS

   In the SR-MPLS network, an SR path is a unidirectional path.
   [I-D.cheng-spring-mpls-path-segment] defines a Path Segment
   identifier to support SR bidirectional path correlation for transport
   network.  In the context of the Transport Profile of SR-MPLS,
   referred to in this document as SR-MPLS-TP, a Path Segment uniquely
   identifies an SR path in a specific context.  For example, the Path
   Segment is used to indicate the intra-domain path in a single domain
   and correlate the two unidirectional SR paths at both ends of the
   paths.

Quan Xiong, et al.     Expires September 11, 2019               [Page 3]
Internet-Draft      SR-MPLS-TP Inter-domain use cases         March 2019

   In multi-domain scenario, the SR bidirectional end-to-end path MUST
   to be established in transport network.  The SR-MPLS-TP inter-domain
   models include the stitching inter-domain model and the nesting
   inter-domain model.  Path Segment MAY also be used to indicate the
   inter-domain path or the end-to-end path and correlate the inter-
   domain paths or end-to-end unidirectional paths.

4.  SR-MPLS-TP Inter-domain

   Two SR-MPLS-TP inter-domain models are discussed in this document
   including the stitching inter-domain model and the nesting inter-
   domain model.  Two use cases of stitching SR-MPLS-TP domains, using a
   border node inter-domain and a border link inter-domain, are
   described in Section 4.1.1 and Section 4.1.2 respectively.

4.1.  SR-MPLS-TP Stitching Inter-domain

4.1.1.  Inter-domain Path Segment

   In the stitching inter-domain model, the end-to-end SR path being
   split into multiple segments.  And each segment can be identified by
   an inter-domain path segment (i-Path or i-PSID).  The inter-domain
   path segment is valid in the corresponding domain and the border
   nodes maintain the forwarding entries of that i-Path segment mapping
   to the next i-Path.  In the headend node, the i-Path can be mapped to
   the inter-domain path of reverse direction and correlates the two
   unidirectional paths.  The border nodes should install the following
   MPLS data entries for Path segments:

     incoming label: i-Path
        outgoing label: the SID list of the next domain or link + next i-Path

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

        incoming label: i-Path(A->X)
           outgoing label: X->Y SID list + i-Path(X->Y)

   The i-Path can be a locally unique label and assigned from the
   Segment Routing Local Block (SRLB).  It is required that the
   controller(e.g., PCE) assigns the label to ensure the ingress and the
   egress node can recognize it and it also can be assigned from egress
   node of each domain.  PCEP based i-Path allocation and procedure is
   defined in [I-D.xiong-pce-stateful-pce-sr-inter-domain].

Quan Xiong, et al.     Expires September 11, 2019               [Page 4]
Internet-Draft      SR-MPLS-TP Inter-domain use cases         March 2019

4.1.2.  Border Node Inter-domain Scenario

   The Figure 1 displays the border node inter-domain scenario.  SR node
   X and SR node Y are the border nodes of two different domains.  The
   i-Paths from A->X, X->Y, and Y->Z are used for the inter-domain path
   segment.  The ingress SR node A encapsulates the data packet with
   i-Path (A->X) and A->X SID list.  The data packet is forwarded to SR
   node X according to the A->X SID list.  Node X pushes the i-Path
   (X->Y) and X->Y SID list based on the above mentioned forwarding
   entry.  The data packet is forwarded to node Y and then to the SR
   node Z based on the same forwarding procedure.  In node Z, the i-Path
   (Y->Z) can be mapped to the path from Z to Y of reverse direction and
   correlates the two unidirectional paths.  The packet transmission of
   the reverse direction is the same with the forwarding direction with
   different i-Paths.

      ..................   .................   ....................
      .                .   .               .   .                  .
  +-----+             +-----+             +-----+              +-----+
  |  A  |             |  X  |             |  Y  |              |  Z  |
  +-----+             +-----+             +-----+              +-----+
      .   Domain 1     .   .    Domain 2   .   .    Domain 3      .
      ..................   .................   ....................

        |<------------------>|<------------------>|<--------------->|
        i-Path(A->X)         i-Path(X->Y)         i-Path(Y->Z)

    Node A               Node X             Node Y             Node Z
+-------------+     +-------------+     +-------------+
|A->X SID list|     |X->Y SID list|     |Y->Z SID list|
+-------------+     +-------------+     +-------------+    +--------------+
|i-Path(A->X) |---->|i-Path(X->Y) |---->|i-Path(Y->Z) |--->|   Payload    |
+-------------+     +-------------+     +-------------+    +--------------+
|  Payload    |     |   Payload   |     |  Payload    |
+-------------+     +-------------+     +-------------+

           Figure 1: Stitching Border Node Inter-Domain Scenario

4.1.3.  Border Link Inter-domain Scenario

   Figure 2 illustrates the border link inter-domain scenario.  All the
   SR nodes belong to a single domain.  Neighboring border nodes of
   different domains are interconnected by direct physical or logical
   links.  Ingress SR node A encapsulates the data packet with i-Path
   (A->B) and A->B SID list.  The data packet is forwarded to SR node B

Quan Xiong, et al.     Expires September 11, 2019               [Page 5]
Internet-Draft      SR-MPLS-TP Inter-domain use cases         March 2019

   according to the A->B SID list.  Node B pushes i-Path (B->C) and the
   inter-domain link label(B->C SID) based on the forwarding entry, and
   forwards the packet to node C.  SR node C forwards the packet to node
   X, then node X forwards the packets to node Y.  The data packet
   reaches the destination SR node Z according to the same forwarding
   procedure.  In node Z, the i-Path (Y->Z) can be mapped to the path
   from Z to Y of reverse direction and correlates the two
   unidirectional paths.  The packet transmission of the reverse
   direction is the same with the forwarding direction with different
   i-Paths.

    ....................   ....................    .....................
    .                  .   .                  .    .                   .
    .+---+       +---+ .   . +---+      +---+ .    .+---+      +----+  .
    .| A |-------| B |------ | C |------| X |-------| Y |------| Z  |  .
    .+---+       +---+ .   . +---+      +---+ .    .+---+      +----+  .
    .    Domain 1      .   .   Domain 2       .    .    Domain 3       .
    ....................   ....................    .....................

     |----------->|----------->|----------->|----------->|---------->|
      i-Path(A->B) i-Path(B->C) i-Path(C->X) i-Path(X->Y) i-Path(Y->Z)

       Node A               Node B            Node C
   +-------------+     +------------+     +-------------+
   |A->B SID list|     |  B->C SID  |     |C->X SID list|
   +-------------+     +------------+     +-------------+
   |i-Path(A->B) |---->|i-Path(B->C)|---->|i-Path(C->X) |---->
   +-------------+     +------------+     +-------------+
   |  Payload    |     |   Payload  |     |  Payload    |
   +-------------+     +------------+     +-------------+

      Node X               Node Y
   +-------------+     +-------------+
   |  X->Y SID   |     |Y->Z SID list|         Node Z
   +-------------+     +-------------+     +--------------+
   |i-Path(X->Y) |---->|i-Path(Y->Z) |---->|   Payload    |
   +-------------+     +-------------+     +--------------+
   |   Payload   |     |  Payload    |
   +-------------+     +-------------+

           Figure 2: Stitching Border Link Inter-Domain Scenario

Quan Xiong, et al.     Expires September 11, 2019               [Page 6]
Internet-Draft      SR-MPLS-TP Inter-domain use cases         March 2019

4.2.  SR-MPLS-TP Nesting Inter-domain

   The nesting inter-domain model is described in
   [I-D.cheng-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.  Only the s-Path is pushed and popped at
   the border nodes of the corresponding 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 path.  The s-Path is
   used to identify the domain's sub-path.  The e-Path, s-Path and SR
   list are pushed by the ingress node.  To reduce the size of the label
   stacks, the use of the binding SID [RFC8402] is recommended to
   replace the SR list of each domain.  As shown in Figure 3, the
   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), B-SID(X-Y), s-Path(A->X) and A->X
   SID list in turn.  When the packet is received at node X, the
   s-Path(A-X) and X->Y SID list are popped, and the new s-Path(X->Y) is
   pushed.  Also, X->Y SID list replaces B-SID(X->Y) to indicate that
   packet to be forwarded from node X to node Y.  The data packet
   reaches the SR node Z according to the same forwarding procedure.  In
   SR node Z, the e-Path (A->Z) is used to correlate the two
   unidirectional end-to-end paths.

   The e-Path can be a globally unique or local label.  If the e-Path is
   globally unique, it MUST be assigned from the SRGB block of each
   domain.  If the e-Path is a local label, it is required that the
   controller(e.g., PCE) or a super controller (e.g., hierarchical PCE)
   assigns the label to ensure the ingress(A) and the egress node(Z) can
   recognize it and there is no SID collision in the ingress and egress
   domains.

Quan Xiong, et al.     Expires September 11, 2019               [Page 7]
Internet-Draft      SR-MPLS-TP Inter-domain use cases         March 2019

      ..................   .................   ....................
      .                .   .               .   .                  .
  +-----+             +-----+             +-----+              +-----+
  |  A  |             |  X  |             |  Y  |              |  Z  |
  +-----+             +-----+             +-----+              +-----+
      .   Domain 1     .   .   Domain 2    .   .   Domain 3       .
      ..................   .................   ....................

      |<------------------>|<------------------>|<--------------->|
           s-Path(A->X)         s-Path(X->Y)       s-Path(Y->Z)
      |<--------------------------------------------------------->|
                           e-Path(A->Z)
    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) |     |Y->Z 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

5.  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 being deployed in the MPLS-TP
   domain.

   Figure 4 shows the stitching model of SR-MPLS-TP inter-working with
   MPLS-TP.  The left is the SR-MPLS-TP network, and the right is the
   MPLS-TP network.  The path segment which is i-Path is used for the
   bidirectional tunnel correlation in SR-MPLS-TP network.  The edge
   nodes of the SR-MPLS-TP network should map the path segment to the
   corresponding MPLS-TP label for bidirectional tunnel indication in
   the MPLS-TP network.

Quan Xiong, et al.     Expires September 11, 2019               [Page 8]
Internet-Draft      SR-MPLS-TP Inter-domain use cases         March 2019

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

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

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

   Figure 5 displays the nesting model of SR-MPLS-TP and MPLS-TP inter-
   working.  Compared with stitching SR-MPLS-TP inter-working with MPLS-
   TP, the path segment is e-Path and presents end-to-end encapsulation
   in the packet from SR-MPLS-TP domain to MPLS-TP domain.

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

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

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

   The requirements for the SR-MPLS-TP inter-working with MPLS-TP are as
   follows:

Quan Xiong, et al.     Expires September 11, 2019               [Page 9]
Internet-Draft      SR-MPLS-TP Inter-domain use cases         March 2019

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

   o  The path segment MUST be carried through SR-MPLS-TP and MPLS-TP
      domains in the nesting SR-MPLS-TP inter-working with MPLS-TP
      model.

   o  The edge nodes of the MPLS-TP network SHOULD process the path
      segment from the SR-MPLS-TP network.

   o  The edge nodes in the MPLS-TP SHOULD process MPLS SID sent from
      the MPLS-SR-TP domain

   o  The edge nodes in the SR-MPLS-TP network SHOULD process the MPLS-
      TP labels sent from the MPLS-TP domain;

6.  Security Considerations

   TBA

7.  Acknowledgements

   TBA

8.  IANA Considerations

   TBA

9.  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-16 (work in
              progress), February 2019.

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

Quan Xiong, et al.     Expires September 11, 2019              [Page 10]
Internet-Draft      SR-MPLS-TP Inter-domain use cases         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-18
              (work in progress), December 2018.

   [I-D.xiong-pce-stateful-pce-sr-inter-domain]
              Xiong, Q., hu, f., Mirsky, G., and W. Cheng, "Stateful PCE
              for SR-MPLS-TP Inter-domain", draft-xiong-pce-stateful-
              pce-sr-inter-domain-00 (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>.

   [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

Quan Xiong, et al.     Expires September 11, 2019              [Page 11]
Internet-Draft      SR-MPLS-TP Inter-domain use cases         March 2019

   Greg Mirsky
   ZTE Corporation
   USA

   Email: gregimirsky@gmail.com

   Fangwei Hu
   Individual
   China

   Email: hufwei@gmail.com

   Weiqiang Cheng
   China Mobile
   Beijing
   China

   Email: chengweiqiang@chinamobile.com

Quan Xiong, et al.     Expires September 11, 2019              [Page 12]