idnits 2.17.1 draft-ietf-spring-segment-routing-mpls-11.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 (October 27, 2017) is 2370 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) == Missing Reference: 'RFC8174' is mentioned on line 31, but not defined -- Looks like a reference, but probably isn't: '1000' on line 516 -- Looks like a reference, but probably isn't: '5000' on line 516 == Unused Reference: 'I-D.ietf-idr-segment-routing-te-policy' is defined on line 735, but no explicit reference was found in the text == Outdated reference: A later version (-15) exists of draft-ietf-spring-segment-routing-12 -- No information found for draft-ietf-isis- - is the name correct? -- No information found for draft-ietf-ospf-ospfv3- - is the name correct? -- No information found for draft-ietf-ospf-segment- - is the name correct? == Outdated reference: A later version (-15) exists of draft-ietf-spring-segment-routing-ldp-interop-08 Summary: 0 errors (**), 0 flaws (~~), 5 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group C. Filsfils, Ed. 2 Internet Draft S. Previdi, Ed. 3 Intended status: Standards Track A. Bashandy 4 Expires: April 2018 Cisco Systems, Inc. 5 B. Decraene 6 S. Litkowski 7 Orange 8 R. Shakir 9 Google 10 October 27, 2017 12 Segment Routing with MPLS data plane 13 draft-ietf-spring-segment-routing-mpls-11 15 Abstract 17 Segment Routing (SR) leverages the source routing paradigm. A node 18 steers a packet through a controlled set of instructions, called 19 segments, by prepending the packet with an SR header. In the MPLS 20 dataplane, the SR header is instantiated through a label stack. This 21 document specifies the forwarding behavior to allow instantiating SR 22 over the MPLS dataplane. 24 Requirements Language 26 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 27 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 28 "OPTIONAL" in this document are to be interpreted as described in BCP 29 14 [RFC2119] [RFC8174] when, and only when, they appear in all 30 capitals, as shown here. 32 Status of this Memo 34 This Internet-Draft is submitted in full conformance with the 35 provisions of BCP 78 and BCP 79. 37 Internet-Drafts are working documents of the Internet Engineering 38 Task Force (IETF). Note that other groups may also distribute 39 working documents as Internet-Drafts. The list of current Internet- 40 Drafts is at http://datatracker.ietf.org/drafts/current/. 42 Internet-Drafts are draft documents valid for a maximum of six months 43 and may be updated, replaced, or obsoleted by other documents at any 44 time. It is inappropriate to use Internet-Drafts as reference 45 material or to cite them other than as "work in progress." 47 This Internet-Draft will expire on April 27, 2009. 49 Copyright Notice 51 Copyright (c) 2017 IETF Trust and the persons identified as the 52 document authors. All rights reserved. 54 This document is subject to BCP 78 and the IETF Trust's Legal 55 Provisions Relating to IETF Documents 56 (http://trustee.ietf.org/license-info) in effect on the date of 57 publication of this document. Please review these documents 58 carefully, as they describe your rights and restrictions with respect 59 to this document. Code Components extracted from this document must 60 include Simplified BSD License text as described in Section 4.e of 61 the Trust Legal Provisions and are provided without warranty as 62 described in the Simplified BSD License. 64 Table of Contents 66 1. Introduction...................................................3 67 2. MPLS Instantiation of Segment Routing..........................3 68 2.1. Supporting Multiple Forwarding Behaviors for the Same Prefix 69 ...............................................................4 70 2.2. SID Representation in the MPLS Forwarding Plane...........4 71 2.3. Segment Routing Global Block and Local Block..............5 72 2.4. Mapping a SID Index to an MPLS label......................6 73 2.5. PUSH, CONTINUE, and NEXT..................................6 74 2.5.1. PUSH.................................................6 75 2.5.2. CONTINUE.............................................7 76 2.5.3. NEXT.................................................7 77 2.6. MPLS Label downloaded to FIB corresponding to Global and 78 Local SIDs.....................................................7 79 2.7. Active Segment............................................7 80 2.8. Forwarding behavior for Global SIDs.......................8 81 2.8.1. Forwarding Behavior for PUSH and CONTINUE Operation for 82 Global SIDs.................................................8 83 2.8.2. Forwarding Behavior for NEXT Operation for Global SIDs9 84 2.9. Forwarding Behavior for Local SIDs.......................10 85 2.9.1. Forwarding Behavior Corresponding to PUSH Operation on 86 Local SIDs.................................................10 87 2.9.2. Forwarding Behavior Corresponding to CONTINUE Operation 88 for Local SIDs.............................................10 89 2.9.3. Outgoing label for NEXT Operation for Local SIDs....11 91 3. IGP Segments Examples.........................................11 92 3.1. Example 1................................................12 93 3.2. Example 2................................................13 94 3.3. Example 3................................................14 95 3.4. Example 4................................................14 96 3.5. Example 5................................................14 97 4. IANA Considerations...........................................15 98 5. Manageability Considerations..................................15 99 6. Security Considerations.......................................15 100 7. Contributors..................................................15 101 8. Acknowledgements..............................................16 102 9. References....................................................16 103 9.1. Normative References.....................................16 104 9.2. Informative References...................................17 106 1. Introduction 108 The Segment Routing architecture [I-D.ietf-spring-segment-routing] 109 can be directly applied to the MPLS architecture with no change in 110 the MPLS forwarding plane. This document specifies the forwarding 111 plane behavior to allow Segment Routing to operate on top of the MPLS 112 data plane. This document does not address the control plane 113 behavior. Control plane behavior is specified in other documents such 114 as [I-D.ietf-isis-segment-routing-extensions], [I-D.ietf-ospf- 115 segment-routing-extensions], and [I-D.ietf-ospf-ospfv3-segment- 116 routing-extensions]. 118 The Segment Routing problem statement is described in [RFC7855]. 120 Co-existence of SR over MPLS forwarding plane with LDP [RFC5036] is 121 specified in [I-D.ietf-spring-segment-routing-ldp-interop]. 123 Policy routing and traffic engineering using segment routing can be 124 found in [I.D. filsfils-spring-segment-routing-policy] 126 2. MPLS Instantiation of Segment Routing 128 MPLS instantiation of Segment Routing fits in the MPLS architecture 129 as defined in [RFC3031] both from a control plane and forwarding 130 plane perspective: 132 o From a control plane perspective, [RFC3031] does not mandate a 133 single signaling protocol. Segment Routing makes use of various 134 control plane protocols such as link State IGPs [I-D.ietf-isis- 135 segment-routing-extensions], [I-D.ietf-ospf-segment-routing- 136 extensions] and [I-D.ietf-ospf-ospfv3-segment-routing-extensions]. 137 The flooding mechanisms of link state IGPs fits very well with 138 label stacking on ingress. Future control layer protocol and/or 139 policy/configuration can be used to specify the label stack. 141 o From a forwarding plane perspective, Segment Routing does not 142 require any change to the forwarding plane because Segment ID 143 (SIDs) are instantiated as MPLS labels and the Segment routing 144 header instantiated as a stack of MPLS labels. 146 We call "MPLS Control Plane Client (MCC)" any control plane entity 147 installing forwarding entries in the MPLS data plane. IGPs with SR 148 extensions [I-D.ietf-isis-segment-routing-extensions], [I-D.ietf- 149 ospf-segment-routing-extensions], [I-D.ietf-ospf-ospfv3-segment- 150 routing-extensions] and LDP [RFC5036] are examples of MCCs. Local 151 configuration and policies applied on a router are also examples of 152 MCCs. 154 2.1. Supporting Multiple Forwarding Behaviors for the Same Prefix 156 The SR architecture does not prohibit having more than one SID for 157 the same prefix. In fact, by allowing multiple SIDs for the same 158 prefix, it is possible to have different forwarding behaviors (such 159 as different paths, different ECMP/UCMP behaviors,...,etc) for the 160 same destination. 162 Instantiating Segment routing over the MPLS forwarding plane fits 163 seamlessly with this principle. An operator may assign multiple MPLS 164 labels or indices to the same prefix and assign different forwarding 165 behaviors to each label/SID. The MCC in the network downloads 166 different MPLS labels/SIDs to the FIB for different forwarding 167 behaviors. The MCC at the entry of an SR domain or at any point in 168 the domain can choose to apply a particular forwarding behavior to a 169 particular packet by applying the PUSH action to that packet using 170 the corresponding SID. 172 2.2. SID Representation in the MPLS Forwarding Plane 174 When instantiating SR over the MPLS forwarding plane, a SID is 175 represented by an MPLS label or an index [I-D.ietf-spring-segment- 176 routing]. 178 A global segment MUST be a label, or an index which may be mapped to 179 an MPLS label using the SRGB of the node installing the global 180 segment in its FIB/receiving the labeled packet. Section 2.4 181 specifies the procedure to map a global segment represented by an 182 index to an MPLS label within the SRGB. 184 The MCC MUST ensure that any label value corresponding to any SID it 185 installs in the forwarding plane follows the following rules: 187 o The label value MUST be unique within the router on which the MCC 188 is running. i.e. the label MUST only be used to represent the SID. 190 o The label value MUST NOT be identical to or within the range of 191 any reserved label value or range [reserved-MPLS], respectively. 193 2.3. Segment Routing Global Block and Local Block 195 The concepts of Segment Routing Global Block (SRGB) and global SID 196 are explained in [I-D.ietf-spring-segment-routing]. In general, the 197 SRGB need not be a contiguous range of labels. 199 For the rest of this document, the SRGB is specified by the list of 200 MPLS Label ranges [Ll(1),Lh(1)], [Ll(2),Lh(2)],..., [Ll(k),Lh(k)] 201 where Ll(i) =< Lh(i) and the ranges do not overlap. 203 The following rules apply to the list of MPLS ranges representing the 204 SRGB 206 o The list of label ranges MUST only be used to instantiate global 207 SIDs into the MPLS forwarding plane 209 o Every range in the list of ranges specifying the SRGB MUST NOT 210 cover or overlap with a reserved label value or range [reserved- 211 MPLS], respectively. 213 Local segments MAY be allocated from the Segment Routing Local Block 214 (SRLB) [I-D.ietf-spring-segment-routing] or from any unused label as 215 long as it does not use a reserved label. The SRLB consists of the 216 range of local labels reserved by the node for certain local 217 segments. In a controller-driven network, some controllers or 218 applications MAY use the control plane to discover the available set 219 of local SIDs on a particular router [I.D. filsfils-spring-segment- 220 routing-policy]. Just like SRGB, the SRLB need not be a single 221 contiguous range of label, except the SRGB MUST only be used to 222 instantiate global SIDs into the MPLS forwarding plane. Hence it is 223 specified the same way and follows the same rules SRGB is specified 224 above in this sub-section. 226 2.4. Mapping a SID Index to an MPLS label 228 This sub-section specifies how the MPLS label value is calculated 229 given the index of a SID. The value of the index is determined by an 230 MCC such as ISIS [I-D.ietf-isis-segment-routing-extensions] or OSPF 231 [I-D.ietf-ospf-segment-routing-extensions]. This section only 232 specifies how to map the index to an MPLS label. The calculated MPLS 233 label is downloaded to the FIB, sent out with a forwarded packet, or 234 both. 236 Consider a SID represented by the index "I". Consider an SRGB as 237 specified in Section 2.3. The total size of the SRGB, represented by 238 the variable "Size", is calculated according to the formula: 240 size = Lh(1)- Ll(1) + 1 + Ll(2)- Ll(2) + 1 + ... + Lh(k)- Ll(k) + 1 242 The following rules MUST be applied by the MCC when calculating the 243 MPLS label value corresponding the SID index value "I". 245 o 0 =< I < size. If the index "I" does not satisfy the previous 246 inequality, then the label cannot be calculated. 248 o The label value corresponding to the SID index "I" is calculated 249 as follows 251 o j = 1 , temp = 0 253 o While temp < I 255 . temp = temp + Lh(j)- Ll(j) + 1 257 . j = j+1 259 o label = I - temp + Ll(j) 261 2.5. PUSH, CONTINUE, and NEXT 263 PUSH, NEXT, and CONTINUE are operations applied by the forwarding 264 plan. The specifications of these operations can be found in [I- 265 D.ietf-spring-segment-routing]. This sub-section specifies how to 266 implement each of these operations in the MPLS forwarding plane. 268 2.5.1. PUSH 270 PUSH corresponds to pushing one or more labels on top of an incoming 271 packet then sending it out of a particular physical interface or 272 virtual interface, such as UDP tunnel [RFC7510] or L2TPv3 tunnel 274 [RFC4817], towards a particular next-hop. Sections 2.8 and 2.9. 275 specify additional details about forwarding behavior. 277 2.5.2. CONTINUE 279 In the MPLS forwarding plane, the CONTINUE operation corresponds to 280 swapping the incoming label with an outgoing label. The value of the 281 outgoing label is calculated as specified in Sections 2.8 and 2.9. 283 2.5.3. NEXT 285 In the MPLS forwarding plane, NEXT corresponds to popping the topmost 286 label. The action before and/or after the popping depends on the 287 instruction associated with the active SID on the received packet 288 prior to the popping. For example suppose the active SID in the 289 received packet was an Adj-SID [I-D.ietf-spring-segment-routing], 290 then on receiving the packet, the node applies NEXT operation, which 291 corresponds to popping the top most label, and then sends the packet 292 out of the physical or virtual interface (e.g. UDP tunnel [RFC7510] 293 or L2TPv3 tunnel [RFC4817]) towards the next-hop corresponding to the 294 adj-SID. 296 2.6. MPLS Label downloaded to FIB corresponding to Global and Local SIDs 298 The label corresponding to the global SID "Si" represented by the 299 global index "I" downloaded to FIB is used to match packets whose 300 active segment (and hence topmost label) is "Si". The value of this 301 label is calculated as specified in Section 2.4. 303 For Local SIDs, the MCC is responsible for downloading the correct 304 label value to FIB. For example, an IGP with SR extensions I-D.ietf- 305 isis-segment-routing-extensions, I-D.ietf-ospf-segment-routing- 306 extensions] allocates and downloads the MPLS label corresponding to 307 an IGP-adjacency-SID [I-D.ietf-spring-segment-routing]. 309 2.7. Active Segment 311 When instantiated in the MPLS domain, the active segment on a packet 312 corresponds to the topmost label on the packet that is calculated 313 according to the procedure specified in Sections 2.8 and 2.9. When 314 arriving at a node, the topmost label corresponding to the active SID 315 matches the MPLS label downloaded to FIB as specified in Section 2.6. 317 2.8. Forwarding behavior for Global SIDs 319 This section specifies forwarding behavior, including the outgoing 320 label(s) calculations corresponding to a global SID when applying 321 PUSH, CONTINUE, and NEXT operations in the MPLS forwarding plane. 323 This document covers the calculation of outgoing label for the top 324 label only. The case where outgoing label is not the top label and is 325 part of a stack of labels that instantiates a routing policy or a 326 traffic engineering tunnel is covered in other documents such as 327 [I.D.filsfils-spring-segment-routing-policy]. 329 2.8.1. Forwarding Behavior for PUSH and CONTINUE Operation for Global 330 SIDs 332 Suppose an MCC on a router "R0" determines that PUSH or CONTINUE 333 operation is to be applied to an incoming packet whose active SID is 334 the global SID "Si" represented by the global index "I" and owned by 335 the router Ri before sending the packet towards a neighbor "N" 336 directly connected to "R0" through a physical or virtual interface 337 such as UDP tunnel [RFC7510] or L2TPv3 tunnel [RFC4817]. 339 The method by which the MCC on router "R0" determines that PUSH or 340 CONTINUE operation must be applied using the SID "Si" is beyond the 341 scope of this document. An example of a method to determine the SID 342 "Si" for PUSH operation is the case where ISIS [I-D.ietf-isis- 343 segment-routing-extensions] receives the prefix-SID "Si" sub-TLV 344 advertised with prefix "P/m" in TLV 135 and the destination address 345 of the incoming IPv4 packet is covered by the prefix "P/m". 347 For CONTINUE operation, an example of a method to determine the SID 348 "Si" is the case where ISIS [I-D.ietf-isis-segment-routing- 349 extensions] receives the prefix-SID "Si" sub-TLV advertised with 350 prefix "P" in TLV 135 and the top label of the incoming packet 351 matches the MPLS label in FIB corresponding to the SID "Si" on the 352 router "R0". 354 The forwarding behavior for PUSH and CONTINUE corresponding to the 355 SID "Si" 357 o If the neighbor "N" does not support SR or "I" does not satisfy 358 the inequality specified in Section 2.4 for the SRGB of the 359 neighbor "N" 360 o If it is possible to send the packet towards the neighbor "N" 361 using standard MPLS forwarding behavior as specified in 362 {RFC3031] and [RFC3032], then forward the packet. The method 363 by which a router decides whether it is possible to send the 364 packet to "N" or not is beyond the scope of this document. For 365 example, the router "R0" can use the downstream label 366 determined by another MCC, such as LDP [RFC5036], to send the 367 packet. 369 o Else if there are other useable next-hops, then use other next- 370 hops to forward the incoming packet. The method by which the 371 router "R0" decides on the possibility of using other next- 372 hops is beyond the scope of this document. For example, the 373 MCC on "R0" may chose the send an IPv4 packet without pushing 374 any label to another next-hop. 376 o Otherwise drop the packet. 378 o Else 380 o Calculate the outgoing label as specified in Section 2.4 using 381 the SRGB of the neighbor "N" 383 o If the operation is PUSH 385 . Push the calculated label according the MPLS label 386 pushing rules specified in [RFC3032] 388 o Else 390 . swap the incoming label with the calculated label 391 according to the label swapping rules in [RFC3032] 393 o Send the packet towards the neighbor "N" 395 2.8.2. Forwarding Behavior for NEXT Operation for Global SIDs 397 As specified in Section 2.5.3 NEXT operation corresponds to popping 398 the top most label. The forwarding behavior is as follows 400 o Pop the topmost label 402 o Apply the instruction associated with the incoming label prior to 403 popping 405 The action on the packet after popping the topmost label depends on 406 the instruction associated with the incoming label as well as the 407 contents of the packet right underneath the top label that got 408 popped. Examples of NEXT operation are described in Section 3. 410 2.9. Forwarding Behavior for Local SIDs 412 This section specifies the forwarding behavior for local SIDs when SR 413 is instantiated over the MPLS forwarding plane. 415 2.9.1. Forwarding Behavior Corresponding to PUSH Operation on Local SIDs 417 Suppose an MCC on a router "R0" determines that PUSH operation is to 418 be applied to an incoming packet using the local SID "Si" before 419 sending the packet towards a neighbor "N" directly connected to R0 420 through a physical or virtual interface such as UDP tunnel [RFC7510] 421 or L2TPv3 tunnel [RFC4817]. 423 An example of such local SID is an IGP-Adj-SID allocated and 424 advertised by ISIS [I-D.ietf-isis-segment-routing-extensions]. The 425 method by which the MCC on "R0" determines that PUSH operation is to 426 be applied to the incoming packet is beyond the scope of this 427 document. An example of such method is backup path used to protect 428 against a failure using Ti-LFA [I.D.bashandy-rtgwg-segment-routing- 429 ti-lfa]. 431 As mentioned in [I-D.ietf-spring-segment-routing], a local SID is 432 specified by an MPLS label. Hence the PUSH operation for a local SID 433 is identical to label push operation [RFC3032] using any MPLS label. 434 The forwarding action after pushing the MPLS label corresponding to 435 the local SID is also determined by the MCC. For example, if the PUSH 436 operation was done to forward a packet over a backup path calculated 437 using Ti-LFA, then the forwarding action may be sending the packet to 438 a certain neighbor that will in turn continue to forward the packet 439 along the backup path 441 2.9.2. Forwarding Behavior Corresponding to CONTINUE Operation for Local 442 SIDs 444 A local SID on a router "R0" corresponds to a local label such as an 445 IGP adj-SID. In such scenario, the outgoing label towards a next-hop 446 "N" is determined by the MCC running on the router "R0"and the 447 forwarding behavior for CONTINUE operation is identical to swap 448 operation [RFC3032] on an MPLS label. 450 2.9.3. Outgoing label for NEXT Operation for Local SIDs 452 NEXT operation for Local SIDs is identical to NEXT operation for 453 global SIDs specified in Section 2.8.2. 455 3. IGP Segments Examples 457 Consider the network diagram of Figure 1 and the IP address and IGP 458 Segment allocation of Figure 2. Assume that the network is running 459 ISIS with SR extensions [I-D.ietf-isis-segment-routing-extensions]. 460 The following examples can be constructed. 462 +--------+ 463 / \ 464 R0-----R1-----R2----------R3-----R8 465 | \ / | 466 | +--R4--+ | 467 | | 468 +-----R5-----+ 470 Figure 1: IGP Segments - Illustration 472 +-----------------------------------------------------------+ 473 | IP address allocated by the operator: | 474 | 192.0.2.1/32 as a loopback of R1 | 475 | 192.0.2.2/32 as a loopback of R2 | 476 | 192.0.2.3/32 as a loopback of R3 | 477 | 192.0.2.4/32 as a loopback of R4 | 478 | 192.0.2.5/32 as a loopback of R5 | 479 | 192.0.2.8/32 as a loopback of R8 | 480 | 198.51.100.9/32 as an anycast loopback of R4 | 481 | 198.51.100.9/32 as an anycast loopback of R5 | 482 | | 483 | SRGB defined by the operator as 1000-5000 | 484 | | 485 | Global IGP SID indices allocated by the operator: | 486 | 1 allocated to 192.0.2.1/32 | 487 | 2 allocated to 192.0.2.2/32 | 488 | 3 allocated to 192.0.2.3/32 | 489 | 4 allocated to 192.0.2.4/32 | 490 | 8 allocated to 192.0.2.8/32 | 491 | 1009 allocated to 198.51.100.9/32 | 492 | | 493 | Local IGP SID allocated dynamically by R2 | 494 | for its "north" adjacency to R3: 9001 | 495 | for its "north" adjacency to R3: 9003 | 496 | for its "south" adjacency to R3: 9002 | 497 | for its "south" adjacency to R3: 9003 | 498 +-----------------------------------------------------------+ 500 Figure 2: IGP Address and Segment Allocation - Illustration 502 3.1. Example 1 504 Suppose R1 wants to send an IPv4 packet P1 to R8. In this case, R1 505 needs to apply PUSH operation to the IPv4 packet. 507 Remember that the SID index "8" is a global IGP segment attached to 508 the IP prefix 192.0.2.8/32. Its semantic is global within the IGP 509 domain: any router forwards a packet received with active segment 8 510 to the next-hop along the ECMP-aware shortest-path to the related 511 prefix. 513 R2 is the next-hop along the shortest path towards R8. By applying 514 the steps in Section 2.6 the local label downloaded to R1's FIB 515 corresponding to the global SID index 8 is 1008 because the SRGB of 516 R2 is [1000,5000] as shown in Figure 2. 518 Because the packet is IPv4, R1 applies the PUSH operation using the 519 label value 1008 as specified in 2.8.1. The resulting MPLS header 520 will have the "S" bit [RFC3032] set because it is followed directly 521 by an IPv4 packet. 523 The packet arrives at router R2. Because the top label 1008 524 corresponds to the IGP SID "8", which is the prefix-SID attached to 525 the prefix 192.0.2.8/32 owned by the R8, then the instruction 526 associated with the SID is "forward the packet using all ECMP/UCMP 527 interfaces and all ECMP/UCMP next-hop(s) along the shortest path 528 towards R8". Because R2 is not the penultimate hop, R2 applies the 529 CONTINUE operation to the packet and sends it to R3 using one of the 530 two links connected to R3 with top label 1008 as specified in Section 531 2.8.1. 533 R3 receives the packet with top label 1008. Because the top label 534 1008 corresponds to the IGP SID "8", which is the prefix-SID attached 535 to the prefix 192.0.2.8/32 owned by the R8, then the instruction 536 associated with the SID is "send the packet using all ECMP interfaces 537 and all next-hop(s) along the shortest path towards R8". Because R3 538 is the penultimate hop, R3 applies NEXT operation then sends the 539 packet to R8. The NEXT operation results in popping the outer label 540 and sending the packet as a pure IPv4 packet to R8. The 542 In conclusion, the path followed by P1 is R1-R2--R3-R8. The ECMP- 543 awareness ensures that the traffic be load-shared between any ECMP 544 path, in this case the two north and south links between R2 and R3. 546 3.2. Example 2 548 Suppose the right most router R0 wants to send a packet P2 to R8 over 549 the path . In that case, the 550 router R0 needs to use the SID list <2, 9001, 8>. Using the 551 calculation techniques specified in Section 2.8 and 2.9 the 552 resulting label stack starting from the topmost label is <1002, 9001, 553 1008>. 555 The MPLS label 1002 is the MPLS instantiation of the global IGP 556 segment index 2 attached to the IP prefix 192.0.2.2/32. Its semantic 557 is global within the IGP domain: any router forwards a packet 558 received with active segment 1002 to the next-hop along the shortest- 559 path to the related prefix. 561 The MPLS label 9001 is a local IGP segment attached by node R2 to its 562 north link to R3. Its semantic is local to node R2: R2 applies NEXT 563 operation, which corresponding to popping the outer label, then 564 switches a packet received with active segment 9001 towards the north 565 link to R3. 567 In conclusion, the path followed by P2 is R0-R1-R2-north-link-R3-R8. 569 3.3. Example 3 571 R0 may send a packet P3 along the same exact path as P2 using a 572 different segment list <2,9003,8> which corresponds to the label 573 stack <1002, 9003, 1008>. 575 9003 is a local IGP segment attached by node R2 to both its north and 576 south links to R3. Its semantic is local to node R2: R2 applies NEXT 577 operation, which corresponds to popping the top label, then switches 578 a packet received with active segment 9003 towards either the north 579 or south links to R3 (e.g. per-flow loadbalancing decision). 581 In conclusion, the path followed by P3 is R0-R1-R2-any-link-R3-R8. 583 3.4. Example 4 585 R0 may send a packet P4 to R8 while avoiding the links between R2 and 586 R3 by pushing the SID list <4,8>, which corresponds to the label 587 stack <1004, 1008>. 589 1004 is a global IGP segment attached to the IP prefix 192.0.2.4/32. 590 Its semantic is global within the IGP domain: any router forwards a 591 packet received with active segment 1004 to the next-hop along the 592 shortest-path to the related prefix. 594 In conclusion, the path followed by P4 is R0-R1-R2-R4-R3-R8. 596 3.5. Example 5 598 R0 may send a packet P5 to R8 while avoiding the links between R2 and 599 R3 and still benefiting from all the remaining shortest paths (via R4 600 and R5) by pushing the SID list <1009, 8> which corresponds to the 601 label stack <2009, 1008> using the steps specified in Sections 2.8 602 and 2.9. 604 1009 is a global anycast-SID [I-D.ietf-spring-segment-routing] 605 attached to the anycast IP prefix 198.51.100.9/32. Its semantic is 606 global within the IGP domain: any router forwards a packet received 607 with top label 2009 (corresponding to the active segment 1009) to the 608 next-hop along the shortest-path to the related prefix. 610 In conclusion, the path followed by P5 is either R0-R1-R2-R4-R3-R8 or 611 R0-R1-R2-R5-R3-R8. 613 4. IANA Considerations 615 This document does not make any request to IANA. 617 5. Manageability Considerations 619 This document describes the applicability of Segment Routing over the 620 MPLS data plane. Segment Routing does not introduce any change in 621 the MPLS data plane. Manageability considerations described in [I- 622 D.ietf-spring-segment-routing] applies to the MPLS data plane when 623 used with Segment Routing. 625 6. Security Considerations 627 This document does not introduce additional security requirements and 628 mechanisms other than the ones described in [I-D.ietf-spring-segment- 629 routing]. 631 7. Contributors 633 The following contributors have substantially helped the definition 634 and editing of the content of this document: 636 Martin Horneffer 637 Deutsche Telekom 638 Email: Martin.Horneffer@telekom.de 640 Wim Henderickx 641 Nokia 642 Email: wim.henderickx@nokia.com 644 Jeff Tantsura 645 Email: jefftant@gmail.com 646 Edward Crabbe 647 Email: edward.crabbe@gmail.com 649 Igor Milojevic 650 Email: milojevicigor@gmail.com 652 Saku Ytti 653 Email: saku@ytti.fi 655 8. Acknowledgements 657 The authors would like to thank Les Ginsberg and Shah Himanshu for 658 their comments on this document. 660 This document was prepared using 2-Word-v2.0.template.dot. 662 9. References 664 9.1. Normative References 666 [I-D.ietf-spring-segment-routing] Filsfils, C., Previdi, S., 667 Decraene, B., Litkowski, S., and R. Shakir, "Segment 668 Routing Architecture", draft-ietf-spring-segment-routing-12 669 (work in progress), June 2017. 671 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 672 Requirement Levels", BCP 14, RFC 2119, DOI 673 0.17487/RFC2119, March 1997, . 676 [RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol 677 Label Switching Architecture", RFC 3031, DOI 678 10.17487/RFC3031, January 2001, . 681 [RFC3032] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y., 682 Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack 683 Encoding", RFC 3032, DOI 10.17487/RFC3032, January 2001, 684 . 686 [reserved-MPLS] "Special-Purpose Multiprotocol Label Switching (MPLS) 687 Label Values", 690 9.2. Informative References 692 [I-D.ietf-isis-segment-routing-extensions] Previdi, S., Filsfils, C., 693 Bashandy, A., Gredler, H., Litkowski, S., Decraene, B., and 694 j. jefftant@gmail.com, "IS-IS Extensions for Segment 695 Routing", draft-ietf-isis- segment-routing-extensions-13 696 (work in progress), June 2017. 698 [I-D.ietf-ospf-ospfv3-segment-routing-extensions] Psenak, P., 699 Previdi, S., Filsfils, C., Gredler, H., Shakir, R., 700 Henderickx, W., and J. Tantsura, "OSPFv3 Extensions for 701 Segment Routing", draft-ietf-ospf-ospfv3- segment-routing- 702 extensions-09 (work in progress), March 2017. 704 [I-D.ietf-ospf-segment-routing-extensions] Psenak, P., Previdi, S., 705 Filsfils, C., Gredler, H., Shakir, R., Henderickx, W., and 706 J. Tantsura, "OSPF Extensions for Segment Routing", draft- 707 ietf-ospf-segment- routing-extensions-16 (work in 708 progress), May 2017. 710 [I-D.ietf-spring-segment-routing-ldp-interop] Filsfils, C., Previdi, 711 S., Bashandy, A., Decraene, B., and S. Litkowski, "Segment 712 Routing interworking with LDP", draft-ietf-spring-segment- 713 routing-ldp-interop-08 (work in progress), June 2017. 715 [RFC7855] Previdi, S., Ed., Filsfils, C., Ed., Decraene, B., 716 Litkowski, S., Horneffer, M., and R. Shakir, "Source Packet 717 Routing in Networking (SPRING) Problem Statement and 718 Requirements", RFC 7855, DOI 10.17487/RFC7855, May 2016, 719 . 721 [RFC5036] Andersson, L., Acreo, AB, Minei, I., Thomas, B., " LDP 722 Specification", RFC5036, DOI 10.17487/RFC5036, October 723 2007, 725 [RFC7510] Xu, X., Sheth, N., Yong, L., Callon, R., and D. Black, 726 "Encapsulating MPLS in UDP", RFC 7510, DOI 727 10.17487/RFC7510, April 2015, . 730 [RFC4817] Townsley, M., Pignataro, C., Wainner, S., Seely, T., Young, 731 T., "Encapsulation of MPLS over Layer 2 Tunneling Protocol 732 Version 3", RFC4817, DOI 10.17487/RFC4817, March 2007, 733 735 [I-D.ietf-idr-segment-routing-te-policy] Previdi, S., Filsfils, C., 736 Mattes, P., Rosen, E., Lin, S., " Advertising Segment 737 Routing Policies in BGP", draft- ietf-idr-segment-routing- 738 te-policy-00 (work in progress), July 2017 740 [I.D. filsfils-spring-segment-routing-policy] Filsfils, C., 741 Sivabalan, S., Raza, K., Liste, J. , Clad, F., Voyer, D., 742 Lin, S., Bogdanov, A., Horneffer, M., Steinberg, D., 743 Decraene, B. , Litkowski, S., " Segment Routing Policy for 744 Traffic Engineering", draft-filsfils-spring-segment- 745 routing-policy-01 (work in progress), July 2017 746 Authors' Addresses 748 Clarence Filsfils (editor) 749 Cisco Systems, Inc. 750 Brussels 751 BE 753 Email: cfilsfil@cisco.com 755 Stefano Previdi (editor) 756 Cisco Systems, Inc. 757 Italy 759 Email: stefano@previdi.net 761 Ahmed Bashandy 762 Cisco Systems, Inc. 763 170, West Tasman Drive 764 San Jose, CA 95134 765 US 767 Email: bashandy@cisco.com 769 Bruno Decraene 770 Orange 771 FR 773 Email: bruno.decraene@orange.com 775 Stephane Litkowski 776 Orange 777 FR 779 Email: stephane.litkowski@orange.com 781 Rob Shakir 782 Google 784 Email: robjs@google.com