idnits 2.17.1 draft-xiong-mpls-path-segment-sr-mpls-interworking-02.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 13, 2020) is 1377 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'I-D.xiong-spring-path-segment-sr-inter-domain' is defined on line 313, but no explicit reference was found in the text == Outdated reference: A later version (-22) exists of draft-ietf-spring-mpls-path-segment-02 == Outdated reference: A later version (-02) exists of draft-xiong-spring-path-segment-sr-inter-domain-01 Summary: 1 error (**), 0 flaws (~~), 5 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 MPLS Q. Xiong 3 Internet-Draft G. Mirsky 4 Intended status: Informational ZTE Corporation 5 Expires: January 14, 2021 W. Cheng 6 China Mobile 7 July 13, 2020 9 The Use of Path Segment in SR-MPLS and MPLS Interworking 10 draft-xiong-mpls-path-segment-sr-mpls-interworking-02 12 Abstract 14 This document illustrates the SR-MPLS and MPLS interworking scenarios 15 to support end-to-end bidirectional tunnel across multiple domains 16 with the use of Path Segments. 18 Status of This Memo 20 This Internet-Draft is submitted in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF). Note that other groups may also distribute 25 working documents as Internet-Drafts. The list of current Internet- 26 Drafts is at https://datatracker.ietf.org/drafts/current/. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 This Internet-Draft will expire on January 14, 2021. 35 Copyright Notice 37 Copyright (c) 2020 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents 42 (https://trustee.ietf.org/license-info) in effect on the date of 43 publication of this document. Please review these documents 44 carefully, as they describe your rights and restrictions with respect 45 to this document. Code Components extracted from this document must 46 include Simplified BSD License text as described in Section 4.e of 47 the Trust Legal Provisions and are provided without warranty as 48 described in the Simplified BSD License. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 53 2. Conventions used in this document . . . . . . . . . . . . . . 3 54 2.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 55 2.2. Requirements Language . . . . . . . . . . . . . . . . . . 4 56 3. SR-MPLS Interworking with MPLS . . . . . . . . . . . . . . . 4 57 3.1. Stitching of Path Segments . . . . . . . . . . . . . . . 5 58 3.2. Nesting of Path Segments . . . . . . . . . . . . . . . . 6 59 4. Security Considerations . . . . . . . . . . . . . . . . . . . 7 60 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 61 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 62 7. Normative References . . . . . . . . . . . . . . . . . . . . 8 63 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 65 1. Introduction 67 Segment Routing (SR) leverages the source routing paradigm. A node 68 steers a packet through an SR Policy instantiated as an ordered list 69 of instructions called "segments". SR supports a per-flow explicit 70 routing while maintaining per-flow state only at the ingress nodes of 71 the SR domain. Segment Routing can be instantiated on MPLS data 72 plane which is referred to as SR-MPLS [RFC8660]. SR-MPLS leverages 73 the MPLS label stack to construct the SR path. 75 IP/MPLS technology can be deployed in domains, which may serve as an 76 access, aggregation, or core network. Further, using SR 77 architecture, the IP/MPLS network may be upgraded to support the SR- 78 MPLS technology. As such transformation is performed incrementally, 79 by one domain at the time, operators are faced with a requirement to 80 support the interworking between MPLS and SR-MPLS networks at the 81 boundaries to provide the end-to-end bidirectional service. As 82 defined in [RFC8402], the headend of an SR Policy binds a Binding 83 Segment ID(B-SID) to its policy. The B-SID could be bound to a SID 84 List or selected path and used to stitch the SR list and the SR Label 85 Switched Paths (LSP) across multiple domains. The use of the B-SID 86 is recommended to reduce the size of the label stack and stitch the 87 SR LSPs. 89 In some scenarios, for example, a mobile backhaul transport network, 90 it is required to provide end-to-end bidirectional path across SR and 91 MPLS networks. The Path Segment as defined in 92 [I-D.ietf-spring-mpls-path-segment] can be used to support 93 bidirectional tunnel scenarios such as SR path Performance 94 Measurement (PM), end-to-end 1+1 SR path protection and bidirectional 95 SR paths correlation. 97 This document illustrates the SR-MPLS and MPLS interworking scenarios 98 to support end-to-end bidirectional tunnel across multiple domains 99 with the use of Path Segments. 101 2. Conventions used in this document 103 2.1. Terminology 105 ABR: Area Border Routers. Routers used to connect two IGP areas 106 (areas in OSPF or levels in IS-IS). 108 AS: Autonomous System. An Autonomous System is composed by one or 109 more IGP areas. 111 ASBR: Autonomous System Border Router. A router used to connect 112 together ASes of the same or different service providers via one or 113 more inter-AS links. 115 Border Node: An ABR that interconnects two or more IGP areas. 117 Border Link: Two ASes are interconnected with ASBRs. 119 B-SID: Binding Segment ID. 121 Domains: Autonomous System (AS) or IGP Area. An Autonomous System is 122 composed of one or more IGP areas. 124 e-PSID: end-to-end Path Segment. 126 IGP: Interior Gateway Protocol. 128 N-PSID: Nesting of Path Segments. 130 PM: Performance Measurement. 132 SID: Segment ID. 134 SR: Segment Routing. 136 SR-MPLS: Segment Routing with MPLS data plane. 138 S-PSID: Stitching of Path Segments. 140 VPN: Virtual Private Network. 142 2.2. Requirements Language 144 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 145 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 146 "OPTIONAL" in this document are to be interpreted as described in BCP 147 14 [RFC2119] [RFC8174] when, and only when, they appear in all 148 capitals, as shown here. 150 3. SR-MPLS Interworking with MPLS 152 It is required to establish the end-to-end Virtual Private Network 153 (VPN) service across the access network, aggregation network, and 154 core network. For example, SR-MPLS may be deployed in access and 155 core network, and MPLS may be deployed in the aggregation network. 156 The network interworking should be taken into account in deployment 157 are the following: 159 o Border Node or Border Link 161 o Stitching of Path Segments or Nesting of Path Segments 163 o End-to-end Path Monitoring 165 The domains of the networks may be IGP Areas or ASes. The SR-MPLS 166 and MPLS networks can be interconnected with a border node between 167 IGP areas or border links between ASes. MPLS domain can be deployed 168 between two SR-MPLS domains, as Figure 1 shows. The packets being 169 transmitted along the SR path in SR-MPLS domains by using the SID 170 list at the ingress node. And the path in MPLS domains can be pre- 171 configuration either via NMS or via the MPLS control plane signaling. 172 This document takes border node scenarios across IGP Areas domains 173 for example. The border link scenarios are in future discussion. 175 B E X 176 + + . . + + 177 + + . . + + 178 + + . . + + 179 A SR-MPLS C MPLS G SR-MPLS Z 180 + IGP 1 + . IGP 2 . + IGP 3 + 181 + + . . + + 182 + + . . + + 183 D F Y 185 |<---Access Network--->|<-Aggregation Network->|<----Core Network---->| 187 Figure 1: SR-MPLS and MPLS interworking Scenario 189 The VPN service across the SR-MPLS and MPLS domains is an end-to-end 190 bidirectional path. In the SR-MPLS network, a Path Segment uniquely 191 identifies an SR path and can be used for the end-to-end 192 bidirectional path. This document illustrates the end-to-end Path 193 Segment used in the interworking scenario including the stitching and 194 nesting models. As described in [I-D.ietf-spring-mpls-path-segment], 195 an end-to-end path segment or PSID (e-PSID), is also referred to as 196 Nesting of Path SID (N-PSID) in nesting model or Stitching of Path 197 SID (S-PSID) in stitching model. 199 3.1. Stitching of Path Segments 201 It is a common requirement that SR-MPLS needs to interwork with MPLS 202 when SR is incrementally deployed in the MPLS domain. Figure 2 shows 203 the stitching of Path Segments in SR-MPLS interworking with MPLS. 204 The SR-LSPs and IP/MPLS LSPs are established independently in each 205 domain which consist of SID list or MPLS label. The end-to-end 206 bidirectional path acrossing the SR-MPLS and MPLS networks is split 207 into multiple segments which can be identified by the S-PSID. The 208 end-to-end path is terminated at the egress node in egress domain. 209 The S-PSID will be popped out at the border node in each domain and 210 correlated to the S-PSID of next domain. 212 The correlation of S-PSIDs can bind the segments of end-to-end path. 213 The S-PSIDs are valid in the corresponding domain and the border 214 nodes maintain the forwarding entries of that S-PSID segment that 215 maps to the next S-PSID and the related path segments. In the 216 headend node, the S-PSID can correlate the inter-domain path of 217 reverse direction and bind the two unidirectional paths. The 218 stitching of Path Segments can support the end-to-end path stitching 219 and monitoring. 221 +-----------------+ ................ +-----------------+ 222 | +---+ | . +---+ . | +---+ | 223 | | B | | . | E | . | | X | | 224 | +---+ | . +---+ . | +---+ | 225 | / \ | . / \ . | / \ | 226 | +---+ SR-MPLS +-----+ MPLS +-----+ SR-MPLS +---+ | 227 | | A | domain1 | C | domain2 | G | domain3 | Z | | 228 | +---+ +-----+ +-----+ +---+ | 229 | \ / | . \ / . | \ / | 230 | +---+ | . +---+ . | +---+ | 231 | | D | | . | F | . | | Y | | 232 | +---+ | . +---+ . | +---+ | 233 +-----------------+ ................ +-----------------+ 235 Service Layer: 236 |<----------------------VPN Service---------------------->| 237 Path Segment: 238 |<-----S-PSID----->o<------S-PSID----->o<-----S-PSID----->| 239 LSP/Tunnel: 240 |<------SR-LSP---->|<---MPLS-LSP------>|<-----SR-LSP----->| 241 Node: 242 |<----SID List---->|<--- MPLS Label--->|<----SID List---->| 244 o Stitching 245 >|< Termination 246 -- Connection 247 S-PSID Stitching of Path Segments 249 Figure 2: Stitching of Path Segments in SR-MPLS and MPLS interworking 251 3.2. Nesting of Path Segments 253 Figure 3 displays the nesting of Path Segments in SR-MPLS and MPLS 254 interworking. The SR-LSPs and IP/MPLS LSPs are established in 255 respective domain which consist of SID list or MPLS label. The SR- 256 LSPs and IP/MPLS LSPs may be stitched across domains with B-SID. 257 Comparing with S-PSID in the stitching model, the N-PSID presents 258 end-to-end encapsulation in the packet from an SR-MPLS domain to an 259 MPLS domain which is encapsulated at the ingress nodes and 260 decapsulated at the egress nodes. The transit nodes, even the border 261 nodes of domains, are not aware of the N-PSID. 263 +-----------------+ ................ +-----------------+ 264 | +---+ | . +---+ . | +---+ | 265 | | B | | . | E | . | | X | | 266 | +---+ | . +---+ . | +---+ | 267 | / \ | . / \ . | / \ | 268 | +---+ SR-MPLS +-----+ MPLS +-----+ SR-MPLS +---+ | 269 | | A | domain1 | C | domain2 | G | domain3 | Z | | 270 | +---+ +-----+ +-----+ +---+ | 271 | \ / | . \ / . | \ / | 272 | +---+ | . +---+ . | +---+ | 273 | | D | | . | F | . | | Y | | 274 | +---+ | . +---+ . | +---+ | 275 +-----------------+ ................ +-----------------+ 277 Service Layer: 278 |<----------------------VPN Service---------------------->| 279 Path Segment: 280 |<------------------------N-PSID------------------------->| 281 LSP/Tunnel: 282 |<------SR-LSP---->o<-----MPLS-LSP----->o<-----SR-LSP---->| 283 Node: 284 |<----SID List---->|<----MPLS Label--->|<----SID List---->| 286 o Stitching 287 >|< Termination 288 -- Connection 289 N-PSID Nesting of Path Segments 291 Figure 3: Nesting of Path Segments in SR-MPLS and MPLS interworking 293 4. Security Considerations 295 TBA 297 5. Acknowledgements 299 TBA 301 6. IANA Considerations 303 TBA 305 7. Normative References 307 [I-D.ietf-spring-mpls-path-segment] 308 Cheng, W., Li, H., Chen, M., Gandhi, R., and R. Zigler, 309 "Path Segment in MPLS Based Segment Routing Network", 310 draft-ietf-spring-mpls-path-segment-02 (work in progress), 311 February 2020. 313 [I-D.xiong-spring-path-segment-sr-inter-domain] 314 Xiong, Q., Mirsky, G., and W. Cheng, "The Use of Path 315 Segment in SR Inter-domain Scenarios", draft-xiong-spring- 316 path-segment-sr-inter-domain-01 (work in progress), 317 October 2019. 319 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 320 Requirement Levels", BCP 14, RFC 2119, 321 DOI 10.17487/RFC2119, March 1997, 322 . 324 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 325 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 326 May 2017, . 328 [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., 329 Decraene, B., Litkowski, S., and R. Shakir, "Segment 330 Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, 331 July 2018, . 333 [RFC8660] Bashandy, A., Ed., Filsfils, C., Ed., Previdi, S., 334 Decraene, B., Litkowski, S., and R. Shakir, "Segment 335 Routing with the MPLS Data Plane", RFC 8660, 336 DOI 10.17487/RFC8660, December 2019, 337 . 339 Authors' Addresses 341 Quan Xiong 342 ZTE Corporation 343 No.6 Huashi Park Rd 344 Wuhan, Hubei 430223 345 China 347 Phone: +86 27 83531060 348 Email: xiong.quan@zte.com.cn 349 Greg Mirsky 350 ZTE Corporation 351 USA 353 Email: gregimirsky@gmail.com 355 Weiqiang Cheng 356 China Mobile 357 Beijing 358 China 360 Email: chengweiqiang@chinamobile.com