idnits 2.17.1 draft-ietf-bess-evpn-pref-df-05.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 seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (December 17, 2019) is 1589 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: 'Pref' is mentioned on line 488, but not defined == Missing Reference: 'DP' is mentioned on line 488, but not defined == Missing Reference: 'Alg' is mentioned on line 307, but not defined -- Looks like a reference, but probably isn't: '500' on line 400 -- Looks like a reference, but probably isn't: '0' on line 512 -- Looks like a reference, but probably isn't: '255' on line 308 -- Looks like a reference, but probably isn't: '100' on line 478 -- Looks like a reference, but probably isn't: '200' on line 512 -- Looks like a reference, but probably isn't: '300' on line 309 -- Looks like a reference, but probably isn't: '1' on line 479 == Missing Reference: 'Preference' is mentioned on line 400, but not defined == Missing Reference: 'PE2-IP' is mentioned on line 479, but not defined == Missing Reference: 'PE1-IP' is mentioned on line 478, but not defined == Missing Reference: 'PE3-IP' is mentioned on line 512, but not defined == Outdated reference: A later version (-15) exists of draft-ietf-bess-evpn-virtual-eth-segment-04 Summary: 0 errors (**), 0 flaws (~~), 10 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 BESS Workgroup J. Rabadan, Ed. 3 Internet-Draft S. Sathappan 4 Intended status: Standards Track Nokia 5 Expires: June 19, 2020 T. Przygienda 6 W. Lin 7 J. Drake 8 Juniper Networks 9 A. Sajassi 10 S. Mohanty 11 Cisco Systems 12 December 17, 2019 14 Preference-based EVPN DF Election 15 draft-ietf-bess-evpn-pref-df-05 17 Abstract 19 The Designated Forwarder (DF) in Ethernet Virtual Private Networks 20 (EVPN) is defined as the PE responsible for sending Broadcast, 21 Unknown unicast and Broadcast traffic (BUM) to a multi-homed device/ 22 network in the case of an all-active multi-homing Ethernet Segment 23 (ES), or BUM and unicast in the case of single-active multi-homing. 25 The DF is selected out of a candidate list of PEs that advertise the 26 same Ethernet Segment Identifier (ESI) to the EVPN network, according 27 to the Default DF Election algorithm. 29 While the Default Algorithm provides an efficient and automated way 30 of selecting the DF across different Ethernet Tags in the ES, there 31 are some use-cases where a more 'deterministic' and user-controlled 32 method is required. At the same time, Service Providers require an 33 easy way to force an on-demand DF switchover in order to carry out 34 some maintenance tasks on the existing DF or control whether a new 35 active PE can preempt the existing DF PE. 37 This document proposes an extension to the Default DF election 38 procedures so that the above requirements can be met. 40 Status of This Memo 42 This Internet-Draft is submitted in full conformance with the 43 provisions of BCP 78 and BCP 79. 45 Internet-Drafts are working documents of the Internet Engineering 46 Task Force (IETF). Note that other groups may also distribute 47 working documents as Internet-Drafts. The list of current Internet- 48 Drafts is at https://datatracker.ietf.org/drafts/current/. 50 Internet-Drafts are draft documents valid for a maximum of six months 51 and may be updated, replaced, or obsoleted by other documents at any 52 time. It is inappropriate to use Internet-Drafts as reference 53 material or to cite them other than as "work in progress." 55 This Internet-Draft will expire on June 19, 2020. 57 Copyright Notice 59 Copyright (c) 2019 IETF Trust and the persons identified as the 60 document authors. All rights reserved. 62 This document is subject to BCP 78 and the IETF Trust's Legal 63 Provisions Relating to IETF Documents 64 (https://trustee.ietf.org/license-info) in effect on the date of 65 publication of this document. Please review these documents 66 carefully, as they describe your rights and restrictions with respect 67 to this document. Code Components extracted from this document must 68 include Simplified BSD License text as described in Section 4.e of 69 the Trust Legal Provisions and are provided without warranty as 70 described in the Simplified BSD License. 72 Table of Contents 74 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 75 1.1. Problem Statement . . . . . . . . . . . . . . . . . . . . 3 76 1.2. Solution requirements . . . . . . . . . . . . . . . . . . 3 77 2. Conventions and Terminology . . . . . . . . . . . . . . . . . 4 78 3. EVPN BGP Attributes Extensions . . . . . . . . . . . . . . . 5 79 4. Solution description . . . . . . . . . . . . . . . . . . . . 6 80 4.1. Use of the Preference algorithm . . . . . . . . . . . . . 7 81 4.2. Use of the Preference algorithm in [RFC7432] Ethernet 82 Segments . . . . . . . . . . . . . . . . . . . . . . . . 9 83 4.3. The Non-Revertive Capability . . . . . . . . . . . . . . 10 84 5. Security Considerations . . . . . . . . . . . . . . . . . . . 12 85 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 86 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13 87 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 13 88 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 89 9.1. Normative References . . . . . . . . . . . . . . . . . . 13 90 9.2. Informative References . . . . . . . . . . . . . . . . . 14 91 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 93 1. Introduction 94 1.1. Problem Statement 96 [RFC7432] defines the Designated Forwarder (DF) in (PBB-)EVPN 97 networks as the PE responsible for sending broadcast, multicast and 98 unknown unicast traffic (BUM) to a multi-homed device/network in the 99 case of an all-active multi-homing ES or BUM and unicast traffic to a 100 multi-homed device or network in case of single-active multi-homing. 102 The DF is selected out of a candidate list of PEs that advertise the 103 Ethernet Segment Identifier (ESI) to the EVPN network and according 104 to the DF Election Algorithm, or DF Alg as per [RFC8584]. 106 While the Default DF Alg [RFC7432] or HRW [RFC8584] provide an 107 efficient and automated way of selecting the DF across different 108 Ethernet Tags in the ES, there are some use-cases where a more 109 'deterministic' and user-controlled method is required. At the same 110 time, Service Providers require an easy way to force an on-demand DF 111 switchover in order to carry out some maintenance tasks on the 112 existing DF or control whether a new active PE can preempt the 113 existing DF PE. 115 This document proposes a new DF Alg and capability to address the 116 above needs. 118 1.2. Solution requirements 120 The procedures described in this document meet the following 121 requirements: 123 a. The solution provides an administrative preference option so that 124 the user can control in what order the candidate PEs may become 125 DF, assuming they are all operationally ready to take over as DF. 127 b. This extension works for [RFC7432] Ethernet Segments and virtual 128 ES, as defined in [I-D.ietf-bess-evpn-virtual-eth-segment]. 130 c. The user may force a PE to preempt the existing DF for a given 131 Ethernet Tag without re-configuring all the PEs in the ES. 133 d. The solution allows an option to NOT preempt the current DF, even 134 if the former DF PE comes back up after a failure. This is also 135 known as "non-revertive" behavior, as opposed to the [RFC7432] DF 136 election procedures that are always revertive. 138 e. The solution works for single-active and all-active multi-homing 139 Ethernet Segments. 141 2. Conventions and Terminology 143 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 144 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 145 "OPTIONAL" in this document are to be interpreted as described in 146 BCP14 [RFC2119] [RFC8174] when, and only when, they appear in all 147 capitals, as shown here. 149 o AC - Attachment Circuit. An AC has an Ethernet Tag associated to 150 it. 152 o BUM - refers to the Broadcast, Unknown unicast and Multicast 153 traffic. 155 o DF, NDF and BDF - Designated Forwarder, Non-Designated Forwarder 156 and Backup Designated Forwarder. 158 o DF Alg - refers to Designated Forwarder Election Algorithm. 160 o HRW - Highest Random Weight, as per [RFC8584]. 162 o ES, vES and ESI - Ethernet Segment, virtual Ethernet Segment and 163 Ethernet Segment Identifier. 165 o EVI - EVPN Instance. 167 o ISID - refers to Service Instance Identifiers in Provider Backbone 168 Bridging (PBB) networks. 170 o MAC-VRF - A Virtual Routing and Forwarding table for Media Access 171 Control (MAC) addresses on a PE. 173 o BD - Broadcast Domain. An EVI may be comprised of one (VLAN-Based 174 or VLAN Bundle services) or multiple (VLAN-Aware Bundle services) 175 Broadcast Domains. 177 o EVC - Ethernet Virtual Circuit. 179 o DP - refers to the "Don't Preempt me" capability in the DF 180 Election extended community. 182 o OAM - refers to Operations And Maintenance protocols. 184 o Ethernet A-D per ES route - refers to [RFC7432] route type 1 or 185 Auto-Discovery per Ethernet Segment route. 187 o Ethernet A-D per EVI route - refers to [RFC7432] route type 1 or 188 Auto-Discovery per EVPN Instance route. 190 o Ethernet Tag - used to represent a Broadcast Domain that is 191 configured on a given ES for the purpose of DF election. Note 192 that any of the following may be used to represent a Broadcast 193 Domain: VIDs (including Q-in-Q tags), configured IDs, VNI (VXLAN 194 Network Identifiers), normalized VID, I-SIDs (Service Instance 195 Identifiers), etc., as long as the representation of the broadcast 196 domains is configured consistently across the multi-homed PEs 197 attached to that ES. The Ethernet Tag value MUST be different 198 from zero. 200 3. EVPN BGP Attributes Extensions 202 This solution reuses and extends the DF Election Extended Community 203 defined in [RFC8584] that is advertised along with the ES route: 205 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 206 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 207 | Type=0x06 | Sub-Type(0x06)| RSV | DF Alg | Bitmap ~ 208 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 209 ~ Bitmap | Reserved | DF Preference (2 octets) | 210 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 212 Figure 1: DF Election Extended Community 214 Where the following fields are defined as follows: 216 o DF Alg can have the following values: 218 - Alg 0 - Default DF Election algorithm, or modulus-based 219 algorithm as per [RFC7432]. 221 - Alg 1 - HRW algorithm as per [RFC8584]. 223 - Alg 2 - Preference algorithm (this document). 225 o Bitmap (2 octets) can have the following values: 227 1 1 1 1 1 1 228 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 229 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 230 |D|A| | 231 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 233 Figure 2: Bitmap field in the DF Election Extended Community 235 - Bit 0 (corresponds to Bit 24 of the DF Election Extended 236 Community and it is defined by this document): D bit or 'Don't 237 Preempt' bit (DP hereafter), determines if the PE advertising 238 the ES route requests the remote PEs in the ES not to preempt 239 it as DF. The default value is DP=0, which is compatible with 240 the 'preempt' or 'revertive' behavior in the Default DF Alg 241 [RFC7432]. The DP bit SHOULD be ignored if the DF Alg is 242 different than 2. 244 - Bit 1: AC-DF or AC-Influenced DF Election, as explained in 245 [RFC8584]. When set to 1, it indicates the desire to use AC- 246 Influenced DF Election with the rest of the PEs in the ES. The 247 AC-DF capability bit MAY be set along with the DP capability 248 and DF Alg 2. 250 o DF Preference (defined in this document): defines a 2-octet value 251 that indicates the PE preference to become the DF in the ES. The 252 allowed values are within the range 0-65535, and the default value 253 MUST be 32767. This value is the midpoint in the allowed 254 Preference range of values, which gives the operator the 255 flexibility of choosing a significant number of values, above or 256 below the default Preference. The DF Preference field is specific 257 to DF Alg 2 and does not represent any Preference value for other 258 Algs. 260 4. Solution description 262 Figure 3 illustrates an example that will be used in the description 263 of the solution. 265 EVPN network 266 +-------------------+ 267 | +-------+ ENNI Aggregation 268 | <---ESI1,500 | PE1 | /\ +----Network---+ 269 | <-----ESI2,100 | |===||=== | 270 | | |===||== \ vES1 | +----+ 271 +-----+ | | \/ |\----------------+CE1 | 272 CE3--+ PE4 | +-------+ | \ ------------+ | 273 +-----+ | | \ / | +----+ 274 | | | X | 275 | <---ESI1,255 +-----+============ \ | 276 | <-----ESI2,200 | PE2 |========== \ vES2 | +----+ 277 | +-----+ | \ ----------+CE2 | 278 | | | --------------| | 279 | +-----+ ----------------------+ | 280 | <-----ESI2,300 | PE3 +--/ | | +----+ 281 | +-----+ +--------------+ 282 --------------------+ 284 Figure 3: Preference-based DF Election 286 Figure 3 shows three PEs that are connecting EVCs coming from the 287 Aggregation Network to their EVIs in the EVPN network. CE1 is 288 connected to vES1 - that spans PE1 and PE2 - and CE2 is connected to 289 vES2, that is defined in PE1, PE2 and PE3. 291 If the algorithm chosen for vES1 and vES2 is Alg 2, i.e., Preference- 292 based, the PEs may become DF irrespective of their IP address and 293 based on an administrative Preference value. The following sections 294 provide some examples of the procedures and how they are applied in 295 the use-case of Figure 3. 297 4.1. Use of the Preference algorithm 299 Assuming the operator wants to control - in a flexible way - what PE 300 becomes the DF for a given vES and the order in which the PEs become 301 DF in case of multiple failures, the following procedure may be used: 303 a. vES1 and vES2 are now configurable with three optional parameters 304 that are signaled in the DF Election extended community. These 305 parameters are the Preference, Preemption option (or "Don't 306 Preempt Me" option) and DF Alg. We will represent these 307 parameters as [Pref,DP,Alg]. Let's assume vES1 is configured as 308 [500,0,Pref] in PE1, and [255,0,Pref] in PE2. vES2 is configured 309 as [100,0,Pref], [200,0,Pref] and [300,0,Pref] in PE1, PE2 and 310 PE3 respectively. 312 b. The PEs will advertise an ES route for each vES, including the 3 313 parameters in the DF Election Extended Community. 315 c. According to [RFC8584], each PE will run the DF election 316 algorithm upon expiration of the DF Wait timer. In this case, 317 each PE runs the Preference-based DF Alg for each ES as follows: 319 - The PE will check the DF Alg value in each ES route, and 320 assuming all the ES routes are consistent in this DF Alg and 321 the value is 2 (Preference-based), the PE will run the new 322 extended procedure. Otherwise, the procedure will fall back 323 to [RFC7432] Default Alg. 325 - In this Preference-based Alg, each PE builds a list of 326 candidate PEs, ordered by Preference. E.g. PE1 will build a 327 list of candidate PEs for vES1 ordered by the Preference, from 328 high to low: PE1>PE2. Hence PE1 will become the DF for vES1. 329 In the same way, PE3 becomes the DF for vES2. 331 d. Note that, by default, the Highest-Preference is chosen for each 332 ES or vES, however the ES configuration can be changed to the 333 Lowest-Preference algorithm as long as this option is consistent 334 in all the PEs in the ES. E.g. vES1 could have been explicitly 335 configured as Alg Preference-based with Lowest-Preference, in 336 which case, PE2 would have been the DF. 338 e. Assuming some maintenance tasks had to be executed on PE3, the 339 operator could set vES2's Preference to e.g., 50 so that PE2 is 340 forced to take over as DF for vES2 (irrespective of the DP 341 capability). Once the maintenance on PE3 is over, the operator 342 could decide to leave the existing preference or configure the 343 old preference back. 345 f. In case of equal Preference in two or more PEs in the ES, the 346 tie-breakers will be the DP bit and the lowest IP PE, in that 347 order. For instance: 349 - If vES1 parameters were [500,0,Pref] in PE1 and [500,1,Pref] 350 in PE2, PE2 would be elected due to the DP bit. 352 - If vES1 parameters were [500,0,Pref] in PE1 and [500,0,Pref] 353 in PE2, PE1 would be elected, assuming PE1's IP address is 354 lower than PE2's. 356 g. The Preference is an administrative option that MUST be 357 configured on a per-ES basis from the management plane, but MAY 358 also be dynamically changed based on the use of local policies. 359 For instance, on PE1, ES1's Preference can be lowered from 500 to 360 100 in case the bandwidth on the ENNI port is decreased a 50% 361 (that could happen if e.g. the 2-port LAG between PE1 and the 362 Aggregation Network loses one port). Policies MAY also trigger 363 dynamic Preference changes based on the PE's bandwidth 364 availability in the core, specific ports going operationally 365 down, etc. The definition of the actual local policies is out of 366 scope of this document. The default Preference value is 32767. 368 The Preference Alg MAY be used along with the AC-DF capability. 369 Assuming all the PEs in the ES are configured consistently with 370 Preference Alg and AC-DF capability, a given PE in the ES is not 371 considered as candidate for DF Election until its corresponding 372 Ethernet A-D per ES and Ethernet A-D per EVI routes are not received, 373 as described in [RFC8584]. 375 The procedures in this document can be used in [RFC7432] based ES or 376 vES as in [I-D.ietf-bess-evpn-virtual-eth-segment], and including 377 EVPN networks as in [RFC8214], [RFC7623] or [RFC8365]. 379 4.2. Use of the Preference algorithm in [RFC7432] Ethernet Segments 381 While the Preference-based DF Alg described in Section 4.1 is 382 typically used in virtual ES scenarios where there is normally an 383 individual Ethernet Tag per vES, the existing [RFC7432] definition of 384 ES allows potentially up to thousands of Ethernet Tags on the same 385 ES. If this is the case, and the operator still wants to control who 386 the DF is for a given Ethernet Tag, the use of the Preference-based 387 DF Alg can also provide some level of load balancing. 389 In this type of scenarios, the ES is configured with an 390 administrative Preference value, but then a range of Ethernet Tags 391 can be defined to use the Highest-Preference or the Lowest-Preference 392 depending on the desired behavior. With this option, the PE will 393 build a list of candidate PEs ordered by Preference, however the DF 394 for a given Ethernet Tag will be determined by the local 395 configuration. 397 For instance: 399 o Assuming ES3 is defined in PE1 and PE2, PE1 may be configured as 400 [500,0,Preference] for ES3 and PE2 as [100,0,Preference]. 402 o In addition, assuming VLAN-based service interfaces, the PEs will 403 be configured with (Ethernet Tag-range,high_or_low), E.g., 404 (1-2000,high) and (2001-4000, low). 406 o This will result in PE1 being DF for Ethernet Tags 1-2000 and PE2 407 being DF for Ethernet Tags 2001-4000. 409 For Ethernet Segments attached to three or more PEs, any other logic 410 that provides a fair distribution of the DF function among the PEs is 411 valid, as long as that logic is consistent in all the PEs in the ES. 413 4.3. The Non-Revertive Capability 415 As discussed in Section 1.2 (d), a capability to NOT preempt the 416 existing DF for a given Ethernet Tag is required and therefore added 417 to the DF Election extended community. This option will allow a non- 418 revertive behavior in the DF election. 420 Note that, when a given PE in an ES is taken down for maintenance 421 operations, before bringing it back, the Preference may be changed in 422 order to provide a non-revertive behavior. The DP bit and the 423 mechanism explained in this section will be used for those cases when 424 a former DF comes back up without any controlled maintenance 425 operation, and the non-revertive option is desired in order to avoid 426 service impact. 428 In Figure 3, we assume that based on the Highest-Pref, PE3 is the DF 429 for ESI2. 431 If PE3 has a link, EVC or node failure, PE2 would take over as DF. 432 If/when PE3 comes back up again, PE3 will take over, causing some 433 unnecessary packet loss in the ES. 435 The following procedure avoids preemption upon failure recovery 436 (please refer to Figure 1): 438 1. A new "Don't Preempt Me" capability is defined on a per-PE per-ES 439 basis, as described in Section 3. If "Don't Preempt Me" is 440 disabled (default behavior), the advertised DP bit will be 0. If 441 "Don't Preempt Me" is enabled, the ES route will be advertised 442 with DP=1 ("Don't Preempt Me"). All the PEs in an ES SHOULD be 443 consistent in their configuration of the DP capability, however 444 this document do not enforces the consistency across all the PEs. 446 2. Assuming we want to avoid 'preemption' in all the PEs in the ES, 447 the three PEs are configured with the "Don't Preempt Me" 448 capability. In this example, we assume ESI2 is configured as 449 'DP=enabled' in the three PEs. 451 3. Assuming Ethernet Tag-1 uses Highest-Pref in vES2 and Ethernet 452 Tag-2 uses Lowest-Pref, when vES2 is enabled in the three PEs, 453 the PEs will exchange the ES routes and select PE3 as DF for 454 Ethernet Tag-1 (due to the Highest-Pref type), and PE1 as DF for 455 Ethernet Tag-2 (due to the Lowest-Pref). 457 4. If PE3's vES2 goes down (due to EVC failure - detected by OAM, or 458 port failure or node failure), PE2 will become the DF for 459 Ethernet Tag-1. No changes will occur for Ethernet Tag-2. 461 5. When PE3's vES2 comes back up, PE3 will start a boot-timer (if 462 booting up) or hold-timer (if the port or EVC recovers). That 463 timer will allow some time for PE3 to receive the ES routes from 464 PE1 and PE2. PE3 will then: 466 - Select two "reference-PEs" among the ES routes in the vES, the 467 "Highest-PE" and the "Lowest-PE": 469 * The Highest-PE is the PE with higher Preference, using the 470 DP bit first (with DP=1 being better) and, after that, the 471 lower PE-IP address as tie-breakers. PE3 will select PE2 472 as Highest-PE over PE1, since, when comparing [Pref,DP,PE- 473 IP], [200,1,PE2-IP] wins over [100,1,PE1-IP]. 475 * The Lowest-PE is the PE with lower Preference, using the DP 476 bit first (with DP=1 being better) and, after that, the 477 lower PE-IP address as tie-breakers. PE3 will select PE1 478 as Lowest-PE over PE2, since [100,1,PE1-IP] wins over 479 [200,1,PE2-IP]. 481 * Note that if there were only one remote PE in the ES, 482 Lowest and Highest PE would be the same PE. 484 - Check its own administrative Pref and compares it with the one 485 of the Highest-PE and Lowest-PE that have DP=1 in their ES 486 routes. Depending on this comparison PE3 will send the ES 487 route with a [Pref,DP] that may be different from its 488 administrative [Pref,DP]: 490 * If PE3's Pref value is higher than the Highest-PE's, PE3 491 will send the ES route with an 'in-use' operational Pref 492 equal to the Highest-PE's and DP=0. 494 * If PE3's Pref value is lower than the Lowest-PE's, PE3 will 495 send the ES route with an 'in-use' operational Preference 496 equal to the Lowest-PE's and DP=0. 498 * If PE3's Pref value is neither higher nor lower than the 499 Highest-PE's or the Lowest-PE's respectively, PE3 will send 500 the ES route with its administrative [Pref,DP]=[300,1]. 502 * In this example, PE3's administrative Pref=300 is higher 503 than the Highest-PE with DP=1, that is, PE2 (Pref=200). 505 Hence PE3 will inherit PE2's preference and send the ES 506 route with an operational 'in-use' [Pref,DP]=[200,0]. 508 - Note that, a PE will always send DP=0 as long as the 509 advertised Pref is the 'in-use' operational Pref (as opposed 510 to the 'administrative' Pref). 512 - This ES route update sent by PE3 (with [200,0,PE3-IP]) will 513 not cause any DF switchover for any Ethernet Tag. PE2 will 514 continue being DF for Ethernet Tag-1. This is because the DP 515 bit will be used as a tie-breaker in the DF election. That 516 is, if a PE has two candidate PEs with the same Pref, it will 517 pick up the one with DP=1. There are no DF changes for 518 Ethernet Tag-2 either. 520 6. Subsequently, if PE2 fails, upon receiving PE2's ES route 521 withdrawal, PE3 and PE1 will go through the process described in 522 (5) to select new Highest and Lowest-PEs (considering their own 523 active ES route) and then they will run the DF Election. 525 - If a PE selects itself as new Highest or Lowest-PE and it was 526 not before, the PE will then compare its operational 'in-use' 527 Pref with its administrative Pref. If different, the PE will 528 send an ES route update with its administrative Pref and DP 529 values. In the example, PE3 will be the new Highest-PE, 530 therefore it will send an ES route update with 531 [Pref,DP]=[300,1]. 533 - After running the DF Election, PE3 will become the new DF for 534 Ethernet Tag-1. No changes will occur for Ethernet Tag-2. 536 Note that, irrespective of the DP bit, when a PE or ES comes back and 537 the PE advertises a DF Election Alg different than 2 (Preference 538 algorithm), the rest of the PEs in the ES MUST fall back to the 539 Default [RFC7432] Alg. 541 This document does not modify the use of the P and B bits in the 542 Ethernet A-D per EVI routes [RFC8214] advertised by the PEs in the ES 543 after running the DF Election, irrespective of the revertive or non- 544 revertive behavior in the PE. 546 5. Security Considerations 548 This document describes a DF Election Algorithm that provides 549 absolute control (by configuration) over what PE is the DF for a 550 given Ethernet Tag. While this control is desired in many situations, 551 a malicious user that gets access to the configuration of a PE in the 552 ES may change the behavior of the network. In other DF Algs such as 553 HRW, the DF Election is more automated and cannot be determined by 554 configuration. 556 The non-revertive capability described in this document may be seen 557 as a security improvement over the regular EVPN revertive DF 558 Election: an intentional link (or node) "flapping" on a PE will only 559 cause service disruption once, when the PE goes to NDF state. 561 6. IANA Considerations 563 This document solicits the allocation of the following values: 565 o DF Alg = 2 in the [RFC8584] "DF Alg" registry, with name 566 "Preference Algorithm". 568 o Bit 0 in the [RFC8584] DF Election Capabilities registry, with 569 name "D (Don't Preempt) Capability" for Non-revertive ES. 571 7. Acknowledgments 573 The authors would like to thank Kishore Tiruveedhula for his review 574 and comments. 576 8. Contributors 578 In addition to the authors listed, the following individuals also 579 contributed to this document: 581 Kiran Nagaraj, Nokia 583 Vinod Prabhu, Nokia 585 Selvakumar Sivaraj, Juniper 587 Sami Boutros, VMWare 589 9. References 591 9.1. Normative References 593 [RFC7432] Sajassi, A., Ed., Aggarwal, R., Bitar, N., Isaac, A., 594 Uttaro, J., Drake, J., and W. Henderickx, "BGP MPLS-Based 595 Ethernet VPN", RFC 7432, DOI 10.17487/RFC7432, February 596 2015, . 598 [RFC8214] Boutros, S., Sajassi, A., Salam, S., Drake, J., and J. 599 Rabadan, "Virtual Private Wire Service Support in Ethernet 600 VPN", RFC 8214, DOI 10.17487/RFC8214, August 2017, 601 . 603 [RFC7623] Sajassi, A., Ed., Salam, S., Bitar, N., Isaac, A., and W. 604 Henderickx, "Provider Backbone Bridging Combined with 605 Ethernet VPN (PBB-EVPN)", RFC 7623, DOI 10.17487/RFC7623, 606 September 2015, . 608 [RFC8365] Sajassi, A., Ed., Drake, J., Ed., Bitar, N., Shekhar, R., 609 Uttaro, J., and W. Henderickx, "A Network Virtualization 610 Overlay Solution Using Ethernet VPN (EVPN)", RFC 8365, 611 DOI 10.17487/RFC8365, March 2018, 612 . 614 [RFC8584] Rabadan, J., Ed., Mohanty, S., Ed., Sajassi, A., Drake, 615 J., Nagaraj, K., and S. Sathappan, "Framework for Ethernet 616 VPN Designated Forwarder Election Extensibility", 617 RFC 8584, DOI 10.17487/RFC8584, April 2019, 618 . 620 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 621 Requirement Levels", BCP 14, RFC 2119, 622 DOI 10.17487/RFC2119, March 1997, 623 . 625 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 626 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 627 May 2017, . 629 9.2. Informative References 631 [I-D.ietf-bess-evpn-virtual-eth-segment] 632 Sajassi, A., Brissette, P., Schell, R., Drake, J., and J. 633 Rabadan, "EVPN Virtual Ethernet Segment", draft-ietf-bess- 634 evpn-virtual-eth-segment-04 (work in progress), January 635 2019. 637 Authors' Addresses 639 J. Rabadan (editor) 640 Nokia 641 777 Middlefield Road 642 Mountain View, CA 94043 643 USA 645 Email: jorge.rabadan@nokia.com 646 S. Sathappan 647 Nokia 649 Email: senthil.sathappan@nokia.com 651 T. Przygienda 652 Juniper Networks 654 Email: prz@juniper.net 656 W. Lin 657 Juniper Networks 659 Email: wlin@juniper.net 661 J. Drake 662 Juniper Networks 664 Email: jdrake@juniper.net 666 A. Sajassi 667 Cisco Systems 669 Email: sajassi@cisco.com 671 S. Mohanty 672 Cisco Systems 674 Email: satyamoh@cisco.com