idnits 2.17.1 draft-eastlake-bess-enhance-evpn-all-active-08.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 (December 31, 2021) is 845 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) No issues found here. Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET-DRAFT D. Eastlake 2 Intended status: Proposed Standard Futurewei Technologies 3 Z. Li 4 S. Zhuang 5 H. Wang 6 Huawei Technologies 7 R. White 8 Juniper Networks 9 Expires: June 30, 2022 December 31, 2021 11 EVPN All Active Usage Enhancement 12 14 Abstract 16 A principal feature of EVPN is the ability to support multihoming 17 from a customer equipment (CE) to multiple provider edge equipment 18 (PE) active with all-active links. This draft specifies an 19 improvement to load balancing such links. 21 Status of This Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Distribution of this document is unlimited. Comments should be sent 27 to the BESS working group mailing list . 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF), its areas, and its working groups. Note that 31 other groups may also distribute working documents as Internet- 32 Drafts. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 The list of current Internet-Drafts can be accessed at 40 https://www.ietf.org/1id-abstracts.html. The list of Internet-Draft 41 Shadow Directories can be accessed at 42 https://www.ietf.org/shadow.html. 44 Table of Contents 46 1. Introduction............................................3 47 1.1 Terminology and Acronyms...............................3 49 2. Improved Load Balancing.................................5 50 2.1 Problem 1: Traffic Bypassing...........................5 51 2.2 Problem 2: VID Encapsulation Confusion.................6 53 3. VLAN-Redirect-Extended Community Attribute..............7 55 4. Operation...............................................8 56 4.1 Establishment..........................................8 57 4.2 Handling Link Failure..................................8 59 5. IANA Considerations.....................................9 60 6. Security Considerations.................................9 62 Normative References......................................10 63 Informative References....................................10 65 Acknowledgements..........................................10 67 Authors' Addresses........................................11 69 1. Introduction 71 A principal feature of EVPN (Ethernet VPN [RFC7432]) is the ability 72 to support multihoming from a customer equipment (CE) to multiple 73 provider edge equipments (PEs) with links used in an all-active 74 redundancy mode. That mode is where a device is multihomed to a group 75 of two or more PEs and where all PEs in such redundancy group can 76 forward traffic to/from the multihomed device or network for a given 77 VLAN [RFC7209]. This draft specifies an improvement in load balancing 78 such PE to CE all-active multi-homing links. 80 In the case where a CE is multihomed to multiple PE nodes, using a 81 Link Aggregation Group (LAG) with All-Active redundancy, it is 82 possible that only a single PE learns a set of the MAC addresses 83 associated with traffic transmitted by the CE. This leads to a 84 situation where remote PE nodes receive MAC/IP Advertisement routes 85 for these addresses from a single PE, even though multiple PEs are 86 connected to the multihomed segment. 88 To address this issue, EVPN introduces the concept of "aliasing", 89 which is the ability of a PE to signal that it has reachability to an 90 EVPN instance (EVI) on a given Ethernet segment (ES) even when it has 91 learned no MAC addresses from that EVI/ES. The Ethernet A-D per EVI 92 route is used for this purpose. A remote PE that receives a MAC/IP 93 Advertisement route with a non-reserved ESI SHOULD consider the 94 advertised MAC address to be reachable via all PEs that have 95 advertised reachability to that MAC address's EVI/ES via the 96 combination of an Ethernet A-D per EVI route for that EVI/ES (and 97 Ethernet tag, if applicable) AND Ethernet A-D per ES routes for that 98 ES with the "Single-Active" bit in the flags of the ESI Label 99 extended community set to 0. 101 1.1 Terminology and Acronyms 103 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 104 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 105 "OPTIONAL" in this document are to be interpreted as described in BCP 106 14 [RFC2119] [RFC8174] when, and only when, they appear in all 107 capitals, as shown here. 109 This document uses the following acronyms and terms: 111 A-D - Auto Discovery. 113 All-Active Redundancy Mode - When a device is multihomed to a group 114 of two or more PEs and when all PEs in such redundancy group can 115 forward traffic to/from the multihomed device or network for a 116 given VLAN. 118 CE - Customer Edge equipment. 120 ES - Ethernet Segment. 122 ESI - Ethernet Segment Identifier. 124 EVI - EVPN Instance. 126 EVPN - Ethernet VPN [RFC7432]. 128 FRR - Fast ReRoute. 130 MAC - Media Access Control. 132 PE - Provider Edge equipment. 134 Single-Active Redundancy Mode - When a device or a network is 135 multihomed to a group of two or more PEs and when only a single PE 136 in such a redundancy group can forward traffic to/from the 137 multihomed device or network for a given VLAN. 139 VLAN - Virtual Local Area Network 141 VPN - Virtual Private Network. 143 2. Improved Load Balancing 145 Consider the example in Figure 1. CE1 is multihomed to PE1 and PE2. 146 CE1 typically uses a hash algorithm to determine whether to send a 147 particular traffic to PE1 or to PE2. Thus, if such traffic from CE1 148 is only sent to PE1, then PE1 will learn CE1's MAC address(es) and 149 that PE2 will not. 151 PE3 and PE4 can do aliasing [RFC7432] because PE1 and PE2 will be 152 advertising the same ESI. Thus PE3 and PE4 will expect that a MAC 153 address reachable from PE1 will also be reachable from PE2. This 154 aliasing will cause PE3 and PE4 to load balance to CE1's MAC(s), 155 sending some traffic to PE1 and some to PE2. 157 ......... 158 +----------+ . . +----------+ 159 | PE1 MAC +------+ +------+ PE3 | 160 | Learning | . . | | 161 +----------+ . . +----------+ 162 / ^ . . | \ 163 +---+ | . EVPN . | +---+ 164 |CE1| | . MPLS . | |CE2| 165 +---+ | . . | +---+ 166 \ | . . | / 167 +----------+ . . +----------+ 168 | PE2 | . . | PE4 | 169 | +------+ +------+ | 170 +----------+ . . +----------+ 171 ......... 173 Figure 1. Current Situation 175 There are two problems associated with this situation that are 176 described in the subsections below. Section 3 describes the 177 mechanism to address these problems. 179 2.1 Problem 1: Traffic Bypassing 181 Since PE2 has not learning CE1's MAC(s), the MAC lookup at PE2 will 182 find that MAC address associated with PE1. PE2 will then tunnel the 183 traffic to PE1. 185 As an enhancement that solves this problem, PE1 can send MAC 186 address(es) with VLAN and ESI information. PE2 will then receive the 187 MAC address(es) and VLAN that PE1 associates with the ESI and PE2 can 188 use this to update its forwarding tables (see Figure 2). As a result, 189 when traffic addressed to a CE1 MAC arrives at PE2, it can send it on 190 the appropriate local interface and VLAN. This avoids the unnecessary 191 extra hop through PE1 for such traffic arriving at PE2. 193 ......... 194 +----------+ . . +----------+ 195 | PE1 MAC +------+ +------+ PE3 | 196 | Learning | . . | | 197 +----------+ . . +----------+ 198 / ^ . . | \ 199 +---+ | . EVPN . | +---+ 200 |CE1| Sy|nc . MPLS . | |CE2| 201 +---+ | . . | +---+ 202 \ v . . | / 203 +----------+ . . +----------+ 204 | PE2 | . . | PE4 | 205 | +------+ +------+ | 206 +----------+ . . +----------+ 207 ......... 209 Figure 2. With Enhancement 211 2.2 Problem 2: VID Encapsulation Confusion 213 If CE1 is connected through a VLAN and has only one VLAN under the 214 EVPN instance of PE2, the unicast traffic can be directly sent to the 215 appropriate interface and encapsulated with the appropriate VID and 216 forwarded to CE1. 218 However, there may be multiple ways for CE1 to connect to PE1 and 219 PE2, including Ethernet Tag, Ethernet Tag termination, and Q-in-Q. 220 PE2 cannot always obtain the appropriate VLANs and in such cases PE2 221 is missing the information needed to forward the unicast traffic to 222 CE1 directly. 224 3. VLAN-Redirect-Extended Community Attribute 226 This document defines a new BGP extended community attribute called 227 the VLAN-Redirect-Extended Community attribute as shown in Figure 3. 229 0 1 2 3 230 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 231 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 232 | 0x06 | Sub-Type=TBA | Flags | Reserved | 233 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 234 | S-VLAN | C-VLAN | 235 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 237 Figure 3. VLAN-Redirect-Extended Community Attribute 239 Where: 241 0x06: EVPN Extended Community Type field. 243 Sub-Type: Sub-Type field indicating that the extended community 244 attribute is a VLAN-Redirect-Extended Community attribute, and 245 the value is TBA as assigned by the IANA. 247 Flags: 8 bits of identification information. Bit 0 set to 0 248 indicates that the action is redirected to the VLANs in this 249 community 251 Reserved: Not used. MUST be sent as zero and ignored on receipt. 253 S-VLAN: Outer VLAN information. MUST NOT be 0 or 0xFFFF. If it is 254 one of those values, which are not valid VLAN IDs, the 255 attribute is ignored. 257 C-VLAN: Inner VLAN information. When 0, it means there is no C- 258 VLAN. MUST NOT be 0xFFFF, which is not a valid VLAN ID. If it 259 is that illegal value, the attribute is ignored. 261 4. Operation 263 Operation with the solution specified in Section 3 and the topology 264 shown in Figure 2 is described below. 266 4.1 Establishment 268 1. PE1 learns MAC addresses from CE1, advertises them to PE2, carries 269 the ESI value as ES1 and the next hop as PE1, and carries the 270 VLAN-Redirect-Extended Community attributes. 272 2. PE2 receives the MAC route advertised by PE1 and finds the 273 interface that connects to CE1 locally according to the ESI value. 274 At the same time, PE2 fills in the VLAN information according to 275 the VLAN-Redirect-Extended Community attributes. 277 3. At the same time, PE2 generates a fast reroute (FRR) entry 278 according to the next hop information (PE1) of the MAC route, that 279 is, a MAC address entry on PE2, where the primary path points to 280 the CE1 link and the standby path points to PE1. 282 4. PE2 also sends the MAC as a local MAC route to PE1. 284 5. PE1 receives the MAC route advertised by PE2 and generates the FRR 285 entry with the MAC route learned by CE1, that is, the MAC address 286 entry on PE1, with the primary path pointing to the CE1 link and 287 the secondary path pointing to PE2. 289 4.2 Handling Link Failure 291 1. When the link between PE1 and CE1 fails, PE1 withdraws the MAC 292 address that PE1 advertised to PE2. 294 2. PE2 receives the MAC withdrawal from PE1, does not delete the MAC 295 immediately, but starts an aging timer, and does not withdraw the 296 MAC address that PE1 advertised to PE2. 298 3. When the aging timer expires, if PE2 cannot receive the traffic 299 from CE1, then PE2 withdraws the MAC address that was advertised 300 to PE2 by PE1 and deletes the MAC entry. If PE2 can communicate 301 directly with CE1, it just eliminates the FRR standby path to PE1. 303 5. IANA Considerations 305 IANA is requested to assign a new EVPN Extended Community SubType as 306 follows: 308 Sub-Type Value Name Reference 309 -------------- -------------------------------- ---------- 310 TBA VLAN-Redirect Extended Community [this doc] 312 6. Security Considerations 314 TBD 316 For general EVPN Security Considerations, see [RFC7432]. 318 Normative References 320 [RFC2119] - Bradner, S., "Key words for use in RFCs to Indicate 321 Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, 322 March 1997, . 324 [RFC7432] - Sajassi, A., Ed., Aggarwal, R., Bitar, N., Isaac, A., 325 Uttaro, J., Drake, J., and W. Henderickx, "BGP MPLS-Based 326 Ethernet VPN", RFC 7432, DOI 10.17487/RFC7432, February 2015, 327 . 329 [RFC8174] - Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 330 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 331 2017, . 333 Informative References 335 [RFC7209] - Sajassi, A., Aggarwal, R., Uttaro, J., Bitar, N., 336 Henderickx, W., and A. Isaac, "Requirements for Ethernet VPN 337 (EVPN)", RFC 7209, DOI 10.17487/RFC7209, May 2014, 338 . 340 Acknowledgements 342 The authors of this document would like to thank the following for 343 their comments and review of this document: 345 TBD 347 Authors' Addresses 349 Donald E. Eastlake, 3rd 350 Futurewei Technologies 351 2386 Panoramic Circle 352 Apopka, FL 32703 USA 354 Phone: +1-508-333-2270 355 Email: d3e3e3@gmail.com 357 Zhenbin Li 358 Huawei Technologies 359 Huawei Bldg., No. 156 Beiqing Road 360 Beijing 100095 China 362 Email: lizhenbin@huawei.com 364 Shunwan Zhang 365 Huawei Technologies 366 Huawei Bldg., No. 156 Beiqing Road 367 Beijing 100095 China 369 Email: zhuangshunwan@huawei.com 371 Haibo Wang 372 Huawei Technologies 373 Huawei Bldg., No. 156 Beiqing Road 374 Beijing 100095 China 376 Email: rainsword.wang@huawei.com 378 Russ White 379 Juniper Networks 381 Email: russ@riw.us 383 Copyright, Disclaimer, and Additional IPR Provisions 385 Copyright (c) 2021 IETF Trust and the persons identified as the 386 document authors. All rights reserved. 388 This document is subject to BCP 78 and the IETF Trust's Legal 389 Provisions Relating to IETF Documents 390 (http://trustee.ietf.org/license-info) in effect on the date of 391 publication of this document. Please review these documents 392 carefully, as they describe your rights and restrictions with respect 393 to this document. Code Components extracted from this document must 394 include Simplified BSD License text as described in Section 4.e of 395 the Trust Legal Provisions and are provided without warranty as 396 described in the Simplified BSD License. The definitive version of 397 an IETF Document is that published by, or under the auspices of, the 398 IETF. Versions of IETF Documents that are published by third parties, 399 including those that are translated into other languages, should not 400 be considered to be definitive versions of IETF Documents. The 401 definitive version of these Legal Provisions is that published by, or 402 under the auspices of, the IETF. Versions of these Legal Provisions 403 that are published by third parties, including those that are 404 translated into other languages, should not be considered to be 405 definitive versions of these Legal Provisions. For the avoidance of 406 doubt, each Contributor to the IETF Standards Process licenses each 407 Contribution that he or she makes as part of the IETF Standards 408 Process to the IETF Trust pursuant to the provisions of RFC 5378. No 409 language to the contrary, or terms, conditions or rights that differ 410 from or are inconsistent with the rights and licenses granted under 411 RFC 5378, shall have any effect and shall be null and void, whether 412 published or posted by such Contributor, or included with or in such 413 Contribution.