idnits 2.17.1 draft-ietf-bess-evpn-pref-df-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 : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. (A line matching the expected section header was found, but with an unexpected indentation: ' scope of this document. The default Preference value is 32767.' ) 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 (October 22, 2018) is 2006 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: 'RFC7432' is mentioned on line 465, but not defined == Missing Reference: 'Pref' is mentioned on line 416, but not defined == Missing Reference: 'DP' is mentioned on line 416, but not defined == Missing Reference: 'Alg' is mentioned on line 248, but not defined -- Looks like a reference, but probably isn't: '500' on line 330 -- Looks like a reference, but probably isn't: '0' on line 439 -- Looks like a reference, but probably isn't: '255' on line 249 -- Looks like a reference, but probably isn't: '100' on line 406 -- Looks like a reference, but probably isn't: '200' on line 439 -- Looks like a reference, but probably isn't: '300' on line 250 -- Looks like a reference, but probably isn't: '1' on line 406 == Missing Reference: 'Preference' is mentioned on line 330, but not defined == Missing Reference: 'PE-IP' is mentioned on line 400, but not defined == Missing Reference: 'PE2-IP' is mentioned on line 406, but not defined == Missing Reference: 'PE1-IP' is mentioned on line 406, but not defined == Missing Reference: 'PE3-IP' is mentioned on line 439, but not defined == Outdated reference: A later version (-09) exists of draft-ietf-bess-evpn-df-election-framework-05 Summary: 1 error (**), 0 flaws (~~), 12 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 Individual W. Lin 8 J. Drake 9 Juniper Networks 11 A. Sajassi 12 S. Mohanty 13 Cisco Systems 15 Expires: April 25, 2019 October 22, 2018 17 Preference-based EVPN DF Election 18 draft-ietf-bess-evpn-pref-df-02 20 Abstract 22 The Designated Forwarder (DF) in (PBB-)EVPN networks is defined as 23 the PE responsible for sending broadcast, multicast and unknown 24 unicast traffic (BUM) to a multi-homed device/network in the case of 25 an all-active multi-homing ES, or BUM and unicast in the case of 26 single-active multi-homing. 28 The DF is selected out of a candidate list of PEs that advertise the 29 Ethernet Segment Identifier (ESI) to the EVPN network, according to 30 the Default DF Election algorithm. 32 While the Default Algorithm provides an efficient and automated way 33 of selecting the DF across different EVIs or ISIDs in the ES, there 34 are some use-cases where a more 'deterministic' and user-controlled 35 method is required. At the same time, Service Providers require an 36 easy way to force an on-demand DF switchover in order to carry out 37 some maintenance tasks on the existing DF or control whether a new 38 active PE can preempt the existing DF PE. 40 This document proposes an extension to the Default DF election 41 procedures so that the above requirements can be met. 43 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 April 25, 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. Problem Statement . . . . . . . . . . . . . . . . . . . . . . . 3 84 2. Solution requirements . . . . . . . . . . . . . . . . . . . . . 3 85 3. EVPN BGP Attributes for Deterministic DF Election . . . . . . . 4 86 4. Solution description . . . . . . . . . . . . . . . . . . . . . 5 87 4.1 Use of the Preference algorithm . . . . . . . . . . . . . . 6 88 4.2 Use of the Preference algorithm in [RFC7432] 89 Ethernet-Segments . . . . . . . . . . . . . . . . . . . . . 7 90 4.3 The Non-Revertive option . . . . . . . . . . . . . . . . . . 8 91 5. Conventions used in this document . . . . . . . . . . . . . . . 11 92 6. Security Considerations . . . . . . . . . . . . . . . . . . . . 11 93 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 11 94 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 95 8.1 Normative References . . . . . . . . . . . . . . . . . . . . 11 96 8.2 Informative References . . . . . . . . . . . . . . . . . . . 11 97 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 12 98 10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 12 99 11. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 12 101 1. Problem Statement 103 [RFC7432] defines the Designated Forwarder (DF) in (PBB-)EVPN 104 networks as the PE responsible for sending broadcast, multicast and 105 unknown unicast traffic (BUM) to a multi-homed device/network in the 106 case of an all-active multi-homing ES or BUM and unicast traffic to a 107 multi-homed device or network in case of single-active multi-homing. 109 The DF is selected out of a candidate list of PEs that advertise the 110 Ethernet Segment Identifier (ESI) to the EVPN network and according 111 to the Alg [DF]. 113 While the Default DF Election Algorithm provides an efficient and 114 automated way of selecting the DF across different EVIs or ISIDs in 115 the ES, there are some use-cases where a more 'deterministic' and 116 user-controlled method is required. At the same time, Service 117 Providers require an easy way to force an on-demand DF switchover in 118 order to carry out some maintenance tasks on the existing DF or 119 control whether a new active PE can preempt the existing DF PE. 121 This document proposes an extension to the current Default DF 122 election procedures [RFC7432] so that the above requirements can be 123 met. 125 2. Solution requirements 127 This document proposes an extension of the [RFC7432] Default DF 128 election Algorithm motivated by the following requirements: 130 a) The solution provides an administrative preference option so that 131 the user can control in what order the candidate PEs may become 132 DF, assuming they are all operationally ready to take over. 134 b) This extension works for [RFC7432] Ethernet Segments (ES) and 135 virtual ES, as defined in [vES]. 137 c) The user may force a PE to preempt the existing DF for a given 138 EVI/ISID without re-configuring all the PEs in the ES. 140 d) The solution allows an option to NOT preempt the current DF, even 141 if the former DF PE comes back up after a failure. This is also 142 known as "non-revertive" behavior, as opposed to the [RFC7432] DF 143 election procedures that are always revertive. 145 e) The solution works for single-active and all-active multi-homing 146 Ethernet Segments. 148 3. EVPN BGP Attributes for Deterministic DF Election 150 This solution reuses and extends the DF Election Extended Community 151 defined in [DF] that is advertised along with the ES route: 153 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 154 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 155 | Type=0x06 | Sub-Type(0x06)| DF Alg | Bitmap | 156 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 157 | Bitmap | Reserved | DF Preference (2 octets) | 158 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 160 Figure 1 - DF Election Extended Community 162 Where the following fields are defined as follows: 164 o DF Alg can have the following values: 166 - Alg 0 - Default, modulo based DF election as per [RFC7432]. 167 - Alg 1 - HRW algorithm as per [DF] 168 - Alg 2 - Preference algorithm (this document) 170 o Bitmap can have the following values: 172 1 1 1 1 1 1 173 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 174 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 175 |D|A| | 176 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 178 Figure 2 - Bitmap field in the DF Election Extended Community 180 - Bit 0 (corresponds to Bit 24 of the DF Election Extended 181 Community) - D bit or 'Don't Preempt' bit (DP hereafter), 182 determines if the PE advertising the ES route requests the remote 183 PEs in the ES not to preempt it as DF. The default value is DP=0, 184 which is compatible with the 'preempt' or 'revertive' behavior in 185 the Default Alg [RFC7432]. The DP bit SHOULD be ignored if the DF 186 Alg is different than 2. 188 - Bit 1 - AC-DF or AC-Influenced DF Election, explained in [DF]. 189 The AC-DF capability bit MAY be set along with the DP capability 190 and Alg 2. 192 o DF Preference defines a 2-octet value that indicates the PE 193 preference to become the DF in the ES. The allowed values are 194 within the range 0-65535, and default value MUST be 32767. This 195 value is the midpoint in the allowed Preference range of values, 196 which gives the operator the flexibility of choosing a significant 197 number of values, above or below the default Preference. The DF 198 Preference field is specific to DF Alg 2 and does not represent any 199 Preference value for other Algs. 201 4. Solution description 203 Figure 3 illustrates an example that will be used in the description 204 of the solution. 206 EVPN network 207 +-------------------+ 208 | +-------+ ENNI Aggregation 209 | <---ESI1,500 | PE1 | /\ +----Network---+ 210 | <-----ESI2,100 | |===||=== | 211 | | |===||== \ vES1 | +----+ 212 +-----+ | | \/ |\----------------+CE1 | 213 CE3--+ PE4 | +-------+ | \ ------------+ | 214 +-----+ | | \ / | +----+ 215 | | | X | 216 | <---ESI1,255 +-----+============ \ | 217 | <-----ESI2,200 | PE2 |========== \ vES2 | +----+ 218 | +-----+ | \ ----------+CE2 | 219 | | | --------------| | 220 | +-----+ ----------------------+ | 221 | <-----ESI2,300 | PE3 +--/ | | +----+ 222 | +-----+ +--------------+ 223 --------------------+ 225 Figure 3 - ES and Deterministic DF Election 227 Figure 1 shows three PEs that are connecting EVCs coming from the 228 Aggregation Network to their EVIs in the EVPN network. CE1 is 229 connected to vES1 - that spans PE1 and PE2 - and CE2 is connected to 230 vES2, that is defined in PE1, PE2 and PE3. 232 If the algorithm chosen for vES1 and vES2 is Alg 2, i.e. Preference- 233 based, the PEs may become DF irrespective of their IP address and 234 based on an administrative Preference value. The following sections 235 provide some examples of the new defined procedures and how they are 236 applied in the use-case in Figure 1. 238 4.1 Use of the Preference algorithm 240 Assuming the operator wants to control - in a flexible way - what PE 241 becomes the DF for a given vES and the order in which the PEs become 242 DF in case of multiple failures, the following procedure may be used: 244 a) vES1 and vES2 are now configurable with three optional parameters 245 that are signaled in the DF Election extended community. These 246 parameters are the Preference, Preemption option (or "Don't 247 Preempt Me" option) and DF Alg. We will represent these parameters 248 as [Pref,DP,Alg]. Let's assume vES1 is configured as [500,0,Pref] 249 in PE1, and [255,0,Pref] in PE2. vES2 is configured as 250 [100,0,Pref], [200,0,Pref] and [300,0,Pref] in PE1, PE2 and PE3 251 respectively. 253 b) The PEs will advertise an ES route for each vES, including the 3 254 parameters in the DF Election Extended Community. 256 c) According to [RFC7432], each PE will wait for the DF timer to 257 expire before running the DF election algorithm. After the timer 258 expires, each PE runs the Preference-based DF election algorithm 259 as follows: 261 o The PE will check the DF Alg in each ES route, and assuming all 262 the ES routes are consistent in this DF Alg and the value is 2 263 (Preference-based), the PE will run the new extended procedure. 264 Otherwise, the procedure will fall back to [RFC7432] Default 265 Alg. 267 o In this extended procedure, each PE builds a list of candidate 268 PEs, ordered based on the Preference. E.g. PE1 will build a list 269 of candidate PEs for vES1 ordered by the Preference, from high 270 to low: PE1>PE2. Hence PE1 will become the DF for vES1. In the 271 same way, PE3 becomes the DF for vES2. 273 d) Note that, by default, the Highest-Preference is chosen for each 274 ES or vES, however the ES configuration can be changed to the 275 Lowest-Preference algorithm as long as this option is consistent 276 in all the PEs in the ES. E.g. vES1 could have been explicitly 277 configured as Alg Preference-based with Lowest-Preference, in 278 which case, PE2 would have been the DF. 280 e) Assuming some maintenance tasks had to be executed on PE3, the 281 operator could set vES2's preference to e.g. 50 so that PE2 is 282 forced to take over as DF for vES2. Once the maintenance on PE3 is 283 over, the operator could decide to leave the existing preference 284 or configure the old preference back. 286 f) In case of equal Preference in two or more PEs in the ES, the tie- 287 breakers will be the DP bit and the lowest IP PE in that order. 288 For instance: 290 o If vES1 parameters were [500,0,Pref] in PE1 and [500,1,Pref] in 291 PE2, PE2 would be elected due to the DP bit. 293 o If vES1 parameters were [500,0,Pref] in PE1 and [500,0,Pref] in 294 PE2, PE1 would be elected, assuming PE1's IP address is lower 295 than PE2's. 297 g) The Preference is an administrative option that MUST be configured 298 on a per-ES basis from the management plane, but MAY also be 299 dynamically changed based on the use of local policies. For 300 instance, on PE1, ES1's Preference can be lowered from 500 to 100 301 in case the bandwidth on the ENNI port is decreased a 50% (that 302 could happen if e.g. the 2-port LAG between PE1 and the 303 Aggregation Network loses one port). Policies MAY also trigger 304 dynamic Preference changes based on the PE's bandwidth 305 availability in the core, of specific ports going operationally 306 down, etc. The definition of the actual local policies is out of 307 scope of this document. The default Preference value is 32767. 309 4.2 Use of the Preference algorithm in [RFC7432] Ethernet-Segments 311 While the Preference-based DF Alg described in section 4.1 is 312 typically used in virtual ES scenarios where there is normally an 313 individual EVI per vES, the existing [RFC7432] definition of ES 314 allows potentially up to thousands of EVIs on the same ES. If this is 315 the case, and the operator still wants to control who the DF is for a 316 given EVI, the use of the Preference-based DF Alg can also provide 317 the desired level of load balancing. 319 In this type of scenarios, the ES is configured with an 320 administrative Preference value, but then a range of EVI/ISIDs can be 321 defined to use the Highest-Preference or the Lowest-Preference 322 depending on the desired behavior. With this option, the PE will 323 build a list of candidate PEs ordered by the Preference, however the 324 DF for a given EVI/ISID will be determined by the local 325 configuration. 327 For instance: 329 o Assuming ES3 is defined in PE1 and PE2, PE1 may be configured as 330 [500,0,Preference] for ES3 and PE2 as [100,0,Preference]. 332 o In addition, assuming vlan-based service interfaces, the PEs will 333 be configured with (vlan/ISID-range,high_or_low), e.g. (1- 334 2000,high) and (2001-4000, low). 336 o This will result in PE1 being DF for EVI/ISIDs 1-2000 and PE2 being 337 DF for EVI/ISIDs 2001-4000. 339 For Ethernet Segments attached to three or more PEs, any other logic 340 that provides a fair distribution of the DF function among the PEs is 341 valid, as long as that logic is consistent in all the PEs in the ES. 343 4.3 The Non-Revertive option 345 As discussed in section 2(d), an option to NOT preempt the existing 346 DF for a given EVI/ISID is required and therefore added to the DF 347 Election extended community. This option will allow a non-revertive 348 behavior in the DF election. 350 Note that, when a given PE in an ES is taken down for maintenance 351 operations, before bringing it back, the Preference may be changed in 352 order to provide a non-revertive behavior. The DP bit and the 353 mechanism explained in this section will be used for those cases when 354 a former DF comes back up without any controlled maintenance 355 operation, and the non-revertive option is desired in order to avoid 356 service impact. 358 In Figure 1, we assume that based on the Highest-Pref, PE3 is the DF 359 for ESI2. 361 If PE3 has a link, EVC or node failure, PE2 would take over as DF. 362 If/when PE3 comes back up again, PE3 will take over, causing some 363 unnecessary packet loss in the ES. 365 The following procedure avoids preemption upon failure recovery 366 (please refer to Figure 1): 368 1) A new "Don't Preempt Me" parameter is defined on a per-PE per-ES 369 basis, as described in section 3. If "Don't Preempt Me" is 370 disabled (default behavior) the advertised DP bit will be 0. If 371 "Don't Preempt Me" is enabled, the ES route will be advertised 372 with DP=1 ("Don't Preempt Me"). 374 2) Assuming we want to avoid 'preemption', the three PEs are 375 configured with the "Don't Preempt Me" option. Note that each PE 376 individually MAY be configured with different preemption value. In 377 this example, we assume ESI2 is configured as 'DP=enabled' in the 378 three PEs. 380 3) Assuming EVI1 uses Highest-Pref in vES2 and EVI2 uses Lowest-Pref, 381 when vES2 is enabled in the three PEs, the PEs will exchange the 382 ES routes and select PE3 as DF for EVI1 (due to the Highest-Pref 383 type), and PE1 as DF for EVI2 (due to the Lowest-Pref). 385 4) If PE3's vES2 goes down (due to EVC failure - detected by OAM, or 386 port failure or node failure), PE2 will become the DF for EVI1. No 387 changes will occur for EVI2. 389 5) When PE3's vES2 comes back up, PE3 will start a boot-timer (if 390 booting up) or hold-timer (if the port or EVC recovers). That 391 timer will allow some time for PE3 to receive the ES routes from 392 PE1 and PE2. PE3 will then: 394 o Select two "reference-PEs" among the ES routes in the vES, the 395 "Highest-PE" and the "Lowest-PE": 397 - The Highest-PE is the PE with higher Preference, using the DP 398 bit first (with DP=1 being better) and, after that, the lower 399 PE-IP address as tie-breakers. PE3 will select PE2 as Highest- 400 PE over PE1, since, when comparing [Pref,DP,PE-IP], 401 [200,1,PE2-IP] wins over [100,1,PE1-IP]. 403 - The Lowest-PE is the PE with lower Preference, using the DP 404 bit first (with DP=1 being better) and, after that, the lower 405 PE-IP address as tie-breakers. PE3 will select PE1 as Lowest- 406 PE over PE2, since [100,1,PE1-IP] wins over [200,1,PE2-IP]. 408 - Note that if there were only one remote PE in the ES, Lowest 409 and Highest PE would be the same PE. 411 o Check its own administrative Pref and compares it with the one 412 of the Highest-PE and Lowest-PE that have DP=1 in their ES 413 routes. Depending on this comparison PE3 will send the ES route 414 with a [Pref,DP] that may be different from its administrative 416 [Pref,DP]: 418 - If PE3's Pref value is higher than the Highest-PE's, PE3 will 419 send the ES route with an 'in-use' operational Pref equal to 420 the Highest-PE's and DP=0. 422 - If PE3's Pref value is lower than the Lowest-PE's, PE3 will 423 send the ES route with an 'in-use' operational Preference 424 equal to the Lowest-PE's and DP=0. 426 - If PE3's Pref value is neither higher nor lower than the 427 Highest-PE's or the Lowest-PE's respectively, PE3 will send 428 the ES route with its administrative [Pref,DP]=[300,1]. 430 - In this example, PE3's administrative Pref=300 is higher than 431 the Highest-PE with DP=1, that is, PE2 (Pref=200). Hence PE3 432 will inherit PE2's preference and send the ES route with an 433 operational 'in-use' [Pref,DP]=[200,0]. 435 Note that, a PE will always send DP=0 as long as the advertised 436 Pref is the 'in-use' operational Pref (as opposed to the 437 'administrative' Pref). 439 This ES route update sent by PE3 (with [200,0,PE3-IP]) will not 440 cause any DF switchover for any EVI/ISID. PE2 will continue being 441 DF for EVI1. This is because the DP bit will be used as a tie- 442 breaker in the DF election. That is, if a PE has two candidate PEs 443 with the same Pref, it will pick up the one with DP=1. There are 444 no DF changes for EVI2 either. 446 6) Subsequently, if PE2 fails, upon receiving PE2's ES route 447 withdrawal, PE3 and PE1 will go through the process described in 448 (5) to select new Highest and Lowest-PEs (considering their own 449 active ES route) and then they will run the DF Election. 451 o If a PE selects itself as new Highest or Lowest-PE and it was 452 not before, the PE will then compare its operational 'in-use' 453 Pref with its administrative Pref. If different, the PE will 454 send an ES route update with its administrative Pref and DP 455 values. In the example, PE3 will be the new Highest-PE, 456 therefore it will send an ES route update with 457 [Pref,DP]=[300,1]. 459 o After running the DF Election, PE3 will become the new DF for 460 EVI1. No changes will occur for EVI2. 462 Note that, irrespective of the DP bit, when a PE or ES comes back and 463 the PE advertises a DF Election Alg different than 2 (Preference 464 algorithm), the rest of the PEs in the ES MUST fall back to the 465 Default [RFC7432] Alg. 467 5. Conventions used in this document 469 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 470 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 471 "OPTIONAL" in this document are to be interpreted as described in 472 BCP14 [RFC2119] [RFC8174] when, and only when, they appear in all 473 capitals, as shown here. 475 6. Security Considerations 477 This section will be added in future versions. 479 7. IANA Considerations 481 This document solicits the allocation of DF Alg = 2 in the registry 482 created by [DF] for the DF Alg field, and the DP bit (Bit 0) in the 483 [DF] Bitmap registry. 485 8. References 487 8.1 Normative References 489 [RFC7432]Sajassi, A., Ed., Aggarwal, R., Bitar, N., Isaac, A., 490 Uttaro, J., Drake, J., and W. Henderickx, "BGP MPLS-Based Ethernet 491 VPN", RFC 7432, DOI 10.17487/RFC7432, February 2015, 492 . 494 [DF] Rabadan J., Mohanty S. et al. "Framework for EVPN Designated 495 Forwarder Election Extensibility", draft-ietf-bess-evpn-df-election- 496 framework-05, work-in-progress, October, 2018. 498 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 499 Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 500 1997, . 502 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 503 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, 504 . 506 8.2 Informative References 508 [vES] Sajassi et al. "EVPN Virtual Ethernet Segment", draft-ietf- 509 bess-evpn-virtual-eth-segment-00, work-in-progress, June, 2018. 511 9. Acknowledgments 513 The authors would like to thank Kishore Tiruveedhula for his review 514 and comments. 516 10. Contributors 518 In addition to the authors listed, the following individuals also 519 contributed to this document: 521 Kiran Nagaraj, Nokia 522 Vinod Prabhu, Nokia 523 Selvakumar Sivaraj, Juniper 525 11. Authors' Addresses 527 Jorge Rabadan 528 Nokia 529 777 E. Middlefield Road 530 Mountain View, CA 94043 USA 531 Email: jorge.rabadan@nokia.com 533 Senthil Sathappan 534 Alcatel-Lucent 535 Email: senthil.sathappan@nokia.com 537 Tony Przygienda 538 Juniper Networks, Inc. 539 Email: prz@juniper.net 541 John Drake 542 Juniper Networks, Inc. 543 Email: jdrake@juniper.net 545 Wen Lin 546 Juniper Networks, Inc. 547 Email: wlin@juniper.net 549 Ali Sajassi 550 Cisco Systems, Inc. 551 Email: sajassi@cisco.com 553 Satya Ranjan Mohanty 554 Cisco Systems, Inc. 556 Email: satyamoh@cisco.com 558 Sami Boutros 559 Email: boutros.sami@gmail.com