idnits 2.17.1 draft-wang-bess-evpn-cmac-overload-reduction-06.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 abstract seems to contain references ([RFC7623], [RFC8986], [I-D.ietf-bess-srv6-services]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 414: '... MUST be the same as the Attachment ...' RFC 2119 keyword, line 625: '...e End.DX2AGG SID MUST be the last segm...' RFC 2119 keyword, line 883: '... of the anycast IRB interfaces MUST be...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (8 May 2021) is 1084 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: 'RFC7796' is mentioned on line 334, but not defined == Unused Reference: 'I-D.ietf-bess-evpn-igmp-mld-proxy' is defined on line 981, but no explicit reference was found in the text == Unused Reference: 'RFC7041' is defined on line 1063, but no explicit reference was found in the text == Unused Reference: 'RFC8365' is defined on line 1076, but no explicit reference was found in the text == Outdated reference: A later version (-21) exists of draft-ietf-bess-evpn-igmp-mld-proxy-09 == Outdated reference: A later version (-21) exists of draft-ietf-bess-evpn-unequal-lb-11 == Outdated reference: A later version (-15) exists of draft-ietf-bess-srv6-services-07 == Outdated reference: A later version (-06) exists of draft-sajassi-bess-evpn-ac-aware-bundling-03 == Outdated reference: A later version (-01) exists of draft-wang-bess-evpn-ac-df-per-evi-00 == Outdated reference: A later version (-17) exists of draft-ietf-bess-evpn-irb-extended-mobility-05 Summary: 2 errors (**), 0 flaws (~~), 11 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 BESS WG Y. Wang 3 Internet-Draft R. Chen 4 Intended status: Standards Track ZTE Corporation 5 Expires: 9 November 2021 8 May 2021 7 Light Weighted EVPN 8 draft-wang-bess-evpn-cmac-overload-reduction-06 10 Abstract 12 SRv6 EVPN [I-D.ietf-bess-srv6-services] is not sufficient for some 13 light-weighted use cases. When PBB EVPN [RFC7623] over SRv6 is used 14 to support these light-weighted EVPN services, it is complicated to 15 make use of the SID list to carry a function that is aiming for 16 C-MACs. 18 In [RFC8986], End.DX2 function is defined, this function can be used 19 in EVPN VPLS. When it is used in EVPN VPLS, the data-plane learning 20 defined in End.DT2U function can also be transplanted into End.DX2 21 function. On the basis of such extended End.DX2 function, SRv6 EVPN 22 can be improved to meet all the requirements per [RFC7623] and bring 23 us some other benefits. Such SRv6 EVPN is called light-weighted SRv6 24 EVPN, and it will be more simpler than PBB EVPN over SRv6. 26 It is easy for the light-weighted SRv6 EVPN to carry a SID that is 27 aiming for customer ethernet packets, because there will be no other 28 ethernet header between the SID list and the customer ethernet 29 header. These SIDs may be user-defined functions for the customer 30 ethernet headers. 32 Status of This Memo 34 This Internet-Draft is submitted in full conformance with the 35 provisions of BCP 78 and BCP 79. 37 Internet-Drafts are working documents of the Internet Engineering 38 Task Force (IETF). Note that other groups may also distribute 39 working documents as Internet-Drafts. The list of current Internet- 40 Drafts is at https://datatracker.ietf.org/drafts/current/. 42 Internet-Drafts are draft documents valid for a maximum of six months 43 and may be updated, replaced, or obsoleted by other documents at any 44 time. It is inappropriate to use Internet-Drafts as reference 45 material or to cite them other than as "work in progress." 47 This Internet-Draft will expire on 9 November 2021. 49 Copyright Notice 51 Copyright (c) 2021 IETF Trust and the persons identified as the 52 document authors. All rights reserved. 54 This document is subject to BCP 78 and the IETF Trust's Legal 55 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 56 license-info) in effect on the date of publication of this document. 57 Please review these documents carefully, as they describe your rights 58 and restrictions with respect to this document. Code Components 59 extracted from this document must include Simplified BSD License text 60 as described in Section 4.e of the Trust Legal Provisions and are 61 provided without warranty as described in the Simplified BSD License. 63 Table of Contents 65 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 66 1.1. Background . . . . . . . . . . . . . . . . . . . . . . . 3 67 1.2. Overview . . . . . . . . . . . . . . . . . . . . . . . . 4 68 1.3. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 69 2. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 5 70 2.1. No C-MAC Awareness in the Backbone . . . . . . . . . . . 6 71 2.2. Flexible Multi-homing Remains Supported . . . . . . . . . 6 72 2.3. C-MAC Address Learning and Confinement . . . . . . . . . 6 73 2.4. No C-MAC Flushing for All-Active ESes . . . . . . . . . . 6 74 2.5. Independent C-MAC Flushing for Single-Active ESes . . . . 7 75 2.6. Independent Convergency per . . . . . . . . . 7 76 2.7. ESI Route Aggregation in Backbone . . . . . . . . . . . . 7 77 2.8. Unequal load-balance . . . . . . . . . . . . . . . . . . 7 78 2.9. AC-aware Service Interface . . . . . . . . . . . . . . . 8 79 2.10. Ingress Filtering for Unicast Flows of E-Tree Services . 8 80 2.11. AC-Influenced DF Election . . . . . . . . . . . . . . . . 8 81 3. Light-Weighted SRv6 EVPN Overview . . . . . . . . . . . . . . 8 82 3.1. Use Case . . . . . . . . . . . . . . . . . . . . . . . . 8 83 3.2. Solution Overview . . . . . . . . . . . . . . . . . . . . 9 84 3.2.1. Aggregatable End.DX2 SID . . . . . . . . . . . . . . 9 85 3.2.2. The Advertisement of ESI-Prefixes . . . . . . . . . . 10 86 3.3. Packet Walkthrough . . . . . . . . . . . . . . . . . . . 11 87 3.3.1. PE1 forward ARP Request to PE2/PE3 . . . . . . . . . 11 88 3.3.2. PE2/PE3's Dataplane MAC Learning . . . . . . . . . . 11 89 3.3.3. PE2 Discard ARP Request to CE1 . . . . . . . . . . . 12 90 3.3.4. PE3 Forward ARP Replay to PE1/PE2 . . . . . . . . . . 12 91 3.3.5. PE1 Forward ARP Replay to CE1 . . . . . . . . . . . . 13 92 4. Decapsulation Optimizations . . . . . . . . . . . . . . . . . 13 93 4.1. Decapsulation Aggregation . . . . . . . . . . . . . . . . 13 94 4.2. End.DX2AGG Function and Arg.ACI . . . . . . . . . . . . . 14 95 5. Advanced Considerations . . . . . . . . . . . . . . . . . . . 15 96 5.1. ESI SID Aggregation . . . . . . . . . . . . . . . . . . . 15 97 5.2. ESI/AC SID Advertisement Optimization . . . . . . . . . . 15 98 5.2.1. Advertise ESI-Locators in Underlay Network . . . . . 15 99 5.2.2. Using EAD/EVI Route to Advertise AC SIDs . . . . . . 16 100 5.2.3. Using EAD/ES Route to Advertise ESI SIDs . . . . . . 16 101 5.2.4. The Reduction of EAD/EVI Routes . . . . . . . . . . . 17 102 5.2.4.1. AC-DF per EVI Mode for Light-Weighted EVPNs . . . 17 103 5.2.4.2. On Receiving Reverse EAD/EVI Routes . . . . . . . 17 104 5.3. Unequal LB Advertisement . . . . . . . . . . . . . . . . 17 105 5.4. AC-aware Bundling Service Interface . . . . . . . . . . . 18 106 5.5. C-MAC Flush Notification Procedure . . . . . . . . . . . 18 107 5.6. E-Tree Support Considerations . . . . . . . . . . . . . . 19 108 5.7. EVPN IRB Support Considerations . . . . . . . . . . . . . 19 109 5.7.1. EVPN IRB Extended Mobility . . . . . . . . . . . . . 19 110 5.7.2. Anycast IRB interfaces . . . . . . . . . . . . . . . 20 111 6. Comparison with Other Solutions . . . . . . . . . . . . . . . 20 112 6.1. Detailed Comparisons with PBB EVPN over SRv6 . . . . . . 20 113 6.2. Detailed Comparisons with Anycast Node SID . . . . . . . 21 114 7. Security Considerations . . . . . . . . . . . . . . . . . . . 21 115 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 116 8.1. End.DX2AGG SID . . . . . . . . . . . . . . . . . . . . . 21 117 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 22 118 10. Normative References . . . . . . . . . . . . . . . . . . . . 22 119 11. Informative References . . . . . . . . . . . . . . . . . . . 23 120 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 24 122 1. Introduction 124 1.1. Background 126 When there are too many customer-MACs (C-MACs), the RRs and/or ASBRs 127 will be overloaded by the RT-2 routes for these MACs according to 128 [RFC7432]. This issue can be solved by light-weighted EVPNs. PBB 129 EVPN [RFC7623] is a MPLS-based light-weighted EVPN solution. But in 130 SRv6 network, PBB EVPN over SRv6 is not a good choice for light- 131 weighted EVPN solution. 133 This document proposes some new extensions to 134 [I-D.ietf-bess-srv6-services] to achieve all-active mode ES 135 redundancy on TPEs and reduce the C-MAC loads for RRs and ASBRs at 136 the same time. The new solution will work even more better than PBB 137 EVPN under the help of these extensions, especially when there is no 138 deployment of MPLS dataplane. 140 Furthermore, it naturally brings the benefits of high scalability, 141 faster network convergence, and reduced operational complexity, and 142 we call it light-weighted EVPNs because of these advantages. 144 1.2. Overview 146 In [RFC7432], the C-MACs is advertised via RT-2 route. This behavior 147 is inheritted by [I-D.ietf-bess-srv6-services]. but in order to 148 solve the C-MAC overload problem for RRs and ASBRs, we have to return 149 to a PBB-like dataplane C-MAC learning procedures. 151 We discuss all the requirements for a light-weighted EVPN solution 152 which pushes no C-MAC entries into the backbone network in Section 2. 153 Note that some of these requirements is not supported well by PBB 154 EVPN. 156 In this document, the light-weighted EVPN solutions are also called 157 as EVPN-lite for short. 159 Note that the EVI here corresponds to the I-Component of [RFC7623], 160 not the B-Component. In fact, there will be no typical B-components 161 in EVPN-lite SRv6 solutions. 163 1.3. Terminology 165 Most of the terminology used in this documents comes from [RFC7432] 166 and [I-D.ietf-bess-srv6-services] except for the following: 168 * Light-weighted EVPN: The EVPN solution with high scalability and 169 reduced operational complexity. 171 * EVPN-lite: The Light-weighted EVPN is also called EVPN-lite for 172 short. 174 * C-MAC: Customer MAC, it is the same as the C-MAC of PBB EVPN. 176 * ISID: a broadcast domain identifier in PBB I-Component. 178 * LDV: Local Discreminating Value. It is similar to the Local 179 Discreminating Value of type 3 ESI. 181 * GDV: Global Discreminating Value. An identifier with global 182 uniqueness. 184 * EGD: EVI-GDV, an EVI's Global Discreminator, it is a GDV for an 185 EVI instance. A EGD is used to idenfify an EVPN Instance (EVI) in 186 data plane. The EGD is a Global Discreminating Value (GDV) of 187 that EVI, so it is also the abbreviation of EVI-GDV. e.g. The 188 EGD of [RFC7348] is a global VNI. In this draft, the EGD of an 189 EVI is that EVI's VPN ID of global uniqueness. 191 * AC SID: The End.DX2 SID of a specified AC, different ACs on the 192 same ES have different AC SIDs. 194 * ESI SID: An SRv6 SID whose function type is End.DX2AGG. Note that 195 when the ESI is all-active mode, the ESI SID is the same on all 196 PEs of that ES, according to Section 3.2. In such case, the ESI 197 SID can be called as ES anycast SID too. Different ACs on the 198 same ES have the same ESI SID with different Arg.ACI. 200 * ESI IP: The End.DX2AGG SID of a specified ESI, but with an empty 201 Arg.ACI. 203 * ESI Prefix: The IPv6 Prefix that covers all AC-SIDs of the 204 specified ESI. 206 * Ingress AC SID: The End.DX2 SID of the ingress-AC on ingress-PE. 207 Note that the Ingress AC SID are typically encapsulated as SRv6 208 Source IP in data plane. 210 * EAD/ES: Ethernet A-D route per EVI, or RT-1 per ES route. 212 * EAD/EVI: Ethernet A-D route per EVI, or RT-1 per ES route. 214 * Arg.ACI: The argument part of a SID of the End.DX2AGG function is 215 called as Arg.ACI, because the value of that argument will be an 216 AC-ID. 218 * RT-2: MAC/IP Advertise Route. 220 * MAC Entry: An entry in the EVPN MAC table in data-plane. 222 * GRT: Global Routing Table. 224 2. Requirements 226 Light-weighted SRv6 EVPNs should be provided together with the 227 following requirements: 229 2.1. No C-MAC Awareness in the Backbone 231 In typical operation, an EVPN PE sends a BGP MAC Advertisement route 232 per C-MAC address. In certain applications, this poses scalability 233 challenges, as is the case in data center interconnect (DCI) 234 scenarios where the number of virtual machines (VMs), and hence the 235 number of C-MAC addresses, can be in the millions. This is called as 236 C-MAC overload of DC Backbone. In such scenarios, it is required to 237 reduce the number of BGP MAC Advertisement routes by relying on a 238 'EVPN-lite' scheme, as is provided by ESI and its equivalents (e.g. 239 Pseudo B-MAC, ESI IP). 241 2.2. Flexible Multi-homing Remains Supported 243 Flexible multi-homing means that different ES instances can have 244 different adjacent-PEs. We call all the adjacent-PEs of the same ES 245 instances as that ES's location-set in this document. Flexible 246 multi-homing means that different ES can have different location-set. 248 For example, ES1's location-set is {PE1}, ES2's location-set is {PE2, 249 PE3}, ES3's location-set is {PE1, PE3}, and ES4's location-set is 250 {PE2,PE4}. 252 2.3. C-MAC Address Learning and Confinement 254 In EVPN, all the PE nodes participating in the same EVPN instance are 255 exposed to all the C-MAC addresses learnt by any one of these PE 256 nodes because a C-MAC learnt by one of the PE nodes is advertised in 257 BGP to other PE nodes in that EVPN instance. This is the case even 258 if some of the PE nodes for that EVPN instance are not involved in 259 forwarding traffic to, or from, these C-MAC addresses. Even if an 260 implementation does not install hardware forwarding entries for C-MAC 261 addresses that are not part of active traffic flows on that PE, the 262 device memory is still consumed by keeping record of the C-MAC 263 addresses in the routing information base (RIB) table. In network 264 applications with millions of C-MAC addresses, this introduces a non- 265 trivial waste of PE resources. As such, it is required to confine 266 the scope of visibility of C-MAC addresses to only those PE nodes 267 that are actively involved in forwarding traffic to, or from, these 268 addresses. 270 2.4. No C-MAC Flushing for All-Active ESes 272 Just as in [RFC7623], it is required to avoid C-MAC address flushing 273 upon link, port, or node failure for remote All-Active multihomed 274 segments. 276 Note that when an ES fails on one PE, it may still works well on 277 another PE, so the C-MACs should not be flushed. 279 2.5. Independent C-MAC Flushing for Single-Active ESes 281 Just as in [RFC7623], upon single-active ESI's link or port failure, 282 the C-MACs of other single-active ESes from the same PE will not be 283 flushed. 285 2.6. Independent Convergency per 287 When the physical port of an All-Active ES works well, but a single 288 Ethernet Tag ID (ETI) of that ES fails on PE1, The traffic to that 289 ETI of that ES will be re-routed to other adjacent PE of the same ES, 290 but the traffic to other ETIs of the same ES will not be affected. 292 If PE1 is the last active link for that before that 293 failure, C-MAC flush should be triggered on the remote PEs. If that 294 ESI is single-active, C-MAC flush should be triggered on the remote 295 PEs too. 297 Note that when AC (ES link) fails but PE node still works well, there 298 should not be steady bypassing traffic either. The steady bypassing 299 problem is discussed in [I-D.wang-bess-evpn-egress-protection]. 301 2.7. ESI Route Aggregation in Backbone 303 In SRv6 EVPN, different sub-interfaces of the same ESI can have 304 different AC-SIDs in order to achieve Independent Convergency per 305 . But only the common prefix (say ESI-Prefix) of them 306 should be advertised in underlay network. 308 Note that only the common prefix need to be advertised in the overlay 309 network before any of these sub-interfaces failed. 311 Note that different ESIs may use the same SRv6 locator. In such 312 case, these ESI SIDs are aggregated into that anycast SRv6 locator 313 while they are advertised in the underlay network. 315 2.8. Unequal load-balance 317 The light-weighted EVPNs should support the unequal load-balance 318 defined in [I-D.ietf-bess-evpn-unequal-lb]. 320 2.9. AC-aware Service Interface 322 In AC-aware bundling service interface 323 [I-D.sajassi-bess-evpn-ac-aware-bundling], the ESes may make its two 324 VLANs to be attached to the same broadcast domain. These two VLANs 325 may be assigned to the same sub-interface, or to different sub- 326 interfaces. 328 2.10. Ingress Filtering for Unicast Flows of E-Tree Services 330 The filtering needed by an E-Tree service for known unicast traffic 331 should be performed at the ingress PE, thus providing very efficient 332 filtering and avoiding sending known unicast traffic over the PSN to 333 be filtered at the egress PE, as is done in traditional E-Tree 334 solutions (i.e., E-Tree for VPLS [RFC7796]). 336 2.11. AC-Influenced DF Election 338 When the EAD/EVI route is not advertised before the corresponding ESI 339 sub-interface fails, The AC-influenced DF Election procedures should 340 elect the right DF before and after that failure. 342 Note that according to [RFC8584], the AC-influenced DF Election will 343 be incorrect when no EAD/EVI route is advertised, even if no ESI sub- 344 interface has failed at all. 346 The AC-influenced DF Election should support "service carving" like 347 what [RFC7432] section 8.5 have done. 349 3. Light-Weighted SRv6 EVPN Overview 351 3.1. Use Case 353 The ethernet segment ES1's ESI is ESI1, the ES1 is attached to EVPN 354 instance EVI1 via attachment circuit AC1 on PE1, the ES1 is attached 355 to EVPN instance EVI1 via attachment circuit AC2 on PE2, We assign an 356 End.DX2 SID SID_AC1 to AC1, and we assign an End.DX2 SID SID_AC2 to 357 AC2. The ethernet segment ES2's ESI is ESI2, the ES2 is attached to 358 EVPN instance EVI1 via attachment circuit AC3 on PE3, We assign an 359 End.DX2 SID SID_AC3 to AC3. 361 +----------+ 362 PE1 | | 363 +-------------+ | | 364 | SID_AC1 | | | PE3 365 /| |----| | +-------------+ 366 / | | | SRv6 | | | 367 LAG / +-------------+ | Backbone | | SID_AC3 |---CE2 368 CE1===== | | | | 369 \ +-------------+ | |---| | 370 \ | | | | +-------------+ 371 \| |----| | 372 | SID_AC2 | | | 373 +-------------+ | | 374 PE2 | | 375 +----------+ 377 Figure 1: EVPN-lite SRv6 Usecase 379 We use IMET routes to build a broadcast-list. The broadcast-list is 380 used to forward BUM traffics. The data-plane MAC learning for BUM 381 traffics produces the first batch of C-MAC entries. The subsequent 382 C-MAC entries can be learnt from Unicast traffics and/or BUM 383 traffics. It is clear that we don't use MAC/IP routes to advertise 384 C-MAC entries as usual, that is for fear that the RRs and/or SPEs are 385 overloaded by these C-MACs. 387 3.2. Solution Overview 389 3.2.1. Aggregatable End.DX2 SID 391 When an Ethernet Segment ES1 is attached to an EVI, the attachment- 392 circuit AC1 for that is assigned with an End.DX2 SID. 393 Different ACs of the same ESI are assigned with different End.DX2 394 SIDs, we call them AC SIDs in this document. But these different 395 End.DX2 SIDs must be able to be aggregated into the same prefix, and 396 this prefix are called as ESI prefix in light-weighted SRv6 EVPNs. 397 The format of aggregatable End.DX2 SIDs is illustrated in the 398 following figure: 400 |<--- ESI-Prefix(128-N bits) ---->|<---- N bits --->| 401 +------------+------------+-----------+-------------------------+ 402 | Block | Node | ESI.LDV | AC-ID | 403 +------------+------------+-----------+-------------------------+ 404 |<------ Locator -------->|<------------- Function ------------>| 406 Figure 2: End.DX2 SID Formart for Aggregation 408 Note that the ESI.LDV field is the Local Discreminator Value (LDV) of 409 the ESI (especially the type 3/4/5 ESI). The AC-ID field is the 410 identifier of the AC's EVI. The ESI.LDV field and the AC-ID field 411 are integrated into the End.DX2 SID's Function part. 413 Note that in "AC-aware bundling service interface" the AC-ID field 414 MUST be the same as the Attachment Circuit ID of 415 [I-D.sajassi-bess-evpn-ac-aware-bundling]. But in other service 416 interfaces the AC-ID field can also be the EGD of that AC's EVPN 417 instance. Note that the EGD has a global meaning like a global VNI 418 or a PBB I-SID, while the ordinary AC-ID part for an aggregatable 419 End.DX2 SID typically is only a VLAN-ID on that ES. 421 Note that the ESI IP of an AC is that AC's End.DX2 SID but with a 422 zero AC-ID. The AC SIDs have non-zero AC-IDs, but the ESI-IPs always 423 have zero AC-IDs. Becuase an ESI-IP identifies an ESI, not an AC. 425 Note that if ESI1 is single-active mode, SID_AC1 is different from 426 SID_AC2, but if ESI1 is all-active mode, SID_AC1 is the same as 427 SID_AC2, we can call them SID21 in such case. 429 3.2.2. The Advertisement of ESI-Prefixes 431 The ESI-prefixes of SID_AC1 and SID_AC2 are defined in Figure 2, and 432 they are called ESI_Prefix1 and ESI_Prefix2 respectively. We can use 433 IGP protocols to advertise these ESI-Prefixes to PE3 respectively in 434 SRv6 underlay. So we don't have to use EAD/ES route or EAD/EVI route 435 in SRv6 EVPN in this section. 437 Note that the SRv6 SID in IMET route is an End.DT2M SID but with a 438 zero argument length. 440 Note that if ESI1 is single-active mode, ESI_Prefix1 is different 441 from ESI_Prefix2, but if ESI1 is all-active mode, ESI_Prefix1 is the 442 same as ESI_Prefix2. 444 Note that when PE1 node fails and the ESI is all active, the PLR node 445 will do underlay anycast FRR switching for SID21(=SID_AC2=SID_AC1). 446 This will bring out fast network convergency. 448 Note that when the PE-CE link of ESI1 fails, the IGP route of 449 ESI_Prefix1 will be withdrawn, So there will be no steady bypassing 450 for that ES, but a temporary bypassing can be performed to further 451 improve the convergency. 453 When two ESes are attached to the same redundancy group of PEs, they 454 can share the same anycast SRv6 Locator. In such case, only the 455 common SRv6 Locator is advertised by the underlay network. But they 456 should have different ESI-Prefix. Because that the ESI-SID 457 Aggregation is not recommanded to be activated in order to avoid the 458 steady bypass problems described in Section 5.1. 460 The detailed comparisons between light-weighted SRv6 EVPN and PBB 461 EVPN over SRv6 is described in Section 6. 463 3.3. Packet Walkthrough 465 3.3.1. PE1 forward ARP Request to PE2/PE3 467 * When CE1 requests CE2's ARP, PE1 will receive the ARP Request BUM1 468 from AC1 of ESI1. PE1 will forward the ARP Request following the 469 broadcast-list of AC1's EVPN instance EVI1. The broadcast-list is 470 constructed by the IMET routes from PE2 and PE3. The End.DX2 SID 471 of AC1 is named as SID_AC1. 473 PE1 will forward the ARP Request to PE2 and PE3. The inner SMAC 474 of the ARP request is M1 which is CE1's MAC address. 476 * In this step, PE1 will forward the ARP Request BUM1 to PE2/PE3 477 with the following SRv6 encapsulation: It's underlay Source IP is 478 the End.DX2 SID (SID_AC1) on PE1 for the ingress AC; It's underlay 479 Destination IP is the End.DT2M SID (whose argument length is zero) 480 on PE2/PE3. 482 Note that the underlay SIP will be the End.DT2U SID (because they 483 don't need any dedicated End.DX2 SIDs) for the single-homed 484 ingress ACs. The multi-homed ingress ACs with single-active 485 behavior may not be assigned with a dedicated ESI-Prefix either. 486 In such situations, the underlay SIP can be the End.DT2U SID too. 487 Note that in such situations, the AC SIDs of all single-active 488 ESIs for the same EVI are aggregated into the same End.DT2U SID. 490 3.3.2. PE2/PE3's Dataplane MAC Learning 492 * When PE2/PE3 receives the ARP Request packet BUM1, they do 493 dataplane MAC learning independently. They will learn that M1 is 494 behind SID_AC1. 496 Note that when PE2 learns that M1 is behind SID_AC1, it will 497 assume that M1 is behind the local AC (AC2) whose End.DX2 SID 498 (SID_AC2) is the same as SID_AC1 too. The local AC may have more 499 higher priority than the remote one. 501 After the dataplane MAC learning, the ARP request packet BUM1 is 502 broadcasted to the local ACs, behind one of which is CE2. 504 3.3.3. PE2 Discard ARP Request to CE1 506 * On receiving BUM1 from PE1, PE2 use the ingress ESI information 507 (SID_AC1) in BUM1 to determine its ingress ESI-Prefix, When ESI1 508 is all-active mode and PE2 is about to forward the ARP request to 509 CE1, PE2 will find that the AC SID (SID_AC2) for the outgoing AC 510 (AC2) is of the same ESI-Prefix, so PE2 discards it for ESI loop- 511 free considerations. 513 Note that before that ARP Request packet is discarded, its source- 514 MAC can be learnt, especially in "AC-aware bundling service 515 interface". The MAC entry is learnt against SID_AC1, but it will 516 consider the local sub-interface (of the same AC SID) on that ES 517 as its outgoing interface, in order to avoid unknown-unicast 518 flooding. 520 When ESI1 is single-active mode, the outgoing AC may be in 521 blocking state, otherwise its corresponding sub-interface on CE1 522 will take charge of packet-drop behavior instead. So although the 523 AC-SID (SID_AC2) for the outgoing AC is not the same as SID_AC1, 524 no loop will arise in the Ethernet Segment. 526 * In this step, PE2 can compare the ingress AC-SID of BUM1 and the 527 AC-SID of outgoing AC directly, no SID-to-ESI lookup needed. 529 3.3.4. PE3 Forward ARP Replay to PE1/PE2 531 * When CE2 replies to CE1 for the ARP request BUM1, PE3 will forward 532 the ARP reply U1 according to the MAC entry M1 learnt previously 533 as above. 535 PE3 will forward the ARP reply U1 to PE1 or PE2 according to 536 SID_AC1's SRv6 locator's IGP route. 538 When ESI1 is all-active mode, SID_AC1 will be the same as SID_AC2, 539 in such case, we call both of them SID21 instead. The traffics to 540 M1 will be load-balanced between PE1 and PE2. Because that 541 SID21's locator is advertised by both PE1 and PE2 in the underlay 542 IGP protocol. 544 * In this step, PE3 will forward the ARP reply U1 to PE1 with the 545 following SRv6 encapsulation: It's underlay Source IP is the 546 End.DX2 SID on PE3 for AC3; It's underlay Destination IP is the 547 End.DX2 SID (SID_AC1) on PE1 for AC1 according to the MAC entry 548 M1. 550 Note that if the DIP is just the anycast node SID of PE1 and PE2, 551 when the PE-CE link of ESI1 fails, the traffic will be steadily 552 bypassed untill that link recovers again. That's why MAC-entries 553 should be learnt against AC-SIDs. 555 3.3.5. PE1 Forward ARP Replay to CE1 557 * When PE1 receives the ARP reply packet U1 from PE3, PE1 first 558 match the packet to the its EVI instance EVI1 by U1's destination 559 End.DX2 SID. And PE1 will not discard it because the egress AC's 560 AC-SID is not the same as the ingress AC-SID (which is represented 561 by U1's source IP). 563 * In this step, When PE1 receives the SRv6 encapsulated ARP reply 564 packet U1 from PE3, PE1 first match the packet to the End.DX2 SID 565 of AC1 by DIP, then match the packet to AC1's EVI instance EVI1. 567 4. Decapsulation Optimizations 569 4.1. Decapsulation Aggregation 571 We want to decapsulation the packets destining to different ESIs for 572 the same EVI using the same forwarding entry. In order to achieve 573 this benefit, we can use an AC's EVI's EGD as that AC's AC SID's AC- 574 ID. 576 These AC SIDs are aggregatable End.DX2 SIDs, so we can consider the 577 ESI prefix aggregated from these End.DX2 SIDs as a new SRv6 function 578 called End.DX2AGG SID, The format of the End.DX2AGG SID is 579 illustrated in the following figure: 581 |<------ Locator -------->|<- FUNC -->|<------ Arg.ACI -------->| 582 +------------+------------+-----------+-----------------------+-+ 583 | Block | Node | ESI.LDV | EGD |L| 584 +------------+------------+-----------+-----------------------+-+ 586 Figure 3: End.DX2AGG SID Format 588 Note that whether these SIDs are considered as lots of End.DX2 SIDs 589 or are considered as a single End.DX2AGG SID with different 590 arguments, it is just a local matter of their PE node's independent 591 choice, other PEs of the same EVI won't be aware of the difference of 592 these two implementations. 594 A SID with the End.DX2AGG function is called as an "ESI SID" in this 595 document. The ESI's ESI-Prefix is the locator and fuction part of 596 its corresponding ESI SID. The argument part of the ESI SID is the 597 AC-ID for the corresponding AC's End.DX2 SID. The AC-ID plus the 598 ESI.LDV works like the function part of an End.DX2 SID. The argument 599 part of an ESI SID is called as Arg.ACI in this document. 601 Note that the Arg.ACI comprises EGD (EVPN Global Discreminator) and L 602 bit. The EGD identifies the EVI of that AC. When that AC is a leaf 603 AC, the L bit is 1, otherwise the L bit is 0. 605 Note that when AC-ID is the EGD, PE2 can still decapsulate the packet 606 following the End.DX2 function or following the End.DX2AGG function. 607 It is just a local matter, while the End.DX2AGG function can reduce 608 the decapsulation forwarding entries. But when AC-ID is that AC's 609 VLAN-IDs, PE2 have to decapsulate the packet following the End.DX2 610 function. 612 4.2. End.DX2AGG Function and Arg.ACI 614 The "Endpoint with decapsulation and Aggregated L2 table forwarding" 615 behavior (End.DX2AGG for short) is a variant of the End.DX2 behavior. 617 Two of the applications of the End.DX2AGG behavior are the EVPN VPLS 618 [RFC7432] and the EVPN ETREE [RFC8317] use-cases. 620 Any SID instance of this behavior is associated with an ESI E. The 621 behavior also takes an argument: "Arg.ACI". This argument provides a 622 local mapping to an EVI V. The outgoing interface corresponds to 623 is OIF, and the EVI V's bridge table is L2 Table T . 625 The End.DX2AGG SID MUST be the last segment in a SR Policy. 627 When N receives a packet whose IPv6 DA is S and S is a local 628 End.DX2AGG SID, the processing is identical to the End.DT2U behavior 629 except for the Upper-layer header processing which is as follows: 631 S01. If (Upper-Layer Header type == 143(Ethernet) ) { 632 S02. Remove the outer IPv6 Header with all its extension headers. 633 S03. Determine the L2 Table T using Arg.ACI. 634 S04. Learn the exposed MAC Source Address in L2 Table T. 635 S05. Find out the OIF, Forward the Ethernet frame to the OIF. 636 S06. } Else { 637 S07. Process as per Section 4.1.1 of [RFC8986]. 638 S08. } 640 Note that the OIF can be found out using the MAC-entries in L2 641 Table T, when the EVI V is an E-LAN service. 643 5. Advanced Considerations 645 5.1. ESI SID Aggregation 647 There are obvious difference between "Route Aggregation" and "SID 648 Aggregation" for an ESI. The "ESI Route Aggregation" is that 649 different End.DX2AGG SIDs are advertised by underlay protocols in a 650 common SRv6 locator, but different ESIs still have different 651 End.DX2AGG SIDs. The "ESI SID Aggregation" is that different ESIs 652 use the same SRv6 SID. 654 Note that the "ESI Route Aggregation" is recommanded as long as it is 655 possible, but the "ESI SID Aggregation" can only be used under 656 certain restraints. 658 When two ESes are attached to the same redundancy group of PEs, they 659 can share the same SRv6 SID. But this will bring out some issues 660 too. One of these issues is that they may be attached to different 661 groups of PEs in the future. Another issue is that when only one of 662 the ESes fails, that common SRv6 SID can't be withdrawn by that PE, 663 so the steady bypass of that ES arises immediately after its failture 664 on that PE. If these issues are not so important in some scenarios, 665 The ESI-SID Aggregation may be activated. This is an option. 667 Note that when ESI SID Aggregation is activated, the local-bias ES 668 split-horizon procedures or its variations should be used. 670 Note that ESI SID Aggregation works well with single-active ESIs (see 671 Section 3.3), its steadby bypassing problem will arise with all- 672 active ESIs only. 674 Note that the sub-interfaces of the same ESI may be assigned with 675 different End.DX2 SIDs, and these End.DX2 SIDs can be aggregated into 676 a common prefix, this common prefix is assigned with that ESI. In 677 such case, only the common prefix should be advertised before any of 678 the sub-interfaces fails. But this is not considered as "ESI SID 679 Aggregation", this is "ESI Route Aggregation". 681 5.2. ESI/AC SID Advertisement Optimization 683 5.2.1. Advertise ESI-Locators in Underlay Network 685 The End.DX2AGG SIDs can be advertised as an IP prefix in underlay IGP 686 protocols. Although it is the aggregation of many AC SIDs, the ESI 687 SIDs may still be too many for the underlay network. And the core 688 routers who are service-agnostic have to install these ESI prefixes. 690 In order to solve these problems, only the anycast SRv6 locators (say 691 ESI-Locators) of such ESI prefixes should be advertised in the 692 underlay network. 694 Note that in such case the ESI/AC SID typically don't have to be 695 advertised by EVPN routes in overlay network, unless some special 696 features (i.e. unequal load-balance) should be providered together. 698 5.2.2. Using EAD/EVI Route to Advertise AC SIDs 700 When the EAD/EVI routes here are used to advertise AC SIDs, the 701 End.DX2 SIDs are advertised in their SRv6 L2 Service TLVs, not in 702 their next hops. Their next hops will be the node SID of the 703 advertising PE. 705 In such case, the EAD/EVI routes will be installed as overlay routes, 706 and the AC SIDs learnt in the MAC entries is treated as the overlay 707 indexes for recursion. 709 In all-active mode, when an AC of a fails on one PE, all 710 other PEs of that should use EAD/EVI route to advertise 711 its AC SID. 713 5.2.3. Using EAD/ES Route to Advertise ESI SIDs 715 EAD/ES routes will be advertised/imported for EVIs but they should be 716 installed into Global Routing Table (GRT). Because there isn't a 717 dedicated B-component in EVPN-lite SRv6 like that in PBB VPLS and PBB 718 EVPN. The GRT plays a B-Component role in EVPN-lite SRv6. 720 Note that the EAD/ES routes won't be installed as overlay routes like 721 the EAD/EVI routes, because that we want to reduce the forwarding 722 table consumption. 724 Although ESI SIDs is installed into GRT, they are awared only on PE 725 nodes, the transit nodes in underlay network won't be aware of ESI 726 SIDs (they may aware the locators of these SIDs) in order to reduce 727 the FIB consumption. 729 Note that when the EAD/ES route here is used to advertise ESI SID, 730 the End.DX2AGG SID is advertised in its SRv6 L2 Service TLV, not in 731 its nexthop. Its nexthop will be the node SID of the advertising PE. 733 Note that in such case, the SRv6 source IP in the dataplane should be 734 set to the entire AC SID of the ingress AC, not just the ESI IP whose 735 AC-ID part is zero. 737 5.2.4. The Reduction of EAD/EVI Routes 739 In order to solve the problem described in Section 2.6, we may have 740 to advertise AC SIDs in the overlay network. But the amount of AC 741 SIDs may be hundreds of times larger than ESI SIDs. It is necessary 742 for the light-weighted SRv6 EVPNs to reduce the advertisement of AC 743 SIDs. 745 The AC SID of a specified will not be advertised by its 746 PEs, until these PEs know that the fails on at least one of 747 them. 749 Note that the entire AC SID for that can be used as the 750 source IP of the SRv6 encapsulation before that AC SID is advertised 751 via EVPN routes. Because that when a MAC is learnt over that AC SID, 752 the packet for that MAC can also be forwarded according to the ESI- 753 Prefix or ESI-Locator of the corresponding ESI SID due to the longest 754 match procedures of IP lookup. 756 5.2.4.1. AC-DF per EVI Mode for Light-Weighted EVPNs 758 When the EAD/EVI routes are not advertised, the AC-influenced DF- 759 Election per [RFC8584] can't work. So the AC-DF per EVI procedures 760 are required. The AC-DF per EVI procedures includes two steps. The 761 first step is the AC-DF per EVI capability negotiation procedure, and 762 the second step is the AC-DF per EVI DF-election procedure. 764 The Capability negotiation procedures and the DF-Election procedures 765 follow [I-D.wang-bess-evpn-ac-df-per-evi]. 767 5.2.4.2. On Receiving Reverse EAD/EVI Routes 769 In all-active mode, when a PE X receives a reverse EAD/EVI route 770 ([I-D.wang-bess-evpn-ac-df-per-evi]), that PE x can use nomal EAD/EVI 771 route to advertise the its local AC SID of that . 773 Note that no EAD/EVI route have to be advertised before receiving the 774 corresponding reverse EAD/EVI routes. This can greatly reduce the 775 amount of EAD/EVI routes. 777 5.3. Unequal LB Advertisement 779 When the ESI SIDs are advertised by EVPN routes for the overlay 780 network according to Section 5.2.2, we can advertise the EVPN Link 781 Bandwidth extended community (see [I-D.ietf-bess-evpn-unequal-lb]) or 782 something else along with the ESI SIDs using such EVPN routes. 784 Note that these extra information (which are advertised along with 785 the EVPN routes) are awared by the PEs only. The underlay network 786 don't have to be aware of it. 788 Note that when the EVPN Link Bandwidth extended community is 789 advertised along with the ESI SID, The nexthop of the EAD/ES route 790 should not be set to the anycast ECMP Node SID of the advertising PE 791 (egress-PE). On receiving such EAD/ES route, the ingress PE may push 792 this EAD/ES route's nexthop onto the End.DX2AGG/End.DX2 SID when 793 constructing the SID stack, if unequal-LB is required. 795 In such case, when the ESI SIDs are used as destination IP addresses, 796 they should be hiden in the SRH behind the node SID of the 797 corresponding egress PE router. This need to be encapsulated under 798 the help of EVPN routes of overlay network. So the ESI/AC SIDs must 799 be advertised in overlay network in such case. 801 Note that the association between an ESI/AC SID and its corresponding 802 Node SID is also advertised by such EVPN routes. Although the 803 destination ESI/AC SIDs won't be exposed untill they reached the 804 egress PE, the ESI-Locator of them should also be advertised in 805 underlay network because that these AC SIDs will be encapsulated as 806 source IPs (for the data packets of the reverse direction) and these 807 source IPs will be checked by underlay URPF (Unicast Reverse Path 808 Forwarding) procedures. 810 5.4. AC-aware Bundling Service Interface 812 In AC-aware bundling service interface, each VLAN of the same AC 813 should have different AC-SID. So End.DX2AGG Function can't be used 814 in AC-aware bundling service interface. 816 Note that each VLAN of the same AC of the same EVPN instance will 817 have the same End.DX2 SID, 819 Note that in "AC-aware bundling service interface", the AC-ID inside 820 that SID_AC1 can help the MAC entry to be installed for the correct 821 outgoing interface. Such MAC entry is called as the synced MAC entry 822 of M1. 824 5.5. C-MAC Flush Notification Procedure 826 The withdraw of an ESI/AC SID Advertisement (as an overlay route) can 827 (if it is the only advertisement of that ESI/AC SID at that time) be 828 used as C-MAC (which was learnt against that ESI/AC SID) flush 829 notification. 831 Note that in single active mode, the ESI-Prefixes of SID_AC1 and 832 SID_AC2 are different, so each withdraw of SID_AC1 or SID_AC2 will be 833 for the single advertisement of that SID. 835 When "AC-DF per EVI" (Section 5.2.4.1) is used, the reverse EAD/EVI 836 routes can be used to trigger C-MAC flush for specified AC SIDs. In 837 such case, these reverse EAD/EVI routes should not use EVI-RT format 838 to carry their EVI's route target. Because that EVI-RT format is not 839 visible to RT constraints mechanism. 841 5.6. E-Tree Support Considerations 843 E-tree Supprot extensions is similar to [RFC8317] section 5 except 844 for the following notable differences: The leaf B-MACs are replaced 845 by leaf ESI-SIDs, the root B-MACs are replaced by root ESI-SIDs. The 846 PBB encapsulation is replaced by SRv6 encapsulation, the B-component 847 is replaced by the underlay GRT. The B-MAC Advertisement Route is 848 replaced by EAD/EVI route or EAD/ES Route. 850 As illustrated in Figure 3, the root AC-SID and leaf AC-SID of the 851 same AC can be considered as the same ESI-SID with different Arg.ACI. 852 Even the EGD part of their Arg.ACIs are the same EGD, only the L bit 853 of their Arg.ACIs are different. The L bit of the leaf AC-SID is set 854 to 1. The L bit of the root AC-SID is set to 0. 856 On the ingress PE, when the L bit of the destination SID for the DMAC 857 of a data packet is 1, and that data packet's ingress AC is a leaf 858 AC, that data packet should be dropped. 860 5.7. EVPN IRB Support Considerations 862 The dataplane in this draft is no more complex than typical SRv6 863 EVPN. So it will work as efficient as we should expect in SRv6 EVPN 864 IRB usecase. 866 5.7.1. EVPN IRB Extended Mobility 868 In EVPN IRB usecase, [I-D.ietf-bess-evpn-irb-extended-mobility] 869 defines some optional extensions to support some specific IRB 870 usecases. In these specific IRB usecases, the bindings will 871 change across VM-moves. These extensions can't be applied to light- 872 weighted EVPNs, just like they can't be applied to PBB EVPNs either. 874 5.7.2. Anycast IRB interfaces 876 When an EVPN IRB interface (on PE1) ping a host H1, the corresponding 877 ICMP Echo Request will be delivered to host H1, whether host H1 is 878 PE1's local host or not . but if that IRB interface is an anycast IRB 879 interface, and host H1 is a local host of PE2 (not of PE1), naturally 880 the Echo Reply for that Echo Request will be delivered to the nearest 881 anycast IRB interface on PE2 (not on PE1) only. 883 Echo Replies received by any of the anycast IRB interfaces MUST be 884 flooded to other PEs of that BD. So that the PE which originated the 885 previous Echo Request can receive the synced Echo Replies. 887 Note that the Echo Replies between two hosts of that BD will not be 888 flooded, because that they will not be received by any of the anycast 889 IRB interfaces. 891 6. Comparison with Other Solutions 893 6.1. Detailed Comparisons with PBB EVPN over SRv6 895 The "PBB EVPN over SRv6 underlay" solution will be complex, if we 896 address too much things to it. I have some examples in the 897 following: 899 * The upper-layer header for SRv6 is the PBB-header for B-MACs, not 900 the ethernet header for C-MACs, so the SID list (SR-Path or 901 network programming Instructions) in the SRH can't be constructed 902 for the sake of the I-Component. For example, when a SRv6 SID for 903 MAC-guarding (or something else, just an example) present in the 904 SRH for PBB EVPN SRv6, I think it means BMAC-guarding, no C-MAC 905 guarding. 907 * The B-MACs for the all-active ESIs can't be aggregated, but the 908 SRv6 SIDs for ESIs can be aggregated. The underlay can advertise 909 the ESI-Locators only, so the burden of the underlay network may 910 not be increased too much. When the underlay routes is 911 aggregated, the C-MACs can also be learnt against /128 source-IP, 912 it is the advantage of a light-weighted SRv6 EVPN, which can't be 913 gained from a PBB header. 915 * The B-MACs are for overlay protection (the real overlay is the 916 I-VPLS, but the B-VPLS is also an overlay network from the 917 viewpoint of the SRv6 network). But the SRv6 SIDs for ESIs will 918 be for underlay protection, it works like the egress protection. 919 They are two different types of protecting solutions. 921 * Light-weighted SRv6 EVPN can support AC-influenced DF Election, 922 but PBB EVPN over SRv6 can't. 924 * Although PBB EVPN can be transplanted into SRv6 networks along 925 with the PBB header (say PBB EVPN over SRv6), It seems to be more 926 complicated to me. Take the EVPN IRB usecases for example, that 927 requires seven sequences of header processing, like (SRv6/B-MAC/C- 928 MAC)(Inner-IP)(C-MAC/B-MAC/SRv6), during the overlay L3 929 forwarding. I think it will be horrible enough for some ASICs to 930 implement it. When the processing is simplified as (SRv6/C- 931 MAC)(Inner-IP)(C-MAC/SRv6), it sounds like a step forward, not 932 backward, IMHO. We can achieve this goal easily inside the EVPN 933 framework, only if the data-plane learning can still be considered 934 as an option after PBB EVPN. 936 Fortunately, SRv6 is just too young to have a transplantation of PBB 937 EVPN. So it will waste nothing for the SRv6 nodes to give up the PBB 938 header that is never used by these SRv6 nodes. Note that the SRv6 939 functions (End.DT2U and End.DT2M) for L2VPNs have source-IP-based 940 data-plane learning for a long time already. 942 Although the extensions in [I-D.ietf-bess-evpn-irb-extended-mobility] 943 can't be applied to PBB EVPNs or light-weighted EVPNs. This will not 944 prevent PBB EVPNs and light-weighted EVPNs from supporting typical 945 IRB use-cases. Note that these extensions are optional. 947 6.2. Detailed Comparisons with Anycast Node SID 949 Note that SRv6 Anycast Node SID is the ultimate aggregation of ESI 950 SIDs. Such ESI SID aggregation will have some problems as described 951 in Section 5.1. 953 7. Security Considerations 955 Security considerations will be added in future versions. 957 8. IANA Considerations 959 8.1. End.DX2AGG SID 961 IANA is requested to allocate a new code points for the new SRv6 962 Endpoint Behaviors defined in this document. 964 +------+-------------+---------------+ 965 | Type | Description | Reference | 966 +------+-------------+---------------+ 967 | TBD1 | End.DX2AGG | This Document | 968 +------+-------------+---------------+ 970 Figure 4: End.DX2AGG 972 9. Acknowledgements 974 The authors would like to thank the following for their comments and 975 review of this document: 977 Ye Shu. 979 10. Normative References 981 [I-D.ietf-bess-evpn-igmp-mld-proxy] 982 Sajassi, A., Thoria, S., Mishra, M. P., Patel, K., Drake, 983 J., and W. Lin, "IGMP and MLD Proxy for EVPN", Work in 984 Progress, Internet-Draft, draft-ietf-bess-evpn-igmp-mld- 985 proxy-09, 19 April 2021, . 988 [I-D.ietf-bess-evpn-unequal-lb] 989 Malhotra, N., Sajassi, A., Rabadan, J., Drake, J., 990 Lingala, A., and S. Thoria, "Weighted Multi-Path 991 Procedures for EVPN Multi-Homing", Work in Progress, 992 Internet-Draft, draft-ietf-bess-evpn-unequal-lb-11, 7 May 993 2021, . 996 [I-D.ietf-bess-srv6-services] 997 Dawra, G., Filsfils, C., Talaulikar, K., Raszuk, R., 998 Decraene, B., Zhuang, S., and J. Rabadan, "SRv6 BGP based 999 Overlay Services", Work in Progress, Internet-Draft, 1000 draft-ietf-bess-srv6-services-07, 11 April 2021, 1001 . 1004 [I-D.sajassi-bess-evpn-ac-aware-bundling] 1005 Sajassi, A., Mishra, M., Thoria, S., Brissette, P., 1006 Rabadan, J., and J. Drake, "AC-Aware Bundling Service 1007 Interface in EVPN", Work in Progress, Internet-Draft, 1008 draft-sajassi-bess-evpn-ac-aware-bundling-03, 16 February 1009 2021, . 1012 [I-D.wang-bess-evpn-ac-df-per-evi] 1013 Wang, Y., "AC-Influenced DF Election per EVI", Work in 1014 Progress, Internet-Draft, draft-wang-bess-evpn-ac-df-per- 1015 evi-00, 7 May 2021, . 1018 [RFC7432] Sajassi, A., Ed., Aggarwal, R., Bitar, N., Isaac, A., 1019 Uttaro, J., Drake, J., and W. Henderickx, "BGP MPLS-Based 1020 Ethernet VPN", RFC 7432, DOI 10.17487/RFC7432, February 1021 2015, . 1023 [RFC7623] Sajassi, A., Ed., Salam, S., Bitar, N., Isaac, A., and W. 1024 Henderickx, "Provider Backbone Bridging Combined with 1025 Ethernet VPN (PBB-EVPN)", RFC 7623, DOI 10.17487/RFC7623, 1026 September 2015, . 1028 [RFC8317] Sajassi, A., Ed., Salam, S., Drake, J., Uttaro, J., 1029 Boutros, S., and J. Rabadan, "Ethernet-Tree (E-Tree) 1030 Support in Ethernet VPN (EVPN) and Provider Backbone 1031 Bridging EVPN (PBB-EVPN)", RFC 8317, DOI 10.17487/RFC8317, 1032 January 2018, . 1034 [RFC8584] Rabadan, J., Ed., Mohanty, S., Ed., Sajassi, A., Drake, 1035 J., Nagaraj, K., and S. Sathappan, "Framework for Ethernet 1036 VPN Designated Forwarder Election Extensibility", 1037 RFC 8584, DOI 10.17487/RFC8584, April 2019, 1038 . 1040 [RFC8986] Filsfils, C., Ed., Camarillo, P., Ed., Leddy, J., Voyer, 1041 D., Matsushima, S., and Z. Li, "Segment Routing over IPv6 1042 (SRv6) Network Programming", RFC 8986, 1043 DOI 10.17487/RFC8986, February 2021, 1044 . 1046 11. Informative References 1048 [I-D.ietf-bess-evpn-irb-extended-mobility] 1049 Malhotra, N., Sajassi, A., Pattekar, A., Rabadan, J., 1050 Lingala, A., and J. Drake, "Extended Mobility Procedures 1051 for EVPN-IRB", Work in Progress, Internet-Draft, draft- 1052 ietf-bess-evpn-irb-extended-mobility-05, 15 March 2021, 1053 . 1056 [I-D.wang-bess-evpn-egress-protection] 1057 Wang, Y. and R. Chen, "EVPN Egress Protection", Work in 1058 Progress, Internet-Draft, draft-wang-bess-evpn-egress- 1059 protection-04, 29 October 2020, 1060 . 1063 [RFC7041] Balus, F., Ed., Sajassi, A., Ed., and N. Bitar, Ed., 1064 "Extensions to the Virtual Private LAN Service (VPLS) 1065 Provider Edge (PE) Model for Provider Backbone Bridging", 1066 RFC 7041, DOI 10.17487/RFC7041, November 2013, 1067 . 1069 [RFC7348] Mahalingam, M., Dutt, D., Duda, K., Agarwal, P., Kreeger, 1070 L., Sridhar, T., Bursell, M., and C. Wright, "Virtual 1071 eXtensible Local Area Network (VXLAN): A Framework for 1072 Overlaying Virtualized Layer 2 Networks over Layer 3 1073 Networks", RFC 7348, DOI 10.17487/RFC7348, August 2014, 1074 . 1076 [RFC8365] Sajassi, A., Ed., Drake, J., Ed., Bitar, N., Shekhar, R., 1077 Uttaro, J., and W. Henderickx, "A Network Virtualization 1078 Overlay Solution Using Ethernet VPN (EVPN)", RFC 8365, 1079 DOI 10.17487/RFC8365, March 2018, 1080 . 1082 Authors' Addresses 1084 Yubao Wang 1085 ZTE Corporation 1086 No.68 of Zijinghua Road, Yuhuatai Distinct 1087 Nanjing 1088 China 1090 Email: wang.yubao2@zte.com.cn 1092 Ran Chen 1093 ZTE Corporation 1094 No. 50 Software Ave, Yuhuatai Distinct 1095 Nanjing 1096 China 1098 Email: chen.ran@zte.com.cn