idnits 2.17.1 draft-ietf-spring-segment-routing-mpls-08.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 (March 10, 2017) is 2602 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-11 == Outdated reference: A later version (-25) exists of draft-ietf-isis-segment-routing-extensions-11 == 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-12 == Outdated reference: A later version (-15) exists of draft-ietf-spring-segment-routing-ldp-interop-06 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: September 11, 2017 Cisco Systems, Inc. 6 B. Decraene 7 S. Litkowski 8 Orange 9 R. Shakir 10 Google 11 March 10, 2017 13 Segment Routing with MPLS data plane 14 draft-ietf-spring-segment-routing-mpls-08 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 September 11, 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 segment are encoded as a label. This implies that, in the 132 MPLS instantiation, the SID values are allocated within a reduced 133 20-bit 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 Contrary to RSVP-based explicit routes where tunnel midpoints 142 maintain states, SR-based explicit routes only require per-flow 143 states at the ingress edge router where the traffic engineer policy 144 is applied. 146 Contrary to RSVP-based explicit routes which consist in non-ECMP 147 circuits (similar to ATM/FR), SR-based explicit routes can be built 148 as list of ECMP-aware node segments and hence ECMP-aware traffic 149 engineering is natively supported by SR. 151 When Segment Routing is instantiated over the MPLS data plane the 152 following applies: 154 o A list of segments is represented as a stack of labels. 156 o The active segment is the top label. 158 o The CONTINUE operation (defined in 159 [I-D.ietf-spring-segment-routing]) is implemented as an MPLS swap 160 operation. The outgoing label value is computed as follows: 162 * When the same Segment Routing Global Block (SRGB, defined in 163 [I-D.ietf-spring-segment-routing] is used throughout the SR 164 domain, the outgoing label value is equal to the incoming label 165 value. 167 * When different SRGBs are used, the outgoing label value is set 168 as: [SRGB(next_hop)+index]. If the index can't be applied to 169 the SRGB (i.e.: if the index points outside the SRGB of the 170 next-hop or the next-hop has not advertised a valid SRGB), then 171 no outgoing label value can be computed and the next-hop MUST 172 be considered as not supporting the MPLS operations for that 173 particular SID. 175 * The index and the SRGB may be learned through different means. 176 Obviously, the SRGB MUST be the one the index is related to. 178 o The NEXT operation (defined in [I-D.ietf-spring-segment-routing]) 179 is implemented as an MPLS pop operation. The NEXT operation does 180 not require any mapping to an outgoing label hence the SRGB is 181 irrelevant for this operation. 183 o The PUSH operation (defined in [I-D.ietf-spring-segment-routing]) 184 is implemented as an MPLS push of a label stack. 186 o The Segment Routing Global Block (SRGB) values MUST be greater 187 than 15 in order to preserve values 0-15 as defined in [RFC3032]. 189 o As described in [I-D.ietf-spring-segment-routing], using the same 190 SRGB on all nodes within the SR domain eases operations and 191 troubleshooting and is expected to be a deployment guideline. 193 In conclusion, there are no changes in the operations of the data- 194 plane currently used in MPLS networks. 196 Note that the kind of deployment of Segment Routing may affect the 197 depth of the MPLS label stack. As every segment in the list is 198 represented by an additional MPLS label, the length of the segment 199 list directly correlates to the depth of the label stack. 200 Implementing a long path with many explicit hops as a segment list 201 may thus yield a deep label stack that would need to be pushed at the 202 head of the SR tunnel. 204 However, many use cases would need very few segments in the list. 205 This is especially true when taking good advantage of the ECMP aware 206 routing within each segment. In fact, most use cases need just one 207 additional segment and thus lead to a similar label stack depth as 208 e.g. RSVP-based routing. 210 Moreover, the use of the binding segment as specified in 211 [I-D.ietf-spring-segment-routing], also allows to substantially 212 reduce the length of the segment list and hence the depth of the 213 label stack. 215 Nodes will often have limits with respect to the label depth 216 supported for a PUSH operation. Two ways can be seen to deal with 217 this limitation: 219 When Segment Routing tunnels are computed by a centralized 220 controller, the controller can consider the Maximum SID depth 221 capability of a node as it may be signaled through routing 222 protocols extensions. 224 When Segment Routing tunnels are not computed by a centralized 225 controller but derived from an operator designed policy, the 226 operator needs to be aware of the limits of the used nodes and 227 take this into account in the design. 229 3. IGP Segments Examples 231 Assuming the network diagram of Figure 1 and the IP address and IGP 232 Segment allocation of Figure 2, the following examples can be 233 constructed. 235 +--------+ 236 / \ 237 R1-----R2----------R3-----R8 238 | \ / | 239 | +--R4--+ | 240 | | 241 +-----R5-----+ 243 Figure 1: IGP Segments - Illustration 245 +-----------------------------------------------------------+ 246 | IP address allocated by the operator: | 247 | 192.0.2.1/32 as a loopback of R1 | 248 | 192.0.2.2/32 as a loopback of R2 | 249 | 192.0.2.3/32 as a loopback of R3 | 250 | 192.0.2.4/32 as a loopback of R4 | 251 | 192.0.2.5/32 as a loopback of R5 | 252 | 192.0.2.8/32 as a loopback of R8 | 253 | 198.51.100.9/32 as an anycast loopback of R4 | 254 | 198.51.100.9/32 as an anycast loopback of R5 | 255 | | 256 | SRGB defined by the operator as 1000-5000 | 257 | | 258 | Global IGP SID allocated by the operator: | 259 | 1001 allocated to 192.0.2.1/32 | 260 | 1002 allocated to 192.0.2.2/32 | 261 | 1003 allocated to 192.0.2.3/32 | 262 | 1004 allocated to 192.0.2.4/32 | 263 | 1008 allocated to 192.0.2.8/32 | 264 | 2009 allocated to 198.51.100.9/32 | 265 | | 266 | Local IGP SID allocated dynamically by R2 | 267 | for its "north" adjacency to R3: 9001 | 268 | for its "north" adjacency to R3: 9003 | 269 | for its "south" adjacency to R3: 9002 | 270 | for its "south" adjacency to R3: 9003 | 271 +-----------------------------------------------------------+ 273 Figure 2: IGP Address and Segment Allocation - Illustration 275 3.1. Example 1 277 R1 may send a packet P1 to R8 simply by pushing an SR header with 278 segment list {1008}. 280 1008 is a global IGP segment attached to the IP prefix 192.0.2.8/32. 281 Its semantic is global within the IGP domain: any router forwards a 282 packet received with active segment 1008 to the next-hop along the 283 ECMP-aware shortest-path to the related prefix. 285 In conclusion, the path followed by P1 is R1-R2--R3-R8. The ECMP- 286 awareness ensures that the traffic be load-shared between any ECMP 287 path, in this case the two north and south links between R2 and R3. 289 3.2. Example 2 291 R1 may send a packet P2 to R8 by pushing an SR header with segment 292 list {1002, 9001, 1008}. 294 1002 is a global IGP segment attached to the IP prefix 192.0.2.2/32. 295 Its semantic is global within the IGP domain: any router forwards a 296 packet received with active segment 1002 to the next-hop along the 297 shortest-path to the related prefix. 299 9001 is a local IGP segment attached by node R2 to its north link to 300 R3. Its semantic is local to node R2: R2 switches a packet received 301 with active segment 9001 towards the north link to R3. 303 In conclusion, the path followed by P2 is R1-R2-north-link-R3-R8. 305 3.3. Example 3 307 R1 may send a packet P3 along the same exact path as P1 using a 308 different segment list {1002, 9003, 1008}. 310 9003 is a local IGP segment attached by node R2 to both its north and 311 south links to R3. Its semantic is local to node R2: R2 switches a 312 packet received with active segment 9003 towards either the north or 313 south links to R3 (e.g. per-flow loadbalancing decision). 315 In conclusion, the path followed by P3 is R1-R2-any-link-R3-R8. 317 3.4. Example 4 319 R1 may send a packet P4 to R8 while avoiding the links between R2 and 320 R3 by pushing an SR header with segment list {1004, 1008}. 322 1004 is a global IGP segment attached to the IP prefix 192.0.2.4/32. 323 Its semantic is global within the IGP domain: any router forwards a 324 packet received with active segment 1004 to the next-hop along the 325 shortest-path to the related prefix. 327 In conclusion, the path followed by P4 is R1-R2-R4-R3-R8. 329 3.5. Example 5 331 R1 may send a packet P5 to R8 while avoiding the links between R2 and 332 R3 while still beneficing from all the remaining shortest paths (via 333 R4 and R5) by pushing an SR header with segment list {2009, 1008}. 335 2009 is a global IGP segment attached to the anycast IP prefix 336 198.51.100.9/32. Its semantic is global within the IGP domain: any 337 router forwards a packet received with active segment 2009 to the 338 next-hop along the shortest-path to the related prefix. 340 In conclusion, the path followed by P5 is either R1-R2-R4-R3-R8 or 341 R1-R2-R5-R3-R8 . 343 4. IANA Considerations 345 This document does not make any request to IANA. 347 5. Manageability Considerations 349 This document describes the applicability of Segment Routing over the 350 MPLS data plane. Segment Routing does not introduce any change in 351 the MPLS data plane. Manageability considerations described in 352 [I-D.ietf-spring-segment-routing] applies to the MPLS data plane when 353 used with Segment Routing. 355 6. Security Considerations 357 This document does not introduce additional security requirements and 358 mechanisms other than the ones described in 359 [I-D.ietf-spring-segment-routing]. 361 7. Contributors 363 The following contributors have substantially helped the definition 364 and editing of the content of this document: 366 Martin Horneffer 367 Deutsche Telekom 368 Email: Martin.Horneffer@telekom.de 370 Wim Henderickx 371 Nokia 372 Email: wim.henderickx@nokia.com 374 Jeff Tantsura 375 Email: jefftant@gmail.com 376 Edward Crabbe 377 Email: edward.crabbe@gmail.com 379 Igor Milojevic 380 Email: milojevicigor@gmail.com 382 Saku Ytti 383 Email: saku@ytti.fi 385 8. Acknowledgements 387 The authors would like to thank Les Ginsberg and Shah Himanshu for 388 their comments on this document. 390 9. References 392 9.1. Normative References 394 [I-D.ietf-spring-segment-routing] 395 Filsfils, C., Previdi, S., Decraene, B., Litkowski, S., 396 and R. Shakir, "Segment Routing Architecture", draft-ietf- 397 spring-segment-routing-11 (work in progress), February 398 2017. 400 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 401 Requirement Levels", BCP 14, RFC 2119, 402 DOI 10.17487/RFC2119, March 1997, 403 . 405 [RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol 406 Label Switching Architecture", RFC 3031, 407 DOI 10.17487/RFC3031, January 2001, 408 . 410 [RFC3032] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y., 411 Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack 412 Encoding", RFC 3032, DOI 10.17487/RFC3032, January 2001, 413 . 415 9.2. Informative References 417 [I-D.ietf-isis-segment-routing-extensions] 418 Previdi, S., Filsfils, C., Bashandy, A., Gredler, H., 419 Litkowski, S., Decraene, B., and j. jefftant@gmail.com, 420 "IS-IS Extensions for Segment Routing", draft-ietf-isis- 421 segment-routing-extensions-11 (work in progress), March 422 2017. 424 [I-D.ietf-ospf-ospfv3-segment-routing-extensions] 425 Psenak, P., Previdi, S., Filsfils, C., Gredler, H., 426 Shakir, R., Henderickx, W., and J. Tantsura, "OSPFv3 427 Extensions for Segment Routing", draft-ietf-ospf-ospfv3- 428 segment-routing-extensions-09 (work in progress), March 429 2017. 431 [I-D.ietf-ospf-segment-routing-extensions] 432 Psenak, P., Previdi, S., Filsfils, C., Gredler, H., 433 Shakir, R., Henderickx, W., and J. Tantsura, "OSPF 434 Extensions for Segment Routing", draft-ietf-ospf-segment- 435 routing-extensions-12 (work in progress), March 2017. 437 [I-D.ietf-spring-segment-routing-ldp-interop] 438 Filsfils, C., Previdi, S., Bashandy, A., Decraene, B., and 439 S. Litkowski, "Segment Routing interworking with LDP", 440 draft-ietf-spring-segment-routing-ldp-interop-06 (work in 441 progress), February 2017. 443 [RFC7855] Previdi, S., Ed., Filsfils, C., Ed., Decraene, B., 444 Litkowski, S., Horneffer, M., and R. Shakir, "Source 445 Packet Routing in Networking (SPRING) Problem Statement 446 and Requirements", RFC 7855, DOI 10.17487/RFC7855, May 447 2016, . 449 Authors' Addresses 451 Clarence Filsfils (editor) 452 Cisco Systems, Inc. 453 Brussels 454 BE 456 Email: cfilsfil@cisco.com 458 Stefano Previdi (editor) 459 Cisco Systems, Inc. 460 Via Del Serafico, 200 461 Rome 00142 462 Italy 464 Email: sprevidi@cisco.com 465 Ahmed Bashandy 466 Cisco Systems, Inc. 467 170, West Tasman Drive 468 San Jose, CA 95134 469 US 471 Email: bashandy@cisco.com 473 Bruno Decraene 474 Orange 475 FR 477 Email: bruno.decraene@orange.com 479 Stephane Litkowski 480 Orange 481 FR 483 Email: stephane.litkowski@orange.com 485 Rob Shakir 486 Google 488 Email: robjs@google.com