idnits 2.17.1 draft-ietf-spring-segment-routing-mpls-12.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 3 instances 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 (February 23, 2018) is 2253 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 == Missing Reference: '16000-17000' is mentioned on line 493, but not defined == Missing Reference: '20000-21000' is mentioned on line 495, but not defined -- Looks like a reference, but probably isn't: '1000' on line 781 -- Looks like a reference, but probably isn't: '5000' on line 781 == Unused Reference: 'I-D.ietf-idr-segment-routing-te-policy' is defined on line 1000, but no explicit reference was found in the text == 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 -- 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 (~~), 9 warnings (==), 6 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 C. Filsfils, Ed. 3 Intended status: Standards Track S. Previdi, 4 Expires: August 2018 Cisco Systems, Inc. 5 B. Decraene 6 S. Litkowski 7 Orange 8 R. Shakir 9 Google 10 February 23, 2018 12 Segment Routing with MPLS data plane 13 draft-ietf-spring-segment-routing-mpls-12 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 August 23, 2018. 49 Copyright Notice 51 Copyright (c) 2018 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. Incoming Label Collision..................................6 74 2.5.1. Tie-breaking Rules...................................8 75 2.5.2. Redistribution between Routing Protocol Instances...11 76 2.5.2.1. Illustration...................................11 77 2.6. Outgoing Label Collision.................................11 78 2.7. PUSH, CONTINUE, and NEXT.................................12 79 2.7.1. PUSH................................................12 80 2.7.2. CONTINUE............................................12 81 2.7.3. NEXT................................................12 82 2.8. MPLS Label downloaded to FIB corresponding to Global and 83 Local SIDs....................................................13 84 2.9. Active Segment...........................................13 85 2.10. Forwarding behavior for Global SIDs.....................13 86 2.10.1. Forwarding Behavior for PUSH and CONTINUE Operation for 87 Global SIDs................................................13 88 2.10.2. Forwarding Behavior for NEXT Operation for Global SIDs 89 ...........................................................15 91 2.11. Forwarding Behavior for Local SIDs......................15 92 2.11.1. Forwarding Behavior Corresponding to PUSH Operation on 93 Local SIDs.................................................15 94 2.11.2. Forwarding Behavior Corresponding to CONTINUE Operation 95 for Local SIDs.............................................16 96 2.11.3. Outgoing label for NEXT Operation for Local SIDs...16 97 3. IGP Segments Examples.........................................16 98 3.1. Example 1................................................17 99 3.2. Example 2................................................18 100 3.3. Example 3................................................19 101 3.4. Example 4................................................19 102 3.5. Example 5................................................19 103 4. IANA Considerations...........................................20 104 5. Manageability Considerations..................................20 105 6. Security Considerations.......................................20 106 7. Contributors..................................................20 107 8. Acknowledgements..............................................21 108 9. References....................................................21 109 9.1. Normative References.....................................21 110 9.2. Informative References...................................22 112 1. Introduction 114 The Segment Routing architecture [I-D.ietf-spring-segment-routing] 115 can be directly applied to the MPLS architecture with no change in 116 the MPLS forwarding plane. This document specifies the forwarding 117 plane behavior to allow Segment Routing to operate on top of the MPLS 118 data plane. This document does not address the control plane 119 behavior. Control plane behavior is specified in other documents such 120 as [I-D.ietf-isis-segment-routing-extensions], [I-D.ietf-ospf- 121 segment-routing-extensions], and [I-D.ietf-ospf-ospfv3-segment- 122 routing-extensions]. 124 The Segment Routing problem statement is described in [RFC7855]. 126 Co-existence of SR over MPLS forwarding plane with LDP [RFC5036] is 127 specified in [I-D.ietf-spring-segment-routing-ldp-interop]. 129 Policy routing and traffic engineering using segment routing can be 130 found in [I.D. filsfils-spring-segment-routing-policy] 132 2. MPLS Instantiation of Segment Routing 134 MPLS instantiation of Segment Routing fits in the MPLS architecture 135 as defined in [RFC3031] both from a control plane and forwarding 136 plane perspective: 138 o From a control plane perspective, [RFC3031] does not mandate a 139 single signaling protocol. Segment Routing makes use of various 140 control plane protocols such as link State IGPs [I-D.ietf-isis- 141 segment-routing-extensions], [I-D.ietf-ospf-segment-routing- 142 extensions] and [I-D.ietf-ospf-ospfv3-segment-routing-extensions]. 143 The flooding mechanisms of link state IGPs fits very well with 144 label stacking on ingress. Future control layer protocol and/or 145 policy/configuration can be used to specify the label stack. 147 o From a forwarding plane perspective, Segment Routing does not 148 require any change to the forwarding plane because Segment ID 149 (SIDs) are instantiated as MPLS labels and the Segment routing 150 header instantiated as a stack of MPLS labels. 152 We call "MPLS Control Plane Client (MCC)" any control plane entity 153 installing forwarding entries in the MPLS data plane. IGPs with SR 154 extensions [I-D.ietf-isis-segment-routing-extensions], [I-D.ietf- 155 ospf-segment-routing-extensions], [I-D.ietf-ospf-ospfv3-segment- 156 routing-extensions] and LDP [RFC5036] are examples of MCCs. Local 157 configuration and policies applied on a router are also examples of 158 MCCs. 160 2.1. Supporting Multiple Forwarding Behaviors for the Same Prefix 162 The SR architecture does not prohibit having more than one SID for 163 the same prefix. In fact, by allowing multiple SIDs for the same 164 prefix, it is possible to have different forwarding behaviors (such 165 as different paths, different ECMP/UCMP behaviors,...,etc) for the 166 same destination. 168 Instantiating Segment routing over the MPLS forwarding plane fits 169 seamlessly with this principle. An operator may assign multiple MPLS 170 labels or indices to the same prefix and assign different forwarding 171 behaviors to each label/SID. The MCC in the network downloads 172 different MPLS labels/SIDs to the FIB for different forwarding 173 behaviors. The MCC at the entry of an SR domain or at any point in 174 the domain can choose to apply a particular forwarding behavior to a 175 particular packet by applying the PUSH action to that packet using 176 the corresponding SID. 178 2.2. SID Representation in the MPLS Forwarding Plane 180 When instantiating SR over the MPLS forwarding plane, a SID is 181 represented by an MPLS label or an index [I-D.ietf-spring-segment- 182 routing]. 184 A global segment MUST be a label, or an index which may be mapped to 185 an MPLS label using the SRGB of the node installing the global 186 segment in its FIB/receiving the labeled packet. Section 2.4 187 specifies the procedure to map a global segment represented by an 188 index to an MPLS label within the SRGB. 190 The MCC MUST ensure that any label value corresponding to any SID it 191 installs in the forwarding plane follows the following rules: 193 o The label value MUST be unique within the router on which the MCC 194 is running. i.e. the label MUST only be used to represent the SID. 196 o The label value MUST NOT be identical to or within the range of 197 any reserved label value or range [reserved-MPLS], respectively. 199 2.3. Segment Routing Global Block and Local Block 201 The concepts of Segment Routing Global Block (SRGB) and global SID 202 are explained in [I-D.ietf-spring-segment-routing]. In general, the 203 SRGB need not be a contiguous range of labels. 205 For the rest of this document, the SRGB is specified by the list of 206 MPLS Label ranges [Ll(1),Lh(1)], [Ll(2),Lh(2)],..., [Ll(k),Lh(k)] 207 where Ll(i) =< Lh(i). 209 The following rules apply to the list of MPLS ranges representing the 210 SRGB 212 o The list of ranges comprising the SRGB MUST NOT overlap. 214 o Every range in the list of ranges specifying the SRGB MUST NOT 215 cover or overlap with a reserved label value or range [reserved- 216 MPLS], respectively. 218 o If the SRGB of a node does not conform to the structure specified 219 in this section or to the previous two rules, then this SRGB is 220 completely ignored and the node is treated as if it does not have 221 an SRGB. 223 o The list of label ranges MUST only be used to instantiate global 224 SIDs into the MPLS forwarding plane 226 Local segments MAY be allocated from the Segment Routing Local Block 227 (SRLB) [I-D.ietf-spring-segment-routing] or from any unused label as 228 long as it does not use a reserved label. The SRLB consists of the 229 range of local labels reserved by the node for certain local 230 segments. In a controller-driven network, some controllers or 231 applications MAY use the control plane to discover the available set 232 of local SIDs on a particular router [I.D. filsfils-spring-segment- 233 routing-policy]. Just like SRGB, the SRLB need not be a single 234 contiguous range of label, except the SRGB MUST only be used to 235 instantiate global SIDs into the MPLS forwarding plane. Hence it is 236 specified the same way and follows the same rules SRGB is specified 237 above in this sub-section. 239 2.4. Mapping a SID Index to an MPLS label 241 This sub-section specifies how the MPLS label value is calculated 242 given the index of a SID. The value of the index is determined by an 243 MCC such as IS-IS [I-D.ietf-isis-segment-routing-extensions] or OSPF 244 [I-D.ietf-ospf-segment-routing-extensions]. This section only 245 specifies how to map the index to an MPLS label. The calculated MPLS 246 label is downloaded to the FIB, sent out with a forwarded packet, or 247 both. 249 Consider a SID represented by the index "I". Consider an SRGB as 250 specified in Section 2.3. The total size of the SRGB, represented by 251 the variable "Size", is calculated according to the formula: 253 size = Lh(1)- Ll(1) + 1 + Lh(2)- Ll(2) + 1 + ... + Lh(k)- Ll(k) + 1 255 The following rules MUST be applied by the MCC when calculating the 256 MPLS label value corresponding the SID index value "I". 258 o 0 =< I < size. If the index "I" does not satisfy the previous 259 inequality, then the label cannot be calculated. 261 o The label value corresponding to the SID index "I" is calculated 262 as follows 264 o j = 1 , temp = 0 266 o While temp + Lh(j)- Ll(j) < I 268 . temp = temp + Lh(j)- Ll(j) + 1 270 . j = j+1 272 o label = I - temp + Ll(j) 274 2.5. Incoming Label Collision 276 MPLS Architecture [RFC3031] defines Forwarding Equivalence Class 277 (FEC) as the set of packets which are forwarded in the same manner 278 (e.g.,over the same path, with the same forwarding treatment) and are 279 bound to the same MPLS incoming (local) label. In Segment-Routing 280 MPLS, local label serves as the SID (possibly via an index 281 indirection) for given FEC. 283 We define Segment Routing (SR) FEC as one of the following [I-D.ietf- 284 spring-segment-routing]: 286 o (Prefix, Routing Instance, Topology, Algorithm), where a topology 287 is identified by a set of links with metrics. For the purpose of 288 incoming label collision resolution, the same numerical value 289 SHOULD be used on all routers to identify the same set of links 290 with metrics. For MCCs where the "Topology" and/or "Algorithm" 291 fields are not defined, the numerical value of zero MUST be used 292 for these two fields. For the purpose of incoming label collision 293 resolution, a routing instance is identified by a single incoming 294 label downloader to FIB. Two MCCs running on the same router are 295 considered different routing instances if the only way the two 296 instances can know about the other's incoming labels is through 297 redistribution. The numerical value used to identify a routing 298 instance MAY be derived from other configuration or MAY be 299 explicitly configured. If it is derived from other configuration, 300 then the same numerical value SHOULD be derived from the same 301 configuration as long as the configuration survives router reload. 302 If the derived numerical value varies for the same configuration, 303 then an implementation SHOULD make numerical value used to 304 identify a routing instance configurable. 306 o (next-hop, outgoing interface), where the outgoing interface is 307 physical or virtual. 309 o (Endpoint, Color) representing an SR policy [I.D. filsfils-spring- 310 segment-routing-policy] 312 This section covers handling the scenario where, because of an 313 error/misconfiguration, more than one SR FEC as defined in this 314 section, map to the same incoming MPLS label. 316 An incoming label collision occurs if the SIDs of the set of FECs 317 {FEC1, FEC2,..., FECk} maps to the same incoming SR MPLS label "L1". 319 The objective of the following steps is to deterministically install 320 in the MPLS Incoming Label MAP, also known as label FIB, a single FEC 321 with the incoming label "L1". Remaining FECs may be installed in the 322 IP FIB without incoming label. 324 The procedure in this section relies completely on the local FEC and 325 label database within a given router. 327 The collision resolution procedure is as follows 329 1. Given the SIDs of the set of FECs, {FEC1, FEC2,..., FECk} map to 330 the same MPLS label "L1". 332 2. Within an MCC, apply tie-breaking rules to select one FEC only and 333 assign the label to it. The losing FECs are handled as if no 334 labels are attached to them. The losing FECs with a non-zero algo 335 are not installed in FIB. 337 a. If the same set of FECs are attached to the same label "L1", 338 then the tie-breaking rules MUST always select the same FEC 339 irrespective of the order in which the FECs and the label "L1" 340 are received. In other words, the tie-breaking rule MUST be 341 deterministic. For example, a first-come-first-serve tie- 342 breaking is not allowed. 344 3. If there is still collision between the FECs belonging to 345 different MCCs, then re-apply the tie-breaking rules to the 346 remaining FECs to select one FEC only and assign the label to that 347 FEC 349 4. Install into the IP FIB the selected FEC and its incoming label in 350 the label FIB. 352 5. The remaining FECs with a zero algorithm are installed in the FIB 353 natively, such as pure IP entries in case of Prefix FEC, without 354 any incoming labels corresponding to their SIDs. The remaining 355 FECs with a non-zero algorithm are not installed in the FIB. 357 2.5.1. Tie-breaking Rules 359 The default tie-breaking rules SHOULD be as follows: 361 1. if FECi has the lowest FEC administrative distance among the 362 competing FEC's as defined in this section below, filter away all 363 the competing FEC's with higher administrative distance. 365 2. if more than one competing FEC remains after step 1, sort them and 366 select the smallest numerical FEC value 368 These rules deterministically select the FEC to install in the MPLS 369 forwarding plane for the given incoming label. 371 This document defines the default tie breaking rules that SHOULD be 372 implemented. An implementation may choose to implement additional 373 tie-breaking rules. All routers in a routing domain SHOULD use the 374 same tie-breaking rules to maximize forwarding consistency. 376 Each FEC is assigned an administrative distance. The FEC 377 administrative distance is encoded as an 8-bit value. The lower the 378 value, the better the administrative distance. 380 The default FEC administrative distance order starting from the 381 lowest value SHOULD be 383 o Explicit SID assignment to a FEC that maps to a label outside the 384 SRGB irrespective of the owner MCC. An explicit SID assignment is 385 a static assignment of a label to a FEC such that the assignment 386 survives router reboot. 388 o An example of explicit SID allocation is static assignment of 389 a specific label to an adjacency SID. 391 o An implementation of explicit SID assignment MUST guarantee 392 collision freeness on the same router 394 o Dynamic SID assignment: 396 o For all FEC types except for SR policy, use the default 397 administrative distance depending on the implementation 399 o Binding SID [I-D.ietf-spring-segment-routing] assigned to SR 400 Policy 402 A user SHOULD ensure that the same administrative distance preference 403 is used on all routers to maximize forwarding consistency. 405 The numerical sort across FEC's SHOULD be performed as follows: 407 o Each FEC is assigned a FEC type encoded in 8 bits. The following 408 are the type code point for each SR FEC defined at the beginning 409 of this Section: 411 o 120: (Prefix, Routing Instance, Topology, Algorithm) 413 o 130: (next-hop, outgoing interface) 415 o 140: (Endpoint, Color) representing an SR policy 417 o The fields of each FEC are encoded as follows 418 o Routing Instance ID represented by 16 bits. For routing 419 instances that are identified by less than 16 bits, encode the 420 Instance ID in the least significant bits while the most 421 significant bits are set to zero 423 o Address Family represented by 8 bits, where IPv4 encoded as 424 100 and IPv6 is encoded as 110 426 o All addresses are represented in 128 bits as follows 428 . IPv6 address is encoded natively 430 . IPv4 address is encoded in the most significant bits and 431 the remaining bits are set to zero 433 o All prefixes are represented by 128. 435 . A prefix is encoded in the most significant bits and the 436 remaining bits are set to zero. 438 . The prefix length is encoded before the prefix 440 o Topology ID is represented by 16 bits. For routing instances 441 that identify topologies using less than 16 bits, encode the 442 topology ID in the least significant bits while the most 443 significant bits are set to zero 445 o Algorithm is encoded in a 16 bits field. 447 o The Color ID is encoded using 16 bits 449 o Choose the set of FECs of the smallest FEC type code point 451 o Out of these FECs, choose the FECs with the smallest address 452 family code point 454 o Encode the remaining set of FECs as follows 456 o Prefix, Routing Instance, Topology, Algorithm: (Prefix Length, 457 Prefix, SR Algorithm, routing_instance_id, Topology) 459 o (next-hop, outgoing interface): (next-hop, 460 outgoing_interface_id) 462 o (Endpoint, Color): (Endpoint_address, Color_id) 464 o Select the FEC with the smallest numerical value 466 2.5.2. Redistribution between Routing Protocol Instances 468 The following rule SHOULD be applied when redistributing SIDs with 469 prefixes between routing protocol instances: 471 o If the receiving instance's SRGB is the same as the SRGB of origin 472 instance, THEN 474 o the index is redistributed with the route 476 o Else 478 o the index is not redistributed and if needed it is the duty of 479 the receiving instance to allocate a fresh index relative to 480 its own SRGB 482 It is outside the scope of this document to define local node 483 behaviors that would allow to map the original index into a new index 484 in the receiving instance via the addition of an offset or other 485 policy means. 487 2.5.2.1. Illustration 489 A----IS-IS----B---OSPF----C-1.1.1.1/32 (20001) 491 Consider the simple topology above. 493 o A and B are in the IS-IS domain with SRGB [16000-17000] 495 o B and C are in OSPF domain with SRGB [20000-21000] 497 o B redistributes 1.1.1.1/32 into IS-IS domain 499 o In that case A learns 1.1.1.1/32 as an IP leaf connected to B as 500 usual for IP prefix redistribution 502 o However, according to the redistribution rule above rule, B does 503 not advertise any index with 1.1.1.1/32 into IS-IS because the 504 SRGB is not the same. 506 2.6. Outgoing Label Collision 508 For the determination of the outgoing label to use, the ingress node 509 pushing new segments, and hence a stack of MPLS labels, MUST use, for 510 a given FEC, the same label that has been selected by the node 511 receiving the packet with that label exposed as top label. So in case 512 of incoming label collision on this receiving node, the ingress node 513 MUST resolve this collision using this same "Incoming Label Collision 514 resolution procedure", using the data of the receiving node. 516 In the general case, the ingress node may not have exactly have the 517 same data of the receiving node, so the result may be different. This 518 is under the responsibility of the network operator. But in typical 519 case, e.g. where a centralized node or a distributed link state IGP 520 is used, all nodes would have the same database. However to minimize 521 the chance of misforwarding, a FEC that loses its incoming label to 522 the tie-breaking rules specified in Section 2.5 MUST NOT be 523 installed in FIB with an outgoing segment routing label based on the 524 SID corresponding to the lost incoming label. 526 2.7. PUSH, CONTINUE, and NEXT 528 PUSH, NEXT, and CONTINUE are operations applied by the forwarding 529 plan. The specifications of these operations can be found in [I- 530 D.ietf-spring-segment-routing]. This sub-section specifies how to 531 implement each of these operations in the MPLS forwarding plane. 533 2.7.1. PUSH 535 PUSH corresponds to pushing one or more labels on top of an incoming 536 packet then sending it out of a particular physical interface or 537 virtual interface, such as UDP tunnel [RFC7510] or L2TPv3 tunnel 538 [RFC4817], towards a particular next-hop. Sections 2.10 and 2.11 539 specify additional details about forwarding behavior. 541 2.7.2. CONTINUE 543 In the MPLS forwarding plane, the CONTINUE operation corresponds to 544 swapping the incoming label with an outgoing label. The value of the 545 outgoing label is calculated as specified in Sections 2.10 and 2.11. 547 2.7.3. NEXT 549 In the MPLS forwarding plane, NEXT corresponds to popping the topmost 550 label. The action before and/or after the popping depends on the 551 instruction associated with the active SID on the received packet 552 prior to the popping. For example suppose the active SID in the 553 received packet was an Adj-SID [I-D.ietf-spring-segment-routing], 554 then on receiving the packet, the node applies NEXT operation, which 555 corresponds to popping the top most label, and then sends the packet 556 out of the physical or virtual interface (e.g. UDP tunnel [RFC7510] 557 or L2TPv3 tunnel [RFC4817]) towards the next-hop corresponding to the 558 adj-SID. 560 2.8. MPLS Label downloaded to FIB corresponding to Global and Local SIDs 562 The label corresponding to the global SID "Si" represented by the 563 global index "I" downloaded to FIB is used to match packets whose 564 active segment (and hence topmost label) is "Si". The value of this 565 label is calculated as specified in Section 2.4. 567 For Local SIDs, the MCC is responsible for downloading the correct 568 label value to FIB. For example, an IGP with SR extensions I-D.ietf- 569 isis-segment-routing-extensions, I-D.ietf-ospf-segment-routing- 570 extensions] allocates and downloads the MPLS label corresponding to 571 an IGP-adjacency-SID [I-D.ietf-spring-segment-routing]. 573 2.9. Active Segment 575 When instantiated in the MPLS domain, the active segment on a packet 576 corresponds to the topmost label on the packet that is calculated 577 according to the procedure specified in Sections 2.10 and 2.11. When 578 arriving at a node, the topmost label corresponding to the active SID 579 matches the MPLS label downloaded to FIB as specified in Section 2.8. 581 2.10. Forwarding behavior for Global SIDs 583 This section specifies forwarding behavior, including the outgoing 584 label(s) calculations corresponding to a global SID when applying 585 PUSH, CONTINUE, and NEXT operations in the MPLS forwarding plane. 587 This document covers the calculation of outgoing label for the top 588 label only. The case where outgoing label is not the top label and is 589 part of a stack of labels that instantiates a routing policy or a 590 traffic engineering tunnel is covered in other documents such as 591 [I.D.filsfils-spring-segment-routing-policy]. 593 2.10.1. Forwarding Behavior for PUSH and CONTINUE Operation for Global 594 SIDs 596 Suppose an MCC on a router "R0" determines that PUSH or CONTINUE 597 operation is to be applied to an incoming packet whose active SID is 598 the global SID "Si" represented by the global index "I" and owned by 599 the router Ri before sending the packet towards a neighbor "N" 600 directly connected to "R0" through a physical or virtual interface 601 such as UDP tunnel [RFC7510] or L2TPv3 tunnel [RFC4817]. 603 The method by which the MCC on router "R0" determines that PUSH or 604 CONTINUE operation must be applied using the SID "Si" is beyond the 605 scope of this document. An example of a method to determine the SID 606 "Si" for PUSH operation is the case where IS-IS [I-D.ietf-isis- 607 segment-routing-extensions] receives the prefix-SID "Si" sub-TLV 608 advertised with prefix "P/m" in TLV 135 and the destination address 609 of the incoming IPv4 packet is covered by the prefix "P/m". 611 For CONTINUE operation, an example of a method to determine the SID 612 "Si" is the case where IS-IS [I-D.ietf-isis-segment-routing- 613 extensions] receives the prefix-SID "Si" sub-TLV advertised with 614 prefix "P" in TLV 135 and the top label of the incoming packet 615 matches the MPLS label in FIB corresponding to the SID "Si" on the 616 router "R0". 618 The forwarding behavior for PUSH and CONTINUE corresponding to the 619 SID "Si" 621 o If the neighbor "N" does not support SR or "I" does not satisfy 622 the inequality specified in Section 2.4 for the SRGB of the 623 neighbor "N" 625 o If it is possible to send the packet towards the neighbor "N" 626 using standard MPLS forwarding behavior as specified in 627 {RFC3031] and [RFC3032], then forward the packet. The method 628 by which a router decides whether it is possible to send the 629 packet to "N" or not is beyond the scope of this document. For 630 example, the router "R0" can use the downstream label 631 determined by another MCC, such as LDP [RFC5036], to send the 632 packet. 634 o Else if there are other useable next-hops, then use other next- 635 hops to forward the incoming packet. The method by which the 636 router "R0" decides on the possibility of using other next- 637 hops is beyond the scope of this document. For example, the 638 MCC on "R0" may chose the send an IPv4 packet without pushing 639 any label to another next-hop. 641 o Otherwise drop the packet. 643 o Else 645 o Calculate the outgoing label as specified in Section 2.4 using 646 the SRGB of the neighbor "N" 648 o If the operation is PUSH 649 . Push the calculated label according the MPLS label 650 pushing rules specified in [RFC3032] 652 o Else 654 . swap the incoming label with the calculated label 655 according to the label swapping rules in [RFC3032] 657 o Send the packet towards the neighbor "N" 659 2.10.2. Forwarding Behavior for NEXT Operation for Global SIDs 661 As specified in Section 2.7.3 NEXT operation corresponds to popping 662 the top most label. The forwarding behavior is as follows 664 o Pop the topmost label 666 o Apply the instruction associated with the incoming label prior to 667 popping 669 The action on the packet after popping the topmost label depends on 670 the instruction associated with the incoming label as well as the 671 contents of the packet right underneath the top label that got 672 popped. Examples of NEXT operation are described in Section 3. 674 2.11. Forwarding Behavior for Local SIDs 676 This section specifies the forwarding behavior for local SIDs when SR 677 is instantiated over the MPLS forwarding plane. 679 2.11.1. Forwarding Behavior Corresponding to PUSH Operation on Local 680 SIDs 682 Suppose an MCC on a router "R0" determines that PUSH operation is to 683 be applied to an incoming packet using the local SID "Si" before 684 sending the packet towards a neighbor "N" directly connected to R0 685 through a physical or virtual interface such as UDP tunnel [RFC7510] 686 or L2TPv3 tunnel [RFC4817]. 688 An example of such local SID is an IGP-Adj-SID allocated and 689 advertised by IS-IS [I-D.ietf-isis-segment-routing-extensions]. The 690 method by which the MCC on "R0" determines that PUSH operation is to 691 be applied to the incoming packet is beyond the scope of this 692 document. An example of such method is backup path used to protect 693 against a failure using Ti-LFA [I.D.bashandy-rtgwg-segment-routing- 694 ti-lfa]. 696 As mentioned in [I-D.ietf-spring-segment-routing], a local SID is 697 specified by an MPLS label. Hence the PUSH operation for a local SID 698 is identical to label push operation [RFC3032] using any MPLS label. 699 The forwarding action after pushing the MPLS label corresponding to 700 the local SID is also determined by the MCC. For example, if the PUSH 701 operation was done to forward a packet over a backup path calculated 702 using Ti-LFA, then the forwarding action may be sending the packet to 703 a certain neighbor that will in turn continue to forward the packet 704 along the backup path 706 2.11.2. Forwarding Behavior Corresponding to CONTINUE Operation for 707 Local SIDs 709 A local SID on a router "R0" corresponds to a local label such as an 710 IGP adj-SID. In such scenario, the outgoing label towards a next-hop 711 "N" is determined by the MCC running on the router "R0"and the 712 forwarding behavior for CONTINUE operation is identical to swap 713 operation [RFC3032] on an MPLS label. 715 2.11.3. Outgoing label for NEXT Operation for Local SIDs 717 NEXT operation for Local SIDs is identical to NEXT operation for 718 global SIDs specified in Section 2.10.2. 720 3. IGP Segments Examples 722 Consider the network diagram of Figure 1 and the IP address and IGP 723 Segment allocation of Figure 2. Assume that the network is running 724 IS-IS with SR extensions [I-D.ietf-isis-segment-routing-extensions]. 725 The following examples can be constructed. 727 +--------+ 728 / \ 729 R0-----R1-----R2----------R3-----R8 730 | \ / | 731 | +--R4--+ | 732 | | 733 +-----R5-----+ 735 Figure 1: IGP Segments - Illustration 737 +-----------------------------------------------------------+ 738 | IP address allocated by the operator: | 739 | 192.0.2.1/32 as a loopback of R1 | 740 | 192.0.2.2/32 as a loopback of R2 | 741 | 192.0.2.3/32 as a loopback of R3 | 742 | 192.0.2.4/32 as a loopback of R4 | 743 | 192.0.2.5/32 as a loopback of R5 | 744 | 192.0.2.8/32 as a loopback of R8 | 745 | 198.51.100.9/32 as an anycast loopback of R4 | 746 | 198.51.100.9/32 as an anycast loopback of R5 | 747 | | 748 | SRGB defined by the operator as 1000-5000 | 749 | | 750 | Global IGP SID indices allocated by the operator: | 751 | 1 allocated to 192.0.2.1/32 | 752 | 2 allocated to 192.0.2.2/32 | 753 | 3 allocated to 192.0.2.3/32 | 754 | 4 allocated to 192.0.2.4/32 | 755 | 8 allocated to 192.0.2.8/32 | 756 | 1009 allocated to 198.51.100.9/32 | 757 | | 758 | Local IGP SID allocated dynamically by R2 | 759 | for its "north" adjacency to R3: 9001 | 760 | for its "north" adjacency to R3: 9003 | 761 | for its "south" adjacency to R3: 9002 | 762 | for its "south" adjacency to R3: 9003 | 763 +-----------------------------------------------------------+ 765 Figure 2: IGP Address and Segment Allocation - Illustration 767 3.1. Example 1 769 Suppose R1 wants to send an IPv4 packet P1 to R8. In this case, R1 770 needs to apply PUSH operation to the IPv4 packet. 772 Remember that the SID index "8" is a global IGP segment attached to 773 the IP prefix 192.0.2.8/32. Its semantic is global within the IGP 774 domain: any router forwards a packet received with active segment 8 775 to the next-hop along the ECMP-aware shortest-path to the related 776 prefix. 778 R2 is the next-hop along the shortest path towards R8. By applying 779 the steps in Section 2.8 the local label downloaded to R1's FIB 780 corresponding to the global SID index 8 is 1008 because the SRGB of 781 R2 is [1000,5000] as shown in Figure 2. 783 Because the packet is IPv4, R1 applies the PUSH operation using the 784 label value 1008 as specified in 2.10.1. The resulting MPLS header 785 will have the "S" bit [RFC3032] set because it is followed directly 786 by an IPv4 packet. 788 The packet arrives at router R2. Because the top label 1008 789 corresponds to the IGP SID "8", which is the prefix-SID attached to 790 the prefix 192.0.2.8/32 owned by the R8, then the instruction 791 associated with the SID is "forward the packet using all ECMP/UCMP 792 interfaces and all ECMP/UCMP next-hop(s) along the shortest path 793 towards R8". Because R2 is not the penultimate hop, R2 applies the 794 CONTINUE operation to the packet and sends it to R3 using one of the 795 two links connected to R3 with top label 1008 as specified in Section 796 2.10.1. 798 R3 receives the packet with top label 1008. Because the top label 799 1008 corresponds to the IGP SID "8", which is the prefix-SID attached 800 to the prefix 192.0.2.8/32 owned by the R8, then the instruction 801 associated with the SID is "send the packet using all ECMP interfaces 802 and all next-hop(s) along the shortest path towards R8". Because R3 803 is the penultimate hop, R3 applies NEXT operation then sends the 804 packet to R8. The NEXT operation results in popping the outer label 805 and sending the packet as a pure IPv4 packet to R8. The 807 In conclusion, the path followed by P1 is R1-R2--R3-R8. The ECMP- 808 awareness ensures that the traffic be load-shared between any ECMP 809 path, in this case the two north and south links between R2 and R3. 811 3.2. Example 2 813 Suppose the right most router R0 wants to send a packet P2 to R8 over 814 the path . In that case, the 815 router R0 needs to use the SID list <2, 9001, 8>. Using the 816 calculation techniques specified in Section 2.10 and 2.11 the 817 resulting label stack starting from the topmost label is <1002, 9001, 818 1008>. 820 The MPLS label 1002 is the MPLS instantiation of the global IGP 821 segment index 2 attached to the IP prefix 192.0.2.2/32. Its semantic 822 is global within the IGP domain: any router forwards a packet 823 received with active segment 1002 to the next-hop along the shortest- 824 path to the related prefix. 826 The MPLS label 9001 is a local IGP segment attached by node R2 to its 827 north link to R3. Its semantic is local to node R2: R2 applies NEXT 828 operation, which corresponding to popping the outer label, then 829 switches a packet received with active segment 9001 towards the north 830 link to R3. 832 In conclusion, the path followed by P2 is R0-R1-R2-north-link-R3-R8. 834 3.3. Example 3 836 R0 may send a packet P3 along the same exact path as P2 using a 837 different segment list <2,9003,8> which corresponds to the label 838 stack <1002, 9003, 1008>. 840 9003 is a local IGP segment attached by node R2 to both its north and 841 south links to R3. Its semantic is local to node R2: R2 applies NEXT 842 operation, which corresponds to popping the top label, then switches 843 a packet received with active segment 9003 towards either the north 844 or south links to R3 (e.g. per-flow loadbalancing decision). 846 In conclusion, the path followed by P3 is R0-R1-R2-any-link-R3-R8. 848 3.4. Example 4 850 R0 may send a packet P4 to R8 while avoiding the links between R2 and 851 R3 by pushing the SID list <4,8>, which corresponds to the label 852 stack <1004, 1008>. 854 1004 is a global IGP segment attached to the IP prefix 192.0.2.4/32. 855 Its semantic is global within the IGP domain: any router forwards a 856 packet received with active segment 1004 to the next-hop along the 857 shortest-path to the related prefix. 859 In conclusion, the path followed by P4 is R0-R1-R2-R4-R3-R8. 861 3.5. Example 5 863 R0 may send a packet P5 to R8 while avoiding the links between R2 and 864 R3 and still benefiting from all the remaining shortest paths (via R4 865 and R5) by pushing the SID list <1009, 8> which corresponds to the 866 label stack <2009, 1008> using the steps specified in Sections 2.10 867 and 2.11. 869 1009 is a global anycast-SID [I-D.ietf-spring-segment-routing] 870 attached to the anycast IP prefix 198.51.100.9/32. Its semantic is 871 global within the IGP domain: any router forwards a packet received 872 with top label 2009 (corresponding to the active segment 1009) to the 873 next-hop along the shortest-path to the related prefix. 875 In conclusion, the path followed by P5 is either R0-R1-R2-R4-R3-R8 or 876 R0-R1-R2-R5-R3-R8. 878 4. IANA Considerations 880 This document does not make any request to IANA. 882 5. Manageability Considerations 884 This document describes the applicability of Segment Routing over the 885 MPLS data plane. Segment Routing does not introduce any change in 886 the MPLS data plane. Manageability considerations described in [I- 887 D.ietf-spring-segment-routing] applies to the MPLS data plane when 888 used with Segment Routing. 890 6. Security Considerations 892 This document does not introduce additional security requirements and 893 mechanisms other than the ones described in [I-D.ietf-spring-segment- 894 routing]. 896 7. Contributors 898 The following contributors have substantially helped the definition 899 and editing of the content of this document: 901 Martin Horneffer 902 Deutsche Telekom 903 Email: Martin.Horneffer@telekom.de 905 Wim Henderickx 906 Nokia 907 Email: wim.henderickx@nokia.com 909 Jeff Tantsura 910 Email: jefftant@gmail.com 911 Edward Crabbe 912 Email: edward.crabbe@gmail.com 914 Igor Milojevic 915 Email: milojevicigor@gmail.com 917 Saku Ytti 918 Email: saku@ytti.fi 920 8. Acknowledgements 922 The authors would like to thank Les Ginsberg and Shah Himanshu for 923 their comments on this document. 925 This document was prepared using 2-Word-v2.0.template.dot. 927 9. References 929 9.1. Normative References 931 [I-D.ietf-spring-segment-routing] Filsfils, C., Previdi, S., 932 Decraene, B., Litkowski, S., and R. Shakir, "Segment 933 Routing Architecture", draft-ietf-spring-segment-routing-12 934 (work in progress), June 2017. 936 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 937 Requirement Levels", BCP 14, RFC 2119, DOI 938 0.17487/RFC2119, March 1997, . 941 [RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol 942 Label Switching Architecture", RFC 3031, DOI 943 10.17487/RFC3031, January 2001, . 946 [RFC3032] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y., 947 Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack 948 Encoding", RFC 3032, DOI 10.17487/RFC3032, January 2001, 949 . 951 [reserved-MPLS] "Special-Purpose Multiprotocol Label Switching (MPLS) 952 Label Values", 955 9.2. Informative References 957 [I-D.ietf-isis-segment-routing-extensions] Previdi, S., Filsfils, C., 958 Bashandy, A., Gredler, H., Litkowski, S., Decraene, B., and 959 j. jefftant@gmail.com, "IS-IS Extensions for Segment 960 Routing", draft-ietf-isis-segment-routing-extensions-13 961 (work in progress), June 2017. 963 [I-D.ietf-ospf-ospfv3-segment-routing-extensions] Psenak, P., 964 Previdi, S., Filsfils, C., Gredler, H., Shakir, R., 965 Henderickx, W., and J. Tantsura, "OSPFv3 Extensions for 966 Segment Routing", draft-ietf-ospf-ospfv3- segment-routing- 967 extensions-09 (work in progress), March 2017. 969 [I-D.ietf-ospf-segment-routing-extensions] Psenak, P., Previdi, S., 970 Filsfils, C., Gredler, H., Shakir, R., Henderickx, W., and 971 J. Tantsura, "OSPF Extensions for Segment Routing", draft- 972 ietf-ospf-segment- routing-extensions-16 (work in 973 progress), May 2017. 975 [I-D.ietf-spring-segment-routing-ldp-interop] Filsfils, C., Previdi, 976 S., Bashandy, A., Decraene, B., and S. Litkowski, "Segment 977 Routing interworking with LDP", draft-ietf-spring-segment- 978 routing-ldp-interop-08 (work in progress), June 2017. 980 [RFC7855] Previdi, S., Ed., Filsfils, C., Ed., Decraene, B., 981 Litkowski, S., Horneffer, M., and R. Shakir, "Source Packet 982 Routing in Networking (SPRING) Problem Statement and 983 Requirements", RFC 7855, DOI 10.17487/RFC7855, May 2016, 984 . 986 [RFC5036] Andersson, L., Acreo, AB, Minei, I., Thomas, B., " LDP 987 Specification", RFC5036, DOI 10.17487/RFC5036, October 988 2007, 990 [RFC7510] Xu, X., Sheth, N., Yong, L., Callon, R., and D. Black, 991 "Encapsulating MPLS in UDP", RFC 7510, DOI 992 10.17487/RFC7510, April 2015, . 995 [RFC4817] Townsley, M., Pignataro, C., Wainner, S., Seely, T., Young, 996 T., "Encapsulation of MPLS over Layer 2 Tunneling Protocol 997 Version 3", RFC4817, DOI 10.17487/RFC4817, March 2007, 998 1000 [I-D.ietf-idr-segment-routing-te-policy] Previdi, S., Filsfils, C., 1001 Mattes, P., Rosen, E., Lin, S., " Advertising Segment 1002 Routing Policies in BGP", draft- ietf-idr-segment-routing- 1003 te-policy-00 (work in progress), July 2017 1005 [I.D. filsfils-spring-segment-routing-policy] Filsfils, C., 1006 Sivabalan, S., Raza, K., Liste, J. , Clad, F., Voyer, D., 1007 Lin, S., Bogdanov, A., Horneffer, M., Steinberg, D., 1008 Decraene, B. , Litkowski, S., " Segment Routing Policy for 1009 Traffic Engineering", draft-filsfils-spring-segment- 1010 routing-policy-01 (work in progress), July 2017 1011 Authors' Addresses 1013 Ahmed Bashandy 1014 Cisco Systems, Inc. 1015 170, West Tasman Drive 1016 San Jose, CA 95134 1017 US 1019 Email: bashandy@cisco.com 1021 Clarence Filsfils (editor) 1022 Cisco Systems, Inc. 1023 Brussels 1024 BE 1026 Email: cfilsfil@cisco.com 1028 Stefano Previdi (editor) 1029 Cisco Systems, Inc. 1030 Italy 1032 Email: stefano@previdi.net 1034 Bruno Decraene 1035 Orange 1036 FR 1038 Email: bruno.decraene@orange.com 1040 Stephane Litkowski 1041 Orange 1042 FR 1044 Email: stephane.litkowski@orange.com 1046 Rob Shakir 1047 Google 1048 US 1050 Email: robjs@google.com