Internet DRAFT - draft-xiong-spring-path-segment-sr-inter-domain
draft-xiong-spring-path-segment-sr-inter-domain
SPRING Q. Xiong
Internet-Draft G. Mirsky
Intended status: Informational ZTE Corporation
Expires: January 14, 2021 W. Cheng
China Mobile
July 13, 2020
The Use of Path Segment in SR Inter-domain Scenarios
draft-xiong-spring-path-segment-sr-inter-domain-02
Abstract
This document illustrates the inter-domain scenarios for SR-MPLS
networks to support end-to-end bidirectional tunnel across multiple
domains with the use of Path Segments.
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 14, 2021.
Copyright Notice
Copyright (c) 2020 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.
Xiong, et al. Expires January 14, 2021 [Page 1]
Internet-DraThe Use of Path Segment in SR Inter-domain Scenar July 2020
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Conventions used in this document . . . . . . . . . . . . . . 3
2.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
2.2. Requirements Language . . . . . . . . . . . . . . . . . . 3
3. End-to-end Path Segment . . . . . . . . . . . . . . . . . . . 4
3.1. S-PSID . . . . . . . . . . . . . . . . . . . . . . . . . 4
3.2. N-PSID . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. SR-MPLS Inter-domain Scenarios . . . . . . . . . . . . . . . 4
4.1. Stitching of Path Segments . . . . . . . . . . . . . . . 5
4.2. Nesting of Path Segments . . . . . . . . . . . . . . . . 6
5. Security Considerations . . . . . . . . . . . . . . . . . . . 7
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
8. Normative References . . . . . . . . . . . . . . . . . . . . 8
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8
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 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.
As defined in [RFC8402], the headend of an SR Policy binds a Binding
Segment ID (B-SID) to its policy. The B-SID could be bound to a SID
List or selected path and used to stitch the SR list and the SR Label
Switched Paths (LSP) across multiple domains. In some scenarios, for
example, a mobile backhaul transport network, it is required to
provide end-to-end bidirectional path across SR networks.
[I-D.ietf-spring-mpls-path-segment] defines a path segment identifier
to support bidirectional path correlation for transport network. In
the multi-domain scenarios, the SR bidirectional end-to-end path MAY
be established with the use of path segments. Path segment MAY be
used to indicate the end-to-end bidirectional path to achieve the
path monitoring including nesting of Path Segments or Path SID
(N-PSID) and stitching of Path Segments or Path SID (S-PSID).
This document illustrates the inter-domain scenarios for SR-MPLS
networks to support end-to-end bidirectional tunnel across multiple
domains with the use of Path Segments.
Xiong, et al. Expires January 14, 2021 [Page 2]
Internet-DraThe Use of Path Segment in SR Inter-domain Scenar July 2020
2. Conventions used in this document
2.1. Terminology
ABR: Area Border Routers. Routers used to connect two IGP areas
(areas in OSPF or levels in IS-IS).
A->B SID list: The SID List from SR node A to SR node B.
AS: Autonomous System. An Autonomous System is composed by one or
more IGP areas.
ASBR: Autonomous System Border Router. A router used to connect
together ASes of the same or different service providers via one or
more inter-AS links.
B-SID: Binding Segment ID.
Domains:Autonomous System (AS) or IGP Area. An Autonomous System is
composed by one or more IGP areas.
e-Path: End-to-end Path Segment.
Inter-Area: Two IGP areas interconnects with an ABR in an AS.
Inter-AS: Two ASes interconnects with an ASBR.
IGP: Interior Gateway Protocol.
N-PSID: Nesting of Path Segments.
S-PSID: Stitching of Path Segments.
SR: Segment Routing.
SR-MPLS: Segment Routing 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.
Xiong, et al. Expires January 14, 2021 [Page 3]
Internet-DraThe Use of Path Segment in SR Inter-domain Scenar July 2020
3. End-to-end Path Segment
3.1. S-PSID
As described in [I-D.ietf-spring-mpls-path-segment], an end-to-end
Path Segment, also referred to as e-Path. In the inter-domain
scenario, the end-to-end SR path is split into multiple segments.
And each segment can be identified by S-PSIDs in stitching model.
The correlation of path segments can stitch the inter-domain paths
and bind unidirectional paths. The S-PSIDs are valid in the
corresponding domain and the border nodes maintain the forwarding
entries of that S-PSID. At the headend node, the S-PSID can
correlate the inter-domain path of reverse direction and bind the two
unidirectional paths.
The S-PSID 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 S-PSID allocation and procedure is
defined in [I-D.xiong-pce-stateful-pce-sr-inter-domain].
3.2. N-PSID
As described in [I-D.ietf-spring-mpls-path-segment], an end-to-end
Path Segment, also referred to as e-Path. In nesting model, the
e-Path is also referred to as N-PSID which 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 N-PSID.
The use of the B-SID is also recommended to reduce t he size of label
stack section 4.2 and stitch the SR list and the SR LSP. The N-PSID
can be used to indicate the end-to-end path and achieve the
bidirectional path monitoring.
The N-PSID can be a globally unique or local label. If the N-PSID is
globally unique, it MUST be assigned from the SRGB block of each
domain. If the N-PSID 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.
4. SR-MPLS Inter-domain Scenarios
The domains of the networks may be IGP Areas or ASes and the inter-
domain scenario may be inter-Area or inter-AS. The multiple SR-MPLS
domains may be interconnected with a ABR within areas or inter-link
between ASes. This document takes IGP Areas domains for example.
Xiong, et al. Expires January 14, 2021 [Page 4]
Internet-DraThe Use of Path Segment in SR Inter-domain Scenar July 2020
The border link scenarios are in future discussion. SR-MPLS domains
can be deployed as Figure 1 shown.
+ + +
+ + + + + +
+ + + + + +
+ + + + + +
A SR-MPLS X SR-MPLS Y SR-MPLS Z
+ IGP 1 + + IGP 2 + + IGP 3 +
+ + + + + +
+ + + + + +
+ + +
Figure 1: SR-MPLS inter-domain Scenario
Two SR-MPLS inter-domain models are discussed in this document
including using the stitching and nesting of Path Segments which are
described in Section 4.1 and Section 4.2 respectively.
4.1. Stitching of Path Segments
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
S-PSIDs 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
S-PSID (A->X), B-SID(Y->Z), B-SID(X->Y) 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 S-PSID (X->Y), B-SID(Y->Z) 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 b ased on the same
forwarding procedure. In node Z, the S-PSID (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
S-PSID. The stitching of path segments can achieve the inter-domain
path monitoring.
Xiong, et al. Expires January 14, 2021 [Page 5]
Internet-DraThe Use of Path Segment in SR Inter-domain Scenar July 2020
.................. ................. ....................
. . . . . .
+-----+ +-----+ +-----+ +-----+
| A | | X | | Y | | Z |
+-----+ +-----+ +-----+ +-----+
. SR Domain 1 . . SR Domain 2 . . SR Domain 3 .
.................. ................. ....................
Service Layer:
|<----------------------End-to-end Service--------------->|
Path Segment:
|<-----S-PSID----->o<------S-PSID----->o<-----S-PSID----->|
LSP/Tunnel:
|<------SR-LSP---->|<-----SR-LSP------>|<-----SR-LSP----->|
Node:
|<----SID List---->|<-----SID List---->|<----SID List---->|
Node A Node X Node Y Node Z
+-------------+
|A->X SID list|
+-------------+ +-------------+
| B-SID(X->Y) | --->|X->Y SID list|
+-------------+ +-------------+ +-------------+
| B-SID(Y->Z) | | B-SID(Y->Z) | --->|Y->Z SID list|
+-------------+ +-------------+ +-------------+ +--------------+
|S-PSID(A->X) | |S-PSID(X->Y) | |S-PSID(Y->Z) | -->| Payload |
+-------------+ +-------------+ +-------------+ +--------------+
| Payload | | Payload | | Payload |
+-------------+ +-------------+ +-------------+
Figure 2: Stitching of Path Segments in Inter-Domain Scenario
4.2. Nesting of Path Segments
Figure 3 shows the SR-MPLS nesting inter-domain scenario. The
e-Path(A->Z) is used to indicate the end-to-end path. The N-PSID,
B-SID and SR list are pushed by the ingress node. The N-PSID is used
to correlate the two unidirectional SR paths to an SR bidirectional
path.
The use of the B-SID is also 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 N-PSID(A->Z),
B-SID(Y->Z), B-SID(X->Y), and A->X SID list in turn. When the packet
is received at node X, the X->Y SID list are popped. 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
Xiong, et al. Expires January 14, 2021 [Page 6]
Internet-DraThe Use of Path Segment in SR Inter-domain Scenar July 2020
according to the same forwarding procedure. In SR node Z, the N-PSID
(A->Z) is used to correlate the two unidirectional end-to-end paths.
.................. ................. ....................
. . . . . .
+-----+ +-----+ +-----+ +-----+
| A | | X | | Y | | Z |
+-----+ +-----+ +-----+ +-----+
. SR Domain 1 . . SR Domain 2 . . SR Domain 3 .
.................. ................. ....................
Service Layer:
|<----------------------End-to-end Service--------------->|
Path Segment:
|<------------------------N-PSID------------------------->|
LSP/Tunnel:
|<------SR-LSP---->o<-------SR-LSP----->o<-----SR-LSP---->|
Node:
|<----SID List---->|<-----SID List----->|<----SID List--->|
Node A Node X Node Y Node Z
+-------------+
|A->X SID list|
+-------------+ +-------------+
|B-SID(X->Y) | --> |X->Y SID list|
+-------------+ +-------------+ +-------------+
|B-SID(Y->Z) | |B-SID(Y->Z) | --> |Y->Z SID list|
+-------------+ +-------------+ +-------------+ +-------------+
|N-PSID(A->Z) | |N-PSID(A->Z) | |N-PSID(A->Z) | --> | Payload |
+-------------+ +-------------+ +-------------+ +-------------+
| Payload | | Payload | | Payload |
+-------------+ +-------------+ +-------------+
Figure 3: Nesting of Path Segments in Inter-Domain Scenario
5. Security Considerations
TBA
6. Acknowledgements
TBA
Xiong, et al. Expires January 14, 2021 [Page 7]
Internet-DraThe Use of Path Segment in SR Inter-domain Scenar July 2020
7. IANA Considerations
TBA
8. 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-02 (work in progress),
February 2020.
[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.
[I-D.xiong-pce-stateful-pce-sr-inter-domain]
Xiong, Q., Mirsky, G., hu, f., and W. Cheng, "Stateful PCE
for SR-MPLS Inter-domain", draft-xiong-pce-stateful-pce-
sr-inter-domain-02 (work in progress), October 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
Xiong, et al. Expires January 14, 2021 [Page 8]
Internet-DraThe Use of Path Segment in SR Inter-domain Scenar July 2020
Greg Mirsky
ZTE Corporation
USA
Email: gregimirsky@gmail.com
Weiqiang Cheng
China Mobile
Beijing
China
Email: chengweiqiang@chinamobile.com
Xiong, et al. Expires January 14, 2021 [Page 9]
