idnits 2.17.1 draft-ietf-spring-segment-routing-mpls-22.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 (May 1, 2019) is 1821 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: '16000-17000' is mentioned on line 580, but not defined == Missing Reference: '20000-21000' is mentioned on line 582, but not defined -- Looks like a reference, but probably isn't: '1000' on line 1509 -- Looks like a reference, but probably isn't: '5000' on line 1113 -- Looks like a reference, but probably isn't: '1999' on line 1509 == 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 (~~), 9 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: November 2019 S. Previdi, 5 Cisco Systems, Inc. 6 B. Decraene 7 S. Litkowski 8 Orange 9 R. Shakir 10 Google 11 May 1, 2019 13 Segment Routing with MPLS data plane 14 draft-ietf-spring-segment-routing-mpls-22 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 November 1, 2019. 42 Copyright Notice 44 Copyright (c) 2019 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.........4 63 2.2. SID Representation in the MPLS Forwarding Plane...........5 64 2.3. Segment Routing Global Block and Local Block..............5 65 2.4. Mapping a SID Index to an MPLS label......................6 66 2.5. Incoming Label Collision..................................7 67 2.5.1. Tie-breaking Rules..................................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.................................15 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.....................................16 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....17 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........19 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..................................20 89 5. Security Considerations.......................................20 90 6. Contributors..................................................20 91 7. Acknowledgements..............................................20 92 8. References....................................................21 93 8.1. Normative References.....................................21 94 8.2. Informative References...................................22 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 fit 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. Local 167 configuration and policies applied on a router are examples of MCCs. 169 In order to have a node segment reach the node, a network operator 170 SHOULD configure at least one node segment per routing instance, 171 topology, or algorithm. Otherwise, the node is not reachable within 172 the routing instance, topology or along the routing algorithm, which 173 restrict its ability to be used by a SR policy, including for TI-LFA. 175 2.1. Multiple Forwarding Behaviors for the Same Prefix 177 The SR architecture does not prohibit having more than one SID for 178 the same prefix. In fact, by allowing multiple SIDs for the same 179 prefix, it is possible to have different forwarding behaviors (such 180 as different paths, different ECMP/UCMP behaviors,...,etc) for the 181 same destination. 183 Instantiating Segment routing over the MPLS forwarding plane fits 184 seamlessly with this principle. An operator may assign multiple MPLS 185 labels or indices to the same prefix and assign different forwarding 186 behaviors to each label/SID. The MCC in the network downloads 187 different MPLS labels/SIDs to the FIB for different forwarding 188 behaviors. The MCC at the entry of an SR domain or at any point in 189 the domain can choose to apply a particular forwarding behavior to a 190 particular packet by applying the PUSH action to that packet using 191 the corresponding SID. 193 2.2. SID Representation in the MPLS Forwarding Plane 195 When instantiating SR over the MPLS forwarding plane, a SID is 196 represented by an MPLS label or an index [RFC8402]. 198 A global segment is a label, or an index which may be mapped to an 199 MPLS label within the Segment Routing Global Block (SRGB) of the node 200 installing the global segment in its FIB/receiving the labeled 201 packet. Section 2.4 specifies the procedure to map a global segment 202 represented by an index to an MPLS label within the SRGB. 204 The MCC MUST ensure that any label value corresponding to any SID it 205 installs in the forwarding plane follows the following rules: 207 o The label value MUST be unique within the router on which the MCC 208 is running. i.e. the label MUST only be used to represent the SID 209 and MUST NOT be used to represent more than one SID or for any 210 other forwarding purpose on the router. 212 o The label value MUST NOT come from the range of special purpose 213 labels [RFC7274]. 215 Labels allocated in this document are considered per platform down- 216 stream allocated labels [RFC3031]. 218 2.3. Segment Routing Global Block and Local Block 220 The concepts of Segment Routing Global Block (SRGB) and global SID 221 are explained in [RFC8402]. In general, the SRGB need not be a 222 contiguous range of labels. 224 For the rest of this document, the SRGB is specified by the list of 225 MPLS Label ranges [Ll(1),Lh(1)], [Ll(2),Lh(2)],..., [Ll(k),Lh(k)] 226 where Ll(i) =< Lh(i). 228 The following rules apply to the list of MPLS ranges representing the 229 SRGB 231 o The list of ranges comprising the SRGB MUST NOT overlap. 233 o Every range in the list of ranges specifying the SRGB MUST NOT 234 cover or overlap with a reserved label value or range [RFC7274], 235 respectively. 237 o If the SRGB of a node does not conform to the structure specified 238 in this section or to the previous two rules, then this SRGB MUST 239 be completely ignored by all routers in the routing domain and the 240 node MUST be treated as if it does not have an SRGB. 242 o The list of label ranges MUST only be used to instantiate global 243 SIDs into the MPLS forwarding plane 245 A Local segment MAY be allocated from the Segment Routing Local Block 246 (SRLB) [RFC8402] or from any unused label as long as it does not use 247 a special purpose label. The SRLB consists of the range of local 248 labels reserved by the node for certain local segments. In a 249 controller-driven network, some controllers or applications MAY use 250 the control plane to discover the available set of local SIDs on a 251 particular router [I-D.ietf-spring-segment-routing-policy]. The rules 252 applicable to the SRGB are also applicable to the SRLB, except the 253 rule that says that the SRGB MUST only be used to instantiate global 254 SIDs into the MPLS forwarding plane. The recommended, minimum, or 255 maximum size of the SRGB and/or SRLB is a matter of future study 257 2.4. Mapping a SID Index to an MPLS label 259 This sub-section specifies how the MPLS label value is calculated 260 given the index of a SID. The value of the index is determined by an 261 MCC such as IS-IS [I-D.ietf-isis-segment-routing-extensions] or OSPF 262 [I-D.ietf-ospf-segment-routing-extensions]. This section only 263 specifies how to map the index to an MPLS label. The calculated MPLS 264 label is downloaded to the FIB, sent out with a forwarded packet, or 265 both. 267 Consider a SID represented by the index "I". Consider an SRGB as 268 specified in Section 2.3. The total size of the SRGB, represented by 269 the variable "Size", is calculated according to the formula: 271 size = Lh(1)- Ll(1) + 1 + Lh(2)- Ll(2) + 1 + ... + Lh(k)- Ll(k) + 1 273 The following rules MUST be applied by the MCC when calculating the 274 MPLS label value corresponding the SID index value "I". 276 o 0 =< I < size. If the index "I" does not satisfy the previous 277 inequality, then the label cannot be calculated. 279 o The label value corresponding to the SID index "I" is calculated 280 as follows 282 o j = 1 , temp = 0 284 o While temp + Lh(j)- Ll(j) < I 286 . temp = temp + Lh(j)- Ll(j) + 1 288 . j = j+1 290 o label = I - temp + Ll(j) 292 An example for how a router calculates labels and forwards traffic 293 based on the procedure described in this section can be found in 294 Appendix A.1. 296 2.5. Incoming Label Collision 298 The MPLS Architecture [RFC3031] defines the term Forwarding 299 Equivalence Class (FEC) as the set of packets with similar and / or 300 identical characteristics which are forwarded the same way and are 301 bound to the same MPLS incoming (local) label. In Segment-Routing 302 MPLS, a local label serves as the SID for given FEC. 304 We define Segment Routing (SR) FEC as one of the following [RFC8402]: 306 o (Prefix, Routing Instance, Topology, Algorithm [RFC8402]), where a 307 topology identifies a set of links with metrics. For the purpose 308 of incoming label collision resolution, the same Topology 309 numerical value SHOULD be used on all routers to identify the same 310 set of links with metrics. For MCCs where the "Topology" and/or 311 "Algorithm" fields are not defined, the numerical value of zero 312 MUST be used for these two fields. For the purpose of incoming 313 label collision resolution, a routing instance is identified by a 314 single incoming label downloader to FIB. Two MCCs running on the 315 same router are considered different routing instances if the only 316 way the two instances can know about the other's incoming labels 317 is through redistribution. The numerical value used to identify a 318 routing instance MAY be derived from other configuration or MAY be 319 explicitly configured. If it is derived from other configuration, 320 then the same numerical value SHOULD be derived from the same 321 configuration as long as the configuration survives router reload. 322 If the derived numerical value varies for the same configuration, 323 then an implementation SHOULD make numerical value used to 324 identify a routing instance configurable. 326 o (next-hop, outgoing interface), where the outgoing interface is 327 physical or virtual. 329 o (number of adjacencies, list of next-hops, list of outgoing 330 interfaces IDs in ascending numerical order). This FEC represents 331 parallel adjacencies [RFC8402] 333 o (Endpoint, Color) representing an SR policy [RFC8402] 335 o (Mirrored SID) The Mirrored SID [RFC8402, Section 5.1] is the IP 336 address advertised by the advertising node to identify the mirror- 337 SID. The IP address is encoded as specified in Section 2.5.1. 339 This section covers the RECOMMENDED procedure to handle the scenario 340 where, because of an error/misconfiguration, more than one SR FEC as 341 defined in this section, map to the same incoming MPLS label. 342 Examples illustrating the behavior specified in this section can be 343 found in Appendix A.2. 345 An incoming label collision occurs if the SIDs of the set of FECs 346 {FEC1, FEC2,..., FECk} map to the same incoming SR MPLS label "L1". 348 Suppose an anycast prefix is advertised with a prefix-SID by some, 349 but not all, of the nodes that advertise that prefix. If the prefix- 350 SID sub-TLVs result in mapping that anycast prefix to the same 351 incoming label, then the advertisement of the prefix-SID by some, but 352 not all, of advertising nodes MUST NOT be treated as a label 353 collision. 355 An implementation MUST NOT allow the MCCs belonging to the same 356 router to assign the same incoming label to more than one SR FEC. 358 The objective of the following steps is to deterministically install 359 in the MPLS Incoming Label Map, also known as label FIB, a single FEC 360 with the incoming label "L1". By "deterministically install" we mean 361 if the set of FECs {FEC1, FEC2,..., FECk} map to the same incoming SR 362 MPLS label "L1", then the steps below assign the same FEC to the 363 label "L1" irrespective of the order by which the mappings of this 364 set of FECs to the label "L1" are received. For example, a first- 365 come-first-serve tie-breaking is not allowed. The remaining FECs may 366 be installed in the IP FIB without incoming label. 368 The procedure in this section relies completely on the local FEC and 369 label database within a given router. 371 The collision resolution procedure is as follows 373 1. Given the SIDs of the set of FECs, {FEC1, FEC2,..., FECk} map to 374 the same MPLS label "L1". 376 2. Within an MCC, apply tie-breaking rules to select one FEC only and 377 assign the label to it. The losing FECs are handled as if no 378 labels are attached to them. The losing FECs with algorithms other 379 than the shortest path first [RFC8402] are not installed in the 380 FIB. 382 a. If the same set of FECs are attached to the same label "L1", 383 then the tie-breaking rules MUST always select the same FEC 384 irrespective of the order in which the FECs and the label "L1" 385 are received. In other words, the tie-breaking rule MUST be 386 deterministic. 388 3. If there is still collision between the FECs belonging to 389 different MCCs, then re-apply the tie-breaking rules to the 390 remaining FECs to select one FEC only and assign the label to that 391 FEC 393 4. Install into the IP FIB the selected FEC and its incoming label in 394 the label FIB. 396 5. The remaining FECs with the default algorithm (see the 397 specification of prefix-SID algorithm [RFC8402]) may be installed 398 in the FIB natively, such as pure IP entries in case of Prefix 399 FEC, without any incoming labels corresponding to their SIDs. The 400 remaining FECs with algorithms other than the shortest path first 401 [RFC8402] are not installed in the FIB. 403 2.5.1. Tie-breaking Rules 405 The default tie-breaking rules are specified as follows: 407 1. if FECi has the lowest FEC administrative distance among the 408 competing FECs as defined in this section below, filter away all 409 the competing FECs with higher administrative distance. 411 2. if more than one competing FEC remains after step 1, select the 412 smallest numerical FEC value. The numerical value of the FEC is 413 determined according to the FEC encoding described later in this 414 section. 416 These rules deterministically select the FEC to install in the MPLS 417 forwarding plane for the given incoming label. 419 This document defines the default tie breaking rules that SHOULD be 420 implemented. An implementation MAY choose to support different tie- 421 breaking rules and MAY use one of the these instead of the default 422 tie-breaking rules. To maximize MPLS forwarding consistency in case 423 of SID configuration error, the network operator MUST deploy, within 424 an IGP flooding area, routers implementing the same tie-breaking 425 rules. 427 Each FEC is assigned an administrative distance. The FEC 428 administrative distance is encoded as an 8-bit value. The lower the 429 value, the better the administrative distance. 431 The default FEC administrative distance order starting from the 432 lowest value SHOULD be: 434 o Explicit SID assignment to a FEC that maps to a label outside the 435 SRGB irrespective of the owner MCC. An explicit SID assignment is 436 a static assignment of a label to a FEC such that the assignment 437 survives router reboot. 439 o An example of explicit SID allocation is static assignment of 440 a specific label to an adj-SID. 442 o An implementation of explicit SID assignment MUST guarantee 443 collision freeness on the same router 445 o Dynamic SID assignment: 447 o For all FEC types except for SR policy, the FEC types are 448 ordered using the default administrative distance ordering 449 defined by the implementation. 451 o Binding SID [RFC8402] assigned to SR Policy always has a 452 higher default administrative distance than the default 453 administrative distance of any other FEC type 455 To maximize MPLS forwarding consistency, If a same FEC is advertised 456 in more than one protocol, a user MUST ensure that the administrative 457 distance preference between protocols is the same on all routers of 458 the IGP flooding domain. Note that this is not really new as this 459 already applies to IP forwarding. 461 The numerical sort across FECs SHOULD be performed as follows: 463 o Each FEC is assigned a FEC type encoded in 8 bits. The following 464 are the type code point for each SR FEC defined at the beginning 465 of this Section: 467 o 120: (Prefix, Routing Instance, Topology, Algorithm) 469 o 130: (next-hop, outgoing interface) 471 o 140: Parallel Adjacency [RFC8402] 473 o 150: an SR policy [RFC8402]. 475 o 160: Mirror SID [RFC8402] 477 o The numerical values above are mentioned to guide 478 implementation. If other numerical values are used, then the 479 numerical values must maintain the same greater-than ordering 480 of the numbers mentioned here. 482 o The fields of each FEC are encoded as follows 484 o All fields in all FECs are encoded in big endian 485 o Routing Instance ID represented by 16 bits. For routing 486 instances that are identified by less than 16 bits, encode the 487 Instance ID in the least significant bits while the most 488 significant bits are set to zero 490 o Address Family represented by 8 bits, where IPv4 encoded as 491 100 and IPv6 is encoded as 110. These numerical values are 492 mentioned to guide implementations. If other numerical values 493 are used, then the numerical value of IPv4 MUST be less than 494 the numerical value for IPv6 496 o All addresses are represented in 128 bits as follows 498 . IPv6 address is encoded natively 500 . IPv4 address is encoded in the most significant bits and 501 the remaining bits are set to zero 503 o All prefixes are represented by (8 + 128) bits. 505 . A prefix is encoded in the most significant bits and the 506 remaining bits are set to zero. 508 . The prefix length is encoded before the prefix in a field 509 of size 8 bits. 511 o Topology ID is represented by 16 bits. For routing instances 512 that identify topologies using less than 16 bits, encode the 513 topology ID in the least significant bits while the most 514 significant bits are set to zero 516 o Algorithm is encoded in a 16 bits field. 518 o The Color ID is encoded using 32 bits 520 o Choose the set of FECs of the smallest FEC type code point 522 o Out of these FECs, choose the FECs with the smallest address 523 family code point 525 o Encode the remaining set of FECs as follows 527 o (Prefix, Routing Instance, Topology, Algorithm) is encoded as 528 (Prefix Length, Prefix, routing_instance_id, Topology, SR 529 Algorithm) 531 o (next-hop, outgoing interface) is encoded as (next-hop, 532 outgoing_interface_id) 534 o (number of adjacencies, list of next-hops in ascending 535 numerical order, list of outgoing interface IDs in ascending 536 numerical order). This encoding is used to encode a parallel 537 adjacency [RFC8402] 539 o (Endpoint, Color) is encoded as (Endpoint_address, Color_id) 541 o (IP address): This is the encoding for a mirror SID FEC. The IP 542 address is encoded as described above in this section 544 o Select the FEC with the smallest numerical value 546 The numerical values mentioned in this section are for guidance only. 547 If other numerical values are used then the other numerical values 548 MUST maintain the same numerical ordering among different SR FECs. 550 2.5.2. Redistribution between Routing Protocol Instances 552 The following rule SHOULD be applied when redistributing SIDs with 553 prefixes between routing protocol instances: 555 o If the receiving instance's SRGB is the same as the SRGB of origin 556 instance, then 558 o the index is redistributed with the route 560 o Else 562 o the index is not redistributed and if the receiving instance 563 decides to advertise an index with the redistributed route, it 564 is the duty of the receiving instance to allocate a fresh 565 index relative to its own SRGB. Note that in this case the 566 receiving instance MUST compute the local label it assignes to 567 the route according to section 2.4 and install it in FIB. 569 It is outside the scope of this document to define local node 570 behaviors that would allow to map the original index into a new index 571 in the receiving instance via the addition of an offset or other 572 policy means. 574 2.5.2.1. Illustration 576 A----IS-IS----B---OSPF----C-192.0.2.1/32 (20001) 578 Consider the simple topology above. 580 o A and B are in the IS-IS domain with SRGB [16000-17000] 582 o B and C are in OSPF domain with SRGB [20000-21000] 584 o B redistributes 192.0.2.1/32 into IS-IS domain 586 o In that case A learns 192.0.2.1/32 as an IP leaf connected to B as 587 usual for IP prefix redistribution 589 o However, according to the redistribution rule above rule, B 590 decides not to advertise any index with 192.0.2.1/32 into IS-IS 591 because the SRGB is not the same. 593 2.5.2.2. Illustration 2 595 Consider the example in the illustration described in Section 596 2.5.2.1. 598 When router B redistributes the prefix 192.0.2.1/32, router B decides 599 to allocate and advertise the same index 1 with the prefix 600 192.0.2.1/32 602 Within the SRGB of the IS-IS domain, index 1 corresponds to the local 603 label 16001 605 o Hence according to the redistribution rule above, router B 606 programs the incoming label 16001 in its FIB to match traffic 607 arriving from the IS-IS domain destined to the prefix 608 192.0.2.1/32. 610 2.6. Effect of Incoming Label Collision on Outgoing Label Programming 612 For the determination of the outgoing label to use, the ingress node 613 pushing new segments, and hence a stack of MPLS labels, MUST use, for 614 a given FEC, the same label that has been selected by the node 615 receiving the packet with that label exposed as top label. So in case 616 of incoming label collision on this receiving node, the ingress node 617 MUST resolve this collision using this same "Incoming Label Collision 618 resolution procedure", using the data of the receiving node. 620 In the general case, the ingress node may not have exactly the same 621 data of the receiving node, so the result may be different. This is 622 under the responsibility of the network operator. But in typical 623 case, e.g. where a centralized node or a distributed link state IGP 624 is used, all nodes would have the same database. However to minimize 625 the chance of misforwarding, a FEC that loses its incoming label to 626 the tie-breaking rules specified in Section 2.5 MUST NOT be 627 installed in FIB with an outgoing segment routing label based on the 628 SID corresponding to the lost incoming label. 630 Examples for the behavior specified in this section can be found in 631 Appendix A.3. 633 2.7. PUSH, CONTINUE, and NEXT 635 PUSH, NEXT, and CONTINUE are operations applied by the forwarding 636 plane. The specifications of these operations can be found in 637 [RFC8402]. This sub-section specifies how to implement each of these 638 operations in the MPLS forwarding plane. 640 2.7.1. PUSH 642 As described in [RFC8402], PUSH corresponds to pushing one or more 643 labels on top of an incoming packet then sending it out of a 644 particular physical interface or virtual interface, such as UDP 645 tunnel [RFC7510] or L2TPv3 tunnel [RFC4817], towards a particular 646 next-hop. When pushing labels onto a packet's label stack, the Time- 647 to-Live (TTL) field ([RFC3032], [RFC3443]) and the Traffic Class (TC) 648 field ([RFC3032], [RFC5462]) of each label stack entry must, of 649 course, be set. This document does not specify any set of rules for 650 setting these fields; that is a matter of local policy. Sections 651 2.10 and 2.11 specify additional details about forwarding 652 behavior. 654 2.7.2. CONTINUE 656 As described in [RFC8402], the CONTINUE operation corresponds to 657 swapping the incoming label with an outgoing label. The value of the 658 outgoing label is calculated as specified in Sections 2.10 and 2.11. 660 2.7.3. NEXT 662 As described in [RFC8402], NEXT corresponds to popping the topmost 663 label. The action before and/or after the popping depends on the 664 instruction associated with the active SID on the received packet 665 prior to the popping. For example suppose the active SID in the 666 received packet was an Adj-SID [RFC8402], then on receiving the 667 packet, the node applies NEXT operation, which corresponds to popping 668 the top most label, and then sends the packet out of the physical or 669 virtual interface (e.g. UDP tunnel [RFC7510] or L2TPv3 tunnel 670 [RFC4817]) towards the next-hop corresponding to the adj-SID. 672 2.7.3.1. Mirror SID 674 If the active SID in the received packet was a Mirror SID [RFC8402, 675 Section 5.1] allocated by the receiving router, then the receiving 676 router applies NEXT operation, which corresponds to popping the top 677 most label, then performs a lookup using the contents of the packet 678 after popping the outer most label in the mirrored forwarding table. 679 The method by which the lookup is made, and/or the actions applied to 680 the packet after the lookup in the mirror table depends on the 681 contents of the packet and the mirror table. Note that the packet 682 exposed after popping the top most label may or may not be an MPLS 683 packet. A mirror SID can be viewed as a generalization of the context 684 label in [RFC5331] because a mirror SID does not make any 685 assumptions about the packet underneath the top label. 687 2.8. MPLS Label Downloaded to FIB for Global and Local SIDs 689 The label corresponding to the global SID "Si" represented by the 690 global index "I" downloaded to FIB is used to match packets whose 691 active segment (and hence topmost label) is "Si". The value of this 692 label is calculated as specified in Section 2.4. 694 For Local SIDs, the MCC is responsible for downloading the correct 695 label value to FIB. For example, an IGP with SR extensions [I-D.ietf- 696 isis-segment-routing-extensions, I-D.ietf-ospf-segment-routing- 697 extensions] downloads the MPLS label corresponding to an Adj-SID 698 [RFC8402]. 700 2.9. Active Segment 702 When instantiated in the MPLS domain, the active segment on a packet 703 corresponds to the topmost label on the packet that is calculated 704 according to the procedure specified in Sections 2.10 and 2.11. When 705 arriving at a node, the topmost label corresponding to the active SID 706 matches the MPLS label downloaded to FIB as specified in Section 2.4. 708 2.10. Forwarding behavior for Global SIDs 710 This section specifies forwarding behavior, including the calculation 711 of outgoing labels, that corresponds to a global SID when applying 712 PUSH, CONTINUE, and NEXT operations in the MPLS forwarding plane. 714 This document covers the calculation of the outgoing label for the 715 top label only. The case where the outgoing label is not the top 716 label and is part of a stack of labels that instantiates a routing 717 policy or a traffic engineering tunnel is outside the scope of this 718 document and may be covered in other documents such as [I-D.ietf- 719 spring-segment-routing-policy]. 721 2.10.1. Forwarding for PUSH and CONTINUE of Global SIDs 723 Suppose an MCC on a router "R0" determines that PUSH or CONTINUE 724 operation is to be applied to an incoming packet related to the 725 global SID "Si" represented by the global index "I" and owned by the 726 router Ri before sending the packet towards a neighbor "N" directly 727 connected to "R0" through a physical or virtual interface such as UDP 728 tunnel [RFC7510] or L2TPv3 tunnel [RFC4817]. 730 The method by which the MCC on router "R0" determines that PUSH or 731 CONTINUE operation must be applied using the SID "Si" is beyond the 732 scope of this document. An example of a method to determine the SID 733 "Si" for PUSH operation is the case where IS-IS [I-D.ietf-isis- 734 segment-routing-extensions] receives the prefix-SID "Si" sub-TLV 735 advertised with prefix "P/m" in TLV 135 and the destination address 736 of the incoming IPv4 packet is covered by the prefix "P/m". 738 For CONTINUE operation, an example of a method to determine the SID 739 "Si" is the case where IS-IS [I-D.ietf-isis-segment-routing- 740 extensions] receives the prefix-SID "Si" sub-TLV advertised with 741 prefix "P" in TLV 135 and the top label of the incoming packet 742 matches the MPLS label in FIB corresponding to the SID "Si" on the 743 router "R0". 745 The forwarding behavior for PUSH and CONTINUE corresponding to the 746 SID "Si" 748 o If the neighbor "N" does not support SR or advertises an invalid 749 SRGB or a SRGB that is too small for the SID "Si" 751 o If it is possible to send the packet towards the neighbor "N" 752 using standard MPLS forwarding behavior as specified in 753 [RFC3031] and [RFC3032], then forward the packet. The method 754 by which a router decides whether it is possible to send the 755 packet to "N" or not is beyond the scope of this document. For 756 example, the router "R0" can use the downstream label 757 determined by another MCC, such as LDP [RFC5036], to send the 758 packet. 760 o Else if there are other useable next-hops, then use other next- 761 hops to forward the incoming packet. The method by which the 762 router "R0" decides on the possibility of using other next- 763 hops is beyond the scope of this document. For example, the 764 MCC on "R0" may chose the send an IPv4 packet without pushing 765 any label to another next-hop. 767 o Otherwise drop the packet. 769 o Else 771 o Calculate the outgoing label as specified in Section 2.4 using 772 the SRGB of the neighbor "N" 774 o If the operation is PUSH 776 . Push the calculated label according to the MPLS label 777 pushing rules specified in [RFC3032] 779 o Else 781 . swap the incoming label with the calculated label 782 according to the label swapping rules in [RFC3032] 784 o Send the packet towards the neighbor "N" 786 2.10.2. Forwarding for NEXT Operation for Global SIDs 788 As specified in Section 2.7.3 NEXT operation corresponds to popping 789 the top most label. The forwarding behavior is as follows 791 o Pop the topmost label 793 o Apply the instruction associated with the incoming label that has 794 been popped 796 The action on the packet after popping the topmost label depends on 797 the instruction associated with the incoming label as well as the 798 contents of the packet right underneath the top label that got 799 popped. Examples of NEXT operation are described in Appendix A.1. 801 2.11. Forwarding Behavior for Local SIDs 803 This section specifies the forwarding behavior for local SIDs when SR 804 is instantiated over the MPLS forwarding plane. 806 2.11.1. Forwarding for PUSH Operation on Local SIDs 808 Suppose an MCC on a router "R0" determines that PUSH operation is to 809 be applied to an incoming packet using the local SID "Si" before 810 sending the packet towards a neighbor "N" directly connected to R0 811 through a physical or virtual interface such as UDP tunnel [RFC7510] 812 or L2TPv3 tunnel [RFC4817]. 814 An example of such local SID is an Adj-SID allocated and advertised 815 by IS-IS [I-D.ietf-isis-segment-routing-extensions]. The method by 816 which the MCC on "R0" determines that PUSH operation is to be applied 817 to the incoming packet is beyond the scope of this document. An 818 example of such method is backup path used to protect against a 819 failure using TI-LFA [I-D.bashandy-rtgwg-segment-routing-ti-lfa]. 821 As mentioned in [RFC8402], a local SID is specified by an MPLS label. 822 Hence the PUSH operation for a local SID is identical to label push 823 operation [RFC3032] using any MPLS label. The forwarding action after 824 pushing the MPLS label corresponding to the local SID is also 825 determined by the MCC. For example, if the PUSH operation was done to 826 forward a packet over a backup path calculated using TI-LFA, then the 827 forwarding action may be sending the packet to a certain neighbor 828 that will in turn continue to forward the packet along the backup 829 path 831 2.11.2. Forwarding for CONTINUE Operation for Local SIDs 833 A local SID on a router "R0" corresponds to a local label. In such 834 scenario, the outgoing label towards a next-hop "N" is determined by 835 the MCC running on the router "R0"and the forwarding behavior for 836 CONTINUE operation is identical to swap operation [RFC3032] on an 837 MPLS label. 839 2.11.3. Outgoing label for NEXT Operation for Local SIDs 841 NEXT operation for Local SIDs is identical to NEXT operation for 842 global SIDs specified in Section 2.10.2. 844 3. IANA Considerations 846 This document does not make any request to IANA. 848 4. Manageability Considerations 850 This document describes the applicability of Segment Routing over the 851 MPLS data plane. Segment Routing does not introduce any change in 852 the MPLS data plane. Manageability considerations described in 853 [RFC8402] applies to the MPLS data plane when used with Segment 854 Routing. SR OAM use cases for the MPLS data plane are defined in 855 [RFC8403]. SR OAM procedures for the MPLS data plane are defined in 856 [RFC8287]. 858 5. Security Considerations 860 This document does not introduce additional security requirements and 861 mechanisms other than the ones described in [RFC8402]. 863 6. Contributors 865 The following contributors have substantially helped the definition 866 and editing of the content of this document: 868 Martin Horneffer 869 Deutsche Telekom 870 Email: Martin.Horneffer@telekom.de 872 Wim Henderickx 873 Nokia 874 Email: wim.henderickx@nokia.com 876 Jeff Tantsura 877 Email: jefftant@gmail.com 878 Edward Crabbe 879 Email: edward.crabbe@gmail.com 881 Igor Milojevic 882 Email: milojevicigor@gmail.com 884 Saku Ytti 885 Email: saku@ytti.fi 887 7. Acknowledgements 889 The authors would like to thank Les Ginsberg, Chris Bowers, Himanshu 890 Shah, Adrian Farrel, Alexander Vainshtein, Przemyslaw Krol, Darren 891 Dukes, Zafar Ali, and Martin Vigoureux for their valuable comments on 892 this document. 894 This document was prepared using 2-Word-v2.0.template.dot. 896 8. References 898 8.1. Normative References 900 [RFC8402] Filsfils, C., Previdi, S., Decraene, B., Litkowski, S., and 901 R. Shakir, "Segment Routing Architecture", RFC 8402, DOI 902 10.17487/RFC8402 July 2018, . 905 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 906 Requirement Levels", BCP 14, RFC 2119, DOI 907 0.17487/RFC2119, March 1997, . 910 [RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol 911 Label Switching Architecture", RFC 3031, DOI 912 10.17487/RFC3031, January 2001, . 915 [RFC3032] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y., 916 Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack 917 Encoding", RFC 3032, DOI 10.17487/RFC3032, January 2001, 918 . 920 [RFC3443] P. Agarwal, P. and Akyol, B. "Time To Live (TTL) Processing 921 in Multi-Protocol Label Switching (MPLS) Networks", RFC 922 3443, DOI 10.17487/RFC3443, January 2003, . 925 [RFC5462] Andersson, L., and Asati, R., " Multiprotocol Label 926 Switching (MPLS) Label Stack Entry: "EXP" Field Renamed to 927 "Traffic Class" Field", RFC 5462, DOI 10.17487/RFC5462, 928 February 2009, . 930 [RFC7274] K. Kompella, L. Andersson, and A. Farrel, "Allocating and 931 Retiring Special-Purpose MPLS Labels", RFC7274 DOI 932 10.17487/RFC7274, May 2014 935 [RFC8174] B. Leiba, " Ambiguity of Uppercase vs Lowercase in RFC 2119 936 Key Words", RFC8174 DOI 10.17487/RFC8174, May 2017 937 939 8.2. Informative References 941 [I-D.ietf-isis-segment-routing-extensions] Previdi, S., Filsfils, C., 942 Bashandy, A., Gredler, H., Litkowski, S., Decraene, B., and 943 j. jefftant@gmail.com, "IS-IS Extensions for Segment 944 Routing", draft-ietf-isis-segment-routing-extensions-13 945 (work in progress), June 2017. 947 [I-D.ietf-ospf-ospfv3-segment-routing-extensions] Psenak, P., 948 Previdi, S., Filsfils, C., Gredler, H., Shakir, R., 949 Henderickx, W., and J. Tantsura, "OSPFv3 Extensions for 950 Segment Routing", draft-ietf-ospf-ospfv3-segment-routing- 951 extensions-09 (work in progress), March 2017. 953 [I-D.ietf-ospf-segment-routing-extensions] Psenak, P., Previdi, S., 954 Filsfils, C., Gredler, H., Shakir, R., Henderickx, W., and 955 J. Tantsura, "OSPF Extensions for Segment Routing", draft- 956 ietf-ospf-segment-routing-extensions-16 (work in progress), 957 May 2017. 959 [I-D.ietf-spring-segment-routing-ldp-interop] Filsfils, C., Previdi, 960 S., Bashandy, A., Decraene, B., and S. Litkowski, "Segment 961 Routing interworking with LDP", draft-ietf-spring-segment- 962 routing-ldp-interop-08 (work in progress), June 2017. 964 [I-D.bashandy-rtgwg-segment-routing-ti-lfa], Bashandy, A., Filsfils, 965 C., Decraene, B., Litkowski, S., Francois, P., Voyer, P. 966 Clad, F., and Camarillo, P., "Topology Independent Fast 967 Reroute using Segment Routing", draft-bashandy-rtgwg- 968 segment-routing-ti-lfa-05 (work in progress), October 2018, 970 [RFC7855] Previdi, S., Ed., Filsfils, C., Ed., Decraene, B., 971 Litkowski, S., Horneffer, M., and R. Shakir, "Source Packet 972 Routing in Networking (SPRING) Problem Statement and 973 Requirements", RFC 7855, DOI 10.17487/RFC7855, May 2016, 974 . 976 [RFC5036] Andersson, L., Acreo, AB, Minei, I., Thomas, B., " LDP 977 Specification", RFC5036, DOI 10.17487/RFC5036, October 978 2007, 980 [RFC5331] Aggarwal, R., Rekhter, Y., Rosen, E., " MPLS Upstream Label 981 Assignment and Context-Specific Label Space", RFC5331 DOI 982 10.17487/RFC5331, August 2008, . 985 [RFC7510] Xu, X., Sheth, N., Yong, L., Callon, R., and D. Black, 986 "Encapsulating MPLS in UDP", RFC 7510, DOI 987 10.17487/RFC7510, April 2015, . 990 [RFC4817] Townsley, M., Pignataro, C., Wainner, S., Seely, T., Young, 991 T., "Encapsulation of MPLS over Layer 2 Tunneling Protocol 992 Version 3", RFC4817, DOI 10.17487/RFC4817, March 2007, 993 995 [RFC8287] N. Kumar, C. Pignataro, G. Swallow, N. Akiya, S. Kini, and 996 M. Chen " Label Switched Path (LSP) Ping/Traceroute for 997 Segment Routing (SR) IGP-Prefix and IGP-Adjacency Segment 998 Identifiers (SIDs) with MPLS Data Planes" RFC8287, DOI 999 10.17487/RFC8287, December 2017, https://www.rfc- 1000 editor.org/info/rfc8287 1002 [RFC8403] R. Geib, C. Filsfils, C. Pignataro, N. Kumar, "A Scalable 1003 and Topology-Aware MPLS Data-Plane Monitoring System", 1004 RFC8403, DOI 10.17487/RFC8403, July 2018, 1007 [I-D.ietf-spring-segment-routing-policy] Filsfils, C., Sivabalan, 1008 S., Raza, K., Liste, J. , Clad, F., Voyer, D., Bogdanov, A., 1009 Mattes, P., " Segment Routing Policy for Traffic Engineering", 1010 draft-ietf-spring-segment-routing-policy-01 (work in progress), June 1011 2018 1013 9. Authors' Addresses 1015 Ahmed Bashandy (editor) 1016 Arrcus 1018 Email: abashandy.ietf@gmail.com 1020 Clarence Filsfils (editor) 1021 Cisco Systems, Inc. 1022 Brussels 1023 BE 1025 Email: cfilsfil@cisco.com 1027 Stefano Previdi 1028 Cisco Systems, Inc. 1029 Italy 1031 Email: stefano@previdi.net 1033 Bruno Decraene 1034 Orange 1035 FR 1037 Email: bruno.decraene@orange.com 1038 Stephane Litkowski 1039 Orange 1040 FR 1042 Email: stephane.litkowski@orange.com 1044 Rob Shakir 1045 Google 1046 US 1048 Email: robjs@google.com 1050 Appendix A. Examples 1052 A.1. IGP Segments Example 1054 Consider the network diagram of Figure 1 and the IP address and IGP 1055 Segment allocation of Figure 2. Assume that the network is running 1056 IS-IS with SR extensions [I-D.ietf-isis-segment-routing-extensions] 1057 and all links have the same metric. The following examples can be 1058 constructed. 1060 +--------+ 1061 / \ 1062 R0-----R1-----R2----------R3-----R8 1063 | \ / | 1064 | +--R4--+ | 1065 | | 1066 +-----R5-----+ 1068 Figure 1: IGP Segments - Illustration 1070 +-----------------------------------------------------------+ 1071 | IP address allocated by the operator: | 1072 | 192.0.2.1/32 as a loopback of R1 | 1073 | 192.0.2.2/32 as a loopback of R2 | 1074 | 192.0.2.3/32 as a loopback of R3 | 1075 | 192.0.2.4/32 as a loopback of R4 | 1076 | 192.0.2.5/32 as a loopback of R5 | 1077 | 192.0.2.8/32 as a loopback of R8 | 1078 | 198.51.100.9/32 as an anycast loopback of R4 | 1079 | 198.51.100.9/32 as an anycast loopback of R5 | 1080 | | 1081 | SRGB defined by the operator as 1000-5000 | 1082 | | 1083 | Global IGP SID indices allocated by the operator: | 1084 | 1 allocated to 192.0.2.1/32 | 1085 | 2 allocated to 192.0.2.2/32 | 1086 | 3 allocated to 192.0.2.3/32 | 1087 | 4 allocated to 192.0.2.4/32 | 1088 | 8 allocated to 192.0.2.8/32 | 1089 | 1009 allocated to 198.51.100.9/32 | 1090 | | 1091 | Local IGP SID allocated dynamically by R2 | 1092 | for its "north" adjacency to R3: 9001 | 1093 | for its "east" adjacency to R3 : 9002 | 1094 | for its "south" adjacency to R3: 9003 | 1095 | for its only adjacency to R4 : 9004 | 1096 | for its only adjacency to R1 : 9005 | 1097 +-----------------------------------------------------------+ 1099 Figure 2: IGP Address and Segment Allocation - Illustration 1101 Suppose R1 wants to send an IPv4 packet P1 to R8. In this case, R1 1102 needs to apply PUSH operation to the IPv4 packet. 1104 Remember that the SID index "8" is a global IGP segment attached to 1105 the IP prefix 192.0.2.8/32. Its semantic is global within the IGP 1106 domain: any router forwards a packet received with active segment 8 1107 to the next-hop along the ECMP-aware shortest-path to the related 1108 prefix. 1110 R2 is the next-hop along the shortest path towards R8. By applying 1111 the steps in Section 2.8 the outgoing label downloaded to R1's FIB 1112 corresponding to the global SID index 8 is 1008 because the SRGB of 1113 R2 is [1000,5000] as shown in Figure 2. 1115 Because the packet is IPv4, R1 applies the PUSH operation using the 1116 label value 1008 as specified in Section 2.10.1. The resulting MPLS 1117 header will have the "S" bit [RFC3032] set because it is followed 1118 directly by an IPv4 packet. 1120 The packet arrives at router R2. Because the top label 1008 1121 corresponds to the IGP SID "8", which is the prefix-SID attached to 1122 the prefix 192.0.2.8/32 owned by the node R8, then the instruction 1123 associated with the SID is "forward the packet using all ECMP/UCMP 1124 interfaces and all ECMP/UCMP next-hop(s) along the shortest/useable 1125 path(s) towards R8". Because R2 is not the penultimate hop, R2 1126 applies the CONTINUE operation to the packet and sends it to R3 using 1127 one of the two links connected to R3 with top label 1008 as specified 1128 in Section 2.10.1. 1130 R3 receives the packet with top label 1008. Because the top label 1131 1008 corresponds to the IGP SID "8", which is the prefix-SID attached 1132 to the prefix 192.0.2.8/32 owned by the node R8, then the instruction 1133 associated with the SID is "send the packet using all ECMP interfaces 1134 and all next-hop(s) along the shortest path towards R8". Because R3 1135 is the penultimate hop, we assume that R3 performs penumtimate hop 1136 popping, which corresponds to the NEXT operation, then sends the 1137 packet to R8. The NEXT operation results in popping the outer label 1138 and sending the packet as a pure IPv4 packet to R8. 1140 In conclusion, the path followed by P1 is R1-R2--R3-R8. The ECMP- 1141 awareness ensures that the traffic be load-shared between any ECMP 1142 path, in this case the two links between R2 and R3. 1144 A.2. Incoming Label Collision Examples 1146 This section describes few examples to illustrate the handling of 1147 label collision described in Section 2.5. 1149 For the examples in this section, we assume that Node A has the 1150 following: 1152 o OSPF default admin distance for implementation=50 1154 o ISIS default admin distance for implementation=60 1156 A.2.1. Example 1 1158 Illustration of incoming label collision resolution for the same FEC 1159 type using MCC administrative distance. 1161 FEC1: 1162 o OSPF prefix SID advertisement from node B for 198.51.100.5/32 with 1163 index=5 1165 o OSPF SRGB on node A = [1000,1999] 1167 o Incoming label=1005 1169 FEC2: 1170 o ISIS prefix SID advertisement from node C for 203.0.113.105/32 1171 with index=5 1173 o ISIS SRGB on node A = [1000,1999] 1175 o Incoming label=1005 1177 FEC1 and FEC2 both use dynamic SID assignment. Since neither ofthe 1178 FEC types is SR Policy, we use the default admin distances of 50 and 1179 60 to break the tie. So FEC1 wins. 1181 A.2.2. Example 2 1183 Illustration of incoming label collision resolution for different FEC 1184 types using the MCC administrative distance. 1186 FEC1: 1187 o Node A receives an OSPF prefix sid advertisement from node B for 1188 198.51.100.6/32 with index=6 1190 o OSPF SRGB on node A = [1000,1999] 1192 o Hence the incoming label on node A corresponding to 1193 198.51.100.6/32 is 1006 1195 FEC2: 1196 ISIS on node A assigns the label 1006 to the globally significant 1197 adj-SID (I.e. when advertised the "L" flag is clear in the adj-SID 1198 sub-TLV as described in [I-D.ietf-isis-segment-routing-extensions]) 1199 towards one of its neighbors. Hence the incoming label corresponding 1200 to this adj-SID 1006. Assume Node A allocates this adj-SID 1201 dynamically, and it may differ across router reboots. 1203 FEC1 and FEC2 both use dynamic SID assignment. Since neither of the 1204 FEC types is SR Policy, we use the default admin distances of 50 and 1205 60 to break the tie. So FEC1 wins. 1207 A.2.3. Example 3 1209 Illustration of incoming label collision resolution based on 1210 preferring static over dynamic SID assignment 1212 FEC1: 1213 OSPF on node A receives a prefix SID advertisement from node B for 1214 198.51.100.7/32 with index=7. Assuming that the OSPF SRGB on node A 1215 is [1000,1999], then incoming label corresponding to 198.51.100.7/32 1216 is 1007 1218 FEC2: 1219 The operator on node A configures ISIS on node A to assign the label 1220 1007 to the globally significant adj-SID (I.e. when advertised the 1221 "L" flag is clear in the adj-SID sub-TLV as described in [I-D.ietf- 1222 isis-segment-routing-extensions]) towards one of its neighbor 1223 advertisement from node A with label=1007 1225 Node A assigns this adj-SID explicitly via configuration, so the adj- 1226 SID survives router reboots. 1228 FEC1 uses dynamic SID assignment, while FEC2 uses explicit SID 1229 assignment. So FEC2 wins. 1231 A.2.4. Example 4 1233 Illustration of incoming label collision resolution using FEC type 1234 default administrative distance 1236 FEC1: 1237 OSPF on node A receives a prefix SID advertisement from node B for 1238 198.51.100.8/32 with index=8. Assuming that OSPF SRGB on node A = 1239 [1000,1999], the incoming label corresponding to 198.51.100.8/32 is 1240 1008. 1242 FEC2: 1243 Suppose the SR Policy advertisement from controller to node A for the 1244 policy identified by (Endpoint = 192.0.2.208, color = 100) and 1245 consisting of SID-List = assigns the globally significant 1246 Binding-SID label 1008 1248 From the point of view of node A, FEC1 and FEC2 both use dynamic SID 1249 assignment. Based on the default administrative distance outlined in 1250 Section 2.5.1, the binding SID has a higher administrative distance 1251 than the prefix-SID and hence FEC1 wins. 1253 A.2.5. Example 5 1255 Illustration of incoming label collision resolution based on FEC type 1256 preference 1258 FEC1: 1259 ISIS on node A receives a prefix SID advertisement from node B for 1260 203.0.113.110/32 with index=10. Assuming that the ISIS SRGB on node A 1261 is [1000,1999], then incoming label corresponding to 203.0.113.110/32 1262 is 1010. 1264 FEC2: 1265 ISIS on node A assigns the label 1010 to the globally significant 1266 adj-SID (I.e. when advertised the "L" flag is clear in the adj-SID 1267 sub-TLV as described in [I-D.ietf-isis-segment-routing-extensions]) 1268 towards one of its neighbors). 1270 Node A allocates this adj-SID dynamically, and it may differ across 1271 router reboots. Hence both FEC1 and FEC2 both use dynamic SID 1272 assignment. 1274 Since both FECs are from the same MCC, they have the same default 1275 admin distance. So we compare FEC type code-point. FEC1 has FEC type 1276 code-point=120, while FEC2 has FEC type code-point=130. Therefore, 1277 FEC1 wins. 1279 A.2.6. Example 6 1281 Illustration of incoming label collision resolution based on address 1282 family preference. 1284 FEC1: 1285 ISIS on node A receives prefix SID advertisement from node B for 1286 203.0.113.111/32 with index 11. Assuming that the ISIS SRGB on node A 1287 is [1000,1999], the incoming label on node A for 203.0.113.111/32 is 1288 1011. 1290 FEC2: 1291 ISIS on node A prefix SID advertisement from node C for 1292 2001:DB8:1000::11/128 with index=11. Assuming that the ISIS SRGB on 1293 node A is [1000,1999], the incoming label on node A for 1294 2001:DB8:1000::11/128 is 1011 1296 FEC1 and FEC2 both use dynamic SID assignment. Since both FECs are 1297 from the same MCC, they have the same default admin distance. So we 1298 compare FEC type code-point. Both FECs have FEC type code-point=120. 1299 So we compare address family. Since IPv4 is preferred over IPv6, FEC1 1300 wins. 1302 A.2.7. Example 7 1304 Illustration incoming label collision resolution based on prefix 1305 length. 1307 FEC1: 1308 ISIS on node A receives a prefix SID advertisement from node B for 1309 203.0.113.112/32 with index 12. Assuming that ISIS SRGB on node A is 1310 [1000,1999], the incoming label for 203.0.113.112/32 on node A is 1311 1012. 1313 FEC2: 1314 ISIS on node A receives a prefix SID advertisement from node C for 1315 203.0.113.128/30 with index 12. Assuming that the ISIS SRGB on node A 1316 is [1000,1999], then incoming label for 203.0.113.128/30 on node A is 1317 1012 1319 FEC1 and FEC2 both use dynamic SID assignment. Since both FECs are 1320 from the same MCC, they have the same default admin distance. So we 1321 compare FEC type code-point. Both FECs have FEC type code-point=120. 1322 So we compare address family. Both are IPv4 address family, so we 1323 compare prefix length. FEC1 has prefix length=32, and FEC2 has 1324 prefix length=30, so FEC2 wins. 1326 A.2.8. Example 8 1328 Illustration of incoming label collision resolution based on the 1329 numerical value of the FECs. 1331 FEC1: 1332 ISIS on node A receives a prefix SID advertisement from node B for 1333 203.0.113.113/32 with index 13. Assuming that ISIS SRGB on node A is 1335 [1000,1999], then the incoming label for 203.0.113.113/32 on node A 1336 is 1013 1338 FEC2: 1339 ISIS on node A receives a prefix SID advertisement from node C for 1340 203.0.113.213/32 with index 13. Assuming that ISIS SRGB on node A is 1341 [1000,1999], then the incoming label for 203.0.113.213/32 on node A 1342 is 1013 1344 FEC1 and FEC2 both use dynamic SID assignment. Since both FECs are 1345 from the same MCC, they have the same default admin distance. So we 1346 compare FEC type code-point. Both FECs have FEC type code-point=120. 1347 So we compare address family. Both are IPv4 address family, so we 1348 compare prefix length. Prefix lengths are the same, so we compare 1349 prefix. FEC1 has the lower prefix, so FEC1 wins. 1351 A.2.9. Example 9 1353 Illustration of incoming label collision resolution based on routing 1354 instance ID. 1356 FEC1: 1357 ISIS on node A receives a prefix SID advertisement from node B for 1358 203.0.113.114/32 with index 14. Assume that this ISIS instance on 1359 node A has the Routing Instance ID 1000 and SRGB [1000,1999]. Hence 1360 the incoming label for 203.0.113.114/32 on node A is 1014 1362 FEC2: 1363 ISIS on node A receives a prefix SID advertisement from node C for 1364 203.0.113.114/32 with index=14. Assume that this is another instance 1365 of ISIS on node A with a different routing Instance ID 2000 but the 1366 same SRGB [1000,1999]. Hence incoming label for 203.0.113.114/32 on 1367 node A 1014 1369 These two FECs match all the way through the prefix length and 1370 prefix. So Routing Instance ID breaks the tie, with FEC1 winning. 1372 A.2.10. Example 10 1374 Illustration of incoming label collision resolution based on topology 1375 ID. 1377 FEC1: 1378 ISIS on node A receives a prefix SID advertisement from node B for 1379 203.0.113.115/32 with index=15. Assume that this ISIS instance on 1380 node A has Routing Instance ID 1000. Assume that the prefix 1381 advertisement of 203.0.113.115/32 was received in ISIS Multi-topology 1382 advertisement with ID = 50. If the ISIS SRGB for this routing 1383 instance on node A is [1000,1999], then incoming label of 1384 203.0.113.115/32 for topology 50 on node A is 1015 1386 FEC2: 1387 ISIS on node A receives a prefix SID advertisement from node C for 1388 203.0.113.115/32 with index 15. Assume that it is the same routing 1389 Instance ID = 1000 but 203.0.113.115/32 was advertised with a 1390 different ISIS Multi-topology ID = 40. If the ISIS SRGB on node A is 1391 [1000,1999], then incoming label of 203.0.113.115/32 for topology 40 1392 on node A is also 1015 1394 These two FECs match all the way through the prefix length, prefix, 1395 and Routing Instance ID. We compare ISIS Multi-topology ID, so FEC2 1396 wins. 1398 A.2.11. Example 11 1400 Illustration of incoming label collision for resolution based on 1401 algorithm ID. 1403 FEC1: 1404 ISIS on node A receives a prefix SID advertisement from node B for 1405 203.0.113.116/32 with index=16 Assume that ISIS on node A has Routing 1406 Instance ID = 1000. Assume that node B advertised 203.0.113.116/32 1407 with ISIS Multi-topology ID = 50 and SR algorithm = 0. Assume that 1408 the ISIS SRGB on node A = [1000,1999]. Hence the incoming label 1409 corresponding to this advertisement of 203.0.113.116/32 is 1016. 1411 FEC2: 1412 ISIS on node A receives a prefix SID advertisement from node C for 1413 203.0.113.116/32 with index=16. Assume that it is the same ISIS 1414 instance on node A with Routing Instance ID = 1000. Also assume that 1415 node C advertised 203.0.113.116/32 with ISIS Multi-topology ID = 50 1416 but with SR algorithm = 22. Since it is the same routing instance, 1417 the SRGB on node A = [1000,1999]. Hence the incoming label 1418 corresponding to this advertisement of 203.0.113.116/32 by node C is 1419 also 1016. 1421 These two FECs match all the way through the prefix length, prefix, 1422 and Routing Instance ID, and Multi-topology ID. We compare SR 1423 algorithm ID, so FEC1 wins. 1425 A.2.12. Example 12 1427 Illustration of incoming label collision resolution based on FEC 1428 numerical value and independent of how the SID assigned to the 1429 colliding FECs. 1431 FEC1: 1432 ISIS on node A receives a prefix SID advertisement from node B for 1433 203.0.113.117/32 with index 17. Assume that the ISIS SRGB on node A 1434 is [1000,1999], then the incoming label is 1017 1436 FEC2: 1437 Suppose there is an ISIS mapping server advertisement (SID/Label 1438 Binding TLV) from node D has Range 100 and Prefix = 203.0.113.1/32. 1439 Suppose this mapping server advertisement generates 100 mappings, one 1440 of which maps 203.0.113.17/32 to index 17. Assuming that it is the 1441 same ISIS instance, then the SRGB is [1000,1999] and hence the 1442 incoming label for 1017. 1444 The fact that FEC1 comes from a normal prefix SID advertisement and 1445 FEC2 is generated from a mapping server advertisement is not used as 1446 a tie-breaking parameter. Both FECs use dynamic SID assignment, are 1447 from the same MCC, have the same FEC type code-point=120. Their 1448 prefix lengths are the same as well. FEC2 wins based on lower 1449 numerical prefix value, since 203.0.113.17 is less than 1450 203.0.113.117. 1452 A.2.13. Example 13 1454 Illustration of incoming label collision resolution based on address 1455 family preference 1457 FEC1: 1458 SR Policy advertisement from controller to node A. Endpoint 1459 address=2001:DB8:3000::100, color=100, SID-List= and the 1460 Binding-SID label=1020 1462 FEC2: 1463 SR Policy advertisement from controller to node A. Endpoint 1464 address=192.0.2.60, color=100, SID-List= and the Binding-SID 1465 label=1020 1466 The FECs match through the tie-breaks up to and including having the 1467 same FEC type code-point=140. FEC2 wins based on IPv4 address family 1468 being preferred over IPv6. 1470 A.2.14. Example 14 1472 Illustration of incoming label resolution based on numerical value of 1473 the policy endpoint. 1475 FEC1: 1476 SR Policy advertisement from controller to node A. Endpoint 1477 address=192.0.2.70, color=100, SID-List= and Binding-SID 1478 label=1021 1480 FEC2: 1481 SR Policy advertisement from controller to node A Endpoint 1482 address=192.0.2.71, color=100, SID-List= and Binding-SID 1483 label=1021 1485 The FECs match through the tie-breaks up to and including having the 1486 same address family. FEC1 wins by having the lower numerical endpoint 1487 address value. 1489 A.3. Examples for the Effect of Incoming Label Collision on Outgoing 1490 Label 1492 This section presents examples to illustrate the effect of incoming 1493 label collision on the selection of the outgoing label described in 1494 Section 2.6. 1496 A.3.1. Example 1 1498 Illustration of the effect of incoming label resolution on the 1499 outgoing label 1501 FEC1: 1502 ISIS on node A receives a prefix SID advertisement from node B for 1503 203.0.113.122/32 with index 22. Assuming that the ISIS SRGB on node A 1504 is [1000,1999] the corresponding incoming label is 1022. 1506 FEC2: 1507 ISIS on node A receives a prefix SID advertisement from node C for 1508 203.0.113.222/32 with index=22 Assuming that the ISIS SRGB on node A 1509 is [1000,1999] the corresponding incoming label is 1022. 1511 FEC1 wins based on lowest numerical prefix value. This means that 1512 node A installs a transit MPLS forwarding entry to SWAP incoming 1513 label 1022, with outgoing label N and use outgoing interface I. N is 1514 determined by the index associated with FEC1 (index 22) and the SRGB 1515 advertised by the next-hop node on the shortest path to reach 1516 203.0.113.122/32. 1518 Node A will generally also install an imposition MPLS forwarding 1519 entry corresponding to FEC1 for incoming prefix=203.0.113.122/32 1520 pushing outgoing label N, and using outgoing interface I. 1522 The rule in Section 2.6 means node A MUST NOT install an ingress 1523 MPLS forwarding entry corresponding to FEC2 (the losing FEC, which 1524 would be for prefix 203.0.113.222/32). 1526 A.3.2. Example 2 1528 Illustration of the effect of incoming label collision resolution on 1529 outgoing label programming on node A 1531 FEC1: 1532 o SR Policy advertisement from controller to node A 1534 o Endpoint address=192.0.2.80, color=100, SID-List= 1536 o Binding-SID label=1023 1538 FEC2: 1539 o SR Policy advertisement from controller to node A 1541 o Endpoint address=192.0.2.81, color=100, SID-List= 1543 o Binding-SID label=1023 1545 FEC1 wins by having the lower numerical endpoint address value. This 1546 means that node A installs a transit MPLS forwarding entry to SWAP 1547 incoming label=1023, with outgoing labels and outgoing interface 1548 determined by the SID-List for FEC1. 1550 In this example, we assume that node A receives two BGP/VPN routes: 1552 o R1 with VPN label=V1, BGP next-hop = 192.0.2.80, and color=100, 1554 o R2 with VPN label=V2, BGP next-hop = 192.0.2.81, and color=100, 1555 We also assume that A has a BGP policy which matches on color=100 1556 that allows that its usage as SLA steering information. In this case, 1557 node A will install a VPN route with label stack = 1558 (corresponding to FEC1). 1560 The rule described in section 2.6 means that node A MUST NOT install 1561 a VPN route with label stack = (corresponding to FEC2.)