idnits 2.17.1 draft-ietf-spring-segment-routing-mpls-18.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. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (December 9, 2018) is 1937 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: 'RFC8042' is mentioned on line 341, but not defined == Missing Reference: '16000-17000' is mentioned on line 574, but not defined == Missing Reference: '20000-21000' is mentioned on line 576, but not defined -- Looks like a reference, but probably isn't: '1000' on line 1500 -- Looks like a reference, but probably isn't: '5000' on line 1103 -- Looks like a reference, but probably isn't: '1999' on line 1500 == 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 == Outdated reference: A later version (-22) exists of draft-ietf-spring-segment-routing-policy-01 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 Arrcus 3 Intended status: Standards Track C. Filsfils, Ed. 4 Expires: June 2019 S. Previdi, 5 Cisco Systems, Inc. 6 B. Decraene 7 S. Litkowski 8 Orange 9 R. Shakir 10 Google 11 December 9, 2018 13 Segment Routing with MPLS data plane 14 draft-ietf-spring-segment-routing-mpls-18 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 June 9, 2019. 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.....................................4 61 2. MPLS Instantiation of Segment Routing..........................4 62 2.1. Multiple Forwarding Behaviors for the Same Prefix.........5 63 2.2. SID Representation in the MPLS Forwarding Plane...........5 64 2.3. Segment Routing Global Block and Local Block..............6 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..................................10 68 2.5.2. Redistribution between Routing Protocol Instances...13 69 2.5.2.1. Illustration...................................13 70 2.5.2.2. Illustration 2.................................14 71 2.6. Effect of Incoming Label Collision on Outgoing Label 72 Programming...................................................14 73 2.7. PUSH, CONTINUE, and NEXT.................................14 74 2.7.1. PUSH................................................15 75 2.7.2. CONTINUE............................................15 76 2.7.3. NEXT................................................15 77 2.7.3.1. Mirror SID.....................................15 78 2.8. MPLS Label Downloaded to FIB for Global and Local SIDs...16 79 2.9. Active Segment...........................................16 80 2.10. Forwarding behavior for Global SIDs.....................16 81 2.10.1. Forwarding for PUSH and CONTINUE of Global SIDs....16 82 2.10.2. Forwarding for NEXT Operation for Global SIDs......18 83 2.11. Forwarding Behavior for Local SIDs......................18 84 2.11.1. Forwarding for PUSH Operation on Local SIDs........18 85 2.11.2. Forwarding for CONTINUE Operation for Local SIDs...19 86 2.11.3. Outgoing label for NEXT Operation for Local SIDs...19 87 3. IANA Considerations...........................................19 88 4. Manageability Considerations..................................19 89 5. Security Considerations.......................................19 90 6. Contributors..................................................19 91 7. Acknowledgements..............................................20 92 8. References....................................................20 93 8.1. Normative References.....................................20 94 8.2. Informative References...................................21 95 9. Authors' Addresses............................................24 96 Appendix A. Examples.............................................26 97 A.1. IGP Segments Example.....................................26 98 A.2. Incoming Label Collision Examples........................28 99 A.2.1. Example 1...........................................28 100 A.2.2. Example 2...........................................29 101 A.2.3. Example 3...........................................30 102 A.2.4. Example 4...........................................30 103 A.2.5. Example 5...........................................31 104 A.2.6. Example 6...........................................31 105 A.2.7. Example 7...........................................32 106 A.2.8. Example 8...........................................32 107 A.2.9. Example 9...........................................33 108 A.2.10. Example 10.........................................33 109 A.2.11. Example 11.........................................34 110 A.2.12. Example 12.........................................35 111 A.2.13. Example 13.........................................35 112 A.2.14. Example 14.........................................36 113 A.3. Examples for the Effect of Incoming Label Collision on 114 Outgoing Label................................................36 115 A.3.1. Example 1...........................................36 116 A.3.2. Example 2...........................................37 118 1. Introduction 120 The Segment Routing architecture RFC8402 can be directly applied to 121 the MPLS architecture with no change in the MPLS forwarding plane. 122 This document specifies the forwarding plane behavior to allow 123 Segment Routing to operate on top of the MPLS data plane. This 124 document does not address the control plane behavior. Control plane 125 behavior is specified in other documents such as [I-D.ietf-isis- 126 segment-routing-extensions], [I-D.ietf-ospf-segment-routing- 127 extensions], and [I-D.ietf-ospf-ospfv3-segment-routing-extensions]. 129 The Segment Routing problem statement is described in [RFC7855]. 131 Co-existence of SR over MPLS forwarding plane with LDP [RFC5036] is 132 specified in [I-D.ietf-spring-segment-routing-ldp-interop]. 134 Policy routing and traffic engineering using segment routing can be 135 found in [I-D.ietf-spring-segment-routing-policy] 137 1.1. Requirements Language 139 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 140 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 141 "OPTIONAL" in this document are to be interpreted as described in BCP 142 14 [RFC2119] [RFC8174] when, and only when, they appear in all 143 capitals, as shown here. 145 2. MPLS Instantiation of Segment Routing 147 MPLS instantiation of Segment Routing fits in the MPLS architecture 148 as defined in [RFC3031] both from a control plane and forwarding 149 plane perspective: 151 o From a control plane perspective, [RFC3031] does not mandate a 152 single signaling protocol. Segment Routing makes use of various 153 control plane protocols such as link state IGPs [I-D.ietf-isis- 154 segment-routing-extensions], [I-D.ietf-ospf-segment-routing- 155 extensions] and [I-D.ietf-ospf-ospfv3-segment-routing-extensions]. 156 The flooding mechanisms of link state IGPs fits very well with 157 label stacking on ingress. Future control layer protocol and/or 158 policy/configuration can be used to specify the label stack. 160 o From a forwarding plane perspective, Segment Routing does not 161 require any change to the forwarding plane because Segment IDs 162 (SIDs) are instantiated as MPLS labels and the Segment routing 163 header instantiated as a stack of MPLS labels. 165 We call "MPLS Control Plane Client (MCC)" any control plane entity 166 installing forwarding entries in the MPLS data plane. IGPs with SR 167 extensions [I-D.ietf-isis-segment-routing-extensions], [I-D.ietf- 168 ospf-segment-routing-extensions], [I-D.ietf-ospf-ospfv3-segment- 169 routing-extensions] and LDP [RFC5036] are examples of MCCs. Local 170 configuration and policies applied on a router are also examples of 171 MCCs. 173 In order to have a node segment to reach the node, a network operator 174 SHOULD configure at least one node segment per routing instance, 175 topology, algorithm. Otherwise, the node is not reachable within the 176 routing instance, topology or along the routing algorithm, which 177 restrict its ability to be used by a SR policy, including for TI-LFA. 178 An implementation MAY check that an IGP node-SID is not associated 179 with a prefix that is owned by more than one router within the same 180 routing domain. If so, it SHOULD NOT use this Node-SID, MAY use 181 another one if available, and SHOULD log an error. 183 2.1. Multiple Forwarding Behaviors for the Same Prefix 185 The SR architecture does not prohibit having more than one SID for 186 the same prefix. In fact, by allowing multiple SIDs for the same 187 prefix, it is possible to have different forwarding behaviors (such 188 as different paths, different ECMP/UCMP behaviors,...,etc) for the 189 same destination. 191 Instantiating Segment routing over the MPLS forwarding plane fits 192 seamlessly with this principle. An operator may assign multiple MPLS 193 labels or indices to the same prefix and assign different forwarding 194 behaviors to each label/SID. The MCC in the network downloads 195 different MPLS labels/SIDs to the FIB for different forwarding 196 behaviors. The MCC at the entry of an SR domain or at any point in 197 the domain can choose to apply a particular forwarding behavior to a 198 particular packet by applying the PUSH action to that packet using 199 the corresponding SID. 201 2.2. SID Representation in the MPLS Forwarding Plane 203 When instantiating SR over the MPLS forwarding plane, a SID is 204 represented by an MPLS label or an index [RFC8402]. 206 A global segment MUST be a label, or an index which may be mapped to 207 an MPLS label within the Segment Routing Global Block (SRGB) of the 208 node installing the global segment in its FIB/receiving the labeled 209 packet. Section 2.4 specifies the procedure to map a global segment 210 represented by an index to an MPLS label within the SRGB. 212 The MCC MUST ensure that any label value corresponding to any SID it 213 installs in the forwarding plane follows the following rules: 215 o The label value MUST be unique within the router on which the MCC 216 is running. i.e. the label MUST only be used to represent the SID 217 and MUST NOT be used to represent more than one SID or for any 218 other forwarding purpose on the router. 220 o The label value MUST NOT come from the range of special purpose 221 labels [RFC7274]. 223 Labels allocated in this document are considered per platform down- 224 stream allocated labels [RFC3031]. 226 2.3. Segment Routing Global Block and Local Block 228 The concepts of Segment Routing Global Block (SRGB) and global SID 229 are explained in [RFC8402]. In general, the SRGB need not be a 230 contiguous range of labels. 232 For the rest of this document, the SRGB is specified by the list of 233 MPLS Label ranges [Ll(1),Lh(1)], [Ll(2),Lh(2)],..., [Ll(k),Lh(k)] 234 where Ll(i) =< Lh(i). 236 The following rules apply to the list of MPLS ranges representing the 237 SRGB 239 o The list of ranges comprising the SRGB MUST NOT overlap. 241 o Every range in the list of ranges specifying the SRGB MUST NOT 242 cover or overlap with a reserved label value or range [RFC7274], 243 respectively. 245 o If the SRGB of a node does not conform to the structure specified 246 in this section or to the previous two rules, then this SRGB MUST 247 be completely ignored by all routers in the routing domain and the 248 node MUST be treated as if it does not have an SRGB. 250 o The list of label ranges MUST only be used to instantiate global 251 SIDs into the MPLS forwarding plane 253 A Local segment MAY be allocated from the Segment Routing Local Block 254 (SRLB) [RFC8402] or from any unused label as long as it does not use 255 a special purpose label. The SRLB consists of the range of local 256 labels reserved by the node for certain local segments. In a 257 controller-driven network, some controllers or applications MAY use 258 the control plane to discover the available set of local SIDs on a 259 particular router [I-D.ietf-spring-segment-routing-policy]. The rules 260 applicable to the SRGB are also applicable to the SRLB, except rule 261 that says that the SRGB MUST only be used to instantiate global SIDs 262 into the MPLS forwarding plane. The recommended, minimum, or maximum 263 size of the SRGB and/or SRLB is a matter of future study 265 2.4. Mapping a SID Index to an MPLS label 267 This sub-section specifies how the MPLS label value is calculated 268 given the index of a SID. The value of the index is determined by an 269 MCC such as IS-IS [I-D.ietf-isis-segment-routing-extensions] or OSPF 270 [I-D.ietf-ospf-segment-routing-extensions]. This section only 271 specifies how to map the index to an MPLS label. The calculated MPLS 272 label is downloaded to the FIB, sent out with a forwarded packet, or 273 both. 275 Consider a SID represented by the index "I". Consider an SRGB as 276 specified in Section 2.3. The total size of the SRGB, represented by 277 the variable "Size", is calculated according to the formula: 279 size = Lh(1)- Ll(1) + 1 + Lh(2)- Ll(2) + 1 + ... + Lh(k)- Ll(k) + 1 281 The following rules MUST be applied by the MCC when calculating the 282 MPLS label value corresponding the SID index value "I". 284 o 0 =< I < size. If the index "I" does not satisfy the previous 285 inequality, then the label cannot be calculated. 287 o The label value corresponding to the SID index "I" is calculated 288 as follows 290 o j = 1 , temp = 0 292 o While temp + Lh(j)- Ll(j) < I 294 . temp = temp + Lh(j)- Ll(j) + 1 296 . j = j+1 298 o label = I - temp + Ll(j) 300 An example for how a router calculates labels and forwards traffic 301 based on the procedure described in this section can be found in 302 Appendix A.1. 304 2.5. Incoming Label Collision 306 MPLS Architecture [RFC3031] defines Forwarding Equivalence Class 307 (FEC) term as the set of packets with similar and / or identical 308 characteristics which are forwarded the same way and are bound to the 309 same MPLS incoming (local) label. In Segment-Routing MPLS, local 310 label serves as the SID for given FEC. 312 We define Segment Routing (SR) FEC as one of the following [RFC8402]: 314 o (Prefix, Routing Instance, Topology, Algorithm [RFC8402]), where a 315 topology identifies a set of links with metrics. For the purpose 316 of incoming label collision resolution, the same Topology 317 numerical value SHOULD be used on all routers to identify the same 318 set of links with metrics. For MCCs where the "Topology" and/or 319 "Algorithm" fields are not defined, the numerical value of zero 320 MUST be used for these two fields. For the purpose of incoming 321 label collision resolution, a routing instance is identified by a 322 single incoming label downloader to FIB. Two MCCs running on the 323 same router are considered different routing instances if the only 324 way the two instances can know about the other's incoming labels 325 is through redistribution. The numerical value used to identify a 326 routing instance MAY be derived from other configuration or MAY be 327 explicitly configured. If it is derived from other configuration, 328 then the same numerical value SHOULD be derived from the same 329 configuration as long as the configuration survives router reload. 330 If the derived numerical value varies for the same configuration, 331 then an implementation SHOULD make numerical value used to 332 identify a routing instance configurable. 334 o (next-hop, outgoing interface), where the outgoing interface is 335 physical or virtual. 337 o (number of adjacencies, list of next-hops, list of outgoing 338 interfaces IDs in ascending numerical order). This FEC represents 339 parallel adjacencies [RFC8402] 341 o (Endpoint, Color) representing an SR policy [RFC8042] 343 o (Mirrored SID) The Mirrored SID [RFC8042, Section 5.1] is the IP 344 address advertised by the advertising node to identify the mirror- 345 SID. The IP address is encoded as specified in Section 2.5.1. 347 This section covers the RECOMMENDED procedure to handle the scenario 348 where, because of an error/misconfiguration, more than one SR FEC as 349 defined in this section, map to the same incoming MPLS label. 350 Examples illustrating the behavior specified in this section can be 351 found in Appendix A.2. 353 An incoming label collision occurs if the SIDs of the set of FECs 354 {FEC1, FEC2,..., FECk} maps to the same incoming SR MPLS label "L1". 356 Suppose an anycast prefix is advertised with a prefix-SID by some, 357 but not all, of the nodes that advertise that prefix. If the prefix- 358 SID subTLVs result in mapping that anycast prefix to the same 359 incoming label, then the advertisement of the prefix-SID by some, but 360 not all, of advertising nodes SHOULD NOT be treated as a label 361 collision. 363 An implementation MUST NOT allow the MCCs belonging to the same 364 router to assign the same incoming label to more than one SR FEC. An 365 implementation that allows such behavior is considered as faulty. 366 Procedures defined in this document equally applies to this case, 367 both for incoming label collision (Section 2.5) and the effect on 368 outgoing label programming (Section 2.6). 370 The objective of the following steps is to deterministically install 371 in the MPLS Incoming Label Map, also known as label FIB, a single FEC 372 with the incoming label "L1". Remaining FECs may be installed in the 373 IP FIB without incoming label. 375 The procedure in this section relies completely on the local FEC and 376 label database within a given router. 378 The collision resolution procedure is as follows 380 1. Given the SIDs of the set of FECs, {FEC1, FEC2,..., FECk} map to 381 the same MPLS label "L1". 383 2. Within an MCC, apply tie-breaking rules to select one FEC only and 384 assign the label to it. The losing FECs are handled as if no 385 labels are attached to them. The losing FECs with a non-zero 386 algorithm are not installed in FIB. 388 a. If the same set of FECs are attached to the same label "L1", 389 then the tie-breaking rules MUST always select the same FEC 390 irrespective of the order in which the FECs and the label "L1" 391 are received. In other words, the tie-breaking rule MUST be 392 deterministic. For example, a first-come-first-serve tie- 393 breaking is not allowed. 395 3. If there is still collision between the FECs belonging to 396 different MCCs, then re-apply the tie-breaking rules to the 397 remaining FECs to select one FEC only and assign the label to that 398 FEC 400 4. Install into the IP FIB the selected FEC and its incoming label in 401 the label FIB. 403 5. The remaining FECs with the default algorithm (see the 404 specification of prefix-SID algorithm [RFC8402]) are installed in 405 the FIB natively, such as pure IP entries in case of Prefix FEC, 406 without any incoming labels corresponding to their SIDs. The 407 remaining FECs with a non-zero algorithm are not installed in the 408 FIB. 410 2.5.1. Tie-breaking Rules 412 The default tie-breaking rules SHOULD be as follows: 414 1. if FECi has the lowest FEC administrative distance among the 415 competing FECs as defined in this section below, filter away all 416 the competing FECs with higher administrative distance. 418 2. if more than one competing FEC remains after step 1, select the 419 smallest numerical FEC value 421 These rules deterministically select the FEC to install in the MPLS 422 forwarding plane for the given incoming label. 424 This document defines the default tie breaking rules that SHOULD be 425 implemented. An implementation MAY choose to implement additional 426 tie-breaking rules. All routers in a routing domain SHOULD use the 427 same tie-breaking rules to maximize forwarding consistency. 429 Each FEC is assigned an administrative distance. The FEC 430 administrative distance is encoded as an 8-bit value. The lower the 431 value, the better the administrative distance. 433 The default FEC administrative distance order starting from the 434 lowest value SHOULD be 436 o Explicit SID assignment to a FEC that maps to a label outside the 437 SRGB irrespective of the owner MCC. An explicit SID assignment is 438 a static assignment of a label to a FEC such that the assignment 439 survives router reboot. 441 o An example of explicit SID allocation is static assignment of 442 a specific label to an adj-SID. 444 o An implementation of explicit SID assignment MUST guarantee 445 collision freeness on the same router 447 o Dynamic SID assignment: 449 o For all FEC types except for SR policy, the FEC types are 450 ordered using the default administrative distance ordering 451 defined by the implementation. 453 o Binding SID [RFC8402] assigned to SR Policy always has a 454 higher default administrative distance than the default 455 administrative distance of any other FEC type 457 A user SHOULD ensure that the same administrative distance preference 458 is used on all routers to maximize forwarding consistency. 460 The numerical sort across FECs SHOULD be performed as follows: 462 o Each FEC is assigned a FEC type encoded in 8 bits. The following 463 are the type code point for each SR FEC defined at the beginning 464 of this Section: 466 o 120: (Prefix, Routing Instance, Topology, Algorithm) 468 o 130: (next-hop, outgoing interface) 470 o 140: Parallel Adjacency [RFC8402] 472 o 150: an SR policy [RFC8402]. 474 o 160: Mirror SID [RFC8402] 476 o The numerical values above are mentioned to guide 477 implementation. If other numerical values are used, then the 478 numerical values must maintain the same greater-than ordering 479 of the numbers mentioned here. 481 o The fields of each FEC are encoded as follows 483 o Routing Instance ID represented by 16 bits. For routing 484 instances that are identified by less than 16 bits, encode the 485 Instance ID in the least significant bits while the most 486 significant bits are set to zero 488 o Address Family represented by 8 bits, where IPv4 encoded as 489 100 and IPv6 is encoded as 110. These numerical values are 490 mentioned to guide implementations. If other numerical values 491 are used, then the numerical value of IPv4 MUST be less than 492 the numerical value for IPv6 494 o All addresses are represented in 128 bits as follows 495 . IPv6 address is encoded natively 497 . IPv4 address is encoded in the most significant bits and 498 the remaining bits are set to zero 500 o All prefixes are represented by (128 + 8) bits. 502 . A prefix is encoded in the most significant bits and the 503 remaining bits are set to zero. 505 . The prefix length is encoded before the prefix in a field 506 of size 8 bits. 508 o Topology ID is represented by 16 bits. For routing instances 509 that identify topologies using less than 16 bits, encode the 510 topology ID in the least significant bits while the most 511 significant bits are set to zero 513 o Algorithm is encoded in a 16 bits field. 515 o The Color ID is encoded using 32 bits 517 o Choose the set of FECs of the smallest FEC type code point 519 o Out of these FECs, choose the FECs with the smallest address 520 family code point 522 o Encode the remaining set of FECs as follows 524 o Prefix, Routing Instance, Topology, Algorithm: (Prefix Length, 525 Prefix, routing_instance_id, Topology, SR Algorithm,) 527 o (next-hop, outgoing interface): (next-hop, 528 outgoing_interface_id) 530 o (number of adjacencies, list of next-hops in ascending 531 numerical order, list of outgoing interface IDs in ascending 532 numerical order). This encoding is used to encode a parallel 533 adjacency [RFC8402] 535 o (Endpoint, Color): (Endpoint_address, Color_id) 537 o (IP address): This is the encoding for a mirror SID FEC. The IP 538 address is encoded as described above in this section 540 o Select the FEC with the smallest numerical value 541 The numerical values mentioned in this section are for guidance only. 542 If other numerical values are used then the other numerical values 543 MUST maintain the same numerical ordering among different 545 2.5.2. Redistribution between Routing Protocol Instances 547 The following rule SHOULD be applied when redistributing SIDs with 548 prefixes between routing protocol instances: 550 o If the receiving instance's SRGB is the same as the SRGB of origin 551 instance, then 553 o the index is redistributed with the route 555 o Else 557 o the index is not redistributed and if needed it is the duty of 558 the receiving instance to allocate a fresh index relative to 559 its own SRGB. Note that in that case, the receiving instance 560 MUST compute its local label according to section 2.4 and 561 install it in FIB. 563 It is outside the scope of this document to define local node 564 behaviors that would allow to map the original index into a new index 565 in the receiving instance via the addition of an offset or other 566 policy means. 568 2.5.2.1. Illustration 570 A----IS-IS----B---OSPF----C-192.0.2.1/32 (20001) 572 Consider the simple topology above. 574 o A and B are in the IS-IS domain with SRGB [16000-17000] 576 o B and C are in OSPF domain with SRGB [20000-21000] 578 o B redistributes 192.0.2.1/32 into IS-IS domain 580 o In that case A learns 192.0.2.1/32 as an IP leaf connected to B as 581 usual for IP prefix redistribution 583 o However, according to the redistribution rule above rule, B 584 decides not to advertise any index with 192.0.2.1/32 into IS-IS 585 because the SRGB is not the same. 587 2.5.2.2. Illustration 2 589 Consider the example in the illustration described in Section 590 2.5.2.1. 592 When router B redistributes the prefix 192.0.2.1/32, router B decides 593 to allocate and advertise the same index 1 with the prefix 594 192.0.2.1/32 596 Within the SRGB of the IS-IS domain, index 1 corresponds to the local 597 label 16001 599 o Hence according to the redistribution rule above, router B 600 programs the incoming label 16001 in its FIB to match traffic 601 arriving from the IS-IS domain destined to the prefix 602 192.0.2.1/32. 604 2.6. Effect of Incoming Label Collision on Outgoing Label Programming 606 For the determination of the outgoing label to use, the ingress node 607 pushing new segments, and hence a stack of MPLS labels, MUST use, for 608 a given FEC, the same label that has been selected by the node 609 receiving the packet with that label exposed as top label. So in case 610 of incoming label collision on this receiving node, the ingress node 611 MUST resolve this collision using this same "Incoming Label Collision 612 resolution procedure", using the data of the receiving node. 614 In the general case, the ingress node may not have exactly the same 615 data of the receiving node, so the result may be different. This is 616 under the responsibility of the network operator. But in typical 617 case, e.g. where a centralized node or a distributed link state IGP 618 is used, all nodes would have the same database. However to minimize 619 the chance of misforwarding, a FEC that loses its incoming label to 620 the tie-breaking rules specified in Section 2.5 MUST NOT be 621 installed in FIB with an outgoing segment routing label based on the 622 SID corresponding to the lost incoming label. 624 Examples for the behavior specified in this section can be found in 625 Appendix A.3. 627 2.7. PUSH, CONTINUE, and NEXT 629 PUSH, NEXT, and CONTINUE are operations applied by the forwarding 630 plane. The specifications of these operations can be found in 631 [RFC8402]. This sub-section specifies how to implement each of these 632 operations in the MPLS forwarding plane. 634 2.7.1. PUSH 636 PUSH corresponds to pushing one or more labels on top of an incoming 637 packet then sending it out of a particular physical interface or 638 virtual interface, such as UDP tunnel [RFC7510] or L2TPv3 tunnel 639 [RFC4817], towards a particular next-hop. When pushing labels onto a 640 packet's label stack, the Time-to-Live (TTL) field ([RFC3032], 641 [RFC3443]) and the Traffic Class (TC) field ([RFC3032], [RFC5462]) of 642 each label stack entry must, of course, be set. This document does 643 not specify any set of rules for setting these fields; that is a 644 matter of local policy. Sections 2.10 and 2.11 specify additional 645 details about forwarding behavior. 647 2.7.2. CONTINUE 649 In the MPLS forwarding plane, the CONTINUE operation corresponds to 650 swapping the incoming label with an outgoing label. The value of the 651 outgoing label is calculated as specified in Sections 2.10 and 2.11. 653 2.7.3. NEXT 655 In the MPLS forwarding plane, NEXT corresponds to popping the topmost 656 label. The action before and/or after the popping depends on the 657 instruction associated with the active SID on the received packet 658 prior to the popping. For example suppose the active SID in the 659 received packet was an Adj-SID [RFC8402], then on receiving the 660 packet, the node applies NEXT operation, which corresponds to popping 661 the top most label, and then sends the packet out of the physical or 662 virtual interface (e.g. UDP tunnel [RFC7510] or L2TPv3 tunnel 663 [RFC4817]) towards the next-hop corresponding to the adj-SID. 665 2.7.3.1. Mirror SID 667 If the active SID in the received packet was a Mirror SID [RFC8402, 668 Section 5.1] allocated by the receiving router, then the receiving 669 router applies NEXT operation, which corresponds to popping the top 670 most label, then performs a lookup using the contents of the packet 671 after popping the outer most label in the mirrored forwarding table. 672 The method by which the lookup is made, and/or the actions applied to 673 the packet after the lookup in the mirror table depends on the 674 contents of the packet and the mirror table. Note that the packet 675 exposed after popping the top most label may or may not be an MPLS 676 packet. A mirror SID can be viewed as a generalization of the context 677 label in [RFC5331] because a mirror SID does not make any 678 assumptions about the packet underneath the top label. 680 2.8. MPLS Label Downloaded to FIB for Global and Local SIDs 682 The label corresponding to the global SID "Si" represented by the 683 global index "I" downloaded to FIB is used to match packets whose 684 active segment (and hence topmost label) is "Si". The value of this 685 label is calculated as specified in Section 2.4. 687 For Local SIDs, the MCC is responsible for downloading the correct 688 label value to FIB. For example, an IGP with SR extensions [I-D.ietf- 689 isis-segment-routing-extensions, I-D.ietf-ospf-segment-routing- 690 extensions] allocates and downloads the MPLS label corresponding to 691 an Adj-SID [RFC8402]. 693 2.9. Active Segment 695 When instantiated in the MPLS domain, the active segment on a packet 696 corresponds to the topmost label on the packet that is calculated 697 according to the procedure specified in Sections 2.10 and 2.11. When 698 arriving at a node, the topmost label corresponding to the active SID 699 matches the MPLS label downloaded to FIB as specified in Section 2.4. 701 2.10. Forwarding behavior for Global SIDs 703 This section specifies forwarding behavior, including the calculation 704 of outgoing labels, that corresponds to a global SID when applying 705 PUSH, CONTINUE, and NEXT operations in the MPLS forwarding plane. 707 This document covers the calculation of the outgoing label for the 708 top label only. The case where the outgoing label is not the top 709 label and is part of a stack of labels that instantiates a routing 710 policy or a traffic engineering tunnel is outside the scope of this 711 document and may be covered in other documents such as [I-D.ietf- 712 spring-segment-routing-policy]. 714 2.10.1. Forwarding for PUSH and CONTINUE of Global SIDs 716 Suppose an MCC on a router "R0" determines that PUSH or CONTINUE 717 operation is to be applied to an incoming packet related to the 718 global SID "Si" represented by the global index "I" and owned by the 719 router Ri before sending the packet towards a neighbor "N" directly 720 connected to "R0" through a physical or virtual interface such as UDP 721 tunnel [RFC7510] or L2TPv3 tunnel [RFC4817]. 723 The method by which the MCC on router "R0" determines that PUSH or 724 CONTINUE operation must be applied using the SID "Si" is beyond the 725 scope of this document. An example of a method to determine the SID 726 "Si" for PUSH operation is the case where IS-IS [I-D.ietf-isis- 727 segment-routing-extensions] receives the prefix-SID "Si" sub-TLV 728 advertised with prefix "P/m" in TLV 135 and the destination address 729 of the incoming IPv4 packet is covered by the prefix "P/m". 731 For CONTINUE operation, an example of a method to determine the SID 732 "Si" is the case where IS-IS [I-D.ietf-isis-segment-routing- 733 extensions] receives the prefix-SID "Si" sub-TLV advertised with 734 prefix "P" in TLV 135 and the top label of the incoming packet 735 matches the MPLS label in FIB corresponding to the SID "Si" on the 736 router "R0". 738 The forwarding behavior for PUSH and CONTINUE corresponding to the 739 SID "Si" 741 o If the neighbor "N" does not support SR or advertises an invalid 742 SRGB or a SRGB that is too small for the SID "Si" 744 o If it is possible to send the packet towards the neighbor "N" 745 using standard MPLS forwarding behavior as specified in 746 [RFC3031] and [RFC3032], then forward the packet. The method 747 by which a router decides whether it is possible to send the 748 packet to "N" or not is beyond the scope of this document. For 749 example, the router "R0" can use the downstream label 750 determined by another MCC, such as LDP [RFC5036], to send the 751 packet. 753 o Else if there are other useable next-hops, then use other next- 754 hops to forward the incoming packet. The method by which the 755 router "R0" decides on the possibility of using other next- 756 hops is beyond the scope of this document. For example, the 757 MCC on "R0" may chose the send an IPv4 packet without pushing 758 any label to another next-hop. 760 o Otherwise drop the packet. 762 o Else 764 o Calculate the outgoing label as specified in Section 2.4 using 765 the SRGB of the neighbor "N" 767 o If the operation is PUSH 769 . Push the calculated label according the MPLS label 770 pushing rules specified in [RFC3032] 772 o Else 773 . swap the incoming label with the calculated label 774 according to the label swapping rules in [RFC3032] 776 o Send the packet towards the neighbor "N" 778 2.10.2. Forwarding for NEXT Operation for Global SIDs 780 As specified in Section 2.7.3 NEXT operation corresponds to popping 781 the top most label. The forwarding behavior is as follows 783 o Pop the topmost label 785 o Apply the instruction associated with the incoming label that has 786 been popped 788 The action on the packet after popping the topmost label depends on 789 the instruction associated with the incoming label as well as the 790 contents of the packet right underneath the top label that got 791 popped. Examples of NEXT operation are described in Appendix A.1. 793 2.11. Forwarding Behavior for Local SIDs 795 This section specifies the forwarding behavior for local SIDs when SR 796 is instantiated over the MPLS forwarding plane. 798 2.11.1. Forwarding for PUSH Operation on Local SIDs 800 Suppose an MCC on a router "R0" determines that PUSH operation is to 801 be applied to an incoming packet using the local SID "Si" before 802 sending the packet towards a neighbor "N" directly connected to R0 803 through a physical or virtual interface such as UDP tunnel [RFC7510] 804 or L2TPv3 tunnel [RFC4817]. 806 An example of such local SID is an Adj-SID allocated and advertised 807 by IS-IS [I-D.ietf-isis-segment-routing-extensions]. The method by 808 which the MCC on "R0" determines that PUSH operation is to be applied 809 to the incoming packet is beyond the scope of this document. An 810 example of such method is backup path used to protect against a 811 failure using TI-LFA [I-D.bashandy-rtgwg-segment-routing-ti-lfa]. 813 As mentioned in [RFC8402], a local SID is specified by an MPLS label. 814 Hence the PUSH operation for a local SID is identical to label push 815 operation [RFC3032] using any MPLS label. The forwarding action after 816 pushing the MPLS label corresponding to the local SID is also 817 determined by the MCC. For example, if the PUSH operation was done to 818 forward a packet over a backup path calculated using TI-LFA, then the 819 forwarding action may be sending the packet to a certain neighbor 820 that will in turn continue to forward the packet along the backup 821 path 823 2.11.2. Forwarding for CONTINUE Operation for Local SIDs 825 A local SID on a router "R0" corresponds to a local label. In such 826 scenario, the outgoing label towards a next-hop "N" is determined by 827 the MCC running on the router "R0"and the forwarding behavior for 828 CONTINUE operation is identical to swap operation [RFC3032] on an 829 MPLS label. 831 2.11.3. Outgoing label for NEXT Operation for Local SIDs 833 NEXT operation for Local SIDs is identical to NEXT operation for 834 global SIDs specified in Section 2.10.2. 836 3. IANA Considerations 838 This document does not make any request to IANA. 840 4. Manageability Considerations 842 This document describes the applicability of Segment Routing over the 843 MPLS data plane. Segment Routing does not introduce any change in 844 the MPLS data plane. Manageability considerations described in 845 [RFC8402] applies to the MPLS data plane when used with Segment 846 Routing. SR OAM use cases for the MPLS data plane are defined in 847 [RFC8403]. SR OAM procedures for the MPLS data plane are defined in 848 [RFC8287]. 850 5. Security Considerations 852 This document does not introduce additional security requirements and 853 mechanisms other than the ones described in [RFC8402]. 855 6. Contributors 857 The following contributors have substantially helped the definition 858 and editing of the content of this document: 860 Martin Horneffer 861 Deutsche Telekom 862 Email: Martin.Horneffer@telekom.de 864 Wim Henderickx 865 Nokia 866 Email: wim.henderickx@nokia.com 868 Jeff Tantsura 869 Email: jefftant@gmail.com 870 Edward Crabbe 871 Email: edward.crabbe@gmail.com 873 Igor Milojevic 874 Email: milojevicigor@gmail.com 876 Saku Ytti 877 Email: saku@ytti.fi 879 7. Acknowledgements 881 The authors would like to thank Les Ginsberg, Chris Bowers, Himanshu 882 Shah, Adrian Farrel, Alexander Vainshtein, Przemyslaw Krol, Darren 883 Dukes, and Zafar Ali for their valuable comments on this document. 885 This document was prepared using 2-Word-v2.0.template.dot. 887 8. References 889 8.1. Normative References 891 [RFC8402] Filsfils, C., Previdi, S., Decraene, B., Litkowski, S., and 892 R. Shakir, "Segment Routing Architecture", RFC 8402, DOI 893 10.17487/RFC8402 July 2018, . 896 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 897 Requirement Levels", BCP 14, RFC 2119, DOI 898 0.17487/RFC2119, March 1997, . 901 [RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol 902 Label Switching Architecture", RFC 3031, DOI 903 10.17487/RFC3031, January 2001, . 906 [RFC3032] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y., 907 Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack 908 Encoding", RFC 3032, DOI 10.17487/RFC3032, January 2001, 909 . 911 [RFC3443] P. Agarwal, P. and Akyol, B. "Time To Live (TTL) Processing 912 in Multi-Protocol Label Switching (MPLS) Networks", RFC 913 3443, DOI 10.17487/RFC3443, January 2003, . 916 [RFC5462] Andersson, L., and Asati, R., " Multiprotocol Label 917 Switching (MPLS) Label Stack Entry: "EXP" Field Renamed to 918 "Traffic Class" Field", RFC 5462, DOI 10.17487/RFC5462, 919 February 2009, . 921 [RFC7274] K. Kompella, L. Andersson, and A. Farrel, "Allocating and 922 Retiring Special-Purpose MPLS Labels", RFC7274 DOI 923 10.17487/RFC7274, May 2014 926 [RFC8174] B. Leiba, " Ambiguity of Uppercase vs Lowercase in RFC 2119 927 Key Words", RFC7274 DOI 10.17487/RFC8174, May 2017 928 930 8.2. Informative References 932 [I-D.ietf-isis-segment-routing-extensions] Previdi, S., Filsfils, C., 933 Bashandy, A., Gredler, H., Litkowski, S., Decraene, B., and 934 j. jefftant@gmail.com, "IS-IS Extensions for Segment 935 Routing", draft-ietf-isis-segment-routing-extensions-13 936 (work in progress), June 2017. 938 [I-D.ietf-ospf-ospfv3-segment-routing-extensions] Psenak, P., 939 Previdi, S., Filsfils, C., Gredler, H., Shakir, R., 940 Henderickx, W., and J. Tantsura, "OSPFv3 Extensions for 941 Segment Routing", draft-ietf-ospf-ospfv3-segment-routing- 942 extensions-09 (work in progress), March 2017. 944 [I-D.ietf-ospf-segment-routing-extensions] Psenak, P., Previdi, S., 945 Filsfils, C., Gredler, H., Shakir, R., Henderickx, W., and 946 J. Tantsura, "OSPF Extensions for Segment Routing", draft- 947 ietf-ospf-segment-routing-extensions-16 (work in progress), 948 May 2017. 950 [I-D.ietf-spring-segment-routing-ldp-interop] Filsfils, C., Previdi, 951 S., Bashandy, A., Decraene, B., and S. Litkowski, "Segment 952 Routing interworking with LDP", draft-ietf-spring-segment- 953 routing-ldp-interop-08 (work in progress), June 2017. 955 [I-D.bashandy-rtgwg-segment-routing-ti-lfa], Bashandy, A., Filsfils, 956 C., Decraene, B., Litkowski, S., Francois, P., Voyer, P. 957 Clad, F., and Camarillo, P., "Topology Independent Fast 958 Reroute using Segment Routing", draft-bashandy-rtgwg- 959 segment-routing-ti-lfa-05 (work in progress), October 2018, 961 [RFC7855] Previdi, S., Ed., Filsfils, C., Ed., Decraene, B., 962 Litkowski, S., Horneffer, M., and R. Shakir, "Source Packet 963 Routing in Networking (SPRING) Problem Statement and 964 Requirements", RFC 7855, DOI 10.17487/RFC7855, May 2016, 965 . 967 [RFC5036] Andersson, L., Acreo, AB, Minei, I., Thomas, B., " LDP 968 Specification", RFC5036, DOI 10.17487/RFC5036, October 969 2007, 971 [RFC5331] Aggarwal, R., Rekhter, Y., Rosen, E., " MPLS Upstream Label 972 Assignment and Context-Specific Label Space", RFC5331 DOI 973 10.17487/RFC5331, August 2008, . 976 [RFC7510] Xu, X., Sheth, N., Yong, L., Callon, R., and D. Black, 977 "Encapsulating MPLS in UDP", RFC 7510, DOI 978 10.17487/RFC7510, April 2015, . 981 [RFC4817] Townsley, M., Pignataro, C., Wainner, S., Seely, T., Young, 982 T., "Encapsulation of MPLS over Layer 2 Tunneling Protocol 983 Version 3", RFC4817, DOI 10.17487/RFC4817, March 2007, 984 986 [RFC8287] N. Kumar, C. Pignataro, G. Swallow, N. Akiya, S. Kini, and 987 M. Chen " Label Switched Path (LSP) Ping/Traceroute for 988 Segment Routing (SR) IGP-Prefix and IGP-Adjacency Segment 989 Identifiers (SIDs) with MPLS Data Planes" RFC8287, DOI 990 10.17487/RFC8287, December 2017, https://www.rfc- 991 editor.org/info/rfc8287 993 [RFC8403] R. Geib, C. Filsfils, C. Pignataro, N. Kumar, "A Scalable 994 and Topology-Aware MPLS Data-Plane Monitoring System", 995 RFC8403, DOI 10.17487/RFC8403, July 2018, 998 [I-D.ietf-spring-segment-routing-policy] Filsfils, C., Sivabalan, 999 S., Raza, K., Liste, J. , Clad, F., Voyer, D., Bogdanov, A., 1000 Mattes, P., " Segment Routing Policy for Traffic Engineering", 1001 draft-ietf-spring-segment-routing-policy-01 (work in progress), June 1002 2018 1004 9. Authors' Addresses 1006 Ahmed Bashandy (editor) 1007 Arrcus 1009 Email: abashandy.ietf@gmail.com 1011 Clarence Filsfils (editor) 1012 Cisco Systems, Inc. 1013 Brussels 1014 BE 1016 Email: cfilsfil@cisco.com 1018 Stefano Previdi 1019 Cisco Systems, Inc. 1020 Italy 1022 Email: stefano@previdi.net 1024 Bruno Decraene 1025 Orange 1026 FR 1028 Email: bruno.decraene@orange.com 1029 Stephane Litkowski 1030 Orange 1031 FR 1033 Email: stephane.litkowski@orange.com 1035 Rob Shakir 1036 Google 1037 US 1039 Email: robjs@google.com 1041 Appendix A. Examples 1043 A.1. IGP Segments Example 1045 Consider the network diagram of Figure 1 and the IP address and IGP 1046 Segment allocation of Figure 2. Assume that the network is running 1047 IS-IS with SR extensions [I-D.ietf-isis-segment-routing-extensions] 1048 and all links have the same metric. The following examples can be 1049 constructed. 1051 +--------+ 1052 / \ 1053 R0-----R1-----R2----------R3-----R8 1054 | \ / | 1055 | +--R4--+ | 1056 | | 1057 +-----R5-----+ 1059 Figure 1: IGP Segments - Illustration 1061 +-----------------------------------------------------------+ 1062 | IP address allocated by the operator: | 1063 | 192.0.2.1/32 as a loopback of R1 | 1064 | 192.0.2.2/32 as a loopback of R2 | 1065 | 192.0.2.3/32 as a loopback of R3 | 1066 | 192.0.2.4/32 as a loopback of R4 | 1067 | 192.0.2.5/32 as a loopback of R5 | 1068 | 192.0.2.8/32 as a loopback of R8 | 1069 | 198.51.100.9/32 as an anycast loopback of R4 | 1070 | 198.51.100.9/32 as an anycast loopback of R5 | 1071 | | 1072 | SRGB defined by the operator as 1000-5000 | 1073 | | 1074 | Global IGP SID indices allocated by the operator: | 1075 | 1 allocated to 192.0.2.1/32 | 1076 | 2 allocated to 192.0.2.2/32 | 1077 | 3 allocated to 192.0.2.3/32 | 1078 | 4 allocated to 192.0.2.4/32 | 1079 | 8 allocated to 192.0.2.8/32 | 1080 | 1009 allocated to 198.51.100.9/32 | 1081 | | 1082 | Local IGP SID allocated dynamically by R2 | 1083 | for its "north" adjacency to R3: 9001 | 1084 | for its "north" adjacency to R3: 9003 | 1085 | for its "south" adjacency to R3: 9002 | 1086 | for its "south" adjacency to R3: 9003 | 1087 +-----------------------------------------------------------+ 1089 Figure 2: IGP Address and Segment Allocation - Illustration 1091 Suppose R1 wants to send an IPv4 packet P1 to R8. In this case, R1 1092 needs to apply PUSH operation to the IPv4 packet. 1094 Remember that the SID index "8" is a global IGP segment attached to 1095 the IP prefix 192.0.2.8/32. Its semantic is global within the IGP 1096 domain: any router forwards a packet received with active segment 8 1097 to the next-hop along the ECMP-aware shortest-path to the related 1098 prefix. 1100 R2 is the next-hop along the shortest path towards R8. By applying 1101 the steps in Section 2.8 the outgoing label downloaded to R1's FIB 1102 corresponding to the global SID index 8 is 1008 because the SRGB of 1103 R2 is [1000,5000] as shown in Figure 2. 1105 Because the packet is IPv4, R1 applies the PUSH operation using the 1106 label value 1008 as specified in Section 2.10.1. The resulting MPLS 1107 header will have the "S" bit [RFC3032] set because it is followed 1108 directly by an IPv4 packet. 1110 The packet arrives at router R2. Because the top label 1008 1111 corresponds to the IGP SID "8", which is the prefix-SID attached to 1112 the prefix 192.0.2.8/32 owned by the node R8, then the instruction 1113 associated with the SID is "forward the packet using all ECMP/UCMP 1114 interfaces and all ECMP/UCMP next-hop(s) along the shortest/useable 1115 path(s) towards R8". Because R2 is not the penultimate hop, R2 1116 applies the CONTINUE operation to the packet and sends it to R3 using 1117 one of the two links connected to R3 with top label 1008 as specified 1118 in Section 2.10.1. 1120 R3 receives the packet with top label 1008. Because the top label 1121 1008 corresponds to the IGP SID "8", which is the prefix-SID attached 1122 to the prefix 192.0.2.8/32 owned by the node R8, then the instruction 1123 associated with the SID is "send the packet using all ECMP interfaces 1124 and all next-hop(s) along the shortest path towards R8". Because R3 1125 is the penultimate hop, we assume that R3 performs penumtimate hop 1126 popping, which corresponds to the NEXT operation, then sends the 1127 packet to R8. The NEXT operation results in popping the outer label 1128 and sending the packet as a pure IPv4 packet to R8. 1130 In conclusion, the path followed by P1 is R1-R2--R3-R8. The ECMP- 1131 awareness ensures that the traffic be load-shared between any ECMP 1132 path, in this case the two links between R2 and R3. 1134 A.2. Incoming Label Collision Examples 1136 This section describes few examples to illustrate the handling of 1137 label collision described in Section 2.5. 1139 For the examples in this section, we assume that Node A has the 1140 following: 1142 o OSPF default admin distance for implementation=50 1144 o ISIS default admin distance for implementation=60 1146 A.2.1. Example 1 1148 Illustration of incoming label collision resolution for the same FEC 1149 type using MCC administrative distance. 1151 FEC1: 1153 o OSPF prefix SID advertisement from node B for 198.51.100.5/32 with 1154 index=5 1156 o OSPF SRGB on node A = [1000,1999] 1158 o Incoming label=1005 1160 FEC2: 1161 o ISIS prefix SID advertisement from node C for 203.0.113.105/32 1162 with index=5 1164 o ISIS SRGB on node A = [1000,1999] 1166 o Incoming label=1005 1168 FEC1 and FEC2 both use dynamic SID assignment. Since neither ofthe 1169 FEC types is SR Policy, we use the default admin distances of 50 and 1170 60 to break the tie. So FEC1 wins. 1172 A.2.2. Example 2 1174 Illustration of incoming label collision resolution for different FEC 1175 types using the MCC administrative distance. 1177 FEC1: 1178 o Node A receives an OSPF prefix sid advertisement from node B for 1179 198.51.100.6/32 with index=6 1181 o OSPF SRGB on node A = [1000,1999] 1183 o Hence the incoming label on node A corresponding to 1184 198.51.100.6/32 is 1006 1186 FEC2: 1187 ISIS on node A assigns the label 1006 to the globally significant 1188 adj-SID (I.e. when advertised the "L" flag is clear in the adj-SID 1189 sub-TLV as described in [I-D.ietf-isis-segment-routing-extensions]) 1190 towards one of its neighbors. Hence the incoming label corresponding 1191 to this adj-SID 1006. Assume Node A allocates this adj-SID 1192 dynamically, and it may differ across router reboots. 1194 FEC1 and FEC2 both use dynamic SID assignment. Since neither of the 1195 FEC types is SR Policy, we use the default admin distances of 50 and 1196 60 to break the tie. So FEC1 wins. 1198 A.2.3. Example 3 1200 Illustration of incoming label collision resolution based on 1201 preferring static over dynamic SID assignment 1203 FEC1: 1204 OSPF on node A receives a prefix SID advertisement from node B for 1205 198.51.100.7/32 with index=7. Assuming that the OSPF SRGB on node A 1206 is [1000,1999], then incoming label corresponding to 198.51.100.7/32 1207 is 1007 1209 FEC2: 1210 The operator on node A configures ISIS on node A to assign the label 1211 1007 to the globally significant adj-SID (I.e. when advertised the 1212 "L" flag is clear in the adj-SID sub-TLV as described in [I-D.ietf- 1213 isis-segment-routing-extensions]) towards one of its neighbor 1214 advertisement from node A with label=1007 1216 Node A assigns this adj-SID explicitly via configuration, so the adj- 1217 SID survives router reboots. 1219 FEC1 uses dynamic SID assignment, while FEC2 uses explicit SID 1220 assignment. So FEC2 wins. 1222 A.2.4. Example 4 1224 Illustration of incoming label collision resolution using FEC type 1225 default administrative distance 1227 FEC1: 1228 OSPF on node A receives a prefix SID advertisement from node B for 1229 198.51.100.8/32 with index=8. Assuming that OSPF SRGB on node A = 1230 [1000,1999], the incoming label corresponding to 198.51.100.8/32 is 1231 1008. 1233 FEC2: 1234 Suppose the SR Policy advertisement from controller to node A for the 1235 policy identified by (Endpoint = 192.0.2.208, color = 100) and 1236 consisting of SID-List = assigns the globally significant 1237 Binding-SID label 1008 1239 From the point of view of node A, FEC1 and FEC2 both use dynamic SID 1240 assignment. Based on the default administrative distance outlined in 1241 Section 2.5.1, the binding SID has a higher administrative distance 1242 than the prefix-SID and hence FEC1 wins. 1244 A.2.5. Example 5 1246 Illustration of incoming label collision resolution based on FEC type 1247 preference 1249 FEC1: 1250 ISIS on node A receives a prefix SID advertisement from node B for 1251 203.0.113.110/32 with index=10. Assuming that the ISIS SRGB on node A 1252 is [1000,1999], then incoming label corresponding to 203.0.113.110/32 1253 is 1010. 1255 FEC2: 1256 ISIS on node A assigns the label 1010 to the globally significant 1257 adj-SID (I.e. when advertised the "L" flag is clear in the adj-SID 1258 sub-TLV as described in [I-D.ietf-isis-segment-routing-extensions]) 1259 towards one of its neighbors). 1261 Node A allocates this adj-SID dynamically, and it may differ across 1262 router reboots. Hence both FEC1 and FEC2 both use dynamic SID 1263 assignment. 1265 Since both FECs are from the same MCC, they have the same default 1266 admin distance. So we compare FEC type code-point. FEC1 has FEC type 1267 code-point=120, while FEC2 has FEC type code-point=130. Therefore, 1268 FEC1 wins. 1270 A.2.6. Example 6 1272 Illustration of incoming label collision resolution based on address 1273 family preference. 1275 FEC1: 1276 ISIS on node A receives prefix SID advertisement from node B for 1277 203.0.113.111/32 with index 11. Assuming that the ISIS SRGB on node A 1278 is [1000,1999], the incoming label on node A for 203.0.113.111/32 is 1279 1011. 1281 FEC2: 1282 ISIS on node A prefix SID advertisement from node C for 1283 2001:DB8:1000::11/128 with index=11. Assuming that the ISIS SRGB on 1284 node A is [1000,1999], the incoming label on node A for 1285 2001:DB8:1000::11/128 is 1011 1287 FEC1 and FEC2 both use dynamic SID assignment. Since both FECs are 1288 from the same MCC, they have the same default admin distance. So we 1289 compare FEC type code-point. Both FECs have FEC type code-point=120. 1290 So we compare address family. Since IPv4 is preferred over IPv6, FEC1 1291 wins. 1293 A.2.7. Example 7 1295 Illustration incoming label collision resolution based on prefix 1296 length. 1298 FEC1: 1299 ISIS on node A receives a prefix SID advertisement from node B for 1300 203.0.113.112/32 with index 12. Assuming that ISIS SRGB on node A is 1301 [1000,1999], the incoming label for 203.0.113.112/32 on node A is 1302 1012. 1304 FEC2: 1305 ISIS on node A receives a prefix SID advertisement from node C for 1306 203.0.113.128/30 with index 12. Assuming that the ISIS SRGB on node A 1307 is [1000,1999], then incoming label for 203.0.113.128/30 on node A is 1308 1012 1310 FEC1 and FEC2 both use dynamic SID assignment. Since both FECs are 1311 from the same MCC, they have the same default admin distance. So we 1312 compare FEC type code-point. Both FECs have FEC type code-point=120. 1313 So we compare address family. Both are IPv4 address family, so we 1314 compare prefix length. FEC1 has prefix length=32, and FEC2 has 1315 prefix length=30, so FEC2 wins. 1317 A.2.8. Example 8 1319 Illustration of incoming label collision resolution based on the 1320 numerical value of the FECs. 1322 FEC1: 1323 ISIS on node A receives a prefix SID advertisement from node B for 1324 203.0.113.113/32 with index 13. Assuming that ISIS SRGB on node A is 1326 [1000,1999], then the incoming label for 203.0.113.113/32 on node A 1327 is 1013 1329 FEC2: 1330 ISIS on node A receives a prefix SID advertisement from node C for 1331 203.0.113.213/32 with index 13. Assuming that ISIS SRGB on node A is 1332 [1000,1999], then the incoming label for 203.0.113.213/32 on node A 1333 is 1013 1335 FEC1 and FEC2 both use dynamic SID assignment. Since both FECs are 1336 from the same MCC, they have the same default admin distance. So we 1337 compare FEC type code-point. Both FECs have FEC type code-point=120. 1338 So we compare address family. Both are IPv4 address family, so we 1339 compare prefix length. Prefix lengths are the same, so we compare 1340 prefix. FEC1 has the lower prefix, so FEC1 wins. 1342 A.2.9. Example 9 1344 Illustration of incoming label collision resolution based on routing 1345 instance ID. 1347 FEC1: 1348 ISIS on node A receives a prefix SID advertisement from node B for 1349 203.0.113.114/32 with index 14. Assume that this ISIS instance on 1350 node A has the Routing Instance ID 1000 and SRGB [1000,1999]. Hence 1351 the incoming label for 203.0.113.114/32 on node A is 1014 1353 FEC2: 1354 ISIS on node A receives a prefix SID advertisement from node C for 1355 203.0.113.114/32 with index=14. Assume that this is another instance 1356 of ISIS on node A with a different routing Instance ID 2000 but the 1357 same SRGB [1000,1999]. Hence incoming label for 203.0.113.114/32 on 1358 node A 1014 1360 These two FECs match all the way through the prefix length and 1361 prefix. So Routing Instance ID breaks the tie, with FEC1 winning. 1363 A.2.10. Example 10 1365 Illustration of incoming label collision resolution based on topology 1366 ID. 1368 FEC1: 1369 ISIS on node A receives a prefix SID advertisement from node B for 1370 203.0.113.115/32 with index=15. Assume that this ISIS instance on 1371 node A has Routing Instance ID 1000. Assume that the prefix 1372 advertisement of 203.0.113.115/32 was received in ISIS Multi-topology 1373 advertisement with ID = 50. If the ISIS SRGB for this routing 1374 instance on node A is [1000,1999], then incoming label of 1375 203.0.113.115/32 for topology 50 on node A is 1015 1377 FEC2: 1378 ISIS on node A receives a prefix SID advertisement from node C for 1379 203.0.113.115/32 with index 15. Assume that it is the same routing 1380 Instance ID = 1000 but 203.0.113.115/32 was advertised with a 1381 different ISIS Multi-topology ID = 40. If the ISIS SRGB on node A is 1382 [1000,1999], then incoming label of 203.0.113.115/32 for topology 40 1383 on node A is also 1015 1385 These two FECs match all the way through the prefix length, prefix, 1386 and Routing Instance ID. We compare ISIS Multi-topology ID, so FEC2 1387 wins. 1389 A.2.11. Example 11 1391 Illustration of incoming label collision for resolution based on 1392 algorithm ID. 1394 FEC1: 1395 ISIS on node A receives a prefix SID advertisement from node B for 1396 203.0.113.116/32 with index=16 Assume that ISIS on node A has Routing 1397 Instance ID = 1000. Assume that node B advertised 203.0.113.116/32 1398 with ISIS Multi-topology ID = 50 and SR algorithm = 0. Assume that 1399 the ISIS SRGB on node A = [1000,1999]. Hence the incoming label 1400 corresponding to this advertisement of 203.0.113.116/32 is 1016. 1402 FEC2: 1403 ISIS on node A receives a prefix SID advertisement from node C for 1404 203.0.113.116/32 with index=16. Assume that it is the same ISIS 1405 instance on node A with Routing Instance ID = 1000. Also assume that 1406 node C advertised 203.0.113.116/32 with ISIS Multi-topology ID = 50 1407 but with SR algorithm = 22. Since it is the same routing instance, 1408 the SRGB on node A = [1000,1999]. Hence the incoming label 1409 corresponding to this advertisement of 203.0.113.116/32 by node C is 1410 also 1016. 1412 These two FECs match all the way through the prefix length, prefix, 1413 and Routing Instance ID, and Multi-topology ID. We compare SR 1414 algorithm ID, so FEC1 wins. 1416 A.2.12. Example 12 1418 Illustration of incoming label collision resolution based on FEC 1419 numerical value and independent of how the SID assigned to the 1420 colliding FECs. 1422 FEC1: 1423 ISIS on node A receives a prefix SID advertisement from node B for 1424 203.0.113.117/32 with index 17. Assume that the ISIS SRGB on node A 1425 is [1000,1999], then the incoming label is 1017 1427 FEC2: 1428 Suppose there is an ISIS mapping server advertisement (SID/Label 1429 Binding TLV) from node D has Range 100 and Prefix = 203.0.113.1/32. 1430 Suppose this mapping server advertisement generates 100 mappings, one 1431 of which maps 203.0.113.17/32 to index 17. Assuming that it is the 1432 same ISIS instance, then the SRGB is [1000,1999] and hence the 1433 incoming label for 1017. 1435 The fact that FEC1 comes from a normal prefix SID advertisement and 1436 FEC2 is generated from a mapping server advertisement is not used as 1437 a tie-breaking parameter. Both FECs use dynamic SID assignment, are 1438 from the same MCC, have the same FEC type code-point=120. Their 1439 prefix lengths are the same as well. FEC2 wins based on lower 1440 numerical prefix value, since 203.0.113.17 is less than 1441 203.0.113.117. 1443 A.2.13. Example 13 1445 Illustration of incoming label collision resolution based on address 1446 family preference 1448 FEC1: 1449 SR Policy advertisement from controller to node A. Endpoint 1450 address=2001:DB8:3000::100, color=100, SID-List= and the 1451 Binding-SID label=1020 1453 FEC2: 1454 SR Policy advertisement from controller to node A. Endpoint 1455 address=192.0.2.60, color=100, SID-List= and the Binding-SID 1456 label=1020 1457 The FECs match through the tie-breaks up to and including having the 1458 same FEC type code-point=140. FEC2 wins based on IPv4 address family 1459 being preferred over IPv6. 1461 A.2.14. Example 14 1463 Illustration of incoming label resolution based on numerical value of 1464 the policy endpoint. 1466 FEC1: 1467 SR Policy advertisement from controller to node A. Endpoint 1468 address=192.0.2.70, color=100, SID-List= and Binding-SID 1469 label=1021 1471 FEC2: 1472 SR Policy advertisement from controller to node A Endpoint 1473 address=192.0.2.71, color=100, SID-List= and Binding-SID 1474 label=1021 1476 The FECs match through the tie-breaks up to and including having the 1477 same address family. FEC1 wins by having the lower numerical endpoint 1478 address value. 1480 A.3. Examples for the Effect of Incoming Label Collision on Outgoing 1481 Label 1483 This section presents examples to illustrate the effect of incoming 1484 label collision on the selection of the outgoing label described in 1485 Section 2.6. 1487 A.3.1. Example 1 1489 Illustration of the effect of incoming label resolution on the 1490 outgoing label 1492 FEC1: 1493 ISIS on node A receives a prefix SID advertisement from node B for 1494 203.0.113.122/32 with index 22. Assuming that the ISIS SRGB on node A 1495 is [1000,1999] the corresponding incoming label is 1022. 1497 FEC2: 1498 ISIS on node A receives a prefix SID advertisement from node C for 1499 203.0.113.222/32 with index=22 Assuming that the ISIS SRGB on node A 1500 is [1000,1999] the corresponding incoming label is 1022. 1502 FEC1 wins based on lowest numerical prefix value. This means that 1503 node A installs a transit MPLS forwarding entry to SWAP incoming 1504 label 1022, with outgoing label N and use outgoing interface I. N is 1505 determined by the index associated with FEC1 (index 22) and the SRGB 1506 advertised by the next-hop node on the shortest path to reach 1507 203.0.113.122/32. 1509 Node A will generally also install an imposition MPLS forwarding 1510 entry corresponding to FEC1 for incoming prefix=203.0.113.122/32 1511 pushing outgoing label N, and using outgoing interface I. 1513 The rule in Section 2.6 means node A MUST NOT install an ingress 1514 MPLS forwarding entry corresponding to FEC2 (the losing FEC, which 1515 would be for prefix 203.0.113.222/32). 1517 A.3.2. Example 2 1519 Illustration of the effect of incoming label collision resolution on 1520 outgoing label programming on node A 1522 FEC1: 1523 o SR Policy advertisement from controller to node A 1525 o Endpoint address=192.0.2.80, color=100, SID-List= 1527 o Binding-SID label=1023 1529 FEC2: 1530 o SR Policy advertisement from controller to node A 1532 o Endpoint address=192.0.2.81, color=100, SID-List= 1534 o Binding-SID label=1023 1536 FEC1 wins by having the lower numerical endpoint address value. This 1537 means that node A installs a transit MPLS forwarding entry to SWAP 1538 incoming label=1023, with outgoing labels and outgoing interface 1539 determined by the SID-List for FEC1. 1541 In this example, we assume that node A receives two BGP/VPN routes: 1543 o R1 with VPN label=V1, BGP next-hop = 192.0.2.80, and color=100, 1545 o R2 with VPN label=V2, BGP next-hop = 192.0.2.81, and color=100, 1546 We also assume that A has a BGP policy which matches on color=100 1547 that allows that its usage as SLA steering information. In this case, 1548 node A will install a VPN route with label stack = 1549 (corresponding to FEC1). 1551 The rule described in section 2.6 means that node A MUST NOT install 1552 a VPN route with label stack = (corresponding to FEC2.)