idnits 2.17.1 draft-xu-mpls-unified-source-routing-instruction-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 : ---------------------------------------------------------------------------- No issues found here. 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 (June 28, 2017) is 2493 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) == Unused Reference: 'RFC4817' is defined on line 399, but no explicit reference was found in the text == Outdated reference: A later version (-26) exists of draft-ietf-6man-segment-routing-header-06 == Outdated reference: A later version (-12) exists of draft-ietf-mpls-spring-entropy-label-06 == Outdated reference: A later version (-09) exists of draft-ietf-ospf-encapsulation-cap-04 == Outdated reference: A later version (-27) exists of draft-ietf-ospf-segment-routing-extensions-17 == Outdated reference: A later version (-15) exists of draft-ietf-spring-segment-routing-ldp-interop-08 == Outdated reference: A later version (-22) exists of draft-ietf-spring-segment-routing-mpls-10 == Outdated reference: A later version (-13) exists of draft-xu-intarea-ip-in-udp-04 == Outdated reference: A later version (-03) exists of draft-xu-mpls-service-chaining-02 Summary: 0 errors (**), 0 flaws (~~), 11 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group X. Xu, Ed. 3 Internet-Draft S. Bryant, Ed. 4 Intended status: Standards Track Huawei 5 Expires: December 30, 2017 R. Raszuk 6 Bloomberg LP 7 U. Chunduri 8 Huawei 9 L. Contreras 10 Telefonica I+D 11 L. Jalil 12 Verizon 13 H. Assarpour 14 Broadcom 15 G. Van De Velde 16 Nokia 17 J. Tantsura 18 Individual 19 S. Ma 20 Juniper 21 June 28, 2017 23 Unified Source Routing Instruction using MPLS Label Stack 24 draft-xu-mpls-unified-source-routing-instruction-02 26 Abstract 28 MPLS-SPRING (a.k.a., MPLS Segment Routing) is an MPLS data plane- 29 based source routing paradigm in which a sender of a packet is 30 allowed to partially or completely specify the route the packet takes 31 through the network by imposing stacked MPLS labels to the packet. 32 MPLS-SPRING could be leveraged to realize a unified source routing 33 mechanism across MPLS, IPv4 and IPv6 data planes by using a unified 34 source routing instruction set while preserving backward 35 compatibility with MPLS-SPRING. 37 Status of This Memo 39 This Internet-Draft is submitted in full conformance with the 40 provisions of BCP 78 and BCP 79. 42 Internet-Drafts are working documents of the Internet Engineering 43 Task Force (IETF). Note that other groups may also distribute 44 working documents as Internet-Drafts. The list of current Internet- 45 Drafts is at http://datatracker.ietf.org/drafts/current/. 47 Internet-Drafts are draft documents valid for a maximum of six months 48 and may be updated, replaced, or obsoleted by other documents at any 49 time. It is inappropriate to use Internet-Drafts as reference 50 material or to cite them other than as "work in progress." 52 This Internet-Draft will expire on December 30, 2017. 54 Copyright Notice 56 Copyright (c) 2017 IETF Trust and the persons identified as the 57 document authors. All rights reserved. 59 This document is subject to BCP 78 and the IETF Trust's Legal 60 Provisions Relating to IETF Documents 61 (http://trustee.ietf.org/license-info) in effect on the date of 62 publication of this document. Please review these documents 63 carefully, as they describe your rights and restrictions with respect 64 to this document. Code Components extracted from this document must 65 include Simplified BSD License text as described in Section 4.e of 66 the Trust Legal Provisions and are provided without warranty as 67 described in the Simplified BSD License. 69 Table of Contents 71 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 72 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 73 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 74 3. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 4 75 4. Packet Forwarding Procedures . . . . . . . . . . . . . . . . 5 76 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 77 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 78 7. Security Considerations . . . . . . . . . . . . . . . . . . . 7 79 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 80 8.1. Normative References . . . . . . . . . . . . . . . . . . 8 81 8.2. Informative References . . . . . . . . . . . . . . . . . 8 82 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 84 1. Introduction 86 MPLS-SPRING [I-D.ietf-spring-segment-routing-mpls] (a.k.a., MPLS 87 Segment Routing) is an MPLS data plane-based source routing paradigm 88 in which a sender of a packet is allowed to partially or completely 89 specify the route the packet takes through the network by imposing 90 stacked MPLS labels to the packet. MPLS-SPRING could be leveraged to 91 realize a unified source routing mechanism across MPLS, IPv4 and IPv6 92 data planes by using a unified source routing instruction set while 93 preserving backward compatibility with MPLS-SPRING. More 94 specifically, the source routing instruction set information 95 contained in a source routed packet could be uniformly encoded as an 96 MPLS label stack no matter the underlay is IPv4, IPv6 or MPLS. 98 Although the source routing instructions are encoded as MPLS labels, 99 this is a hardware convenience rather than an indication that the 100 whole MPLS protocol stack and in particular the MPLS control 101 protocols need to be deployed. Note that the complexity associated 102 with the whole MPLS protocol stack is largely due to the complex 103 control plane protocols. 105 The traditional IPv4 and IPv6 source routing mechanisms by use of 106 IPv4 Source Routing Options and IPv6 Route Header Type 0 Extension 107 respectively have been deprecated due to their obvious security 108 vulnerabilities. IPv6 SPRING (a.k.a., SRv6) 109 [I-D.ietf-6man-segment-routing-header] is a newly proposed IPv6 110 source routing mechanism in which the source route instruction 111 information is encoded as an ordered list of 128-bit long IPv6 112 addresses and contained in the Source Routing Header (SRH). Although 113 it has overcome the security vulnerability issues associated with the 114 traditional IPv6 source routing mechanism as claimed in 115 [I-D.ietf-6man-segment-routing-header], it still has the following 116 obvious drawbacks which need to be addressed: 1) the encapsulation 117 overhead is significant especially when the list of the explicit 118 routing hops is very long; 2) for those transit IPv6 routers that 119 don't support the flow label-based load-balancing mechanism yet, the 120 ECMP load-balancing effect may be impacted seriously if they could 121 not recognize the SRH and therefore could not obtain the five tuple 122 of the source routed IPv6 packet; 3) it requires a totally new 123 forwarding logic on basis of the SRH and the forwarding performance 124 associated with the IPv6 SRH may still be a big concern for some 125 hardware platforms; 4) the SRH-based souring routing mechanism could 126 not be applied to IPv4 networks. 128 Section 3 describes various use cases for the unified source routing 129 instruction mechanism and Section 4 describes a typical application 130 scenario and how the packet forwarding happens. 132 1.1. Requirements Language 134 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 135 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 136 document are to be interpreted as described in RFC 2119 [RFC2119]. 138 2. Terminology 140 This memo makes use of the terms defined in [RFC3031] and 141 [I-D.ietf-spring-segment-routing-mpls]. 143 3. Use Cases 145 The unified source routing mechanism across IPv4, IPv6 and MPLS is 146 useful at least in the following use cases: 148 o Incremental deployment of the MPLS-SPRING technology 149 [I-D.xu-mpls-spring-islands-connection-over-ip]. Since there is 150 no need to run any other label distribution protocol (e.g., LDP, 151 see [I-D.ietf-spring-segment-routing-ldp-interop] for more 152 details.) on those non-MPLS-SPRING routers for incremental 153 deployment purposes, the network provisioning is greatly 154 simplified, which is one of the major claimed benefits of the 155 MPLS-SPRING technology (i.e., running a single protocol). In 156 fact, this unified source routing mechanism is even useful in a 157 fully upgraded MPLS-SPRING network since the headache associated 158 with the MPLS-SPRING load-balancing as described in 159 [I-D.ietf-mpls-spring-entropy-label] can now be avoided by using 160 the MPLS-in-UDP encapsulation [RFC7510] where the source port of 161 the UDP tunnel header is used as an entropy field. 163 o A poor man's light-weight alternative to SRv6 164 [I-D.ietf-6man-segment-routing-header]. At least, it could be 165 deployed as an interim until full featured SRv6 is available on 166 more platforms. Since the Source Routing Header (SRH) 167 [I-D.ietf-6man-segment-routing-header] consisting of an ordered 168 list of 128-bit long IPv6 addresses is now replaced by an ordered 169 list of 32-bit long label entries (i.e., label stack), the 170 encapsulation overhead and forwarding performance issues 171 associated with SRv6 are eliminated. 173 o A new IPv4 source routing mechanism which has overcome the 174 security vulnerability issues associated with the traditional IPv4 175 source routing mechanism. 177 o Traffic Engineering scenarios where only a few routers (e.g., the 178 entry and exit nodes of each plane in the dual-plane network ) are 179 specified as segments of explicit paths. In this way, only a few 180 routers are required to support the MPLS-SPRING capability while 181 all the other routers just need to support IP forwarding 182 capability, which would significantly reduce the deployment cost 183 of this new technology. 185 o MPLS-based Service Function Chaining (SFC) 186 [I-D.xu-mpls-service-chaining]. Based on the unified source 187 routing mechanism as described in this document, only SFC-related 188 nodes including Service Function Forwarders (SFF), Service 189 Functions (SF) and classifiers are required to recognize the SFC 190 encapsulation header in the MPLS label stack form, while the 191 intermediate routers just need to support vanilla IP forwarding 192 (either IPv4 or IPv6). In other words, it undoubtedly complies 193 with the transport-independence requirement as listed in the SFC 194 architecture document [RFC7665]. 196 4. Packet Forwarding Procedures 198 +-----+ +-----+ +-----+ +-----+ +-----+ 199 | A +-------+ B +-------+ C +--------+ D +--------+ H | 200 +-----+ +--+--+ +--+--+ +--+--+ +-----+ 201 | | | 202 | | | 203 +--+--+ +--+--+ +--+--+ 204 | E +-------+ F +--------+ G | 205 +-----+ +-----+ +-----+ 207 +--------+ 208 |IP(A->E)| 209 +--------+ +--------+ 210 | L(G) | |IP(E->G)| 211 +--------+ +--------+ +--------+ 212 | L(H) | | L(H) | |IP(G->H)| 213 +--------+ +--------+ +--------+ 214 | Packet | ---> | Packet | ---> | Packet | 215 +--------+ +--------+ +--------+ 216 Figure 1 218 As shown in Figure 1, Assume Router A, E, G and H are MPLS-SPRING- 219 capable routers while the remaining are only capable of forwarding IP 220 packets. Router A, E, G and H advertise their Segment Routing 221 related information via IS-IS or OSPF. Now assume router A wants to 222 send a given IP or MPLS packet via an explicit path of {E->G->H}, 223 router A would impose an MPLS label stack corresponding to that 224 explicit path on the received IP packet. Since there is no Label 225 Switching Path (LSP) towards router E, router A would replace the top 226 label indicating router E with an IP-based tunnel for MPLS (e.g., 227 MPLS-over-UDP [RFC7510] or MPLS-over-GRE [RFC4023]) towards router E 228 and then send it out. In other words, router A would pop the top 229 label and then encapsulate the MPLS packet with an IP-based tunnel 230 towards router E. When the IP-encapsulated MPLS packet arrives at 231 router E, router E would strip the IP-based tunnel header and then 232 process the decapsulated MPLS packet accordingly. Since there is no 233 LSP towards router G which is indicated by the current top label of 234 the decapsulated MPLS packet, router E would replace the current top 235 label with an IP-based tunnel towards router G and send it out. When 236 the packet arrives at router G, router G would strip the IP-based 237 tunnel header and then process the decapsulated MPLS packet. Since 238 there is no LSP towards router H, router G would replace the current 239 top label with an IP-based tunnel towards router H. Now the packet 240 encapsulated with the IP-based tunnel towards router H is exactly the 241 original packet that router A had intended to send towards router H. 242 If the packet is an MPLS packet, router G could use any IP-based 243 tunnel for MPLS (e.g., MPLS-over-UDP [RFC7510] or MPLS-over-GRE 244 [RFC4023]). If the packet is an IP packet, router G could use any IP 245 tunnel for IP (e.g., IP-in-UDP [I-D.xu-intarea-ip-in-udp] or GRE 246 [RFC2784]). That original IP or MPLS packet would be forwarded 247 towards router H via an IP-based tunnel. When the encapsulated 248 packet arrives at router H, router H would decapsulate it into the 249 original packet and then process it accordingly. 251 Note that in the above description, it's assumed that the label 252 associated with each prefix-SID advertised by the owner of the 253 prefix-SID is a Penultimate Hop Popping (PHP) label (e.g., the NP- 254 flag [I-D.ietf-ospf-segment-routing-extensions] associated with the 255 corresponding prefix SID is not set). Figure 2 demostrates the 256 packet walk in the case where the label associated with each prefix- 257 SID advertised by the owner of the prefix-SID is not a Penultimate 258 Hop Popping (PHP) label (e.g., the NP-flag 259 [I-D.ietf-ospf-segment-routing-extensions] associated with the 260 corresponding prefix SID is set). Although the above description is 261 based on the use of prefix-SIDs, the unified source routing 262 instruction approach is actually applicable to the use of adj-SIDs as 263 well. For instance, when the top label of a received MPLS packet 264 indicates an given adj-SID and the corresponding adjacent node to 265 that adj-SID is not MPLS-capable, the top label would be replaced by 266 an IP-based tunnel towards that adjacent node and then forwarded over 267 the correponding link indicated by that adj-SID. 269 +-----+ +-----+ +-----+ +-----+ +-----+ 270 | A +-------+ B +-------+ C +--------+ D +--------+ H | 271 +-----+ +--+--+ +--+--+ +--+--+ +-----+ 272 | | | 273 | | | 274 +--+--+ +--+--+ +--+--+ 275 | E +-------+ F +--------+ G | 276 +-----+ +-----+ +-----+ 278 +--------+ 279 |IP(A->E)| 280 +--------+ +--------+ 281 | L(E) | |IP(E->G)| 282 +--------+ +--------+ +--------+ 283 | L(G) | | L(G) | |IP(G->H)| 284 +--------+ +--------+ +--------+ 285 | L(H) | | L(H) | | L(H) | 286 +--------+ +--------+ +--------+ 287 | Packet | ---> | Packet | ---> | Packet | 288 +--------+ +--------+ +--------+ 289 Figure 2 291 Note that as for which tunnel encapsulation type should be used, it 292 could be manually specified on tunnel ingress routers or be learnt 293 from the tunnel egress routers' advertisements of its tunnel 294 encapsulation capability. How to advertise the tunnel encapsulation 295 capability using IS-IS or OSPF are specified in 296 [I-D.ietf-isis-encapsulation-cap] and 297 [I-D.ietf-ospf-encapsulation-cap] respectively. 299 5. Acknowledgements 301 Thanks Joel Halpern, Bruno Decraene and Loa Andersson for their 302 insightful comments on this draft. 304 6. IANA Considerations 306 No IANA action is required. 308 7. Security Considerations 310 TBD. 312 8. References 313 8.1. Normative References 315 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 316 Requirement Levels", BCP 14, RFC 2119, 317 DOI 10.17487/RFC2119, March 1997, 318 . 320 8.2. Informative References 322 [I-D.ietf-6man-segment-routing-header] 323 Previdi, S., Filsfils, C., Raza, K., Leddy, J., Field, B., 324 daniel.voyer@bell.ca, d., daniel.bernier@bell.ca, d., 325 Matsushima, S., Leung, I., Linkova, J., Aries, E., Kosugi, 326 T., Vyncke, E., Lebrun, D., Steinberg, D., and R. Raszuk, 327 "IPv6 Segment Routing Header (SRH)", draft-ietf-6man- 328 segment-routing-header-06 (work in progress), March 2017. 330 [I-D.ietf-isis-encapsulation-cap] 331 Xu, X., Decraene, B., Raszuk, R., Chunduri, U., Contreras, 332 L., and L. Jalil, "Advertising Tunnelling Capability in 333 IS-IS", draft-ietf-isis-encapsulation-cap-01 (work in 334 progress), April 2017. 336 [I-D.ietf-mpls-spring-entropy-label] 337 Kini, S., Kompella, K., Sivabalan, S., Litkowski, S., 338 Shakir, R., and j. jefftant@gmail.com, "Entropy label for 339 SPRING tunnels", draft-ietf-mpls-spring-entropy-label-06 340 (work in progress), May 2017. 342 [I-D.ietf-ospf-encapsulation-cap] 343 Xu, X., Decraene, B., Raszuk, R., Contreras, L., and L. 344 Jalil, "Advertising Tunneling Capability in OSPF", draft- 345 ietf-ospf-encapsulation-cap-04 (work in progress), June 346 2017. 348 [I-D.ietf-ospf-segment-routing-extensions] 349 Psenak, P., Previdi, S., Filsfils, C., Gredler, H., 350 Shakir, R., Henderickx, W., and J. Tantsura, "OSPF 351 Extensions for Segment Routing", draft-ietf-ospf-segment- 352 routing-extensions-17 (work in progress), June 2017. 354 [I-D.ietf-spring-segment-routing-ldp-interop] 355 Filsfils, C., Previdi, S., Bashandy, A., Decraene, B., and 356 S. Litkowski, "Segment Routing interworking with LDP", 357 draft-ietf-spring-segment-routing-ldp-interop-08 (work in 358 progress), June 2017. 360 [I-D.ietf-spring-segment-routing-mpls] 361 Filsfils, C., Previdi, S., Bashandy, A., Decraene, B., 362 Litkowski, S., and R. Shakir, "Segment Routing with MPLS 363 data plane", draft-ietf-spring-segment-routing-mpls-10 364 (work in progress), June 2017. 366 [I-D.xu-intarea-ip-in-udp] 367 Xu, X., Lee, Y., and F. Yongbing, "Encapsulating IP in 368 UDP", draft-xu-intarea-ip-in-udp-04 (work in progress), 369 December 2016. 371 [I-D.xu-mpls-service-chaining] 372 Xu, X., Bryant, S., Assarpour, H., Shah, H., Contreras, 373 L., daniel.bernier@bell.ca, d., jefftant@gmail.com, j., 374 and S. Ma, "Service Chaining using an Unified Source 375 Routing Instruction", draft-xu-mpls-service-chaining-02 376 (work in progress), May 2017. 378 [I-D.xu-mpls-spring-islands-connection-over-ip] 379 Xu, X., Raszuk, R., Chunduri, U., Contreras, L., and L. 380 Jalil, "Connecting MPLS-SPRING Islands over IP Networks", 381 draft-xu-mpls-spring-islands-connection-over-ip-00 (work 382 in progress), October 2016. 384 [RFC2784] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P. 385 Traina, "Generic Routing Encapsulation (GRE)", RFC 2784, 386 DOI 10.17487/RFC2784, March 2000, 387 . 389 [RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol 390 Label Switching Architecture", RFC 3031, 391 DOI 10.17487/RFC3031, January 2001, 392 . 394 [RFC4023] Worster, T., Rekhter, Y., and E. Rosen, Ed., 395 "Encapsulating MPLS in IP or Generic Routing Encapsulation 396 (GRE)", RFC 4023, DOI 10.17487/RFC4023, March 2005, 397 . 399 [RFC4817] Townsley, M., Pignataro, C., Wainner, S., Seely, T., and 400 J. Young, "Encapsulation of MPLS over Layer 2 Tunneling 401 Protocol Version 3", RFC 4817, DOI 10.17487/RFC4817, March 402 2007, . 404 [RFC7510] Xu, X., Sheth, N., Yong, L., Callon, R., and D. Black, 405 "Encapsulating MPLS in UDP", RFC 7510, 406 DOI 10.17487/RFC7510, April 2015, 407 . 409 [RFC7665] Halpern, J., Ed. and C. Pignataro, Ed., "Service Function 410 Chaining (SFC) Architecture", RFC 7665, 411 DOI 10.17487/RFC7665, October 2015, 412 . 414 Authors' Addresses 416 Xiaohu Xu (editor) 417 Huawei 419 Email: xuxiaohu@huawei.com 421 Stewart Bryant (editor) 422 Huawei 424 Email: stewart.bryant@gmail.com 426 Robert Raszuk 427 Bloomberg LP 429 Email: robert@raszuk.net 431 Uma Chunduri 432 Huawei 434 Email: uma.chunduri@gmail.com 436 Luis M. Contreras 437 Telefonica I+D 439 Email: luismiguel.contrerasmurillo@telefonica.com 441 Luay Jalil 442 Verizon 444 Email: luay.jalil@verizon.com 446 Hamid Assarpour 447 Broadcom 449 Email: hamid.assarpour@broadcom.com 450 Gunter Van De Velde 451 Nokia 452 Antwerp 453 Belgium 455 Email: gunter.van_de_velde@nokia.com 457 Jeff Tantsura 458 Individual 460 Email: jefftant.ietf@gmail.com 462 Shaowen Ma 463 Juniper 465 Email: mashao@juniper.net