idnits 2.17.00 (12 Aug 2021) /tmp/idnits27202/draft-ietf-spring-conflict-resolution-01.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (June 22, 2016) is 2158 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) == Outdated reference: draft-ietf-isis-segment-routing-extensions has been published as RFC 8667 == Outdated reference: draft-ietf-spring-segment-routing-mpls has been published as RFC 8660 == Outdated reference: draft-ietf-ospf-segment-routing-extensions has been published as RFC 8665 == Outdated reference: draft-ietf-ospf-ospfv3-segment-routing-extensions has been published as RFC 8666 == Outdated reference: draft-ietf-spring-segment-routing has been published as RFC 8402 Summary: 0 errors (**), 0 flaws (~~), 6 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Networking Working Group L. Ginsberg 3 Internet-Draft P. Psenak 4 Intended status: Standards Track S. Previdi 5 Expires: December 24, 2016 Cisco Systems 6 M. Pilka 7 June 22, 2016 9 Segment Routing Conflict Resolution 10 draft-ietf-spring-conflict-resolution-01.txt 12 Abstract 14 In support of Segment Routing (SR) routing protocols advertise a 15 variety of identifiers used to define the segments which direct 16 forwarding of packets. In cases where the information advertised by 17 a given protocol instance is either internally inconsistent or 18 conflicts with advertisements from another protocol instance a means 19 of achieving consistent forwarding behavior in the network is 20 required. This document defines the policies used to resolve these 21 occurrences. 23 Requirements Language 25 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 26 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 27 document are to be interpreted as described in RFC 2119 [RFC2119]. 29 Status of This Memo 31 This Internet-Draft is submitted in full conformance with the 32 provisions of BCP 78 and BCP 79. 34 Internet-Drafts are working documents of the Internet Engineering 35 Task Force (IETF). Note that other groups may also distribute 36 working documents as Internet-Drafts. The list of current Internet- 37 Drafts is at http://datatracker.ietf.org/drafts/current/. 39 Internet-Drafts are draft documents valid for a maximum of six months 40 and may be updated, replaced, or obsoleted by other documents at any 41 time. It is inappropriate to use Internet-Drafts as reference 42 material or to cite them other than as "work in progress." 44 This Internet-Draft will expire on December 24, 2016. 46 Copyright Notice 48 Copyright (c) 2016 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (http://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with respect 56 to this document. Code Components extracted from this document must 57 include Simplified BSD License text as described in Section 4.e of 58 the Trust Legal Provisions and are provided without warranty as 59 described in the Simplified BSD License. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 64 2. SR Global Block Inconsistency . . . . . . . . . . . . . . . . 3 65 3. SR-MPLS Segment Identifier Conflicts . . . . . . . . . . . . 5 66 3.1. Conflict Types . . . . . . . . . . . . . . . . . . . . . 6 67 3.1.1. Prefix Conflict . . . . . . . . . . . . . . . . . . . 6 68 3.1.2. SID Conflict . . . . . . . . . . . . . . . . . . . . 8 69 3.2. Processing conflicting entries . . . . . . . . . . . . . 9 70 3.2.1. Policy: Ignore conflicting entries . . . . . . . . . 9 71 3.2.2. Policy: Preference Algorithm/Quarantine . . . . . . . 10 72 3.2.3. Policy: Preference algorithm/ignore overlap only . . 10 73 3.2.4. Preference Algorithm . . . . . . . . . . . . . . . . 10 74 3.2.5. Example Behavior - Single Topology/Algorithm . . . . 11 75 3.2.6. Example Behavior - Multiple Topologies . . . . . . . 12 76 3.2.7. Evaluation of Policy Alternatives . . . . . . . . . . 13 77 3.2.8. Guaranteeing Database Consistency . . . . . . . . . . 14 78 4. Scope of SR-MPLS SID Conflicts . . . . . . . . . . . . . . . 14 79 5. Security Considerations . . . . . . . . . . . . . . . . . . . 15 80 6. IANA Consideration . . . . . . . . . . . . . . . . . . . . . 15 81 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 15 82 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 83 8.1. Normative References . . . . . . . . . . . . . . . . . . 15 84 8.2. Informational References . . . . . . . . . . . . . . . . 16 85 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 87 1. Introduction 89 Segment Routing (SR) as defined in [SR-ARCH] utilizes forwarding 90 instructions called "segments" to direct packets through the network. 91 Depending on the forwarding plane architecture in use, routing 92 protocols advertise various identifiers which define the permissible 93 values which can be used as segments, which values are assigned to 94 specific prefixes, etc. Where segments have global scope it is 95 necessary to have non-conflicting assignments - but given that the 96 advertisements may originate from multiple nodes the possibility 97 exists that advertisements may be received which are either 98 internally inconsistent or conflicting with advertisements originated 99 by other nodes. In such cases it is necessary to have consistent 100 resolution of conflicts network-wide in order to avoid forwarding 101 loops. 103 The problem to be addressed is protocol independent i.e., segment 104 related advertisements may be originated by multiple nodes using 105 different protocols and yet the conflict resolution MUST be the same 106 on all nodes regardless of the protocol used to transport the 107 advertisements. 109 The remainder of this document defines conflict resolution policies 110 which meet these requirements. All protocols which support SR MUST 111 adhere to the policies defined in this document. 113 2. SR Global Block Inconsistency 115 In support of an MPLS dataplane routing protocols advertise an SR 116 Global Block (SRGB) which defines a set of label ranges reserved for 117 use by the advertising node in support of SR. The details of how 118 protocols advertise this information can be found in the protocol 119 specific drafts e.g., [SR-OSPF], [SR-OSPFv3], and [SR-IS-IS]. 120 However the protocol independent semantics are illustrated by the 121 following example: 123 The originating router advertises the following ranges: 125 Range 1: (100, 199) 126 Range 2: (1000, 1099) 127 Range 3: (500, 599) 129 The receiving routers concatenate the ranges and build the Segment 130 Routing Global Block (SRGB) as follows: 132 SRGB = (100, 199) 133 (1000, 1099) 134 (500, 599) 136 The indeces span multiple ranges: 138 index=0 means label 100 139 ... 140 index 99 means label 199 141 index 100 means label 1000 142 index 199 means label 1099 143 ... 144 index 200 means label 500 145 ... 147 Note that the ranges are an ordered set - what labels are mapped to a 148 given index depends on the placement of a given label range in the 149 set of ranges advertised. 151 For the set of ranges to be usable the ranges MUST be disjoint. 152 Sender behavior is defined in various SR protocol drafts such as [SR- 153 IS-IS] which specify that senders MUST NOT advertise overlapping 154 ranges. 156 Receivers of SRGB ranges MUST validate the SRGB ranges advertised by 157 other nodes. If the advertised ranges do not conform to the 158 restrictions defined in the respective protocol specification 159 receivers MUST ignore all advertised SRGB ranges from that node. 160 Operationally the node is treated as though it did not advertise any 161 SRGB ranges. [SR-MPLS] defines the procedures for mapping global 162 SIDs to outgoing labels. 164 Note that utilization of local SIDs (e.g. adjacency SIDs) advertised 165 by a node is not affected by the state of the advertised SRGB. 167 3. SR-MPLS Segment Identifier Conflicts 169 In support of an MPLS dataplane Segment identifiers (SIDs) are 170 advertised and associated with a given prefix. SIDs may be 171 advertised in the prefix reachability advertisements originated by a 172 routing protocol (PFX) . SIDs may also be advertised by a Segment 173 Routing Mapping Server (SRMS). 175 Mapping entries have an explicit context which includes the topology 176 and the SR algorithm. A generalized mapping entry can be represented 177 using the following definitions: 179 Src- PFX or SRMS 180 Pi - Initial prefix 181 Pe - End prefix 182 L - Prefix length 183 Lx - Maximum prefix length (32 for IPv4, 128 for IPv6) 184 Si - Initial SID value 185 Se - End SID value 186 R - Range value (See Note 1) 187 T - Topology 188 A - Algorithm 190 A Mapping Entry is then the tuple: (Src, Pi/L, Si, R, T, A) 191 Pe = (Pi + ((R-1) << (Lx-L)) 192 Se = Si + (R-1) 194 NOTE 1: The SID advertised in a prefix reachability advertisement 195 always has an implicit range of 1. 197 Conflicts in SID advertisements may occur as a result of 198 misconfiguration. Conflicts may occur either in the set of 199 advertisements originated by a single node or between advertisements 200 originated by different nodes. Conflicts which occur within the set 201 of advertisements (P-SID and SRMS) originated by a single node SHOULD 202 be prevented by configuration validation on the originating node. 204 When conflicts occur, it is not possible for routers to know which of 205 the conflicting advertisements is "correct". In order to avoid 206 forwarding loops and/or blackholes, there is a need for all nodes to 207 resolve the conflicts in a consistent manner. This in turn requires 208 that all routers have identical sets of advertisements and that they 209 all use the same selection algorithm. This document defines 210 procedures to achieve these goals. 212 3.1. Conflict Types 214 Two types of conflicts may occur - Prefix Conflicts and SID 215 Conflicts. Examples are provided in this section to illustrate these 216 conflict types. 218 3.1.1. Prefix Conflict 220 When different SIDs are assigned to the same prefix we have a "prefix 221 conflict". Prefix conflicts are specific to mapping entries sharing 222 the same topology and algorithm. 224 Example PC1 226 (PFX, 192.0.2.120/32, 200, 1, 0, 0) 227 (PFX, 192.0.2.120/32, 30, 1, 0, 0) 229 The prefix 192.0.2.120/32 has been assigned two different SIDs: 230 200 by the first advertisement 231 30 by the second advertisement 233 Example PC2 235 (PFX, 2001:DB8::1/128, 400, 1, 2, 0) 236 (PFX, 2001:DB8::1/128, 50, 1, 2, 0) 238 The prefix 2001:DB8::1/128 has been assigned two different SIDs: 239 400 by the first advertisement 240 50 by the second advertisement 242 Prefix conflicts may also occur as a result of overlapping prefix 243 ranges. 245 Example PC3 247 (SRMS, 192.0.2.1/32, 200, 200, 0, 0) 248 (SRMS, 192.0.2.121/32, 30, 10, 0, 0) 250 Prefixes 192.0.2.121/32 - 192.0.2.130/32 are assigned two 251 different SIDs: 252 320 through 329 by the first advertisement 253 30 through 39 by the second advertisement 255 Example PC4 256 (SRMS, 2001:DB8::1/128, 400, 200, 2, 0) 257 (SRMS, 2001:DB8::121/128, 50, 10, 2, 0) 259 Prefixes 2001:DB8::121/128 - 2001:DB8::130/128 are assigned 260 two different SIDs: 261 420 through 429 by the first advertisement 262 50 through 59 by the second advertisement 264 Examples PC3 and PC4 illustrate a complication - only part of the 265 range advertised in the first advertisement is in conflict. It is 266 logically possible to isolate the conflicting portion and try to use 267 the non-conflicting portion(s) at the cost of increased 268 implementation complexity. 270 A variant of the overlapping prefix range is a case where we have 271 overlapping prefix ranges but no actual SID conflict. 273 Example PC5 275 (SRMS, 192.0.2.1/32, 200, 200, 0, 0) 276 (SRMS, 192.0.2.121/32, 320, 10, 0, 0) 278 (SRMS, 2001:DB8::1/128, 400, 200, 2, 0) 279 (SRMS, 2001:DB8::121/128, 520, 10, 2, 0) 281 Although there is prefix overlap between the two IPv4 entries (and 282 the two IPv6 entries) the same SID is assigned to all of the shared 283 prefixes by the two entries. 285 Given two mapping entries: 287 (SRC, P1/L1, S1, R1, T1, A1) and 288 (SRC, P2/L2, S2, R2, T2, A2) 290 where P1 <= P2 292 a prefix conflict exists if all of the following are true: 294 1)(T1 == T2) && (A1 == A2) 295 2)P1 <= P2 296 3)The prefixes are in the same address family. 297 2)L1 == L2 298 3)(P1e >= P2) && ((S1 + (P2 - P1)) != S2) 300 3.1.2. SID Conflict 302 When the same SID has been assigned to multiple prefixes we have a 303 "SID conflict". SID conflicts are independent of address-family, 304 independent of prefix len, independent of topology, and independent 305 of algorithm. A SID conflict occurs when a mapping entry which has 306 previously been checked to have no prefix conflict assigns one or 307 more SIDs that are assigned by another entry which also has no prefix 308 conflicts. 310 Example SC1 312 (PFX, 192.0.2.1/32, 200, 1, 0, 0) 313 (PFX, 192.0.2.222/32, 200, 1, 0, 0) 314 SID 200 has been assigned to 192.0.2.1/32 by the 315 first advertisement. 316 The second advertisement assigns SID 200 to 192.0.2.222/32. 318 Example SC2 320 (PFX, 2001:DB8::1/128, 400, 1, 2, 0) 321 (PFX, 2001:DB8::222/128, 400, 1, 2, 0) 322 SID 400 has been assigned to 2001:DB8::1/128 by the 323 first advertisement. 324 The second advertisement assigns SID 400 to 2001:DB8::222/128 326 SID conflicts may also occur as a result of overlapping SID ranges. 328 Example SC3 330 (SRMS, 192.0.2.1/32, 200, 200, 0, 0) 331 (SRMS, 198.51.100.1/32, 300, 10, 0, 0) 333 SIDs 300 - 309 have been assigned to two different prefixes. 334 The first advertisement assigns these SIDs 335 to 192.0.2.101/32 - 192.0.2.110/32. 336 The second advertisement assigns these SIDs to 337 198.51.100.1/32 - 198.51.100.10/32. 339 Example SC4 340 (SRMS, 2001:DB8::1/128, 400, 200, 2, 0) 341 (SRMS, 2001:DB8:1::1/128, 500, 10, 2, 0) 343 SIDs 500 - 509 have been assigned to two different prefixes. 344 The first advertisement assigns these SIDs to 345 2001:DB8::101/128 - 2001:DB8::10A/128. 346 The second advertisement assigns these SIDs to 347 2001:DB8:1::1/128 - 2001:DB8:1::A/128. 349 Examples SC3 and SC4 illustrate a complication - only part of the 350 range advertised in the first advertisement is in conflict. 352 3.2. Processing conflicting entries 354 Two general approaches can be used to process conflicting entries. 356 1. Conflicting entries can be ignored 358 2. A standard preference algorithm can be used to choose which of 359 the conflicting entries will be used 361 The following sections discuss these two approaches in more detail. 363 Note: This document does not discuss any implementation details i.e. 364 what type of data structure is used to store the entries (trie, radix 365 tree, etc.) nor what type of keys may be used to perform lookups in 366 the database. 368 3.2.1. Policy: Ignore conflicting entries 370 In cases where entries are in conflict none of the conflicting 371 entries are used i.e., the network operates as if the conflicting 372 advertisements were not present. 374 Implementations are required to identify the conflicting entries and 375 ensure that they are not used. 377 3.2.2. Policy: Preference Algorithm/Quarantine 379 For entries which are in conflict properties of the conflicting 380 advertisements are used to determine which of the conflicting entries 381 are used in forwarding and which are "quarantined" and not used. The 382 entire quarantined entry is not used. 384 This approach requires that conflicting entries first be identified 385 and then evaluated based on a preference rule. Based on which entry 386 is preferred this in turn may impact what other entries are 387 considered in conflict i.e. if A conflicts with B and B conflicts 388 with C - it is possible that A does NOT conflict with C. Hence if as 389 a result of the evaluation of the conflict between A and B, entry B 390 is not used the conflict between B and C will not be detected. 392 3.2.3. Policy: Preference algorithm/ignore overlap only 394 A variation of the preference algorithm approach is to quarantine 395 only the portions of the less preferred entry which actually 396 conflicts. The original entry is split into multiple ranges. The 397 ranges which are in conflict are quarantined. The ranges which are 398 not in conflict are used in forwarding. This approach adds 399 complexity as the relationship between the derived sub-ranges of the 400 original mapping entry have to be associated with the original entry 401 - and every time some change to the advertisement database occurs the 402 derived sub-ranges have to be recalculated. 404 3.2.4. Preference Algorithm 406 The following algorithm is used to select the preferred mapping entry 407 when a conflict exists. Evaluation is made in the order specified. 408 Prefix conflicts are evaluated first. SID conflicts are then 409 evaluated on the Active entries remaining after Prefix Conflicts have 410 been resolved. 412 1. PFX source wins over SRMS source 414 2. Smaller range wins 416 3. IPv6 entry wins over IPv4 entry 418 4. Longer prefix length wins 420 5. Smaller algorithm wins 421 6. Smaller starting address (considered as an unsigned integer 422 value) wins 424 7. Smaller starting SID wins 426 8. If topology IDs are NOT identical both entries MUST be ignored 428 Using smaller range as the highest priority tie breaker makes 429 advertisements with a range of 1 the most preferred. This has the 430 nice property that a single misconfiguration of an SRMS entry with a 431 large range will not be preferred over a large number of 432 advertisements with smaller ranges. 434 Since topology identifiers are locally scoped, it is not possible to 435 make a consistent choice network wide when all elements of a mapping 436 entry are identical except for the topology. This is why both 437 entries MUST be ignored in such cases (Rule #8 above). Note that 438 Rule #8 only applies when considering SID conflicts since Prefix 439 conflicts are restricted to a single topology. 441 3.2.5. Example Behavior - Single Topology/Algorithm 443 The following mapping entries exist:in the database. For brevity, 444 Topology/Algorithm is omitted and assumed to be (0,0) in all entries. 446 1. (PFX, 192.0.2.1/32, 100, 1) 448 2. (PFX, 192.0.2.101/32, 200, 1) 450 3. (SRMS, 192.0.2.1/32, 400, 255) !Prefix conflict with entries 1 451 and 2 453 4. (SRMS, 198.51.100.40/32, 200,1) !SID conflict with entry 2 455 The table below shows what mapping entries will be used in the 456 forwarding plane (Active) and which ones will not be used (Excluded) 457 under the three candidate policies: 459 +--------------------------------------------------------------------+ 460 |Policy | Active Entries | Excluded Entries | 461 +--------------------------------------------------------------------+ 462 |Ignore | |(PFX,192.0.2.1/32,100,1) | 463 | | |(PFX,192.0.2.101/32,200,1) | 464 | | |(SRMS,192.0.2.1/32,400,255) | 465 | | |(SRMS,198.51.100.40/32,200,1)| 466 +--------------------------------------------------------------------+ 467 |Quarantine|(PFX,192.0.1.1/32,100,1) |(SRMS,192.0.2.1/32,400,255) | 468 | |(PFX,192.0.2.101/32,200,1) |(SRMS,198.51.100.40/32,200,1)| 469 +--------------------------------------------------------------------+ 470 |Overlap- |(PFX,192.0.2.1/32,100,1) |(SRMS,198.51.100.40/32,200,1)| 471 | Only |(PFX,192.0.2.101/32,200,1) |*(SRMS,192.0.2.1/32,400,1) | 472 | |*(SRMS,192.0.2.2/32,401,99)|*(SRMS,192.0.2.101/32,500,1) | 473 | |*(SRMS,192.0.2.102/32, | 474 | | 501,153) | | 475 +--------------------------------------------------------------------+ 477 * Derived from (SRMS,192.0.2.1/32,400,300) 479 3.2.6. Example Behavior - Multiple Topologies 481 When using a preference rule the order in which conflict resolution 482 is applied has an impact on what entries are usable when entries for 483 multiple topologies (or algorithms) are present. The following 484 mapping entries exist in the database: 486 1. (PFX, 192.0.2.1/32, 100, 1, 0, 0) !Topology 0 488 2. (PFX, 192.0.2.1/32, 200, 1, 0, 0) !Topology 0, Prefix Conflict 489 with entry #1 491 3. (PFX, 198.51.100.40/32, 200,1,1,0) ! Topology 1, SID conflict 492 with entry 2 494 The table below shows what mapping entries will be used in the 495 forwarding plane (Active) and which ones will not be used (Excluded) 496 under the Quarantine Policy based on the order in which conflict 497 resolution is applied. 499 +------------------------------------------------------------------+ 500 |Order | Active Entries | Excluded Entries | 501 +------------------------------------------------------------------+ 502 |Prefix- |(PFX,192.0.2.1/32,100,1,0,0)|(PFX,192.0.2.101/32,200,1,0)| 503 |Conflict|(PFX,198.51.100.40/32,200,1,| | 504 |First | 1,0) | | 505 +------------------------------------------------------------------+ 506 |SID- |(PFX,192.0.2.1/32,100,1,0,0)|(PFX,192.0.2.101/32,200,1,0)| 507 |Conflict| |(PFX,198.51.100.40/32,200,1,| 508 |First | | 1,0) | 509 +------------------------------------------------------------------+ 511 This illustrates the advantage of evaluating prefix conflicts within 512 a given topology (or algorithm) before evaluating topology (or 513 algorithm) independent SID conflicts. It insures that entries which 514 will be excluded based on intratopology preference will not prevent a 515 SID assigned in another topology from being considered Active. 517 3.2.7. Evaluation of Policy Alternatives 519 The previous sections have defined three alternatives for resolving 520 conflicts - ignore, quarantine, and ignore overlap-only. 522 The ignore policy impacts the greatest amount of traffic as 523 forwarding to all destinations which have a conflict is affected. 525 Quarantine allows forwarding for some destinations which have a 526 conflict to be supported. 528 Ignore overlap-only maximizes the destinations which will be 529 forwarded as all destinations covered by some mapping entry 530 (regardless of range) will be able to use the SID assigned by the 531 winning range. This alternative increases implementation complexity 532 as compared to quarantine. Mapping entries with a range greater than 533 1 which are in conflict with other mapping entries have to internally 534 be split into 2 or more "derived mapping entries". The derived 535 mapping entries then fall into two categories - those that are in 536 conflict with other mapping entries and those which are NOT in 537 conflict. The former are ignored and the latter are used. Each time 538 the underived mapping database is updated the derived entries have to 539 be recomputed based on the updated database. Internal data 540 structures have to be maintained which maintain the relationship 541 between the advertised mapping entry and the set of derived mapping 542 entries. All nodes in the network have to achieve the same behavior 543 regardless of implementation internals. 545 There is then a tradeoff between a goal of maximizing traffic 546 delivery and the risks associated with increased implementation 547 complexity. 549 It is the opinion of the authors that "quarantine" is the best 550 alternative. 552 3.2.8. Guaranteeing Database Consistency 554 In order to obtain consistent active entries all nodes in a network 555 MUST have the same mapping entry database. Mapping entries can be 556 obtained from a variety of sources. 558 o SIDs can be configured locally for prefixes assigned to interfaces 559 on the router itself. Only SIDs which are advertised to protocol 560 peers can be considered as part of the mapping entry database. 562 o SIDs can be received in prefix reachability advertisements from 563 protocol peers. These advertisements may originate from peers 564 local to the area or be leaked from other areas and/or 565 redistributed from other routing protocols. 567 o SIDs can be received from SRMS advertisements - these 568 advertisements can originate from routers local to the area or 569 leaked from other areas 571 o In cases where multiple routing protocols are in use mapping 572 entries advertised by all routing protocols MUST be included. 574 4. Scope of SR-MPLS SID Conflicts 576 The previous section defines the types of SID conflicts and 577 procedures to resolve such conflicts when using an MPLS dataplane. 578 The mapping entry database used MUST be populated with entries for 579 destinations for which the associated SID will be used to derive the 580 labels installed in the forwarding plane of routers in the network. 581 This consists of entries associated with intra-domain routes. 583 There are cases where destinations which are external to the domain 584 are advertised by protocol speakers running within that network - and 585 it is possible that those advertisements have SIDs associated with 586 those destinations. However, if reachability to a destination is 587 topologically outside the forwarding domain of the protocol instance 588 then the SIDs for such destinations will never be installed in the 589 forwarding plane of any router within the domain - so such 590 advertisements cannot create a SID conflict within the domain. Such 591 entries therefore MUST NOT be installed in the database used for 592 intra-domain conflict resolution. 594 Consider the case of two sites "A and B" associated with a given 595 [RFC4364] VPN. Connectivity between the sites is via a provider 596 backbone. SIDs associated with destinations in Site A will never be 597 installed in the forwarding plane of routers in Site B. Reachability 598 between the sites (assuming SR is being used across the backbone) 599 only requires using a SID associated with a gateway PE. So a 600 destination in Site A MAY use the same SID as a destination in Site B 601 without introducing any conflict in the forwarding plane of routers 602 in Site A. 604 Such cases are handled by insuring that the mapping entries in the 605 database used by the procedures defined in the previous section only 606 include entries associated with advertisements within the site. 608 5. Security Considerations 610 TBD 612 6. IANA Consideration 614 This document has no actions for IANA. 616 7. Acknowledgements 618 The authors would like to thank Jeff Tantsura, Wim Henderickx, and 619 Bruno Decraene for their careful review and content suggestions. 621 8. References 623 8.1. Normative References 625 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 626 Requirement Levels", BCP 14, RFC 2119, 627 DOI 10.17487/RFC2119, March 1997, 628 . 630 [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private 631 Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February 632 2006, . 634 [SR-IS-IS] 635 "IS-IS Extensions for Segment Routing, draft-ietf-isis- 636 segment-routing-extensions-07(work in progress)", June 637 2016. 639 [SR-MPLS] "Segment Routing with MPLS dataplane, draft-ietf-spring- 640 segment-routing-mpls-04(work in progress)", March 2016. 642 [SR-OSPF] "OSPF Extensions for Segment Routing, draft-ietf-ospf- 643 segment-routing-extensions-08(work in progress)", May 644 2016. 646 [SR-OSPFv3] 647 "OSPFv3 Extensions for Segment Routing, draft-ietf-ospf- 648 ospfv3-segment-routing-extensions-05(work in progress)", 649 March 2016. 651 8.2. Informational References 653 [SR-ARCH] "Segment Routing Architecture, draft-ietf-spring-segment- 654 routing-08(work in progress)", May 2016. 656 Authors' Addresses 658 Les Ginsberg 659 Cisco Systems 660 510 McCarthy Blvd. 661 Milpitas, CA 95035 662 USA 664 Email: ginsberg@cisco.com 666 Peter Psenak 667 Cisco Systems 668 Apollo Business Center Mlynske nivy 43 669 Bratislava 821 09 670 Slovakia 672 Email: ppsenak@cisco.com 674 Stefano Previdi 675 Cisco Systems 676 Via Del Serafico 200 677 Rome 0144 678 Italy 680 Email: sprevidi@cisco.com 682 Martin Pilka 684 Email: martin@infobox.sk