idnits 2.17.1 draft-xiong-mpls-path-segment-sr-mpls-interworking-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 4 instances of too long lines in the document, the longest one being 8 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (July 3, 2019) is 1752 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-22) exists of draft-ietf-spring-mpls-path-segment-00 Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 MPLS Quan Xiong 3 Internet-Draft Greg Mirsky 4 Intended status: Standards Track ZTE Corporation 5 Expires: January 4, 2020 Weiqiang Cheng 6 China Mobile 7 July 3, 2019 9 The Use of Path Segment in SR-MPLS and MPLS Interworking 10 draft-xiong-mpls-path-segment-sr-mpls-interworking-00 12 Abstract 14 This document discusses the SR-MPLS and MPLS interworking scenarios 15 and proposes the solution with the use of Path Segment. 17 Status of This Memo 19 This Internet-Draft is submitted in full conformance with the 20 provisions of BCP 78 and BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF). Note that other groups may also distribute 24 working documents as Internet-Drafts. The list of current Internet- 25 Drafts is at https://datatracker.ietf.org/drafts/current/. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 This Internet-Draft will expire on January 4, 2020. 34 Copyright Notice 36 Copyright (c) 2019 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents 41 (https://trustee.ietf.org/license-info) in effect on the date of 42 publication of this document. Please review these documents 43 carefully, as they describe your rights and restrictions with respect 44 to this document. Code Components extracted from this document must 45 include Simplified BSD License text as described in Section 4.e of 46 the Trust Legal Provisions and are provided without warranty as 47 described in the Simplified BSD License. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 52 2. Conventions used in this document . . . . . . . . . . . . . . 2 53 2.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 54 2.2. Requirements Language . . . . . . . . . . . . . . . . . . 3 55 3. SR-MPLS Interworking with MPLS . . . . . . . . . . . . . . . 3 56 3.1. Stitching interworking with i-Path . . . . . . . . . . . 4 57 3.2. Nesting interworking with e-Path . . . . . . . . . . . . 5 58 4. Security Considerations . . . . . . . . . . . . . . . . . . . 6 59 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6 60 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 61 7. Normative References . . . . . . . . . . . . . . . . . . . . 6 62 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 64 1. Introduction 66 Segment Routing (SR) leverages the source routing paradigm. A node 67 steers a packet through a SR Policy instantiated as an ordered list 68 of instructions called "segments". SR supports per-flow explicit 69 routing while maintaining per-flow state only at the ingress nodes of 70 the SR domain. Segment Routing can be instantiated on MPLS data 71 plane which is referred to as SR-MPLS 72 [I-D.ietf-spring-segment-routing-mpls]. SR-MPLS leverages the MPLS 73 label stack to construct the SR path. 75 In some scenarios, for example, mobile backhaul transport network, it 76 is required to provide end-to-end bidirectional tunnel across 77 multiple domains. IP/MPLS technology can be deployed in these 78 domains which may be access network, aggregation network or core 79 network under the control of a single operator. With the SR 80 architecture, the IP/MPLS may be upgraded to support the SR-MPLS 81 technology. There are requirements to support the interworking 82 between MPLS and SR-MPLS neworks at the boundaries and provide end- 83 to-end bidirectional service. 85 [I-D.ietf-spring-mpls-path-segment] defined a Path Segment identifier 86 to support SR path PM, end-to-end 1+1 SR path protection and 87 bidirectional SR paths correlation. This document discusses the 88 interworking scenarios between SR-MPLS and MPLS networks and proposes 89 the solution with the use of Path Segment. 91 2. Conventions used in this document 92 2.1. Terminology 94 ABR: Area Border Routers. Routers used to connect two IGP areas 95 (areas in OSPF or levels in IS-IS). 97 AS: Autonomous System. An Autonomous System is composed by one or 98 more IGP area. 100 ASBR: Autonomous System Border Router. Router used to connect 101 together ASes of the same or different service providers via one or 102 more inter-AS links. 104 Border Node: Two IGP areas interconnects with an ABR. 106 Border Link: Two ASes interconnects with an ASBR. 108 Domains:Autonomous System (AS) or IGP Area. An Autonomous System is 109 composed by one or more IGP area. 111 e-Path: End-to-end Path segment. 113 IGP: Interior Gateway Protocol. 115 i-Path/i-PSID: Inter-domain Path Segment. 117 PM: Performance Measurement. 119 SR: Segment Routing. 121 SR-MPLS: Segment Routing with MPLS data plane. 123 s-Path: Sub-path Path Segment. 125 VPN: Virtual Private Network. 127 2.2. Requirements Language 129 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 130 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 131 "OPTIONAL" in this document are to be interpreted as described in BCP 132 14 [RFC2119] [RFC8174] when, and only when, they appear in all 133 capitals, as shown here. 135 3. SR-MPLS Interworking with MPLS 137 It is required to establish the end-to-end VPN service across the 138 access network, aggregation network and core network. For example, 139 SR-MPLS may be deployed in access and core network and MPLS may be 140 deployed in aggregation network. The network interworking should be 141 taken into account in deployment are the following: 143 o Border Node or Border Link 145 o Stitching Model or Nesting Model 147 o End-to-End OAM or Per-domain OAM 149 The domains of the networks may be IGP Areas or ASes. The SR-MPLS 150 and MPLS networks can be interconnect with border node between IGP 151 Areas or border link between ASes. This document takes IGP Areas 152 domains for example. MPLS domain can be deployed between two SR-MPLS 153 domains as Figure 1 shown. The packets being transmitted along the 154 SR path in SR-MPLS domains by using the SID list at the ingress node. 155 And the path in MPLS domains can be pre-configuration either via NMS 156 or via the MPLS control plane signaling. 158 B E X 159 + + . . + + 160 + + . . + + 161 + + . . + + 162 A SR-MPLS C MPLS G SR-MPLS Z 163 + IGP 1 + . IGP 2 . + IGP 3 + 164 + + . . + + 165 + + . . + + 166 D F Y 168 |<---Access Network--->|<-Aggregation Network->|<----Core Network---->| 170 Figure 1: SR-MPLS and MPLS interworking Scenario 172 The VPN service across the SR-MPLS and MPLS domains is an end-to-end 173 bidirectional path. In the SR-MPLS network, a Path Segment uniquely 174 identifies an SR path and can be used for bidirectional path. This 175 document proposed the solution of Path Segment used in interworking 176 scenario including the stitching and nesting models. 178 3.1. Stitching interworking with i-Path 180 It is a common requirement that SR-MPLS needs to interwork with MPLS 181 when SR is incrementally being deployed in the MPLS domain. Figure 2 182 shows the stitching model of SR-MPLS inter-working with MPLS. 184 The end-to-end bidirectional path acrossing the SR-MPLS and MPLS 185 network being split into multiple segments. And each segment can be 186 identified by an inter-domain path segment (i-Path or i-PSID) as 187 defined in draft-xiong-spring-path-segment-sr-inter-domain. The 188 i-Pathis valid in the corresponding domain and the border nodes 189 maintain the forwarding entries of that i-Path segment binding the 190 next i-Path and the related labels, e.g, SID list or MPLS labels. In 191 the headend node, the i-Path can correlate the inter-domain path of 192 reverse direction and bind the two unidirectional paths. 194 +-----------------+ ................ +-----------------+ 195 | +---+ | . +---+ . | +---+ | 196 | | B | | . | E | . | | X | | 197 | +---+ | . +---+ . | +---+ | 198 | / \ | . / \ . | / \ | 199 | +---+ SR-MPLS +-----+ MPLS +-----+ SR-MPLS +---+ | 200 | | A | domain1 | C | domain2 | G | domain3 | Z | | 201 | +---+ +-----+ +-----+ +---+ | 202 | \ / | . \ / . | \ / | 203 | +---+ | . +---+ . | +---+ | 204 | | D | | . | F | . | | Y | | 205 | +---+ | . +---+ . | +---+ | 206 +-----------------+ ................ +-----------------+ 208 |<----SID List---->|<--- MPLS Label--->|<----SID List---->| 209 |<-----i-Path----->|<------i-Path----->|<-----i-Path----->| 210 |<----------------------VPN Service---------------------->| 212 Figure 2: SR-MPLS and MPLS interworking with Path Segment 214 3.2. Nesting interworking with e-Path 216 Figure 3 displays the nesting model of SR-MPLS and MPLS interworking. 217 Compared with stitching model, the path segment presents end-to-end 218 encapsulation in the packet from SR-MPLS domain to MPLS domain. As 219 described in [I-D.ietf-spring-mpls-path-segment], an end-to-end path 220 segment, also referred to as e-Path, is used to indicate the end-to- 221 end path, and an s-Path is used to indicate the intra-domain path.The 222 e-Path is encapsulated at the ingress nodes and decapsulated at the 223 egress nodes. The transit nodes, even the border nodes of domains, 224 are not aware of the e-Path segment. The s-Path can be used as 225 stitching label to correlate the two domains. The use of the binding 226 SID [RFC8402] is also recommended to reduce the size of lable stack. 228 +-----------------+ ................ +-----------------+ 229 | +---+ | . +---+ . | +---+ | 230 | | B | | . | E | . | | X | | 231 | +---+ | . +---+ . | +---+ | 232 | / \ | . / \ . | / \ | 233 | +---+ SR-MPLS +-----+ MPLS +-----+ SR-MPLS +---+ | 234 | | A | domain1 | C | domain2 | G | domain3 | Z | | 235 | +---+ +-----+ +-----+ +---+ | 236 | \ / | . \ / . | \ / | 237 | +---+ | . +---+ . | +---+ | 238 | | D | | . | F | . | | Y | | 239 | +---+ | . +---+ . | +---+ | 240 +-----------------+ ................ +-----------------+ 242 |<----SID List---->|<-- MPLS Label-->|<----SID List---->| 243 |<-----s-Path----->|<------s-Path----->|<-----s-Path----->| 244 |<------------------------e-Path------------------------->| 245 |<----------------------VPN Service---------------------->| 247 Figure 3: Nesting SR-MPLS inter-working with MPLS 249 4. Security Considerations 251 TBA 253 5. Acknowledgements 255 TBA 257 6. IANA Considerations 259 TBA 261 7. Normative References 263 [I-D.ietf-spring-mpls-path-segment] 264 Cheng, W., Li, H., Chen, M., Gandhi, R., and R. Zigler, 265 "Path Segment in MPLS Based Segment Routing Network", 266 draft-ietf-spring-mpls-path-segment-00 (work in progress), 267 March 2019. 269 [I-D.ietf-spring-segment-routing-mpls] 270 Bashandy, A., Filsfils, C., Previdi, S., Decraene, B., 271 Litkowski, S., and R. Shakir, "Segment Routing with MPLS 272 data plane", draft-ietf-spring-segment-routing-mpls-22 273 (work in progress), May 2019. 275 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 276 Requirement Levels", BCP 14, RFC 2119, 277 DOI 10.17487/RFC2119, March 1997, 278 . 280 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 281 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 282 May 2017, . 284 [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., 285 Decraene, B., Litkowski, S., and R. Shakir, "Segment 286 Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, 287 July 2018, . 289 Authors' Addresses 291 Quan Xiong 292 ZTE Corporation 293 No.6 Huashi Park Rd 294 Wuhan, Hubei 430223 295 China 297 Phone: +86 27 83531060 298 Email: xiong.quan@zte.com.cn 300 Greg Mirsky 301 ZTE Corporation 302 USA 304 Email: gregimirsky@gmail.com 306 Weiqiang Cheng 307 China Mobile 308 Beijing 309 China 311 Email: chengweiqiang@chinamobile.com