idnits 2.17.00 (12 Aug 2021) /tmp/idnits3759/draft-ietf-bess-evpn-virtual-eth-segment-07.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 (July 6, 2021) is 312 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: draft-ietf-bess-evpn-inter-subnet-forwarding has been published as RFC 9135 == Outdated reference: A later version (-04) exists of draft-ietf-bess-pbb-evpn-isid-cmacflush-00 Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 BESS WorkGroup A. Sajassi 3 Internet-Draft P. Brissette 4 Intended status: Standards Track Cisco Systems 5 Expires: January 7, 2022 R. Schell 6 Verizon 7 J. Drake 8 Juniper 9 J. Rabadan 10 Nokia 11 July 6, 2021 13 EVPN Virtual Ethernet Segment 14 draft-ietf-bess-evpn-virtual-eth-segment-07 16 Abstract 18 EVPN and PBB-EVPN introduce a family of solutions for multipoint 19 Ethernet services over MPLS/IP network with many advanced features 20 among which their multi-homing capabilities. These solutions 21 introduce Single-Active and All-Active for an Ethernet Segment (ES), 22 itself defined as a set of physical links between the multi-homed 23 device/network and a set of PE devices that they are connected to. 24 This document extends the Ethernet Segment concept so that an ES can 25 be associated to a set of EVCs (e.g., VLANs) or other objects such as 26 MPLS Label Switch Paths (LSPs) or Pseudowires (PWs), referred to as 27 Virtual Ethernet Segments (vES). This draft describes the 28 requirements and the extensions needed to support vES in EVPN and 29 PBB-EVPN. 31 Requirements Language 33 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 34 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 35 document are to be interpreted as described in RFC 2119 [RFC2119] and 36 RFC 8174 [RFC8174]. 38 Status of This Memo 40 This Internet-Draft is submitted in full conformance with the 41 provisions of BCP 78 and BCP 79. 43 Internet-Drafts are working documents of the Internet Engineering 44 Task Force (IETF). Note that other groups may also distribute 45 working documents as Internet-Drafts. The list of current Internet- 46 Drafts is at https://datatracker.ietf.org/drafts/current/. 48 Internet-Drafts are draft documents valid for a maximum of six months 49 and may be updated, replaced, or obsoleted by other documents at any 50 time. It is inappropriate to use Internet-Drafts as reference 51 material or to cite them other than as "work in progress." 53 This Internet-Draft will expire on January 7, 2022. 55 Copyright Notice 57 Copyright (c) 2021 IETF Trust and the persons identified as the 58 document authors. All rights reserved. 60 This document is subject to BCP 78 and the IETF Trust's Legal 61 Provisions Relating to IETF Documents 62 (https://trustee.ietf.org/license-info) in effect on the date of 63 publication of this document. Please review these documents 64 carefully, as they describe your rights and restrictions with respect 65 to this document. Code Components extracted from this document must 66 include Simplified BSD License text as described in Section 4.e of 67 the Trust Legal Provisions and are provided without warranty as 68 described in the Simplified BSD License. 70 Table of Contents 72 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 73 1.1. Virtual Ethernet Segments in Access Ethernet Networks . . 3 74 1.2. Virtual Ethernet Segments in Access MPLS Networks . . . . 5 75 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 76 3. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 7 77 3.1. Single-Homed and Multi-Homed vES . . . . . . . . . . . . 8 78 3.2. Scalability . . . . . . . . . . . . . . . . . . . . . . . 8 79 3.3. Local Switching . . . . . . . . . . . . . . . . . . . . . 9 80 3.4. EVC Service Types . . . . . . . . . . . . . . . . . . . . 9 81 3.5. Designated Forwarder (DF) Election . . . . . . . . . . . 9 82 3.6. OAM . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 83 3.7. Failure and Recovery . . . . . . . . . . . . . . . . . . 10 84 3.8. Fast Convergence . . . . . . . . . . . . . . . . . . . . 11 85 4. Solution Overview . . . . . . . . . . . . . . . . . . . . . . 11 86 4.1. EVPN DF Election for vES . . . . . . . . . . . . . . . . 12 87 4.2. Grouping and Route Colouring for vES . . . . . . . . . . 14 88 4.2.1. EVPN Route Colouring for vES . . . . . . . . . . . . 14 89 4.2.2. PBB-EVPN Route Colouring for vES . . . . . . . . . . 15 90 5. Failure Handling and Recovery . . . . . . . . . . . . . . . . 15 91 5.1. EVC Failure Handling for Single-Active vES in EVPN . . . 16 92 5.2. EVC Failure Handling for Single-Active vES in PBB-EVPN . 17 93 5.3. Port Failure Handling for Single-Active vESes in EVPN . . 18 94 5.4. Port Failure Handling for Single-Active vESes in PBB-EVPN 18 95 5.5. Fast Convergence in (PBB-)EVPN . . . . . . . . . . . . . 20 97 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 22 98 7. Security Considerations . . . . . . . . . . . . . . . . . . . 22 99 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 100 9. Intellectual Property Considerations . . . . . . . . . . . . 22 101 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 22 102 10.1. Normative References . . . . . . . . . . . . . . . . . . 23 103 10.2. Informative References . . . . . . . . . . . . . . . . . 23 104 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 24 106 1. Introduction 108 [RFC7432] and [RFC7623] introduce a family of solutions for 109 multipoint Ethernet services over MPLS/IP network with many advanced 110 features among which their multi-homing capabilities. These 111 solutions introduce Single-Active and All-Active for an Ethernet 112 Segment (ES), itself defined as a set of links between the 113 multi-homed device/network and a set of PE devices that they are 114 connected to. 116 This document extends the Ethernet Segment concept so that an ES can 117 be associated to a set of EVCs (e.g., VLANs) or other objects such as 118 MPLS Label Switch Paths (LSPs) or Pseudowires (PWs), referred to as 119 Virtual Ethernet Segments (vES). This draft describes the 120 requirements and the extensions needed to support vES in EVPN and 121 PBB-EVPN. 123 1.1. Virtual Ethernet Segments in Access Ethernet Networks 125 Some Service Providers (SPs) want to extend the concept of the 126 physical links in an ES to Ethernet Virtual Circuits (EVCs) where 127 many of such EVCs (e.g., VLANs) can be aggregated on a single 128 physical External Network-to-Network Interface (ENNI). An ES that 129 consists of a set of EVCs instead of physical links is referred to as 130 a virtual ES (vES). Figure 1 depicts two PE devices (PE1 and PE2) 131 each with an ENNI where a number of vESes are aggregated on - each of 132 which through its associated EVC. 134 Carrier 135 Ethernet 136 +-----+ Network 137 | CE11|EVC1 +---------+ 138 +-----+ \ | | +---+ 139 Cust. A \-0=========0--ENNI1| | 140 +-----+ | | ENNI1| | +-------+ +---+ 141 | CE12|EVC2--0=========0--ENNI1|PE1|---| | | | 142 +-----+ | | ENNI1| | | |---|PE3|- 143 | ==0--ENNI1| | |IP/MPLS| | | \ +---+ 144 +-----+ | / | +---+ |Core | +---+ \-| | 145 | CE22|EVC3--0==== / | |Network| |CE4| 146 +-----+ | X | | | +---+ | | 147 Cust. B | / \ | +---+ | | | | /-| | 148 +-----+ -0=== ===0--ENNI2| | | |---|PE4|-/ +---+ 149 | CE3 |EVC4/ | | ENNI2|PE2|---| | | | 150 | |EVC5--0=========0--ENNI2| | +-------+ +---+ 151 +-----+ | | +---+ 152 Cust. C +---------+ /\ 153 /\ || 154 || ENNI 155 EVCs Interface 156 <--------802.1Q----------> <---- EVPN Network -----> <-802.1Q-> 158 Figure 1: DHD/DHN (both SA/AA) and SH on same ENNI 160 ENNIs are commonly used to reach off-network / out-of-franchise 161 customer sites via independent Ethernet access networks or third- 162 party Ethernet Access Providers (EAP) (see Figure 1). ENNIs can 163 aggregate traffic from hundreds to thousands of vESes, where each vES 164 is represented by its associated EVC on that ENNI. As a result, 165 ENNIs and their associated EVCs are a key element of SP off-networks 166 that are carefully designed and closely monitored. 168 In order to meet customers' Service Level Agreements (SLA), SPs build 169 redundancy via multiple EVPN PEs and across multiple ENNIs (as shown 170 in Figure 1) where a given vES can be multi-homed to two or more EVPN 171 PE devices (on two or more ENNIs) via their associated EVCs. Just 172 like physical ES's in [RFC7432] and [RFC7623] solutions, these vESes 173 can be single-homed or multi-homed ES's and when multi-homed, then 174 can operate in either Single-Active or All-Active redundancy modes. 175 In a typical SP off-network scenario, an ENNI can be associated with 176 several thousands of single-homed vESes, several hundreds of Single- 177 Active vESes and it may also be associated with tens or hundreds of 178 All-Active vESes. 180 1.2. Virtual Ethernet Segments in Access MPLS Networks 182 Other Service Providers (SPs) want to extend the concept of the 183 physical links in an ES to individual Pseudowires (PWs) or to MPLS 184 Label Switched Paths (LSPs) in Access MPLS networks - i.e., a vES 185 consisting of a set of PWs or a set of LSPs. Figure 2 illustrates 186 this concept. 188 MPLS Aggregation 189 Network 190 +-----+ +-----------------+ 191 | CE11|EVC1 | | 192 +-----+ \ +AG1-+ PW1 +-+---+ 193 Cust. A -0----|===========| | 194 +-----+ | ---+===========| | +-------+ +---+ 195 | CE12|EVC2-0/ | PW2 /\ | PE1 +---+ | | | 196 +-----+ ++---+ ==||=| | | +---+PE3+- 197 | //=||=| | |IP/MPLS| | | \ +---+ 198 | // \/ +-+---+ |Core | +---+ \-+ | 199 +-----+EVC3 | PW3// LSP1 | |Network| |CE4| 200 | CE13| \+AG2-+===/PW4 | | | +---+ | | 201 +-----+ 0 |=== /\ +-+---+ | | | | /-+ | 202 0 |==PW5===||=| | | +---+PE4+-/ +---+ 203 +-----+ /++---+==PW6===||=| PE2 +---+ | | | 204 | CE14|EVC4 | \/ | | +-------+ +---+ 205 +-----+ | LSP2+-+---+ 206 Cust. C +-----------------+ 207 /\ 208 || 209 EVCs 210 <--802.1Q--> <-----MPLS Agg----> <--- EVPN Network ---> <-802.1Q-> 212 Figure 2: DHN and SH on MPLS Aggregation networks 214 In some cases, Service Providers use MPLS Aggregation Networks that 215 belong to separate administrative entities or third parties as a way 216 to get access to their own IP/MPLS Core network infrastructure. This 217 is the case illustrated in Figure 2. 219 In such scenarios, a virtual ES (vES) is defined as a set of 220 individual PWs if they cannot be aggregated into a common LSP. If 221 the aggregation of PWs is possible, the vES can be associated to an 222 LSP in a given PE. In the example of Figure 2, EVC3 is connected to 223 a VPWS instance in AG2 that is connected to PE1 and PE2 via PW3 and 224 PW5 respectively. EVC4 is connected to a separate VPWS instance on 225 AG2 that gets connected to an EVI on PE1 and PE2 via PW4 and PW6, 226 respectively. Since the PWs for the two VPWS instances can be 227 aggregated into the same LSPs going to the MPLS network, a common 228 virtual ES can be defined for LSP1 and LSP2. This vES will be shared 229 by two separate EVIs in the EVPN network. 231 In some cases, this aggregation of PWs into common LSPs may not be 232 possible. For instance, if PW3 were terminated into a third PE, e.g. 233 PE3, instead of PE1, the vES would need to be defined on a per 234 individual PW on each PE, i.e. PW3 and PW5 would belong to ES-1, 235 whereas PW4 and PW6 would be associated to ES-2. 237 For MPLS/IP access networks where a vES represents a set of PWs or 238 LSPs, this document extends Single-Active multi-homing procedures of 239 [RFC7432] and [RFC7623] to vES. The vES extension to All-Active 240 multi-homing is outside of the scope of this document for MPLS/IP 241 access networks. 243 This draft describes requirements and the extensions needed to 244 support a vES in [RFC7432] and [RFC7623]. Section 3 lists the set of 245 requirements for a vES. Section 4 describes extensions for a vES 246 that are applicable to EVPN solutions including [RFC7432] and 247 [RFC7209]. Furthermore, these extensions meet the requirements 248 described in Section 3. Section 4 gives solution overview and 249 Section 5 describes failure handling, recovery, scalability, and fast 250 convergence of [RFC7432] and [RFC7623] for vESes. 252 2. Terminology 254 AC: Attachment Circuit 256 BEB: Backbone Edge Bridge 258 B-MAC: Backbone MAC Address 260 CE: Customer Edge 262 CFM: Connectivity Fault Management (802.1ag) 264 C-MAC: Customer/Client MAC Address 266 DF: Designated Forwarder 268 DHD: Dual-homed Device 270 DHN: Dual-homed Network 272 ENNI: External Network-Network Interface 273 ES: Ethernet Segment 275 ESI: Ethernet Segment Identifier 277 EVC: Ethernet Virtual Circuit 279 EVPN: Ethernet VPN 281 I-SID: Service Instance Identifier (24 bits and global within a 282 PBB network see [RFC7080]) 284 LACP: Link Aggregation Control Protocol 286 PBB: Provider Backbone Bridge 288 PBB-EVPN: Provider Backbone Bridge EVPN 290 PE: Provider Edge 292 MHD: Multi-homed Device 294 MHN: Multi-homed Network 296 SH: Single-Homed 298 VPWS: Virtual Pseudowire Service 300 Single-Active Redundancy Mode (SA): When only a single PE, among a 301 group of PEs attached to an Ethernet Segment, is allowed to 302 forward traffic to/from that Ethernet Segment, then the 303 Ethernet Segment is defined to be operating in Single- 304 Active redundancy mode. 306 All-Active Redundancy Mode (AA): When all PEs attached to an 307 Ethernet segment are allowed to forward traffic to/from 308 that Ethernet Segment, then the Ethernet Segment is defined 309 to be operating in All-Active redundancy mode. 311 3. Requirements 313 This section describes the requirements specific to virtual Ethernet 314 Segment (vES) for (PBB-)EVPN solutions. These requirements are in 315 addition to the ones described in [RFC8214], [RFC7432], and 316 [RFC7623]. 318 3.1. Single-Homed and Multi-Homed vES 320 A PE needs to support the following types of vESes: 322 (R1a) A PE MUST handle single-homed vESes on a single physical port 323 (e.g., single ENNI) 325 (R1b) A PE MUST handle a mix of Single-Homed vESes and Single-Active 326 multi-homed vESes simultaneously on a single physical port (e.g., 327 single ENNI). Single-Active multi-homed vESes will be simply 328 referred to as Single-Active vESes through the rest of this document. 330 (R1c) A PE MAY handle All-Active multi-homed vESes on a single 331 physical port. All-Active multi-homed vESes will be simply referred 332 to as All-Active vESes through the rest of this document. 334 (R1d) A PE MAY handle a mix of All-Active vESes along with other 335 types of vESes on a single physical port. 337 (R1e) A Multi-Homed vES (Single-Active or All-Active) can be spread 338 across two or more ENNIs, on any two or more PEs. 340 3.2. Scalability 342 A single physical port (e.g., ENNI) can be associated with many 343 vESes. The following requirements give a quantitative measure for 344 each vES type. 346 (R2a) A PE SHOULD handle very large number of Single-Homed vESes on a 347 single physical port (e.g., thousands of vESes on a single ENNI). 349 (R2b) A PE SHOULD handle large number of Single-Active vESes on a 350 single physical port (e.g., hundreds of vESes on a single ENNI). 352 (R2c) A PE MAY handle large number of All-Active vESes on a single 353 physical port (e.g., hundreds of vESes on a single ENNI). 355 (R2d) A PE SHOULD handle the above scale for a mix of Single-homed 356 vESes and Single-Active vESes simultaneously on a single physical 357 port (e.g., single ENNI). 359 (R2e) A PE MAY handle the above sale for a mix of All-Active vESes 360 along with other types of vESes on a single physical port. 362 3.3. Local Switching 364 Many vESes of different types can be aggregated on a single physical 365 port on a PE device and some of these vES can belong to the same 366 service instance (or customer). This translates into the need for 367 supporting local switching among the vESes of the same service 368 instance on the same physical port (e.g., ENNI) of the PE. 370 (R3a) A PE MUST support local switching among different vESes 371 belonging to the same service instance (or customer) on a single 372 physical port. For example, in Figure 1, PE1 MUST support local 373 switching between CE11 and CE12 (both belonging to customer A) that 374 are mapped to two Single-homed vESes on ENNI1. In case of Single- 375 Active vESes, the local switching is performed among active EVCs 376 belonging to the same service instance on the same ENNI. 378 3.4. EVC Service Types 380 A physical port (e.g., ENNI) of a PE can aggregate many EVCs each of 381 which is associated with a vES. Furthermore, an EVC may carry one or 382 more VLANs. Typically, an EVC carries a single VLAN and thus it is 383 associated with a single broadcast domain. However, there is no 384 restriction on an EVC to carry more than one VLAN. 386 (R4a) An EVC can be associated with a single broadcast domain - e.g., 387 VLAN-based service or VLAN bundle service. 389 (R4b) An EVC MAY be associated with several broadcast domains - e.g., 390 VLAN-aware bundle service. 392 In the same way, a PE can aggregate many LSPs and PWs. In the case 393 of individual PWs per vES, typically a PW is associated with a single 394 broadcast domain, but there is no restriction on the PW to carry more 395 than one VLAN if the PW is of type Raw mode. 397 (R4c) A PW can be associated with a single broadcast domain - e.g., 398 VLAN-based service or VLAN bundle service. 400 (R4d) An PW MAY be associated with several broadcast domains - e.g., 401 VLAN-aware bundle service. 403 3.5. Designated Forwarder (DF) Election 405 Section 8.5 of [RFC7432] describes the default procedure for DF 406 election in EVPN which is also used in [RFC7623] and [RFC8214]. 407 [RFC8584] describes the additional procedures for DF election in 408 EVPN. These DF election procedures is performed at the granularity 409 of (ESI, Ethernet Tag). In case of a vES, the same EVPN default 410 procedure for DF election also applies; however, at the granularity 411 of (vESI, Ethernet Tag); where vESI is the virtual Ethernet Segment 412 Identifier and the Ethernet Tag field is represented by and I-SID in 413 PBB-EVPN and by a VLAN ID (VID) in EVPN. As in [RFC7432], this 414 default procedure for DF election at the granularity of (vESI, 415 Ethernet Tag) is also referred to as "service carving". With service 416 carving, it is desirable to evenly partition the DFs for different 417 vES's among different PEs, thus evenly distributing the traffic among 418 different PEs. The following list the requirements apply to DF 419 election of vES's for (PBB-)EVPN. 421 (R5a) A vES with m EVCs can be distributed among n ENNIs belonging to 422 p PEs in any arbitrary order; where n >= p >= m. For example, if 423 there is an vES with 2 EVCs and there are 5 ENNIs on 5 PEs (PE1 424 through PE5), then vES can be dual-homed to PE2 and PE4 and the DF 425 election must be performed between PE2 and PE4. 427 (R5b) Each vES MUST be identified by its own virtual ESI (vESI). 429 3.6. OAM 431 In order to detect the failure of an individual EVC and perform DF 432 election for its associated vES as the result of this failure, each 433 EVC should be monitored independently. 435 (R6a) Each EVC SHOULD be monitored for its health independently. 437 (R6b) A single EVC failure (among many aggregated on a single 438 physical port/ENNI) MUST trigger DF election for its associated vES. 440 3.7. Failure and Recovery 442 (R7a) Failure and failure recovery of an EVC for a Single-homed vES 443 SHALL NOT impact any other EVCs within its service instance or any 444 other service instances. In other words, for PBB-EVPN, it SHALL NOT 445 trigger any MAC flushing both within its own I-SID as well as other 446 I-SIDs. 448 (R7b) In case of All-Active vES, failure and failure recovery of an 449 EVC for that vES SHALL NOT impact any other EVCs within its service 450 instance or any other service instances. In other words, for PBB- 451 EVPN, it SHALL NOT trigger any MAC flushing both within its own I-SID 452 as well as other I-SIDs. 454 (R7c) Failure and failure recovery of an EVC for a Single-Active vES 455 SHALL impact only its own service instance. In other words, for PBB- 456 EVPN, MAC flushing SHALL be limited to the associated I-SID only and 457 SHALL NOT impact any other I-SIDs. 459 (R7d) Failure and failure recovery of an EVC for a Single-Active vES 460 MAY only impact C-MACs associated with MHD/MHNs for that service 461 instance. In other words, MAC flushing SHOULD be limited to single 462 service instance (I-SID in the case of PBB-EVPN) and only C-MACs for 463 Single-Active MHD/MHNs. 465 3.8. Fast Convergence 467 Since a large number of EVCs (and their associated vESes) are 468 aggregated via a single physical port (e.g., ENNI), then the failure 469 of that physical port impacts a large number of vESes and triggers 470 equally many ES route withdrawals. Formulating, sending, receiving, 471 and processing such large number of BGP messages can introduce delay 472 in DF election and convergence time. As such, it is highly desirable 473 to have a mass-withdraw mechanism similar to the one in [RFC7432] for 474 withdrawing many Ethernet A-D per ES routes. 476 (R8a) There SHOULD be a mechanism equivalent to EVPN mass-withdraw 477 such that upon an ENNI failure, only a single BGP message is needed 478 to indicate to the remote PEs to trigger DF election for all impacted 479 vES associated with that ENNI. 481 4. Solution Overview 483 The solutions described in [RFC7432] and [RFC7623] are leveraged 484 as-is with the modification that the ESI assignment is performed for 485 an EVC or a group of EVCs or LSPs/PWs instead of a link or a group of 486 physical links. In other words, the ESI is associated with a virtual 487 ES (vES), hereby referred to as vESI. 489 For the EVPN solution, everything basically remains the same except 490 for the handling of physical port failure where many vESes can be 491 impacted. Sections 5.1 and 5.3 below describe the handling of 492 physical port/link failure for EVPN. In a typical multi-homed 493 operation, MAC addresses are learned behind a vES and are advertised 494 with the ESI corresponding to the vES (i.e., vESI). EVPN aliasing 495 and mass-withdraw operations are performed with respect to vES 496 identifier: the Ethernet A-D routes for these operations are 497 advertised with vESI instead of ESI. 499 For PBB-EVPN solution, the main change is with respect to the B-MAC 500 address assignment which is performed similar to what is described in 501 section 7.2.1.1 of [RFC7623] with the following refinements: 503 o One shared B-MAC address SHOULD be used per PE for the 504 single-homed vESes. In other words, a single B-MAC is shared for 505 all single-homed vESes on that PE. 507 o One shared B-MAC address SHOULD be used per PE per physical port 508 (e.g., ENNI) for the Single-Active vESes. In other words, a 509 single B-MAC is shared for all Single-Active vESes that share the 510 same ENNI. 512 o One shared B-MAC address MAY be used for all Single-Active vESes 513 on that PE. 515 o One B-MAC address SHOULD be used per set of EVCs representing an 516 All-Active vES. In other words, a single B-MAC address is used 517 per vES for All-Active scenarios. 519 o A single B-MAC address MAY also be used per vES per PE for Single- 520 Active scenarios. 522 BEB +--------------+ BEB 523 || | | || 524 \/ | | \/ 525 +----+ EVC1 +----+ | | +----+ +----+ 526 | CE1|------| | | | | |---| CE2| 527 +----+\ | PE1| | IP/MPLS | | PE3| +----+ 528 \ +----+ | Network | +----+ 529 \ | | 530 EVC2\ +----+ | | 531 \ | | | | 532 \| PE2| | | 533 +----+ | | 534 /\ +--------------+ 535 || 536 BEB 537 <--802.1Q--><---------- PBB-EVPN --------><--802.1Q-> 539 Figure 3: PBB-EVPN Network 541 4.1. EVPN DF Election for vES 543 The procedure for service carving for virtual Ethernet Segments is 544 the same as the ones outlined in section 8.5 of [RFC7432] and 545 [RFC8584] except for the fact that ES is replaced with vES. 547 For the sake of clarity and completeness, the default DF election 548 procedure of [RFC7432] is repeated below: 550 1. When a PE discovers the vESI or is configured with the vESI 551 associated with its attached vES, it advertises an Ethernet 552 Segment route with the associated ES-Import extended community 553 attribute. 555 2. The PE then starts a timer (default value = 3 seconds) to allow 556 the reception of Ethernet Segment routes from other PE nodes 557 connected to the same vES. This timer value MUST be same across 558 all PEs connected to the same vES. 560 3. When the timer expires, each PE builds an ordered list of the IP 561 addresses of all the PE nodes connected to the vES (including 562 itself), in increasing numeric value. Each IP address in this 563 list is extracted from the "Originator Router's IP address" field 564 of the advertised Ethernet Segment route. Every PE is then given 565 an ordinal indicating its position in the ordered list, starting 566 with 0 as the ordinal for the PE with the numerically lowest IP 567 address. The ordinals are used to determine which PE node will 568 be the DF for a given EVPN instance on the vES using the 569 following rule: Assuming a redundancy group of N PE nodes, the PE 570 with ordinal i is the DF for an EVPN instance with an associated 571 Ethernet Tag value of V when (V mod N) = i. It should be noted 572 that using "Originator Router's IP address" field in the Ethernet 573 Segment route to get the PE IP address needed for the ordered 574 list, allows for a CE to be multi-homed across different ASes if 575 such need ever arises. 577 4. The PE that is elected as a DF for a given EVPN instance will 578 unblock traffic for that EVPN instance. Note that the DF PE 579 unblocks all traffic in both ingress and egress directions for 580 Single-Active vES and unblocks multi-destination in egress 581 direction for All-Active Multi-homed vES. All non-DF PEs block 582 all traffic in both ingress and egress directions for Single- 583 Active vES and block multi-destination traffic in the egress 584 direction for All-Active vES. 586 In the case of an EVC failure, the affected PE withdraws its Virtual 587 Ethernet Segment route if there are no more EVCs associated to the 588 vES in the PE. This will re-trigger the DF Election procedure on all 589 the PEs in the Redundancy Group. For PE node failure, or upon PE 590 commissioning or decommissioning, the PEs re-trigger the DF Election 591 procedure across all affected vESes. In case of a Single-Active, 592 when a service moves from one PE in the Redundancy Group to another 593 PE as a result of DF re-election, the PE, which ends up being the 594 elected DF for the service, SHOULD trigger a MAC address flush 595 notification towards the associated vES. This can be done, for e.g. 596 using IEEE 802.1ak MVRP 'new' declaration. 598 For LSP-based and PW-based vES, the non-DF PE SHOULD signal PW-status 599 'standby' to the Aggregation PE (e.g., AG PE in Figure 2), and a new 600 DF PE MAY send an LDP MAC withdraw message as a MAC address flush 601 notification. It should be noted that the PW-status is signaled for 602 the scenarios where there is a one-to-one mapping between EVI/BD and 603 the PW. 605 4.2. Grouping and Route Colouring for vES 607 Physical ports (e.g. ENNI) which aggregate a large number of EVCs 608 are 'coloured' to enable the grouping schemes described below. 610 By default, the MAC address of the corresponding port (e.g. ENNI) is 611 used to represent the 'colour' of the port, and the EVPN Router's MAC 612 Extended Community defined in 613 [I-D.ietf-bess-evpn-inter-subnet-forwarding] is used to signal this 614 colour. 616 The difference between colouring mechanism for EVPN and PBB-EVPN is 617 that for EVPN, the extended community is advertised with the Ethernet 618 A-D per ES route whereas for PBB-EVPN, the extended community may be 619 advertised with the B-MAC route. 621 The following sections describe Grouping Ethernet A-D per ES and 622 Grouping B-MAC, will become crucial for port failure handling as seen 623 in Section 5.3, Section 5.4 and Section 5.5 below. 625 4.2.1. EVPN Route Colouring for vES 627 When a PE discovers the vESI or is configured with the vESI 628 associated with its attached vES, an Ethernet-Segment route and 629 Ethernet A-D per ES route are generated using the vESI identifier. 631 These Ethernet-Segment and Ethernet A-D per ES routes specific to 632 each vES are coloured with an attribute representing their 633 association to a physical port (e.g. ENNI). 635 The corresponding port 'colour' is encoded in the EVPN Router's MAC 636 Extended Community defined in 637 [I-D.ietf-bess-evpn-inter-subnet-forwarding] and advertised along 638 with the Ethernet Segment and Ethernet A-D per ES routes for this 639 vES. 641 The PE also constructs a special Grouping Ethernet A-D per ES route 642 which represents all the vES associated with the port (e.g. ENNI). 643 The corresponding port 'colour' is encoded in the ESI field. For 644 this encoding, Type 3 ESI ([RFC7432] Section 5) is used with the MAC 645 field set to the colour (MAC address) of the port and the 3-octet 646 local discriminator field set to 0xFFFFFF. 648 The ESI label extended community ([RFC7432] Section 7.5) is not 649 relevant to Grouping Ethernet A-D per ES. The label value is NOT 650 used for encalsulating BUM packets for any split-horizon function and 651 the 'Single-Active' but is left as 0. To save label space, all 652 Grouping Ethernet A-D per ES of a PE SHOULD use same label value. 654 This Grouping Ethernet A-D per ES is advertised with a list of Route 655 Targets corresponding to the impacted service instances. If the 656 number of Route Targets is more than can fit into a single attribute, 657 then a set of Grouping Ethernet A-D per ES routes are advertised. 659 4.2.2. PBB-EVPN Route Colouring for vES 661 For PBB-EVPN, especially where there here are large number of service 662 instances (i.e., I-SIDs) associated with each EVC the PE MAY colour 663 each vES B-MAC route with an attribute representing their association 664 to a physical port (e.g. ENNI). 666 The corresponding port 'colour' is encoded in the EVPN Router's MAC 667 Extended Community defined in 668 [I-D.ietf-bess-evpn-inter-subnet-forwarding] and advertised along 669 with the B-MAC for this vES in PBB-EVPN. 671 The PE MAY then also construct a special Grouping B-MAC route which 672 represents all the vES associated with the port (e.g. ENNI). The 673 corresponding port 'colour' is encoded directly into this special 674 Grouping B-MAC route. 676 5. Failure Handling and Recovery 678 There are a number of failure scenarios to consider such as: 680 A: CE uplink port failure 682 B: Ethernet Access Network failure 684 C: PE access-facing port or link failure 686 D: PE node failure 688 E: PE isolation from IP/MPLS network 690 [RFC7432], [RFC7623], and [RFC8214] solutions provide protection 691 against such failures as described in the corresponding references. 692 In the presence of virtual Ethernet Segments (vESes) in these 693 solutions, besides the above failure scenarios, individual EVC 694 failure is an additional scenario to consider. Handling vES failure 695 scenarios implies that individual EVCs or PWs need to be monitored 696 and upon detection of failure or restoration of services, appropriate 697 DF election and failure recovery mechanisms are executed. 699 [RFC7023] is used for monitoring EVCs and upon failure detection of a 700 given EVC, DF election procedure per Section 4.1 is executed. For 701 PBB-EVPN, some extensions are needed to handle the failure and 702 recovery procedures of [RFC7623] in order to meet the above 703 requirements. These extensions are described in the next section. 705 [RFC4377] and [RFC6310] are used for monitoring the status of LSPs 706 and/or PWs associated to vES. 708 B D 709 || || 710 \/ \/ 711 +-----+ 712 +-----+ | | +---+ 713 | CE1 |EVC2--0=====0--ENNI1| | +-------+ 714 +-----+ | =0--ENNI1|PE1|---| | +---+ +---+ 715 Cust. A | / | | | |IP/MPLS|--|PE3|--|CE4| 716 +-----+ | / | +---+ |Network| | | +---+ 717 | |EVC2--0== | | | +---+ 718 | CE2 | | | +---+ | | 719 | |EVC3--0=====0--ENNI2|PE2|---| | 720 +-----+ | | | | +-------+ 721 +-----+ +---+ 722 /\ /\ /\ 723 || || || 724 A C E 726 Figure 4: Failure Scenarios A,B,C,D and E 728 5.1. EVC Failure Handling for Single-Active vES in EVPN 730 In [RFC7432], when a DF PE connected to a Single-Active multi-homed 731 Ethernet Segment loses connectivity to the segment, due to link or 732 port failure, it signals to the remote PEs to invalidate all MAC 733 addresses associated with that Ethernet Segment. This is done by 734 means of a mass-withdraw message, by withdrawing the Ethernet A-D per 735 ES route. It should be noted that for dual-homing use cases where 736 there is only a single backup path, MAC invalidating can be avoided 737 by the remote PEs as they can update their nexthop associated with 738 the affected MAC entries to the backup path per procedure described 739 in section 8.2 of [RFC7432]. 741 In case of an EVC failure which impacts a single vES, this same EVPN 742 procedure is used. In this case, the mass-withdraw is conveyed by 743 withdrawing the Ethernet A-D per vES route carrying the vESI 744 representing the failed EVC. The remote PEs upon receiving this 745 message perform the same procedures outlined in section 8.2 of 746 [RFC7432]. 748 5.2. EVC Failure Handling for Single-Active vES in PBB-EVPN 750 In [RFC7432], when a PE connected to a Single-Active Ethernet Segment 751 loses connectivity to the segment, due to link or port failure, it 752 signals the remote PE to flush all C-MAC addresses associated with 753 that Ethernet Segment. This is done by updating the advertised a 754 B-MAC route's MAC Mobility Extended community. 756 In case of an EVC failure that impacts a single vES, if the above 757 PBB-EVPN procedure is used, it results in excessive C-MAC flushing 758 because a single physical port can support large number of EVCs (and 759 their associated vESes) and thus updating the advertised B-MAC 760 corresponding to the physical port, with MAC mobility Extended 761 community, will result in flushing C-MAC addresses not just for the 762 impacted EVC but for all other EVCs on that port. 764 In order to reduce the scope of C-MAC flushing to only the impacted 765 service instances (the service instance(s) impacted by the EVC 766 failure), the PBB-EVPN C-MAC flushing needs to be adapted on a per 767 service instance basis (i.e., per I-SID). 768 [I-D.ietf-bess-pbb-evpn-isid-cmacflush] introduces B-MAC/I-SID route 769 where existing PBB-EVPN B-MAC route is modified to carry an I-SID in 770 the "Ethernet Tag ID" field instead of NULL value. This field 771 indicates to the receiving PE, to flush all C-MAC addresses 772 associated with that I-SID for that B-MAC. This C-MAC flushing 773 mechanism per I-SID SHOULD be used in case of EVC failure impacting a 774 vES. Since typically an EVC maps to a single broadcast domain and 775 thus a single service instance, the affected PE only needs to 776 advertise a single B-MAC/I-SID route. However, if the failed EVC 777 carries multiple VLANs each with its own broadcast domain, then the 778 affected PE needs to advertise multiple B-MAC/I-SID routes - one for 779 each VLAN (broadcast domain) - i.e., one for each I-SID. Each B-MAC/ 780 I-SID route basically instructs the remote PEs to perform flushing 781 for C-MACs corresponding to the advertised B-MAC only for the 782 advertised I-SID. 784 The C-MAC flushing based on B-MAC/I-SID route works fine when there 785 are only a few VLANs (e.g., I-SIDs) per EVC. However if the number 786 of I-SIDs associated with a failed EVC is large, then it is 787 recommended to assign a B-MAC per vES and upon EVC failure, the 788 affected PE simply withdraws this B-MAC message to other PEs. 790 5.3. Port Failure Handling for Single-Active vESes in EVPN 792 When a large number of EVCs are aggregated via a single physical port 793 on a PE, where each EVC corresponds to a vES, then the port failure 794 impacts all the associated EVCs and their corresponding vESes. If 795 the number of EVCs corresponding to the Single-Active vESes for that 796 physical port is in thousands, then thousands of service instances 797 are impacted. Therefore, the propagation if failure in BGP needs to 798 address all these impacted service instances. In order to achieve 799 this, the following extensions are added to the baseline EVPN 800 mechanism: 802 1. When a PE advertises an Ethernet A-D per ES route for a given 803 vES, it is coloured as described in Section 4.2.1 using the 804 physical port MAC by default. The receiving PEs take note of 805 this colour and create a list of vESes for this colour. 807 2. The PE also advertises a special Grouping Ethernet A-D per ES 808 route for that colour, which represents all the vES associated 809 with the port. 811 3. Upon a port failure (e.g., ENNI failure), the PE sends a 812 mass-withdraw message by withdrawing the Grouping Ethernet A-D 813 per ES route. 815 4. The remote PEs upon receiving this message, by identifying the 816 Grouping Ethernet A-D per ES route, detect the special vES 817 mass-withdraw message. The remote PEs then access the list 818 created in (1) of the vES's for the specified colour, and 819 initiate locally MAC address invalidating procedures for each of 820 the vES's in the list. 822 In scenarios where a logical ENNI is used the above procedure equally 823 applies. The logical ENNI is represented by a Grouping Ethernet A-D 824 per ES where the Type 3 ESI and the 6 bytes used in the ENNI's ESI 825 MAC address field is used as a colour for vESes as described above 826 and in Section 4.2.1. 828 5.4. Port Failure Handling for Single-Active vESes in PBB-EVPN 830 When a large number of EVCs are aggregated via a single physical port 831 on a PE, where each EVC corresponds to a vES, then the port failure 832 impacts all the associated EVCs and their corresponding vESes. If 833 the number of EVCs corresponding to the Single-Active vESes for that 834 physical port is in thousands, then thousands of service instances 835 (I-SIDs) are impacted. In such failure scenarios, the following two 836 MAC flushing mechanisms per [RFC7623] can be performed. 838 1. If the MAC address of the physical port is used for PBB 839 encapsulation as B-MAC SA, then upon the port failure, the PE 840 MUST use the EVPN MAC route withdrawal message to signal the 841 flush. 843 2. If the PE shared MAC address is used for PBB encapsulation as 844 B-MAC SA, then upon the port failure, the PE MUST re-advertise 845 this MAC route with the MAC Mobility Extended Community to signal 846 the flush. 848 The first method is recommended because it reduces the scope of 849 flushing the most. 851 As noted above, the advertisement of the extended community along 852 with B-MAC route for colouring purposes is optional and only 853 recommended when there are many vESes per physical port and each vES 854 is associated with very large number of service instances (i.e., 855 large numbe of I-SIDs). 857 If there are large number of service instances (i.e., I-SIDs) 858 associated with each EVC, and if there is a B-MAC assigned per vES as 859 recommended in the above section, then in order to handle port 860 failure efficiently, the following extensions are added to the 861 baseline PBB-EVPN mechanism: 863 1. Each vES MAY be coloured with a MAC address representing the 864 physical port similar to the colouring mechanism for EVPN. In 865 other words, each B-MAC representing a vES is advertised with the 866 'colour' of the physical port per Section 4.2.2. The receiving 867 PEs take note of this colour being advertised along with the 868 B-MAC route and for each such colour, create a list of vESes 869 associated with this colour. 871 2. The PE also advertises a special Grouping B-MAC route for that 872 colour (consisting by default of port MAC address), which 873 represents all the vES associated with the port. 875 3. Upon a port failure (e.g., ENNI failure), the PE sends a 876 mass-withdraw message by withdrawing the Grouping B-MAC route. 878 4. The remote PEs upon receiving this message, by identifying the 879 Grouping B-MAC route, detect the special vES mass-withdraw 880 message. The remote PEs then access the list created in (1) of 881 the vES's for the specified colour, and flush C-MACs associated 882 with the failed physical port. 884 5.5. Fast Convergence in (PBB-)EVPN 886 As described above, when a large number of EVCs are aggregated via a 887 physical port on a PE, and where each EVC corresponds to a vES, then 888 the port failure impacts all the associated EVCs and their 889 corresponding vESes. Two actions must be taken as the result of such 890 port failure: 892 o For EVPN initiate mass-withdraw procedure for all vESes associated 893 with the failed port to invalidate MACs and for PBB-EVPN flush all 894 C-MACs associated with the failed port across all vESes and the 895 impacted I-SIDs 897 o DF election for all impacted vESes associated with the failed port 899 Section 5.3 already describes how to perform mass-withdraw for all 900 affected vESes and invalidating MACs using a single BGP withdrawal of 901 the Grouping Ethernet A-D per ES route. Section 5.4 describes how to 902 only flush C-MAC address associated with the failed physical port 903 (e.g., optimum C-MAC flushing) as well as, optionally, the withdrawal 904 of a Grouping B-MAC route. 906 This section describes how to perform DF election in the most optimal 907 way - e.g., to trigger DF election for all impacted vESes (which can 908 be very large) among the participating PEs via a single BGP message 909 as opposed to sending large number of BGP messages (one per vES). 910 This section assumes that the MAC flushing mechanism described in 911 Section 5.4, bullet (1) is used and route colouring is used. 913 +-----+ 914 +----+ | | +---+ 915 | CE1|AC1--0=====0--ENNI1| | +-------+ 916 | |AC2--0 | |PE1|--| | 917 +----+ |\ ==0--ENNI2| | | | 918 | \/ | +---+ | | 919 | /\ | |IP/MPLS| 920 +----+ |/ \ | +---+ |Network| +---+ +---+ 921 | CE2|AC4--0 =0--ENNI3| | | |---|PE4|--|CE4| 922 | |AC4--0=====0--ENNI3|PE2|--| | +---+ +---+ 923 +----+ | ====0--ENNI3| | | | 924 |/ | +---+ | | 925 0 | | | 926 +----+ /| | +---+ | | 927 | CE3|AC5- | | |PE3|--| | 928 | |AC6--0=====0--ENNI4| | +-------+ 929 +----+ | | +---+ 930 +-----+ 932 Figure 5: Fast Convergence Upon ENNI Failure 934 The procedure for colouring vES Ethernet Segment routes is described 935 in Section 4.2. The following describes the procedure for fast 936 convergence for DF election using these coloured routes: 938 1. When a vES is configured, the PE advertises the Ethernet Segment 939 route for this vES with a colour corresponding to the physical 940 port. 942 2. All receiving PEs (in the redundancy group) take note of this 943 colour and create a list of vESes for this colour. 945 3. Recall, that the PE is advertising also a Grouping Ethernet A-D 946 per ES (for EVPN) and a Grouping B-MAC (for PBB-EVPN) 947 representing this colour and vES grouping. 949 4. Upon a port failure (e.g., ENNI failure), the PE withdraws this 950 previously advertised Grouping Ethernet A-D per ES or Grouping 951 B-MAC associated with the failed port. The PE should prioritize 952 sending these Grouping routes withdraw message over individual 953 vES route withdrawal messages of impacted vESes. 955 5. On reception of Grouping Ethernet A-D per ES or Grouping B-MAC 956 route withdrawal, other PEs in the redundancy group initiate DF 957 election procedures across all their affected vESes. 959 6. The PE with the physical port failure (ENNI failure), also sends 960 vES route withdrawal for every impacted vES. The other PEs upon 961 receiving these messages, clear up their BGP tables. It should 962 be noted the vES route withdrawal messages are not used for 963 executing DF election procedures by the receiving PEs when 964 Grouping Ethernet A-D per ES or Grouping B-MAC withdrawal has 965 been previously received. 967 6. Acknowledgements 969 The authors would like to thank Mei Zhang, Jose Liste, and 970 Luc Andre Burdet for their reviews of this document and feedback. 972 7. Security Considerations 974 All the security considerations in [RFC7432] and [RFC7623] apply 975 directly to this document because this document leverages the control 976 and data plane procedures described in those documents. 978 This document does not introduce any new security considerations 979 beyond that of [RFC7432] and [RFC7623] because advertisements and 980 processing of Ethernet Segment route for vES in this document follows 981 that of physical ES in those RFCs. 983 8. IANA Considerations 985 IANA has allocated sub-type value 7 in the "EVPN Extended Community 986 Sub-Types" registry defined in "https://www.iana.org/assignments/bgp- 987 extended-communities/bgp-extended-communities.xhtml#evpn" as follows: 989 SUB-TYPE NAME Reference 990 ---- -------------- ------------- 991 0x07 I-SID Ext Comm [draft-ietf-bess-evpn-virtual-eth-segment] 993 It is requested from IANA to update the reference to this document. 995 9. Intellectual Property Considerations 997 This document is being submitted for use in IETF standards 998 discussions. 1000 10. References 1001 10.1. Normative References 1003 [I-D.ietf-bess-evpn-inter-subnet-forwarding] 1004 Sajassi, A., Salam, S., Thoria, S., Drake, J., and J. 1005 Rabadan, "Integrated Routing and Bridging in EVPN", draft- 1006 ietf-bess-evpn-inter-subnet-forwarding-11 (work in 1007 progress), October 2020. 1009 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1010 Requirement Levels", BCP 14, RFC 2119, 1011 DOI 10.17487/RFC2119, March 1997, 1012 . 1014 [RFC7432] Sajassi, A., Ed., Aggarwal, R., Bitar, N., Isaac, A., 1015 Uttaro, J., Drake, J., and W. Henderickx, "BGP MPLS-Based 1016 Ethernet VPN", RFC 7432, DOI 10.17487/RFC7432, February 1017 2015, . 1019 [RFC7623] Sajassi, A., Ed., Salam, S., Bitar, N., Isaac, A., and W. 1020 Henderickx, "Provider Backbone Bridging Combined with 1021 Ethernet VPN (PBB-EVPN)", RFC 7623, DOI 10.17487/RFC7623, 1022 September 2015, . 1024 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1025 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1026 May 2017, . 1028 [RFC8214] Boutros, S., Sajassi, A., Salam, S., Drake, J., and J. 1029 Rabadan, "Virtual Private Wire Service Support in Ethernet 1030 VPN", RFC 8214, DOI 10.17487/RFC8214, August 2017, 1031 . 1033 10.2. Informative References 1035 [I-D.ietf-bess-pbb-evpn-isid-cmacflush] 1036 Rabadan, J., Sathappan, S., Nagaraj, K., Miyake, M., and 1037 T. Matsuda, "PBB-EVPN ISID-based CMAC-Flush", draft-ietf- 1038 bess-pbb-evpn-isid-cmacflush-00 (work in progress), 1039 October 2019. 1041 [RFC4377] Nadeau, T., Morrow, M., Swallow, G., Allan, D., and S. 1042 Matsushima, "Operations and Management (OAM) Requirements 1043 for Multi-Protocol Label Switched (MPLS) Networks", 1044 RFC 4377, DOI 10.17487/RFC4377, February 2006, 1045 . 1047 [RFC6310] Aissaoui, M., Busschbach, P., Martini, L., Morrow, M., 1048 Nadeau, T., and Y(J). Stein, "Pseudowire (PW) Operations, 1049 Administration, and Maintenance (OAM) Message Mapping", 1050 RFC 6310, DOI 10.17487/RFC6310, July 2011, 1051 . 1053 [RFC7023] Mohan, D., Ed., Bitar, N., Ed., Sajassi, A., Ed., DeLord, 1054 S., Niger, P., and R. Qiu, "MPLS and Ethernet Operations, 1055 Administration, and Maintenance (OAM) Interworking", 1056 RFC 7023, DOI 10.17487/RFC7023, October 2013, 1057 . 1059 [RFC7080] Sajassi, A., Salam, S., Bitar, N., and F. Balus, "Virtual 1060 Private LAN Service (VPLS) Interoperability with Provider 1061 Backbone Bridges", RFC 7080, DOI 10.17487/RFC7080, 1062 December 2013, . 1064 [RFC7209] Sajassi, A., Aggarwal, R., Uttaro, J., Bitar, N., 1065 Henderickx, W., and A. Isaac, "Requirements for Ethernet 1066 VPN (EVPN)", RFC 7209, DOI 10.17487/RFC7209, May 2014, 1067 . 1069 [RFC8584] Rabadan, J., Ed., Mohanty, S., Ed., Sajassi, A., Drake, 1070 J., Nagaraj, K., and S. Sathappan, "Framework for Ethernet 1071 VPN Designated Forwarder Election Extensibility", 1072 RFC 8584, DOI 10.17487/RFC8584, April 2019, 1073 . 1075 Authors' Addresses 1077 Ali Sajassi 1078 Cisco Systems 1080 Email: sajassi@cisco.com 1082 Patrice Brissette 1083 Cisco Systems 1085 Email: pbrisset@cisco.com 1087 Rick Schell 1088 Verizon 1090 Email: richard.schell@verizon.com 1091 John E Drake 1092 Juniper 1094 Email: jdrake@juniper.net 1096 Jorge Rabadan 1097 Nokia 1099 Email: jorge.rabadan@nokia.com