| 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
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.
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 (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 the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
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.
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.
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.
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 s-Path are encapsulated and decapsualted in the border nodes of its domain.
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.
.................. ................. ....................
. . . . . .
. . . . . .
+-----+ +-----+ +-----+ +-----+
| 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
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 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
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), 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
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 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.
................................ .................................. . . . . .+---+ +---+ +---+ . . +---+ +---+ +----+ . .| 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: