idnits 2.17.1 draft-ietf-spring-segment-routing-mpls-14.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 1 instance of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. -- 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 11, 2018) is 2143 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: '16000-17000' is mentioned on line 492, but not defined == Missing Reference: '20000-21000' is mentioned on line 494, but not defined -- Looks like a reference, but probably isn't: '1000' on line 794 -- Looks like a reference, but probably isn't: '5000' on line 794 == Missing Reference: 'I-D.ietf-spring-oam-usecase' is mentioned on line 902, but not defined == 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 (~~), 10 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group A. Bashandy, Ed. 2 Internet Draft Individual 3 Intended status: Standards Track C. Filsfils, Ed. 4 Expires: December 2018 S. Previdi, 5 Cisco Systems, Inc. 6 B. Decraene 7 S. Litkowski 8 Orange 9 R. Shakir 10 Google 11 June 11, 2018 13 Segment Routing with MPLS data plane 14 draft-ietf-spring-segment-routing-mpls-14 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. This 22 document specifies the forwarding behavior to allow instantiating SR 23 over the MPLS dataplane. 25 Status of this Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at http://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on December 11, 2018. 42 Copyright Notice 44 Copyright (c) 2018 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (http://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction...................................................3 60 1.1. Requirements Language.....................................3 61 2. MPLS Instantiation of Segment Routing..........................3 62 2.1. Multiple Forwarding Behaviors for the Same Prefix.........4 63 2.2. SID Representation in the MPLS Forwarding Plane...........4 64 2.3. Segment Routing Global Block and Local Block..............5 65 2.4. Mapping a SID Index to an MPLS label......................6 66 2.5. Incoming Label Collision..................................7 67 2.5.1. Tie-breaking Rules...................................8 68 2.5.2. Redistribution between Routing Protocol Instances...11 69 2.5.2.1. Illustration...................................11 70 2.5.2.2. Illustration 2.................................12 71 2.6. Outgoing Label Collision.................................12 72 2.7. PUSH, CONTINUE, and NEXT.................................12 73 2.7.1. PUSH................................................13 74 2.7.2. CONTINUE............................................13 75 2.7.3. NEXT................................................13 76 2.8. MPLS Label Downloaded to FIB for Global and Local SIDs...13 77 2.9. Active Segment...........................................13 78 2.10. Forwarding behavior for Global SIDs.....................14 79 2.10.1. Forwarding for PUSH and CONTINUE of Global SIDs....14 80 2.10.2. Forwarding for NEXT Operation for Global SIDs......15 81 2.11. Forwarding Behavior for Local SIDs......................16 82 2.11.1. Forwarding for PUSH Operation on Local SIDs........16 83 2.11.2. Forwarding for CONTINUE Operation for Local SIDs...16 84 2.11.3. Outgoing label for NEXT Operation for Local SIDs...16 85 3. IGP Segments Examples.........................................17 86 3.1. Example 1................................................18 87 3.2. Example 2................................................19 88 3.3. Example 3................................................20 89 3.4. Example 4................................................20 90 3.5. Example 5................................................20 91 4. IANA Considerations...........................................21 92 5. Manageability Considerations..................................21 93 6. Security Considerations.......................................21 94 7. Contributors..................................................21 95 8. Acknowledgements..............................................22 96 9. References....................................................22 97 9.1. Normative References.....................................22 98 9.2. Informative References...................................23 100 1. Introduction 102 The Segment Routing architecture [I-D.ietf-spring-segment-routing] 103 can be directly applied to the MPLS architecture with no change in 104 the MPLS forwarding plane. This document specifies the forwarding 105 plane behavior to allow Segment Routing to operate on top of the MPLS 106 data plane. This document does not address the control plane 107 behavior. Control plane behavior is specified in other documents such 108 as [I-D.ietf-isis-segment-routing-extensions], [I-D.ietf-ospf- 109 segment-routing-extensions], and [I-D.ietf-ospf-ospfv3-segment- 110 routing-extensions]. 112 The Segment Routing problem statement is described in [RFC7855]. 114 Co-existence of SR over MPLS forwarding plane with LDP [RFC5036] is 115 specified in [I-D.ietf-spring-segment-routing-ldp-interop]. 117 Policy routing and traffic engineering using segment routing can be 118 found in [I.D. filsfils-spring-segment-routing-policy] 120 1.1. Requirements Language 122 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 123 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 124 "OPTIONAL" in this document are to be interpreted as described in BCP 125 14 [RFC2119] [RFC8174] when, and only when, they appear in all 126 capitals, as shown here. 128 2. MPLS Instantiation of Segment Routing 130 MPLS instantiation of Segment Routing fits in the MPLS architecture 131 as defined in [RFC3031] both from a control plane and forwarding 132 plane perspective: 134 o From a control plane perspective, [RFC3031] does not mandate a 135 single signaling protocol. Segment Routing makes use of various 136 control plane protocols such as link state IGPs [I-D.ietf-isis- 137 segment-routing-extensions], [I-D.ietf-ospf-segment-routing- 138 extensions] and [I-D.ietf-ospf-ospfv3-segment-routing-extensions]. 139 The flooding mechanisms of link state IGPs fits very well with 140 label stacking on ingress. Future control layer protocol and/or 141 policy/configuration can be used to specify the label stack. 143 o From a forwarding plane perspective, Segment Routing does not 144 require any change to the forwarding plane because Segment IDs 145 (SIDs) are instantiated as MPLS labels and the Segment routing 146 header instantiated as a stack of MPLS labels. 148 We call "MPLS Control Plane Client (MCC)" any control plane entity 149 installing forwarding entries in the MPLS data plane. IGPs with SR 150 extensions [I-D.ietf-isis-segment-routing-extensions], [I-D.ietf- 151 ospf-segment-routing-extensions], [I-D.ietf-ospf-ospfv3-segment- 152 routing-extensions] and LDP [RFC5036] are examples of MCCs. Local 153 configuration and policies applied on a router are also examples of 154 MCCs. 156 2.1. Multiple Forwarding Behaviors for the Same Prefix 158 The SR architecture does not prohibit having more than one SID for 159 the same prefix. In fact, by allowing multiple SIDs for the same 160 prefix, it is possible to have different forwarding behaviors (such 161 as different paths, different ECMP/UCMP behaviors,...,etc) for the 162 same destination. 164 Instantiating Segment routing over the MPLS forwarding plane fits 165 seamlessly with this principle. An operator may assign multiple MPLS 166 labels or indices to the same prefix and assign different forwarding 167 behaviors to each label/SID. The MCC in the network downloads 168 different MPLS labels/SIDs to the FIB for different forwarding 169 behaviors. The MCC at the entry of an SR domain or at any point in 170 the domain can choose to apply a particular forwarding behavior to a 171 particular packet by applying the PUSH action to that packet using 172 the corresponding SID. 174 2.2. SID Representation in the MPLS Forwarding Plane 176 When instantiating SR over the MPLS forwarding plane, a SID is 177 represented by an MPLS label or an index [I-D.ietf-spring-segment- 178 routing]. 180 A global segment MUST be a label, or an index which may be mapped to 181 an MPLS label within the Segment Routing Global Block (SRGB) of the 182 node installing the global segment in its FIB/receiving the labeled 183 packet. Section 2.4 specifies the procedure to map a global segment 184 represented by an index to an MPLS label within the SRGB. 186 The MCC MUST ensure that any label value corresponding to any SID it 187 installs in the forwarding plane follows the following rules: 189 o The label value MUST be unique within the router on which the MCC 190 is running. i.e. the label MUST only be used to represent the SID 191 and MUST NOT be used to represent more than one SID or for any 192 other forwarding purpose on the router. 194 o The label value MUST NOT come from the range of special purpose 195 labels [RFC7274]. 197 2.3. Segment Routing Global Block and Local Block 199 The concepts of Segment Routing Global Block (SRGB) and global SID 200 are explained in [I-D.ietf-spring-segment-routing]. In general, the 201 SRGB need not be a contiguous range of labels. 203 For the rest of this document, the SRGB is specified by the list of 204 MPLS Label ranges [Ll(1),Lh(1)], [Ll(2),Lh(2)],..., [Ll(k),Lh(k)] 205 where Ll(i) =< Lh(i). 207 The following rules apply to the list of MPLS ranges representing the 208 SRGB 210 o The list of ranges comprising the SRGB MUST NOT overlap. 212 o Every range in the list of ranges specifying the SRGB MUST NOT 213 cover or overlap with a reserved label value or range [RFC7274], 214 respectively. 216 o If the SRGB of a node does not conform to the structure specified 217 in this section or to the previous two rules, then this SRGB MUST 218 be completely ignored by all routers in the routing domain and the 219 node MUST be treated as if it does not have an SRGB. 221 o The list of label ranges MUST only be used to instantiate global 222 SIDs into the MPLS forwarding plane 224 Local segments MAY be allocated from the Segment Routing Local Block 225 (SRLB) [I-D.ietf-spring-segment-routing] or from any unused label as 226 long as it does not use a special purpose label. The SRLB consists of 227 the range of local labels reserved by the node for certain local 228 segments. In a controller-driven network, some controllers or 229 applications MAY use the control plane to discover the available set 230 of local SIDs on a particular router [I.D. filsfils-spring-segment- 231 routing-policy]. Just like SRGB, the SRLB need not be a single 232 contiguous range of labels, except the SRGB MUST only be used to 233 instantiate global SIDs into the MPLS forwarding plane. Hence it is 234 specified the same way and follows the same rules SRGB is specified 235 above in this sub-section. 237 2.4. Mapping a SID Index to an MPLS label 239 This sub-section specifies how the MPLS label value is calculated 240 given the index of a SID. The value of the index is determined by an 241 MCC such as IS-IS [I-D.ietf-isis-segment-routing-extensions] or OSPF 242 [I-D.ietf-ospf-segment-routing-extensions]. This section only 243 specifies how to map the index to an MPLS label. The calculated MPLS 244 label is downloaded to the FIB, sent out with a forwarded packet, or 245 both. 247 Consider a SID represented by the index "I". Consider an SRGB as 248 specified in Section 2.3. The total size of the SRGB, represented by 249 the variable "Size", is calculated according to the formula: 251 size = Lh(1)- Ll(1) + 1 + Lh(2)- Ll(2) + 1 + ... + Lh(k)- Ll(k) + 1 253 The following rules MUST be applied by the MCC when calculating the 254 MPLS label value corresponding the SID index value "I". 256 o 0 =< I < size. If the index "I" does not satisfy the previous 257 inequality, then the label cannot be calculated. 259 o The label value corresponding to the SID index "I" is calculated 260 as follows 262 o j = 1 , temp = 0 264 o While temp + Lh(j)- Ll(j) < I 266 . temp = temp + Lh(j)- Ll(j) + 1 268 . j = j+1 270 o label = I - temp + Ll(j) 272 2.5. Incoming Label Collision 274 MPLS Architecture [RFC3031] defines Forwarding Equivalence Class 275 (FEC) term as the set of packets with similar and / or identical 276 characteristics which are forwarded the same way and are bound to the 277 same MPLS incoming (local) label. In Segment-Routing MPLS, local 278 label serves as the SID for given FEC. 280 We define Segment Routing (SR) FEC as one of the following [I-D.ietf- 281 spring-segment-routing]: 283 o (Prefix, Routing Instance, Topology, Algorithm), where a topology 284 is identified by a set of links with metrics. For the purpose of 285 incoming label collision resolution, the same numerical value 286 SHOULD be used on all routers to identify the same set of links 287 with metrics. For MCCs where the "Topology" and/or "Algorithm" 288 fields are not defined, the numerical value of zero MUST be used 289 for these two fields. For the purpose of incoming label collision 290 resolution, a routing instance is identified by a single incoming 291 label downloader to FIB. Two MCCs running on the same router are 292 considered different routing instances if the only way the two 293 instances can know about the other's incoming labels is through 294 redistribution. The numerical value used to identify a routing 295 instance MAY be derived from other configuration or MAY be 296 explicitly configured. If it is derived from other configuration, 297 then the same numerical value SHOULD be derived from the same 298 configuration as long as the configuration survives router reload. 299 If the derived numerical value varies for the same configuration, 300 then an implementation SHOULD make numerical value used to 301 identify a routing instance configurable. 303 o (next-hop, outgoing interface), where the outgoing interface is 304 physical or virtual. 306 o (Endpoint, Color) representing an SR policy [I.D. filsfils-spring- 307 segment-routing-policy] 309 This section covers handling the scenario where, because of an 310 error/misconfiguration, more than one SR FEC as defined in this 311 section, map to the same incoming MPLS label. 313 An incoming label collision occurs if the SIDs of the set of FECs 314 {FEC1, FEC2,..., FECk} maps to the same incoming SR MPLS label "L1". 316 The objective of the following steps is to deterministically install 317 in the MPLS Incoming Label MAP, also known as label FIB, a single FEC 318 with the incoming label "L1". Remaining FECs may be installed in the 319 IP FIB without incoming label. 321 The procedure in this section relies completely on the local FEC and 322 label database within a given router. 324 The collision resolution procedure is as follows 326 1. Given the SIDs of the set of FECs, {FEC1, FEC2,..., FECk} map to 327 the same MPLS label "L1". 329 2. Within an MCC, apply tie-breaking rules to select one FEC only and 330 assign the label to it. The losing FECs are handled as if no 331 labels are attached to them. The losing FECs with a non-zero 332 algorithm are not installed in FIB. 334 a. If the same set of FECs are attached to the same label "L1", 335 then the tie-breaking rules MUST always select the same FEC 336 irrespective of the order in which the FECs and the label "L1" 337 are received. In other words, the tie-breaking rule MUST be 338 deterministic. For example, a first-come-first-serve tie- 339 breaking is not allowed. 341 3. If there is still collision between the FECs belonging to 342 different MCCs, then re-apply the tie-breaking rules to the 343 remaining FECs to select one FEC only and assign the label to that 344 FEC 346 4. Install into the IP FIB the selected FEC and its incoming label in 347 the label FIB. 349 5. The remaining FECs with a zero algorithm are installed in the FIB 350 natively, such as pure IP entries in case of Prefix FEC, without 351 any incoming labels corresponding to their SIDs. The remaining 352 FECs with a non-zero algorithm are not installed in the FIB. 354 2.5.1. Tie-breaking Rules 356 The default tie-breaking rules SHOULD be as follows: 358 1. if FECi has the lowest FEC administrative distance among the 359 competing FECs as defined in this section below, filter away all 360 the competing FECs with higher administrative distance. 362 2. if more than one competing FEC remains after step 1, select the 363 smallest numerical FEC value 365 These rules deterministically select the FEC to install in the MPLS 366 forwarding plane for the given incoming label. 368 This document defines the default tie breaking rules that SHOULD be 369 implemented. An implementation MAY choose to implement additional 370 tie-breaking rules. All routers in a routing domain SHOULD use the 371 same tie-breaking rules to maximize forwarding consistency. 373 Each FEC is assigned an administrative distance. The FEC 374 administrative distance is encoded as an 8-bit value. The lower the 375 value, the better the administrative distance. 377 The default FEC administrative distance order starting from the 378 lowest value SHOULD be 380 o Explicit SID assignment to a FEC that maps to a label outside the 381 SRGB irrespective of the owner MCC. An explicit SID assignment is 382 a static assignment of a label to a FEC such that the assignment 383 survives router reboot. 385 o An example of explicit SID allocation is static assignment of 386 a specific label to an adj-SID. 388 o An implementation of explicit SID assignment MUST guarantee 389 collision freeness on the same router 391 o Dynamic SID assignment: 393 o For all FEC types except for SR policy, use the default 394 administrative distance depending on the implementation 396 o Binding SID [I-D.ietf-spring-segment-routing] assigned to SR 397 Policy 399 A user SHOULD ensure that the same administrative distance preference 400 is used on all routers to maximize forwarding consistency. 402 The numerical sort across FECs SHOULD be performed as follows: 404 o Each FEC is assigned a FEC type encoded in 8 bits. The following 405 are the type code point for each SR FEC defined at the beginning 406 of this Section: 408 o 120: (Prefix, Routing Instance, Topology, Algorithm) 410 o 130: (next-hop, outgoing interface) 411 o 140: (Endpoint, Color) representing an SR policy 413 o The fields of each FEC are encoded as follows 415 o Routing Instance ID represented by 16 bits. For routing 416 instances that are identified by less than 16 bits, encode the 417 Instance ID in the least significant bits while the most 418 significant bits are set to zero 420 o Address Family represented by 8 bits, where IPv4 encoded as 421 100 and IPv6 is encoded as 110 423 o All addresses are represented in 128 bits as follows 425 . IPv6 address is encoded natively 427 . IPv4 address is encoded in the most significant bits and 428 the remaining bits are set to zero 430 o All prefixes are represented by 128. 432 . A prefix is encoded in the most significant bits and the 433 remaining bits are set to zero. 435 . The prefix length is encoded before the prefix 437 o Topology ID is represented by 16 bits. For routing instances 438 that identify topologies using less than 16 bits, encode the 439 topology ID in the least significant bits while the most 440 significant bits are set to zero 442 o Algorithm is encoded in a 16 bits field. 444 o The Color ID is encoded using 16 bits 446 o Choose the set of FECs of the smallest FEC type code point 448 o Out of these FECs, choose the FECs with the smallest address 449 family code point 451 o Encode the remaining set of FECs as follows 453 o Prefix, Routing Instance, Topology, Algorithm: (Prefix Length, 454 Prefix, SR Algorithm, routing_instance_id, Topology) 456 o (next-hop, outgoing interface): (next-hop, 457 outgoing_interface_id) 459 o (Endpoint, Color): (Endpoint_address, Color_id) 461 o Select the FEC with the smallest numerical value 463 2.5.2. Redistribution between Routing Protocol Instances 465 The following rule SHOULD be applied when redistributing SIDs with 466 prefixes between routing protocol instances: 468 o If the receiving instance's SRGB is the same as the SRGB of origin 469 instance, then 471 o the index is redistributed with the route 473 o Else 475 o the index is not redistributed and if needed it is the duty of 476 the receiving instance to allocate a fresh index relative to 477 its own SRGB. Note that in that case, the receiving instance 478 MUST compute its local label according section 2.4 and 479 install it in FIB. 481 It is outside the scope of this document to define local node 482 behaviors that would allow to map the original index into a new index 483 in the receiving instance via the addition of an offset or other 484 policy means. 486 2.5.2.1. Illustration 488 A----IS-IS----B---OSPF----C-192.0.2.1/32 (20001) 490 Consider the simple topology above. 492 o A and B are in the IS-IS domain with SRGB [16000-17000] 494 o B and C are in OSPF domain with SRGB [20000-21000] 496 o B redistributes 192.0.2.1/32 into IS-IS domain 498 o In that case A learns 192.0.2.1/32 as an IP leaf connected to B as 499 usual for IP prefix redistribution 501 o However, according to the redistribution rule above rule, B 502 decides not to advertise any index with 192.0.2.1/32 into IS-IS 503 because the SRGB is not the same. 505 2.5.2.2. Illustration 2 507 Consider the example in the illustration described in Section 508 2.5.2.1. 510 When router B redistributes the prefix 192.0.2.1/32, router B decides 511 to allocate and advertise the same index 1 with the prefix 512 192.0.2.1/32 514 Within the SRGB of the IS-IS domain, index 1 corresponds to the local 515 label 16001 517 o Hence according to the redistribution rule above, router B 518 programs the incoming label 16001 in its FIB to match traffic 519 arriving from the IS-IS domain destined to the prefix 520 192.0.2.1/32. 522 2.6. Outgoing Label Collision 524 For the determination of the outgoing label to use, the ingress node 525 pushing new segments, and hence a stack of MPLS labels, MUST use, for 526 a given FEC, the same label that has been selected by the node 527 receiving the packet with that label exposed as top label. So in case 528 of incoming label collision on this receiving node, the ingress node 529 MUST resolve this collision using this same "Incoming Label Collision 530 resolution procedure", using the data of the receiving node. 532 In the general case, the ingress node may not have exactly have the 533 same data of the receiving node, so the result may be different. This 534 is under the responsibility of the network operator. But in typical 535 case, e.g. where a centralized node or a distributed link state IGP 536 is used, all nodes would have the same database. However to minimize 537 the chance of misforwarding, a FEC that loses its incoming label to 538 the tie-breaking rules specified in Section 2.5 MUST NOT be 539 installed in FIB with an outgoing segment routing label based on the 540 SID corresponding to the lost incoming label. 542 2.7. PUSH, CONTINUE, and NEXT 544 PUSH, NEXT, and CONTINUE are operations applied by the forwarding 545 plane. The specifications of these operations can be found in [I- 546 D.ietf-spring-segment-routing]. This sub-section specifies how to 547 implement each of these operations in the MPLS forwarding plane. 549 2.7.1. PUSH 551 PUSH corresponds to pushing one or more labels on top of an incoming 552 packet then sending it out of a particular physical interface or 553 virtual interface, such as UDP tunnel [RFC7510] or L2TPv3 tunnel 554 [RFC4817], towards a particular next-hop. Sections 2.10 and 2.11 555 specify additional details about forwarding behavior. 557 2.7.2. CONTINUE 559 In the MPLS forwarding plane, the CONTINUE operation corresponds to 560 swapping the incoming label with an outgoing label. The value of the 561 outgoing label is calculated as specified in Sections 2.10 and 2.11. 563 2.7.3. NEXT 565 In the MPLS forwarding plane, NEXT corresponds to popping the topmost 566 label. The action before and/or after the popping depends on the 567 instruction associated with the active SID on the received packet 568 prior to the popping. For example suppose the active SID in the 569 received packet was an Adj-SID [I-D.ietf-spring-segment-routing], 570 then on receiving the packet, the node applies NEXT operation, which 571 corresponds to popping the top most label, and then sends the packet 572 out of the physical or virtual interface (e.g. UDP tunnel [RFC7510] 573 or L2TPv3 tunnel [RFC4817]) towards the next-hop corresponding to the 574 adj-SID. 576 2.8. MPLS Label Downloaded to FIB for Global and Local SIDs 578 The label corresponding to the global SID "Si" represented by the 579 global index "I" downloaded to FIB is used to match packets whose 580 active segment (and hence topmost label) is "Si". The value of this 581 label is calculated as specified in Section 2.4. 583 For Local SIDs, the MCC is responsible for downloading the correct 584 label value to FIB. For example, an IGP with SR extensions I-D.ietf- 585 isis-segment-routing-extensions, I-D.ietf-ospf-segment-routing- 586 extensions] allocates and downloads the MPLS label corresponding to 587 an Adj-SID [I-D.ietf-spring-segment-routing]. 589 2.9. Active Segment 591 When instantiated in the MPLS domain, the active segment on a packet 592 corresponds to the topmost label on the packet that is calculated 593 according to the procedure specified in Sections 2.10 and 2.11. When 594 arriving at a node, the topmost label corresponding to the active SID 595 matches the MPLS label downloaded to FIB as specified in Section 2.4. 597 2.10. Forwarding behavior for Global SIDs 599 This section specifies forwarding behavior, including the calculation 600 of outgoing labels, that corresponds to a global SID when applying 601 PUSH, CONTINUE, and NEXT operations in the MPLS forwarding plane. 603 This document covers the calculation of the outgoing label for the 604 top label only. The case where the outgoing label is not the top 605 label and is part of a stack of labels that instantiates a routing 606 policy or a traffic engineering tunnel is covered in other documents 607 such as [I.D.filsfils-spring-segment-routing-policy]. 609 2.10.1. Forwarding for PUSH and CONTINUE of Global SIDs 611 Suppose an MCC on a router "R0" determines that PUSH or CONTINUE 612 operation is to be applied to an incoming packet whose active SID is 613 the global SID "Si" represented by the global index "I" and owned by 614 the router Ri before sending the packet towards a neighbor "N" 615 directly connected to "R0" through a physical or virtual interface 616 such as UDP tunnel [RFC7510] or L2TPv3 tunnel [RFC4817]. 618 The method by which the MCC on router "R0" determines that PUSH or 619 CONTINUE operation must be applied using the SID "Si" is beyond the 620 scope of this document. An example of a method to determine the SID 621 "Si" for PUSH operation is the case where IS-IS [I-D.ietf-isis- 622 segment-routing-extensions] receives the prefix-SID "Si" sub-TLV 623 advertised with prefix "P/m" in TLV 135 and the destination address 624 of the incoming IPv4 packet is covered by the prefix "P/m". 626 For CONTINUE operation, an example of a method to determine the SID 627 "Si" is the case where IS-IS [I-D.ietf-isis-segment-routing- 628 extensions] receives the prefix-SID "Si" sub-TLV advertised with 629 prefix "P" in TLV 135 and the top label of the incoming packet 630 matches the MPLS label in FIB corresponding to the SID "Si" on the 631 router "R0". 633 The forwarding behavior for PUSH and CONTINUE corresponding to the 634 SID "Si" 636 o If the neighbor "N" does not support SR or "I" does not satisfy 637 the inequality specified in Section 2.4 for the SRGB of the 638 neighbor "N" 639 o If it is possible to send the packet towards the neighbor "N" 640 using standard MPLS forwarding behavior as specified in 641 [RFC3031] and [RFC3032], then forward the packet. The method 642 by which a router decides whether it is possible to send the 643 packet to "N" or not is beyond the scope of this document. For 644 example, the router "R0" can use the downstream label 645 determined by another MCC, such as LDP [RFC5036], to send the 646 packet. 648 o Else if there are other useable next-hops, then use other next- 649 hops to forward the incoming packet. The method by which the 650 router "R0" decides on the possibility of using other next- 651 hops is beyond the scope of this document. For example, the 652 MCC on "R0" may chose the send an IPv4 packet without pushing 653 any label to another next-hop. 655 o Otherwise drop the packet. 657 o Else 659 o Calculate the outgoing label as specified in Section 2.4 using 660 the SRGB of the neighbor "N" 662 o If the operation is PUSH 664 . Push the calculated label according the MPLS label 665 pushing rules specified in [RFC3032] 667 o Else 669 . swap the incoming label with the calculated label 670 according to the label swapping rules in [RFC3032] 672 o Send the packet towards the neighbor "N" 674 2.10.2. Forwarding for NEXT Operation for Global SIDs 676 As specified in Section 2.7.3 NEXT operation corresponds to popping 677 the top most label. The forwarding behavior is as follows 679 o Pop the topmost label 681 o Apply the instruction associated with the incoming label that has 682 been popped 684 The action on the packet after popping the topmost label depends on 685 the instruction associated with the incoming label as well as the 686 contents of the packet right underneath the top label that got 687 popped. Examples of NEXT operation are described in Section 3. 689 2.11. Forwarding Behavior for Local SIDs 691 This section specifies the forwarding behavior for local SIDs when SR 692 is instantiated over the MPLS forwarding plane. 694 2.11.1. Forwarding for PUSH Operation on Local SIDs 696 Suppose an MCC on a router "R0" determines that PUSH operation is to 697 be applied to an incoming packet using the local SID "Si" before 698 sending the packet towards a neighbor "N" directly connected to R0 699 through a physical or virtual interface such as UDP tunnel [RFC7510] 700 or L2TPv3 tunnel [RFC4817]. 702 An example of such local SID is an Adj-SID allocated and advertised 703 by IS-IS [I-D.ietf-isis-segment-routing-extensions]. The method by 704 which the MCC on "R0" determines that PUSH operation is to be applied 705 to the incoming packet is beyond the scope of this document. An 706 example of such method is backup path used to protect against a 707 failure using TI-LFA [I.D.bashandy-rtgwg-segment-routing-ti-lfa]. 709 As mentioned in [I-D.ietf-spring-segment-routing], a local SID is 710 specified by an MPLS label. Hence the PUSH operation for a local SID 711 is identical to label push operation [RFC3032] using any MPLS label. 712 The forwarding action after pushing the MPLS label corresponding to 713 the local SID is also determined by the MCC. For example, if the PUSH 714 operation was done to forward a packet over a backup path calculated 715 using TI-LFA, then the forwarding action may be sending the packet to 716 a certain neighbor that will in turn continue to forward the packet 717 along the backup path 719 2.11.2. Forwarding for CONTINUE Operation for Local SIDs 721 A local SID on a router "R0" corresponds to a local label such as an 722 Adj-SID. In such scenario, the outgoing label towards a next-hop "N" 723 is determined by the MCC running on the router "R0"and the forwarding 724 behavior for CONTINUE operation is identical to swap operation 725 [RFC3032] on an MPLS label. 727 2.11.3. Outgoing label for NEXT Operation for Local SIDs 729 NEXT operation for Local SIDs is identical to NEXT operation for 730 global SIDs specified in Section 2.10.2. 732 3. IGP Segments Examples 734 Consider the network diagram of Figure 1 and the IP address and IGP 735 Segment allocation of Figure 2. Assume that the network is running 736 IS-IS with SR extensions [I-D.ietf-isis-segment-routing-extensions] 737 and all links have the same metric. The following examples can be 738 constructed. 740 +--------+ 741 / \ 742 R0-----R1-----R2----------R3-----R8 743 | \ / | 744 | +--R4--+ | 745 | | 746 +-----R5-----+ 748 Figure 1: IGP Segments - Illustration 750 +-----------------------------------------------------------+ 751 | IP address allocated by the operator: | 752 | 192.0.2.1/32 as a loopback of R1 | 753 | 192.0.2.2/32 as a loopback of R2 | 754 | 192.0.2.3/32 as a loopback of R3 | 755 | 192.0.2.4/32 as a loopback of R4 | 756 | 192.0.2.5/32 as a loopback of R5 | 757 | 192.0.2.8/32 as a loopback of R8 | 758 | 198.51.100.9/32 as an anycast loopback of R4 | 759 | 198.51.100.9/32 as an anycast loopback of R5 | 760 | | 761 | SRGB defined by the operator as 1000-5000 | 762 | | 763 | Global IGP SID indices allocated by the operator: | 764 | 1 allocated to 192.0.2.1/32 | 765 | 2 allocated to 192.0.2.2/32 | 766 | 3 allocated to 192.0.2.3/32 | 767 | 4 allocated to 192.0.2.4/32 | 768 | 8 allocated to 192.0.2.8/32 | 769 | 1009 allocated to 198.51.100.9/32 | 770 | | 771 | Local IGP SID allocated dynamically by R2 | 772 | for its "north" adjacency to R3: 9001 | 773 | for its "north" adjacency to R3: 9003 | 774 | for its "south" adjacency to R3: 9002 | 775 | for its "south" adjacency to R3: 9003 | 776 +-----------------------------------------------------------+ 778 Figure 2: IGP Address and Segment Allocation - Illustration 780 3.1. Example 1 782 Suppose R1 wants to send an IPv4 packet P1 to R8. In this case, R1 783 needs to apply PUSH operation to the IPv4 packet. 785 Remember that the SID index "8" is a global IGP segment attached to 786 the IP prefix 192.0.2.8/32. Its semantic is global within the IGP 787 domain: any router forwards a packet received with active segment 8 788 to the next-hop along the ECMP-aware shortest-path to the related 789 prefix. 791 R2 is the next-hop along the shortest path towards R8. By applying 792 the steps in Section 2.8 the local label downloaded to R1's FIB 793 corresponding to the global SID index 8 is 1008 because the SRGB of 794 R2 is [1000,5000] as shown in Figure 2. 796 Because the packet is IPv4, R1 applies the PUSH operation using the 797 label value 1008 as specified in Section 2.10.1. The resulting MPLS 798 header will have the "S" bit [RFC3032] set because it is followed 799 directly by an IPv4 packet. 801 The packet arrives at router R2. Because the top label 1008 802 corresponds to the IGP SID "8", which is the prefix-SID attached to 803 the prefix 192.0.2.8/32 owned by the R8, then the instruction 804 associated with the SID is "forward the packet using all ECMP/UCMP 805 interfaces and all ECMP/UCMP next-hop(s) along the shortest path 806 towards R8". Because R2 is not the penultimate hop, R2 applies the 807 CONTINUE operation to the packet and sends it to R3 using one of the 808 two links connected to R3 with top label 1008 as specified in Section 809 2.10.1. 811 R3 receives the packet with top label 1008. Because the top label 812 1008 corresponds to the IGP SID "8", which is the prefix-SID attached 813 to the prefix 192.0.2.8/32 owned by the R8, then the instruction 814 associated with the SID is "send the packet using all ECMP interfaces 815 and all next-hop(s) along the shortest path towards R8". Because R3 816 is the penultimate hop, R3 applies NEXT operation then sends the 817 packet to R8. The NEXT operation results in popping the outer label 818 and sending the packet as a pure IPv4 packet to R8. The 820 In conclusion, the path followed by P1 is R1-R2--R3-R8. The ECMP- 821 awareness ensures that the traffic be load-shared between any ECMP 822 path, in this case the two north and south links between R2 and R3. 824 3.2. Example 2 826 Suppose the right most router R0 wants to send a packet P2 to R8 over 827 the path . In that case, the 828 router R0 needs to use the SID list <2, 9001, 8>. Using the 829 calculation techniques specified in Section 2.10 and 2.11 the 830 resulting label stack starting from the topmost label is <1002, 9001, 831 1008>. 833 The MPLS label 1002 is the MPLS instantiation of the global IGP 834 segment index 2 attached to the IP prefix 192.0.2.2/32. Its semantic 835 is global within the IGP domain: any router forwards a packet 836 received with active segment 1002 to the next-hop along the shortest- 837 path to the related prefix. 839 The MPLS label 9001 is a local IGP segment attached by node R2 to its 840 north link to R3. Its semantic is local to node R2: R2 applies NEXT 841 operation, which corresponding to popping the outer label, then 842 switches a packet received with active segment 9001 towards the north 843 link to R3. 845 In conclusion, the path followed by P2 is R0-R1-R2-north-link-R3-R8. 847 3.3. Example 3 849 R0 may send a packet P3 along the same exact path as P2 using a 850 different segment list <2,9003,8> which corresponds to the label 851 stack <1002, 9003, 1008>. 853 9003 is a local IGP segment attached by node R2 to both its north and 854 south links to R3. Its semantic is local to node R2: R2 applies NEXT 855 operation, which corresponds to popping the top label, then switches 856 a packet received with active segment 9003 towards either the north 857 or south links to R3 (e.g. per-flow loadbalancing decision). 859 In conclusion, the path followed by P3 is R0-R1-R2-any-link-R3-R8. 861 3.4. Example 4 863 R0 may send a packet P4 to R8 while avoiding the links between R2 and 864 R3 by pushing the SID list <4,8>, which corresponds to the label 865 stack <1004, 1008>. 867 1004 is a global IGP segment attached to the IP prefix 192.0.2.4/32. 868 Its semantic is global within the IGP domain: any router forwards a 869 packet received with active segment 1004 to the next-hop along the 870 shortest-path to the related prefix. 872 In conclusion, the path followed by P4 is R0-R1-R2-R4-R3-R8. 874 3.5. Example 5 876 R0 may send a packet P5 to R8 while avoiding the links between R2 and 877 R3 and still benefiting from all the remaining shortest paths (via R4 878 and R5) by pushing the SID list <1009, 8> which corresponds to the 879 label stack <2009, 1008> using the steps specified in Sections 2.10 880 and 2.11. 882 1009 is a global anycast-SID [I-D.ietf-spring-segment-routing] 883 attached to the anycast IP prefix 198.51.100.9/32. Its semantic is 884 global within the IGP domain: any router forwards a packet received 885 with top label 2009 (corresponding to the active segment 1009) to the 886 next-hop along the shortest-path to the related prefix. 888 In conclusion, the path followed by P5 is either R0-R1-R2-R4-R3-R8 or 889 R0-R1-R2-R5-R3-R8. 891 4. IANA Considerations 893 This document does not make any request to IANA. 895 5. Manageability Considerations 897 This document describes the applicability of Segment Routing over the 898 MPLS data plane. Segment Routing does not introduce any change in 899 the MPLS data plane. Manageability considerations described in [I- 900 D.ietf-spring-segment-routing] applies to the MPLS data plane when 901 used with Segment Routing. SR OAM use cases for the MPLS data plane 902 are defined in [I-D.ietf-spring-oam-usecase]. SR OAM procedures for 903 the MPLS data plane are defined in [RFC8287]. 905 6. Security Considerations 907 This document does not introduce additional security requirements and 908 mechanisms other than the ones described in [I-D.ietf-spring-segment- 909 routing]. 911 7. Contributors 913 The following contributors have substantially helped the definition 914 and editing of the content of this document: 916 Martin Horneffer 917 Deutsche Telekom 918 Email: Martin.Horneffer@telekom.de 920 Wim Henderickx 921 Nokia 922 Email: wim.henderickx@nokia.com 924 Jeff Tantsura 925 Email: jefftant@gmail.com 926 Edward Crabbe 927 Email: edward.crabbe@gmail.com 929 Igor Milojevic 930 Email: milojevicigor@gmail.com 932 Saku Ytti 933 Email: saku@ytti.fi 935 8. Acknowledgements 937 The authors would like to thank Les Ginsberg and Himanshu Shah for 938 their comments on this document. 940 This document was prepared using 2-Word-v2.0.template.dot. 942 9. References 944 9.1. Normative References 946 [I-D.ietf-spring-segment-routing] Filsfils, C., Previdi, S., 947 Decraene, B., Litkowski, S., and R. Shakir, "Segment 948 Routing Architecture", draft-ietf-spring-segment-routing-12 949 (work in progress), June 2017. 951 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 952 Requirement Levels", BCP 14, RFC 2119, DOI 953 0.17487/RFC2119, March 1997, . 956 [RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol 957 Label Switching Architecture", RFC 3031, DOI 958 10.17487/RFC3031, January 2001, . 961 [RFC3032] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y., 962 Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack 963 Encoding", RFC 3032, DOI 10.17487/RFC3032, January 2001, 964 . 966 [RFC7274] K. Kompella, L. Andersson, and A. Farrel, "Allocating and 967 Retiring Special-Purpose MPLS Labels", RFC7274 DOI 968 10.17487/RFC7274, May 2014 971 [RFC8174] B. Leiba, " Ambiguity of Uppercase vs Lowercase in RFC 2119 972 Key Words", RFC7274 DOI 10.17487/RFC8174, May 2017 973 975 9.2. Informative References 977 [I-D.ietf-isis-segment-routing-extensions] Previdi, S., Filsfils, C., 978 Bashandy, A., Gredler, H., Litkowski, S., Decraene, B., and 979 j. jefftant@gmail.com, "IS-IS Extensions for Segment 980 Routing", draft-ietf-isis-segment-routing-extensions-13 981 (work in progress), June 2017. 983 [I-D.ietf-ospf-ospfv3-segment-routing-extensions] Psenak, P., 984 Previdi, S., Filsfils, C., Gredler, H., Shakir, R., 985 Henderickx, W., and J. Tantsura, "OSPFv3 Extensions for 986 Segment Routing", draft-ietf-ospf-ospfv3-segment-routing- 987 extensions-09 (work in progress), March 2017. 989 [I-D.ietf-ospf-segment-routing-extensions] Psenak, P., Previdi, S., 990 Filsfils, C., Gredler, H., Shakir, R., Henderickx, W., and 991 J. Tantsura, "OSPF Extensions for Segment Routing", draft- 992 ietf-ospf-segment-routing-extensions-16 (work in progress), 993 May 2017. 995 [I-D.ietf-spring-segment-routing-ldp-interop] Filsfils, C., Previdi, 996 S., Bashandy, A., Decraene, B., and S. Litkowski, "Segment 997 Routing interworking with LDP", draft-ietf-spring-segment- 998 routing-ldp-interop-08 (work in progress), June 2017. 1000 [RFC7855] Previdi, S., Ed., Filsfils, C., Ed., Decraene, B., 1001 Litkowski, S., Horneffer, M., and R. Shakir, "Source Packet 1002 Routing in Networking (SPRING) Problem Statement and 1003 Requirements", RFC 7855, DOI 10.17487/RFC7855, May 2016, 1004 . 1006 [RFC5036] Andersson, L., Acreo, AB, Minei, I., Thomas, B., " LDP 1007 Specification", RFC5036, DOI 10.17487/RFC5036, October 1008 2007, 1010 [RFC7510] Xu, X., Sheth, N., Yong, L., Callon, R., and D. Black, 1011 "Encapsulating MPLS in UDP", RFC 7510, DOI 1012 10.17487/RFC7510, April 2015, . 1015 [RFC4817] Townsley, M., Pignataro, C., Wainner, S., Seely, T., Young, 1016 T., "Encapsulation of MPLS over Layer 2 Tunneling Protocol 1017 Version 3", RFC4817, DOI 10.17487/RFC4817, March 2007, 1018 1020 [RFC8287] N. Kumar, C. Pignataro, G. Swallow, N. Akiya, S. Kini, and 1021 M. Chen " Label Switched Path (LSP) Ping/Traceroute for 1022 Segment Routing (SR) IGP-Prefix and IGP-Adjacency Segment 1023 Identifiers (SIDs) with MPLS Data Planes" RFC8287, DOI 1024 10.17487/RFC8287, December 2017, 1027 [I.D. filsfils-spring-segment-routing-policy] Filsfils, C., 1028 Sivabalan, S., Raza, K., Liste, J. , Clad, F., Voyer, D., 1029 Lin, S., Bogdanov, A., Horneffer, M., Steinberg, D., 1030 Decraene, B. , Litkowski, S., " Segment Routing Policy for 1031 Traffic Engineering", draft-filsfils-spring-segment- 1032 routing-policy-01 (work in progress), July 2017 1033 Authors' Addresses 1035 Ahmed Bashandy 1036 Individual 1038 Email: abashandy.ietf@gmail.com 1040 Clarence Filsfils (editor) 1041 Cisco Systems, Inc. 1042 Brussels 1043 BE 1045 Email: cfilsfil@cisco.com 1047 Stefano Previdi (editor) 1048 Cisco Systems, Inc. 1049 Italy 1051 Email: stefano@previdi.net 1053 Bruno Decraene 1054 Orange 1055 FR 1057 Email: bruno.decraene@orange.com 1059 Stephane Litkowski 1060 Orange 1061 FR 1063 Email: stephane.litkowski@orange.com 1065 Rob Shakir 1066 Google 1067 US 1069 Email: robjs@google.com