idnits 2.17.1 draft-ietf-spring-conflict-resolution-02.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 (October 26, 2016) is 2738 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: A later version (-25) exists of draft-ietf-isis-segment-routing-extensions-08 == Outdated reference: A later version (-22) exists of draft-ietf-spring-segment-routing-mpls-05 == Outdated reference: A later version (-27) exists of draft-ietf-ospf-segment-routing-extensions-09 == Outdated reference: A later version (-23) exists of draft-ietf-ospf-ospfv3-segment-routing-extensions-06 == Outdated reference: A later version (-15) exists of draft-ietf-spring-segment-routing-09 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: April 29, 2017 Cisco Systems 6 M. Pilka 7 October 26, 2016 9 Segment Routing Conflict Resolution 10 draft-ietf-spring-conflict-resolution-02.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 April 29, 2017. 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. SID Preference . . . . . . . . . . . . . . . . . . . . . 6 67 3.2. Conflict Types . . . . . . . . . . . . . . . . . . . . . 6 68 3.2.1. Prefix Conflict . . . . . . . . . . . . . . . . . . . 6 69 3.2.2. SID Conflict . . . . . . . . . . . . . . . . . . . . 8 70 3.3. Processing conflicting entries . . . . . . . . . . . . . 9 71 3.3.1. Policy: Ignore conflicting entries . . . . . . . . . 9 72 3.3.2. Policy: Preference Algorithm/Quarantine . . . . . . . 10 73 3.3.3. Policy: Preference algorithm/ignore overlap only . . 10 74 3.3.4. Preference Algorithm . . . . . . . . . . . . . . . . 10 75 3.3.5. Example Behavior - Single Topology/Algorithm . . . . 11 76 3.3.6. Example Behavior - Multiple Topologies . . . . . . . 12 77 3.3.7. Evaluation of Policy Alternatives . . . . . . . . . . 13 78 3.3.8. Guaranteeing Database Consistency . . . . . . . . . . 14 79 4. Scope of SR-MPLS SID Conflicts . . . . . . . . . . . . . . . 14 80 5. Security Considerations . . . . . . . . . . . . . . . . . . . 15 81 6. IANA Consideration . . . . . . . . . . . . . . . . . . . . . 15 82 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 15 83 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 84 8.1. Normative References . . . . . . . . . . . . . . . . . . 15 85 8.2. Informational References . . . . . . . . . . . . . . . . 16 86 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 88 1. Introduction 90 Segment Routing (SR) as defined in [SR-ARCH] utilizes forwarding 91 instructions called "segments" to direct packets through the network. 92 Depending on the forwarding plane architecture in use, routing 93 protocols advertise various identifiers which define the permissible 94 values which can be used as segments, which values are assigned to 95 specific prefixes, etc. Where segments have global scope it is 96 necessary to have non-conflicting assignments - but given that the 97 advertisements may originate from multiple nodes the possibility 98 exists that advertisements may be received which are either 99 internally inconsistent or conflicting with advertisements originated 100 by other nodes. In such cases it is necessary to have consistent 101 resolution of conflicts network-wide in order to avoid forwarding 102 loops. 104 The problem to be addressed is protocol independent i.e., segment 105 related advertisements may be originated by multiple nodes using 106 different protocols and yet the conflict resolution MUST be the same 107 on all nodes regardless of the protocol used to transport the 108 advertisements. 110 The remainder of this document defines conflict resolution policies 111 which meet these requirements. All protocols which support SR MUST 112 adhere to the policies defined in this document. 114 2. SR Global Block Inconsistency 116 In support of an MPLS dataplane routing protocols advertise an SR 117 Global Block (SRGB) which defines a set of label ranges reserved for 118 use by the advertising node in support of SR. The details of how 119 protocols advertise this information can be found in the protocol 120 specific drafts e.g., [SR-OSPF], [SR-OSPFv3], and [SR-IS-IS]. 121 However the protocol independent semantics are illustrated by the 122 following example: 124 The originating router advertises the following ranges: 126 Range 1: (100, 199) 127 Range 2: (1000, 1099) 128 Range 3: (500, 599) 130 The receiving routers concatenate the ranges and build the Segment 131 Routing Global Block (SRGB) as follows: 133 SRGB = (100, 199) 134 (1000, 1099) 135 (500, 599) 137 The indeces span multiple ranges: 139 index=0 means label 100 140 ... 141 index 99 means label 199 142 index 100 means label 1000 143 index 199 means label 1099 144 ... 145 index 200 means label 500 146 ... 148 Note that the ranges are an ordered set - what labels are mapped to a 149 given index depends on the placement of a given label range in the 150 set of ranges advertised. 152 For the set of ranges to be usable the ranges MUST be disjoint. 153 Sender behavior is defined in various SR protocol drafts such as [SR- 154 IS-IS] which specify that senders MUST NOT advertise overlapping 155 ranges. 157 Receivers of SRGB ranges MUST validate the SRGB ranges advertised by 158 other nodes. If the advertised ranges do not conform to the 159 restrictions defined in the respective protocol specification 160 receivers MUST ignore all advertised SRGB ranges from that node. 161 Operationally the node is treated as though it did not advertise any 162 SRGB ranges. [SR-MPLS] defines the procedures for mapping global 163 SIDs to outgoing labels. 165 Note that utilization of local SIDs (e.g. adjacency SIDs) advertised 166 by a node is not affected by the state of the advertised SRGB. 168 3. SR-MPLS Segment Identifier Conflicts 170 In support of an MPLS dataplane Segment identifiers (SIDs) are 171 advertised and associated with a given prefix. SIDs may be 172 advertised in the prefix reachability advertisements originated by a 173 routing protocol (PFX) . SIDs may also be advertised by a Segment 174 Routing Mapping Server (SRMS). 176 Information in a SID advertisement is used to construct a mapping 177 entry. A generalized mapping entry can be represented using the 178 following definitions: 180 Prf - Preference Value (See Section 3.1) 181 Pi - Initial prefix 182 Pe - End prefix 183 L - Prefix length 184 Lx - Maximum prefix length (32 for IPv4, 128 for IPv6) 185 Si - Initial SID value 186 Se - End SID value 187 R - Range value (See Note 1) 188 T - Topology 189 A - Algorithm 191 A Mapping Entry is then the tuple: (Prf, Src, Pi/L, Si, R, T, A) 192 Pe = (Pi + ((R-1) << (Lx-L)) 193 Se = Si + (R-1) 195 NOTE 1: The SID advertised in a prefix reachability advertisement 196 always has an implicit range of 1. 198 Conflicts in SID advertisements may occur as a result of 199 misconfiguration. Conflicts may occur either in the set of 200 advertisements originated by a single node or between advertisements 201 originated by different nodes. Conflicts which occur within the set 202 of advertisements (P-SID and SRMS) originated by a single node SHOULD 203 be prevented by configuration validation on the originating node. 205 When conflicts occur, it is not possible for routers to know which of 206 the conflicting advertisements is "correct". In order to avoid 207 forwarding loops and/or blackholes, there is a need for all nodes to 208 resolve the conflicts in a consistent manner. This in turn requires 209 that all routers have identical sets of advertisements and that they 210 all use the same selection algorithm. This document defines 211 procedures to achieve these goals. 213 3.1. SID Preference 215 If a node acts as an SRMS, it MAY advertise a preference to be 216 associated with all SRMS SID advertisements sent by that node. The 217 means of advertising the preference is defined in the protocol 218 specific drafts e.g., [SR-OSPF], [SR-OSPFv3], and [SR-IS-IS]. The 219 preference value is an unsigned 8 bit integer with the following 220 properties: 222 0 - Reserved value indicating advertisements from that node 223 MUST NOT be used. 224 1 - 255 Preference value 226 Advertisement of a preference value is optional. Nodes which do not 227 advertise a preference value are assigned a preference value of 128. 229 All SIDs advertised in prefix reachability advertisements implicitly 230 have a preference value of 192. 232 3.2. Conflict Types 234 Two types of conflicts may occur - Prefix Conflicts and SID 235 Conflicts. Examples are provided in this section to illustrate these 236 conflict types. 238 3.2.1. Prefix Conflict 240 When different SIDs are assigned to the same prefix we have a "prefix 241 conflict". Prefix conflicts are specific to mapping entries sharing 242 the same topology and algorithm. 244 Example PC1 246 (192, 192.0.2.120/32, 200, 1, 0, 0) 247 (192, 192.0.2.120/32, 30, 1, 0, 0) 249 The prefix 192.0.2.120/32 has been assigned two different SIDs: 250 200 by the first advertisement 251 30 by the second advertisement 253 Example PC2 255 (192, 2001:DB8::1/128, 400, 1, 2, 0) 256 (192, 2001:DB8::1/128, 50, 1, 2, 0) 258 The prefix 2001:DB8::1/128 has been assigned two different SIDs: 259 400 by the first advertisement 260 50 by the second advertisement 262 Prefix conflicts may also occur as a result of overlapping prefix 263 ranges. 265 Example PC3 267 (128, 192.0.2.1/32, 200, 200, 0, 0) 268 (128, 192.0.2.121/32, 30, 10, 0, 0) 270 Prefixes 192.0.2.121/32 - 192.0.2.130/32 are assigned two 271 different SIDs: 272 320 through 329 by the first advertisement 273 30 through 39 by the second advertisement 275 Example PC4 276 (128, 2001:DB8::1/128, 400, 200, 2, 0) 277 (128, 2001:DB8::121/128, 50, 10, 2, 0) 279 Prefixes 2001:DB8::121/128 - 2001:DB8::130/128 are assigned 280 two different SIDs: 281 420 through 429 by the first advertisement 282 50 through 59 by the second advertisement 284 Examples PC3 and PC4 illustrate a complication - only part of the 285 range advertised in the first advertisement is in conflict. It is 286 logically possible to isolate the conflicting portion and try to use 287 the non-conflicting portion(s). 289 A variant of the overlapping prefix range is a case where we have 290 overlapping prefix ranges but no actual SID conflict. 292 Example PC5 294 (128, 192.0.2.1/32, 200, 200, 0, 0) 295 (128, 192.0.2.121/32, 320, 10, 0, 0) 297 (128, 2001:DB8::1/128, 400, 200, 2, 0) 298 (128, 2001:DB8::121/128, 520, 10, 2, 0) 300 Although there is prefix overlap between the two IPv4 entries (and 301 the two IPv6 entries) the same SID is assigned to all of the shared 302 prefixes by the two entries. 304 Given two mapping entries: 306 (Prf, P1/L1, S1, R1, T1, A1) and 307 (Prf, P2/L2, S2, R2, T2, A2) 309 where P1 <= P2 311 a prefix conflict exists if all of the following are true: 313 1)(T1 == T2) && (A1 == A2) 314 2)P1 <= P2 315 3)The prefixes are in the same address family. 316 2)L1 == L2 317 3)(P1e >= P2) && ((S1 + (P2 - P1)) != S2) 319 3.2.2. SID Conflict 321 When the same SID has been assigned to multiple prefixes we have a 322 "SID conflict". SID conflicts are independent of address-family, 323 independent of prefix len, independent of topology, and independent 324 of algorithm. A SID conflict occurs when a mapping entry which has 325 previously been checked to have no prefix conflict assigns one or 326 more SIDs that are assigned by another entry which also has no prefix 327 conflicts. 329 Example SC1 331 (192, 192.0.2.1/32, 200, 1, 0, 0) 332 (192, 192.0.2.222/32, 200, 1, 0, 0) 333 SID 200 has been assigned to 192.0.2.1/32 by the 334 first advertisement. 335 The second advertisement assigns SID 200 to 192.0.2.222/32. 337 Example SC2 339 (192, 2001:DB8::1/128, 400, 1, 2, 0) 340 (192, 2001:DB8::222/128, 400, 1, 2, 0) 341 SID 400 has been assigned to 2001:DB8::1/128 by the 342 first advertisement. 343 The second advertisement assigns SID 400 to 2001:DB8::222/128 345 SID conflicts may also occur as a result of overlapping SID ranges. 347 Example SC3 349 (128, 192.0.2.1/32, 200, 200, 0, 0) 350 (128, 198.51.100.1/32, 300, 10, 0, 0) 352 SIDs 300 - 309 have been assigned to two different prefixes. 353 The first advertisement assigns these SIDs 354 to 192.0.2.101/32 - 192.0.2.110/32. 355 The second advertisement assigns these SIDs to 356 198.51.100.1/32 - 198.51.100.10/32. 358 Example SC4 359 (128, 2001:DB8::1/128, 400, 200, 2, 0) 360 (128, 2001:DB8:1::1/128, 500, 10, 2, 0) 362 SIDs 500 - 509 have been assigned to two different prefixes. 363 The first advertisement assigns these SIDs to 364 2001:DB8::101/128 - 2001:DB8::10A/128. 365 The second advertisement assigns these SIDs to 366 2001:DB8:1::1/128 - 2001:DB8:1::A/128. 368 Examples SC3 and SC4 illustrate a complication - only part of the 369 range advertised in the first advertisement is in conflict. 371 3.3. Processing conflicting entries 373 Two general approaches can be used to process conflicting entries. 375 1. Conflicting entries can be ignored 377 2. A standard preference algorithm can be used to choose which of 378 the conflicting entries will be used 380 The following sections discuss these two approaches in more detail. 382 Note: This document does not discuss any implementation details i.e. 383 what type of data structure is used to store the entries (trie, radix 384 tree, etc.) nor what type of keys may be used to perform lookups in 385 the database. 387 3.3.1. Policy: Ignore conflicting entries 389 In cases where entries are in conflict none of the conflicting 390 entries are used i.e., the network operates as if the conflicting 391 advertisements were not present. 393 Implementations are required to identify the conflicting entries and 394 ensure that they are not used. 396 3.3.2. Policy: Preference Algorithm/Quarantine 398 For entries which are in conflict properties of the conflicting 399 advertisements are used to determine which of the conflicting entries 400 are used in forwarding and which are "quarantined" and not used. The 401 entire quarantined entry is not used. 403 This approach requires that conflicting entries first be identified 404 and then evaluated based on a preference rule. Based on which entry 405 is preferred this in turn may impact what other entries are 406 considered in conflict i.e. if A conflicts with B and B conflicts 407 with C - it is possible that A does NOT conflict with C. Hence if as 408 a result of the evaluation of the conflict between A and B, entry B 409 is not used the conflict between B and C will not be detected. 411 3.3.3. Policy: Preference algorithm/ignore overlap only 413 A variation of the preference algorithm approach is to quarantine 414 only the portions of the less preferred entry which actually 415 conflicts. The original entry is split into multiple ranges. The 416 ranges which are in conflict are quarantined. The ranges which are 417 not in conflict are used in forwarding. This approach adds 418 complexity as the relationship between the derived sub-ranges of the 419 original mapping entry have to be associated with the original entry 420 - and every time some change to the advertisement database occurs the 421 derived sub-ranges have to be recalculated. 423 3.3.4. Preference Algorithm 425 The following algorithm is used to select the preferred mapping entry 426 when a conflict exists. Evaluation is made in the order specified. 427 Prefix conflicts are evaluated first. SID conflicts are then 428 evaluated on the Active entries remaining after Prefix Conflicts have 429 been resolved. 431 1. Higher preference value wins 433 2. Smaller range wins 435 3. IPv6 entry wins over IPv4 entry 437 4. Longer prefix length wins 439 5. Smaller algorithm wins 440 6. Smaller starting address (considered as an unsigned integer 441 value) wins 443 7. Smaller starting SID wins 445 8. If topology IDs are NOT identical both entries MUST be ignored 447 As SIDs associated with prefix reachability advertisements have a 448 preference of 192 while by default SRMS preference is 128, the 449 default behavior is then to prefer SIDs advertised in prefix 450 reachability advertisements over SIDs advertised by SRMSs, but an 451 operator can choose to override this behavior by setting SRMS 452 preference higher than 192. 454 Preferring advertisements with smaller range has the nice property 455 that a single misconfiguration of an SRMS entry with a large range 456 will not be preferred over a large number of advertisements with 457 smaller ranges. 459 Since topology identifiers are locally scoped, it is not possible to 460 make a consistent choice network wide when all elements of a mapping 461 entry are identical except for the topology. This is why both 462 entries MUST be ignored in such cases (Rule #8 above). Note that 463 Rule #8 only applies when considering SID conflicts since Prefix 464 conflicts are restricted to a single topology. 466 3.3.5. Example Behavior - Single Topology/Algorithm 468 The following mapping entries exist:in the database. For brevity, 469 Topology/Algorithm is omitted and assumed to be (0,0) in all entries. 471 1. (192, 192.0.2.1/32, 100, 1) 473 2. (192, 192.0.2.101/32, 200, 1) 475 3. (128, 192.0.2.1/32, 400, 255) !Prefix conflict with entries 1 and 476 2 478 4. (128, 198.51.100.40/32, 200,1) !SID conflict with entry 2 480 The table below shows what mapping entries will be used in the 481 forwarding plane (Active) and which ones will not be used (Excluded) 482 under the three candidate policies: 484 +--------------------------------------------------------------------+ 485 |Policy | Active Entries | Excluded Entries | 486 +--------------------------------------------------------------------+ 487 |Ignore | |(192,192.0.2.1/32,100,1) | 488 | | |(192,192.0.2.101/32,200,1) | 489 | | |(128,192.0.2.1/32,400,255) | 490 | | |(128,198.51.100.40/32,200,1) | 491 +--------------------------------------------------------------------+ 492 |Quarantine|(192,192.0.1.1/32,100,1) |(128,192.0.2.1/32,400,255) | 493 | |(192,192.0.2.101/32,200,1) |(128,198.51.100.40/32,200,1) | 494 +--------------------------------------------------------------------+ 495 |Overlap- |(192,192.0.2.1/32,100,1) |(128,198.51.100.40/32,200,1) | 496 | Only |(192,192.0.2.101/32,200,1) |*(128,192.0.2.1/32,400,1) | 497 | |*(128,192.0.2.2/32,401,99) |*(128,192.0.2.101/32,500,1) | 498 | |*(128,192.0.2.102/32, | 499 | | 501,153) | | 500 +--------------------------------------------------------------------+ 502 * Derived from (128,192.0.2.1/32,400,300) 504 3.3.6. Example Behavior - Multiple Topologies 506 When using a preference rule the order in which conflict resolution 507 is applied has an impact on what entries are usable when entries for 508 multiple topologies (or algorithms) are present. The following 509 mapping entries exist in the database: 511 1. (192, 192.0.2.1/32, 100, 1, 0, 0) !Topology 0 513 2. (192, 192.0.2.1/32, 200, 1, 0, 0) !Topology 0, Prefix Conflict 514 with entry #1 516 3. (192, 198.51.100.40/32, 200,1,1,0) ! Topology 1, SID conflict 517 with entry 2 519 The table below shows what mapping entries will be used in the 520 forwarding plane (Active) and which ones will not be used (Excluded) 521 under the Quarantine Policy based on the order in which conflict 522 resolution is applied. 524 +------------------------------------------------------------------+ 525 |Order | Active Entries | Excluded Entries | 526 +------------------------------------------------------------------+ 527 |Prefix- |(192,192.0.2.1/32,100,1,0,0)|(192,192.0.2.101/32,200,1,0)| 528 |Conflict|(192,198.51.100.40/32,200,1,| | 529 |First | 1,0) | | 530 +------------------------------------------------------------------+ 531 |SID- |(192,192.0.2.1/32,100,1,0,0)|(192,192.0.2.101/32,200,1,0)| 532 |Conflict| |(192,198.51.100.40/32,200,1,| 533 |First | | 1,0) | 534 +------------------------------------------------------------------+ 536 This illustrates the advantage of evaluating prefix conflicts within 537 a given topology (or algorithm) before evaluating topology (or 538 algorithm) independent SID conflicts. It insures that entries which 539 will be excluded based on intratopology preference will not prevent a 540 SID assigned in another topology from being considered Active. 542 3.3.7. Evaluation of Policy Alternatives 544 The previous sections have defined three alternatives for resolving 545 conflicts - ignore, quarantine, and ignore overlap-only. 547 The ignore policy impacts the greatest amount of traffic as 548 forwarding to all destinations which have a conflict is affected. 550 Quarantine allows forwarding for some destinations which have a 551 conflict to be supported. 553 Ignore overlap-only maximizes the destinations which will be 554 forwarded as all destinations covered by some mapping entry 555 (regardless of range) will be able to use the SID assigned by the 556 winning range. This alternative increases implementation complexity 557 as compared to quarantine. Mapping entries with a range greater than 558 1 which are in conflict with other mapping entries have to internally 559 be split into 2 or more "derived mapping entries". The derived 560 mapping entries then fall into two categories - those that are in 561 conflict with other mapping entries and those which are NOT in 562 conflict. The former are ignored and the latter are used. Each time 563 the underived mapping database is updated the derived entries have to 564 be recomputed based on the updated database. Internal data 565 structures have to be maintained which maintain the relationship 566 between the advertised mapping entry and the set of derived mapping 567 entries. All nodes in the network have to achieve the same behavior 568 regardless of implementation internals. 570 There is then a tradeoff between a goal of maximizing traffic 571 delivery and the risks associated with increased implementation 572 complexity. 574 Consensus of the working group is that maximizing traffic delivery is 575 the most important deployment consideration - therefore ignore- 576 overlap-only is specified as the standard policy which MUST be 577 implemented by all nodes which support SR-MPLS. 579 3.3.8. Guaranteeing Database Consistency 581 In order to obtain consistent active entries all nodes in a network 582 MUST have the same mapping entry database. Mapping entries can be 583 obtained from a variety of sources. 585 o SIDs can be configured locally for prefixes assigned to interfaces 586 on the router itself. Only SIDs which are advertised to protocol 587 peers can be considered as part of the mapping entry database. 589 o SIDs can be received in prefix reachability advertisements from 590 protocol peers. These advertisements may originate from peers 591 local to the area or be leaked from other areas and/or 592 redistributed from other routing protocols. 594 o SIDs can be received from SRMS advertisements - these 595 advertisements can originate from routers local to the area or 596 leaked from other areas 598 o In cases where multiple routing protocols are in use mapping 599 entries advertised by all routing protocols MUST be included. 601 4. Scope of SR-MPLS SID Conflicts 603 The previous section defines the types of SID conflicts and 604 procedures to resolve such conflicts when using an MPLS dataplane. 605 The mapping entry database used MUST be populated with entries for 606 destinations for which the associated SID will be used to derive the 607 labels installed in the forwarding plane of routers in the network. 608 This consists of entries associated with intra-domain routes. 610 There are cases where destinations which are external to the domain 611 are advertised by protocol speakers running within that network - and 612 it is possible that those advertisements have SIDs associated with 613 those destinations. However, if reachability to a destination is 614 topologically outside the forwarding domain of the protocol instance 615 then the SIDs for such destinations will never be installed in the 616 forwarding plane of any router within the domain - so such 617 advertisements cannot create a SID conflict within the domain. Such 618 entries therefore MUST NOT be installed in the database used for 619 intra-domain conflict resolution. 621 Consider the case of two sites "A and B" associated with a given 622 [RFC4364] VPN. Connectivity between the sites is via a provider 623 backbone. SIDs associated with destinations in Site A will never be 624 installed in the forwarding plane of routers in Site B. Reachability 625 between the sites (assuming SR is being used across the backbone) 626 only requires using a SID associated with a gateway PE. So a 627 destination in Site A MAY use the same SID as a destination in Site B 628 without introducing any conflict in the forwarding plane of routers 629 in Site A. 631 Such cases are handled by insuring that the mapping entries in the 632 database used by the procedures defined in the previous section only 633 include entries associated with advertisements within the site. 635 5. Security Considerations 637 The ability to introduce SID conflicts into a deployment may 638 compromise traffic forwarding. Protocol specific security mechanisms 639 SHOULD be used to insure that all SID advertisements originate from 640 trusted sources. 642 6. IANA Consideration 644 This document has no actions for IANA. 646 7. Acknowledgements 648 The authors would like to thank Jeff Tantsura, Wim Henderickx, and 649 Bruno Decraene for their careful review and content suggestions. 651 8. References 653 8.1. Normative References 655 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 656 Requirement Levels", BCP 14, RFC 2119, 657 DOI 10.17487/RFC2119, March 1997, 658 . 660 [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private 661 Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February 662 2006, . 664 [SR-IS-IS] 665 "IS-IS Extensions for Segment Routing, draft-ietf-isis- 666 segment-routing-extensions-08(work in progress)", October 667 2016. 669 [SR-MPLS] "Segment Routing with MPLS dataplane, draft-ietf-spring- 670 segment-routing-mpls-05(work in progress)", July 2016. 672 [SR-OSPF] "OSPF Extensions for Segment Routing, draft-ietf-ospf- 673 segment-routing-extensions-09(work in progress)", July 674 2016. 676 [SR-OSPFv3] 677 "OSPFv3 Extensions for Segment Routing, draft-ietf-ospf- 678 ospfv3-segment-routing-extensions-06(work in progress)", 679 July 2016. 681 8.2. Informational References 683 [SR-ARCH] "Segment Routing Architecture, draft-ietf-spring-segment- 684 routing-09(work in progress)", July 2016. 686 Authors' Addresses 688 Les Ginsberg 689 Cisco Systems 690 821 Alder Drive 691 Milpitas, CA 95035 692 USA 694 Email: ginsberg@cisco.com 696 Peter Psenak 697 Cisco Systems 698 Apollo Business Center Mlynske nivy 43 699 Bratislava 821 09 700 Slovakia 702 Email: ppsenak@cisco.com 703 Stefano Previdi 704 Cisco Systems 705 Via Del Serafico 200 706 Rome 0144 707 Italy 709 Email: sprevidi@cisco.com 711 Martin Pilka 713 Email: martin@infobox.sk