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, . [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, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [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, . [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, . 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]