idnits 2.17.1 draft-ietf-spring-segment-routing-mpls-10.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 : ---------------------------------------------------------------------------- -- The document has examples using IPv4 documentation addresses according to RFC6890, but does not use any IPv6 documentation addresses. Maybe there should be IPv6 examples, too? Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (June 22, 2017) is 2500 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 (-15) exists of draft-ietf-spring-segment-routing-12 == Outdated reference: A later version (-25) exists of draft-ietf-isis-segment-routing-extensions-13 == Outdated reference: A later version (-23) exists of draft-ietf-ospf-ospfv3-segment-routing-extensions-09 == Outdated reference: A later version (-27) exists of draft-ietf-ospf-segment-routing-extensions-16 == Outdated reference: A later version (-15) exists of draft-ietf-spring-segment-routing-ldp-interop-08 Summary: 0 errors (**), 0 flaws (~~), 6 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group C. Filsfils, Ed. 3 Internet-Draft S. Previdi, Ed. 4 Intended status: Standards Track A. Bashandy 5 Expires: December 24, 2017 Cisco Systems, Inc. 6 B. Decraene 7 S. Litkowski 8 Orange 9 R. Shakir 10 Google 11 June 22, 2017 13 Segment Routing with MPLS data plane 14 draft-ietf-spring-segment-routing-mpls-10 16 Abstract 18 Segment Routing (SR) leverages the source routing paradigm. A node 19 steers a packet through a controlled set of instructions, called 20 segments, by prepending the packet with an SR header. In the MPLS 21 dataplane, the SR header is instantiated through a label stack. A 22 segment can represent any instruction, topological or service-based. 23 Additional segments can be defined in the future. SR allows to 24 enforce a flow through any topological path and/or service chain 25 while maintaining per-flow state only at the ingress node to the SR 26 domain. 28 Segment Routing can be directly applied to the MPLS architecture with 29 no change in the forwarding plane. This drafts describes how Segment 30 Routing operates on top of the MPLS data plane. 32 Requirements Language 34 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 35 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 36 document are to be interpreted as described in RFC 2119 [RFC2119]. 38 Status of This Memo 40 This Internet-Draft is submitted in full conformance with the 41 provisions of BCP 78 and BCP 79. 43 Internet-Drafts are working documents of the Internet Engineering 44 Task Force (IETF). Note that other groups may also distribute 45 working documents as Internet-Drafts. The list of current Internet- 46 Drafts is at http://datatracker.ietf.org/drafts/current/. 48 Internet-Drafts are draft documents valid for a maximum of six months 49 and may be updated, replaced, or obsoleted by other documents at any 50 time. It is inappropriate to use Internet-Drafts as reference 51 material or to cite them other than as "work in progress." 53 This Internet-Draft will expire on December 24, 2017. 55 Copyright Notice 57 Copyright (c) 2017 IETF Trust and the persons identified as the 58 document authors. All rights reserved. 60 This document is subject to BCP 78 and the IETF Trust's Legal 61 Provisions Relating to IETF Documents 62 (http://trustee.ietf.org/license-info) in effect on the date of 63 publication of this document. Please review these documents 64 carefully, as they describe your rights and restrictions with respect 65 to this document. Code Components extracted from this document must 66 include Simplified BSD License text as described in Section 4.e of 67 the Trust Legal Provisions and are provided without warranty as 68 described in the Simplified BSD License. 70 Table of Contents 72 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 73 2. MPLS Instantiation of Segment Routing . . . . . . . . . . . . 3 74 3. IGP Segments Examples . . . . . . . . . . . . . . . . . . . . 5 75 3.1. Example 1 . . . . . . . . . . . . . . . . . . . . . . . . 6 76 3.2. Example 2 . . . . . . . . . . . . . . . . . . . . . . . . 7 77 3.3. Example 3 . . . . . . . . . . . . . . . . . . . . . . . . 7 78 3.4. Example 4 . . . . . . . . . . . . . . . . . . . . . . . . 7 79 3.5. Example 5 . . . . . . . . . . . . . . . . . . . . . . . . 8 80 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 81 5. Manageability Considerations . . . . . . . . . . . . . . . . 8 82 6. Security Considerations . . . . . . . . . . . . . . . . . . . 8 83 7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 8 84 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 85 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 86 9.1. Normative References . . . . . . . . . . . . . . . . . . 9 87 9.2. Informative References . . . . . . . . . . . . . . . . . 9 88 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 90 1. Introduction 92 The Segment Routing architecture [I-D.ietf-spring-segment-routing] 93 can be directly applied to the MPLS architecture with no change in 94 the MPLS forwarding plane. This drafts describes how Segment Routing 95 operates on top of the MPLS data plane. 97 The Segment Routing problem statement is described in [RFC7855]. 99 Link State protocol extensions for Segment Routing are described in 100 [I-D.ietf-isis-segment-routing-extensions], 101 [I-D.ietf-ospf-segment-routing-extensions] and 102 [I-D.ietf-ospf-ospfv3-segment-routing-extensions]. 104 Segment Routing, applied to the MPLS data plane, offers the ability 105 to tunnel services (VPN, VPLS, VPWS) from an ingress PE to an egress 106 PE, without any other protocol than ISIS or OSPF 107 ([I-D.ietf-isis-segment-routing-extensions] and 108 [I-D.ietf-ospf-segment-routing-extensions]). LDP and RSVP-TE 109 signaling protocols are not required. 111 Note that [I-D.ietf-spring-segment-routing-ldp-interop] documents SR 112 co-existence and interworking with other MPLS signaling protocols, if 113 present in the network during a migration, or in case of non- 114 homogeneous deployments. 116 2. MPLS Instantiation of Segment Routing 118 MPLS instantiation of Segment Routing fits in the MPLS architecture 119 as defined in [RFC3031] both from a control plane and forwarding 120 plane perspective: 122 o From a control plane perspective, [RFC3031] does not mandate a 123 single signaling protocol. Segment Routing makes use of Link 124 State IGPs since their flooding mechanism fits very well with 125 label stacking on ingress. 127 o From a forwarding plane perspective, Segment Routing does not 128 require any change to the forwarding plane. 130 When applied to MPLS, a Segment is a LSP and the 20 right-most bits 131 of the SID are encoded as a label. This implies that, in the MPLS 132 instantiation, the SID values are allocated within a reduced 20-bit 133 space out of the 32-bit SID space. 135 The notion of indexed global segment, defined in 136 [I-D.ietf-spring-segment-routing], fits the MPLS architecture 137 [RFC3031] as the absolute value allocated to any segment (global or 138 local) can be managed by a local allocation process (similarly to 139 other MPLS signaling protocols). 141 Local segments MAY be allocated from the SR Local Block (SRLB) which 142 consists of the range of local labels reserved by the node for local 143 segments. In a controller-driven network, some controllers or 144 applications MAY use the control plane to discover the available set 145 of local SIDs on a particular router. In such cases, the SRLB is 146 advertised in the control plane (e.g., using 147 [I-D.ietf-isis-segment-routing-extensions]). 149 Contrary to RSVP-based explicit routes where tunnel midpoints 150 maintain states, SR-based explicit routes only require per-flow 151 states at the ingress edge router where the traffic engineer policy 152 is applied. 154 Contrary to RSVP-based explicit routes which consist in non-ECMP 155 circuits (similar to ATM/FR), SR-based explicit routes can be built 156 as list of ECMP-aware node segments and hence ECMP-aware traffic 157 engineering is natively supported by SR. 159 When Segment Routing is instantiated over the MPLS data plane the 160 following applies: 162 o A list of segments is represented as a stack of labels. 164 o The active segment is the top label. 166 o The CONTINUE operation (defined in 167 [I-D.ietf-spring-segment-routing]) is implemented as an MPLS swap 168 operation. The outgoing label value is computed as follows: 170 * When the same Segment Routing Global Block (SRGB, defined in 171 [I-D.ietf-spring-segment-routing] is used throughout the SR 172 domain, the outgoing label value is equal to the incoming label 173 value. 175 * When different SRGBs are used, the outgoing label value is set 176 as: [SRGB(next_hop)+index]. If the index can't be applied to 177 the SRGB (i.e.: if the index points outside the SRGB of the 178 next-hop or the next-hop has not advertised a valid SRGB), then 179 no outgoing label value can be computed and the next-hop MUST 180 be considered as not supporting the MPLS operations for that 181 particular SID. 183 * The index and the SRGB may be learned through different means. 184 Obviously, the SRGB MUST be the one the index is related to. 186 o The NEXT operation (defined in [I-D.ietf-spring-segment-routing]) 187 is implemented as an MPLS pop operation. The NEXT operation does 188 not require any mapping to an outgoing label hence the SRGB is 189 irrelevant for this operation. 191 o The PUSH operation (defined in [I-D.ietf-spring-segment-routing]) 192 is implemented as an MPLS push of a label stack. 194 o The Segment Routing Global Block (SRGB) values MUST be greater 195 than 15 in order to preserve values 0-15 as defined in [RFC3032]. 197 o As described in [I-D.ietf-spring-segment-routing], using the same 198 SRGB on all nodes within the SR domain eases operations and 199 troubleshooting and is expected to be a deployment guideline. 201 In conclusion, there are no changes in the operations of the data- 202 plane currently used in MPLS networks. 204 Note that the kind of deployment of Segment Routing may affect the 205 depth of the MPLS label stack. As every segment in the list is 206 represented by an additional MPLS label, the length of the segment 207 list directly correlates to the depth of the label stack. 208 Implementing a long path with many explicit hops as a segment list 209 may thus yield a deep label stack that would need to be pushed at the 210 head of the SR tunnel. 212 However, many use cases would need very few segments in the list. 213 This is especially true when taking good advantage of the ECMP aware 214 routing within each segment. In fact, most use cases need just one 215 additional segment and thus lead to a similar label stack depth as 216 e.g. RSVP-based routing. 218 Moreover, the use of the binding segment as specified in 219 [I-D.ietf-spring-segment-routing], also allows to substantially 220 reduce the length of the segment list and hence the depth of the 221 label stack. 223 Nodes will often have limits with respect to the label depth 224 supported for a PUSH operation. Two ways can be seen to deal with 225 this limitation: 227 When Segment Routing tunnels are computed by a centralized 228 controller, the controller can consider the Maximum SID depth 229 capability of a node as it may be signaled through routing 230 protocols extensions. 232 When Segment Routing tunnels are not computed by a centralized 233 controller but derived from an operator designed policy, the 234 operator needs to be aware of the limits of the used nodes and 235 take this into account in the design. 237 3. IGP Segments Examples 239 Assuming the network diagram of Figure 1 and the IP address and IGP 240 Segment allocation of Figure 2, the following examples can be 241 constructed. 243 +--------+ 244 / \ 245 R1-----R2----------R3-----R8 246 | \ / | 247 | +--R4--+ | 248 | | 249 +-----R5-----+ 251 Figure 1: IGP Segments - Illustration 253 +-----------------------------------------------------------+ 254 | IP address allocated by the operator: | 255 | 192.0.2.1/32 as a loopback of R1 | 256 | 192.0.2.2/32 as a loopback of R2 | 257 | 192.0.2.3/32 as a loopback of R3 | 258 | 192.0.2.4/32 as a loopback of R4 | 259 | 192.0.2.5/32 as a loopback of R5 | 260 | 192.0.2.8/32 as a loopback of R8 | 261 | 198.51.100.9/32 as an anycast loopback of R4 | 262 | 198.51.100.9/32 as an anycast loopback of R5 | 263 | | 264 | SRGB defined by the operator as 1000-5000 | 265 | | 266 | Global IGP SID allocated by the operator: | 267 | 1001 allocated to 192.0.2.1/32 | 268 | 1002 allocated to 192.0.2.2/32 | 269 | 1003 allocated to 192.0.2.3/32 | 270 | 1004 allocated to 192.0.2.4/32 | 271 | 1008 allocated to 192.0.2.8/32 | 272 | 2009 allocated to 198.51.100.9/32 | 273 | | 274 | Local IGP SID allocated dynamically by R2 | 275 | for its "north" adjacency to R3: 9001 | 276 | for its "north" adjacency to R3: 9003 | 277 | for its "south" adjacency to R3: 9002 | 278 | for its "south" adjacency to R3: 9003 | 279 +-----------------------------------------------------------+ 281 Figure 2: IGP Address and Segment Allocation - Illustration 283 3.1. Example 1 285 R1 may send a packet P1 to R8 simply by pushing an SR header with 286 segment list {1008}. 288 1008 is a global IGP segment attached to the IP prefix 192.0.2.8/32. 289 Its semantic is global within the IGP domain: any router forwards a 290 packet received with active segment 1008 to the next-hop along the 291 ECMP-aware shortest-path to the related prefix. 293 In conclusion, the path followed by P1 is R1-R2--R3-R8. The ECMP- 294 awareness ensures that the traffic be load-shared between any ECMP 295 path, in this case the two north and south links between R2 and R3. 297 3.2. Example 2 299 R1 may send a packet P2 to R8 by pushing an SR header with segment 300 list {1002, 9001, 1008}. 302 1002 is a global IGP segment attached to the IP prefix 192.0.2.2/32. 303 Its semantic is global within the IGP domain: any router forwards a 304 packet received with active segment 1002 to the next-hop along the 305 shortest-path to the related prefix. 307 9001 is a local IGP segment attached by node R2 to its north link to 308 R3. Its semantic is local to node R2: R2 switches a packet received 309 with active segment 9001 towards the north link to R3. 311 In conclusion, the path followed by P2 is R1-R2-north-link-R3-R8. 313 3.3. Example 3 315 R1 may send a packet P3 along the same exact path as P1 using a 316 different segment list {1002, 9003, 1008}. 318 9003 is a local IGP segment attached by node R2 to both its north and 319 south links to R3. Its semantic is local to node R2: R2 switches a 320 packet received with active segment 9003 towards either the north or 321 south links to R3 (e.g. per-flow loadbalancing decision). 323 In conclusion, the path followed by P3 is R1-R2-any-link-R3-R8. 325 3.4. Example 4 327 R1 may send a packet P4 to R8 while avoiding the links between R2 and 328 R3 by pushing an SR header with segment list {1004, 1008}. 330 1004 is a global IGP segment attached to the IP prefix 192.0.2.4/32. 331 Its semantic is global within the IGP domain: any router forwards a 332 packet received with active segment 1004 to the next-hop along the 333 shortest-path to the related prefix. 335 In conclusion, the path followed by P4 is R1-R2-R4-R3-R8. 337 3.5. Example 5 339 R1 may send a packet P5 to R8 while avoiding the links between R2 and 340 R3 while still beneficing from all the remaining shortest paths (via 341 R4 and R5) by pushing an SR header with segment list {2009, 1008}. 343 2009 is a global IGP segment attached to the anycast IP prefix 344 198.51.100.9/32. Its semantic is global within the IGP domain: any 345 router forwards a packet received with active segment 2009 to the 346 next-hop along the shortest-path to the related prefix. 348 In conclusion, the path followed by P5 is either R1-R2-R4-R3-R8 or 349 R1-R2-R5-R3-R8 . 351 4. IANA Considerations 353 This document does not make any request to IANA. 355 5. Manageability Considerations 357 This document describes the applicability of Segment Routing over the 358 MPLS data plane. Segment Routing does not introduce any change in 359 the MPLS data plane. Manageability considerations described in 360 [I-D.ietf-spring-segment-routing] applies to the MPLS data plane when 361 used with Segment Routing. 363 6. Security Considerations 365 This document does not introduce additional security requirements and 366 mechanisms other than the ones described in 367 [I-D.ietf-spring-segment-routing]. 369 7. Contributors 371 The following contributors have substantially helped the definition 372 and editing of the content of this document: 374 Martin Horneffer 375 Deutsche Telekom 376 Email: Martin.Horneffer@telekom.de 378 Wim Henderickx 379 Nokia 380 Email: wim.henderickx@nokia.com 382 Jeff Tantsura 383 Email: jefftant@gmail.com 384 Edward Crabbe 385 Email: edward.crabbe@gmail.com 387 Igor Milojevic 388 Email: milojevicigor@gmail.com 390 Saku Ytti 391 Email: saku@ytti.fi 393 8. Acknowledgements 395 The authors would like to thank Les Ginsberg and Shah Himanshu for 396 their comments on this document. 398 9. References 400 9.1. Normative References 402 [I-D.ietf-spring-segment-routing] 403 Filsfils, C., Previdi, S., Decraene, B., Litkowski, S., 404 and R. Shakir, "Segment Routing Architecture", draft-ietf- 405 spring-segment-routing-12 (work in progress), June 2017. 407 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 408 Requirement Levels", BCP 14, RFC 2119, 409 DOI 10.17487/RFC2119, March 1997, 410 . 412 [RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol 413 Label Switching Architecture", RFC 3031, 414 DOI 10.17487/RFC3031, January 2001, 415 . 417 [RFC3032] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y., 418 Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack 419 Encoding", RFC 3032, DOI 10.17487/RFC3032, January 2001, 420 . 422 9.2. Informative References 424 [I-D.ietf-isis-segment-routing-extensions] 425 Previdi, S., Filsfils, C., Bashandy, A., Gredler, H., 426 Litkowski, S., Decraene, B., and j. jefftant@gmail.com, 427 "IS-IS Extensions for Segment Routing", draft-ietf-isis- 428 segment-routing-extensions-13 (work in progress), June 429 2017. 431 [I-D.ietf-ospf-ospfv3-segment-routing-extensions] 432 Psenak, P., Previdi, S., Filsfils, C., Gredler, H., 433 Shakir, R., Henderickx, W., and J. Tantsura, "OSPFv3 434 Extensions for Segment Routing", draft-ietf-ospf-ospfv3- 435 segment-routing-extensions-09 (work in progress), March 436 2017. 438 [I-D.ietf-ospf-segment-routing-extensions] 439 Psenak, P., Previdi, S., Filsfils, C., Gredler, H., 440 Shakir, R., Henderickx, W., and J. Tantsura, "OSPF 441 Extensions for Segment Routing", draft-ietf-ospf-segment- 442 routing-extensions-16 (work in progress), May 2017. 444 [I-D.ietf-spring-segment-routing-ldp-interop] 445 Filsfils, C., Previdi, S., Bashandy, A., Decraene, B., and 446 S. Litkowski, "Segment Routing interworking with LDP", 447 draft-ietf-spring-segment-routing-ldp-interop-08 (work in 448 progress), June 2017. 450 [RFC7855] Previdi, S., Ed., Filsfils, C., Ed., Decraene, B., 451 Litkowski, S., Horneffer, M., and R. Shakir, "Source 452 Packet Routing in Networking (SPRING) Problem Statement 453 and Requirements", RFC 7855, DOI 10.17487/RFC7855, May 454 2016, . 456 Authors' Addresses 458 Clarence Filsfils (editor) 459 Cisco Systems, Inc. 460 Brussels 461 BE 463 Email: cfilsfil@cisco.com 465 Stefano Previdi (editor) 466 Cisco Systems, Inc. 467 Italy 469 Email: stefano@previdi.net 470 Ahmed Bashandy 471 Cisco Systems, Inc. 472 170, West Tasman Drive 473 San Jose, CA 95134 474 US 476 Email: bashandy@cisco.com 478 Bruno Decraene 479 Orange 480 FR 482 Email: bruno.decraene@orange.com 484 Stephane Litkowski 485 Orange 486 FR 488 Email: stephane.litkowski@orange.com 490 Rob Shakir 491 Google 493 Email: robjs@google.com