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