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