Internet DRAFT - draft-hu-mpls-sr-inter-domain-use-cases
draft-hu-mpls-sr-inter-domain-use-cases
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]
