idnits 2.17.1 draft-eastlake-bess-enhance-evpn-all-active-05.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 13, 2020) is 1354 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 Expires: January 12, 2021 July 13, 2020 9 EVPN All Active Usage Enhancement 10 12 Abstract 14 A principal feature of EVPN is the ability to support multihoming 15 from a customer equipment (CE) to multiple provider edge equipment 16 (PE) active with all-active links. This draft specifies an 17 improvement to load balancing such links. 19 Status of This Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Distribution of this document is unlimited. Comments should be sent 25 to the BESS working group mailing list . 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF), its areas, and its working groups. Note that 29 other groups may also distribute working documents as Internet- 30 Drafts. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 The list of current Internet-Drafts can be accessed at 38 http://www.ietf.org/1id-abstracts.html. The list of Internet-Draft 39 Shadow Directories can be accessed at 40 http://www.ietf.org/shadow.html. 42 Table of Contents 44 1. Introduction............................................3 45 1.1 Terminology and Acronyms...............................3 47 2. Improved Load Balancing.................................5 48 2.1 Problem 1: Traffic Bypassing...........................5 49 2.2 Problem 2: VID Encapsulation Confusion.................6 51 3. VLAN-Redirect-Extended Community Attribute..............7 53 4. Operation...............................................8 54 4.1 Establishment..........................................8 55 4.2 Handling Link Failure..................................8 57 5. IANA Considerations.....................................9 58 6. Security Considerations.................................9 60 Normative References......................................10 61 Informative References....................................10 63 Acknowledgements..........................................10 64 Authors' Addresses........................................11 66 1. Introduction 68 A principal feature of EVPN (Ethernet VPN [RFC7432]) is the ability 69 to support multihoming from a customer equipment (CE) to multiple 70 provider edge equipments (PEs) with links used in an all-active 71 redundancy mode. That mode is where a device is multihomed to a group 72 of two or more PEs and where all PEs in such redundancy group can 73 forward traffic to/from the multihomed device or network for a given 74 VLAN [RFC7209]. This draft specifies an improvement in load balancing 75 such PE to CE all-active multi-homing links. 77 In the case where a CE is multihomed to multiple PE nodes, using a 78 Link Aggregation Group (LAG) with All-Active redundancy, it is 79 possible that only a single PE learns a set of the MAC addresses 80 associated with traffic transmitted by the CE. This leads to a 81 situation where remote PE nodes receive MAC/IP Advertisement routes 82 for these addresses from a single PE, even though multiple PEs are 83 connected to the multihomed segment. 85 To address this issue, EVPN introduces the concept of "aliasing", 86 which is the ability of a PE to signal that it has reachability to an 87 EVPN instance (EVI) on a given Ethernet segment (ES) even when it has 88 learned no MAC addresses from that EVI/ES. The Ethernet A-D per EVI 89 route is used for this purpose. A remote PE that receives a MAC/IP 90 Advertisement route with a non-reserved ESI SHOULD consider the 91 advertised MAC address to be reachable via all PEs that have 92 advertised reachability to that MAC address's EVI/ES via the 93 combination of an Ethernet A-D per EVI route for that EVI/ES (and 94 Ethernet tag, if applicable) AND Ethernet A-D per ES routes for that 95 ES with the "Single-Active" bit in the flags of the ESI Label 96 extended community set to 0. 98 1.1 Terminology and Acronyms 100 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 101 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 102 "OPTIONAL" in this document are to be interpreted as described in BCP 103 14 [RFC2119] [RFC8174] when, and only when, they appear in all 104 capitals, as shown here. 106 This document uses the following acronyms and terms: 108 A-D - Auto Discovery. 110 All-Active Redundancy Mode - When a device is multihomed to a group 111 of two or more PEs and when all PEs in such redundancy group can 112 forward traffic to/from the multihomed device or network for a 113 given VLAN. 115 CE - Customer Edge equipment. 117 ES - Ethernet Segment. 119 ESI - Ethernet Segment Identifier. 121 EVI - EVPN Instance. 123 EVPN - Ethernet VPN [RFC7432]. 125 FRR - Fast ReRoute. 127 MAC - Media Access Control. 129 PE - Provider Edge equipment. 131 Single-Active Redundancy Mode - When a device or a network is 132 multihomed to a group of two or more PEs and when only a single PE 133 in such a redundancy group can forward traffic to/from the 134 multihomed device or network for a given VLAN. 136 VLAN - Virtual Local Area Network 138 VPN - Virtual Private Network. 140 2. Improved Load Balancing 142 Consider the example in Figure 1. CE1 is multihomed to PE1 and PE2. 143 CE1 typically uses a hash algorithm to determine whether to send a 144 particular traffic to PE1 or to PE2. Thus, if such traffic from CE1 145 is only sent to PE1, then PE1 will learn CE1's MAC address(es) and 146 that PE2 will not. 148 PE3 and PE4 can do aliasing [RFC7432] because PE1 and PE2 will be 149 advertising the same ESI. Thus PE3 and PE4 will expect that a MAC 150 address reachable from PE1 will also be reachable from PE2. This 151 aliasing will cause PE3 and PE4 to load balance to CE1's MAC(s), 152 sending some traffic to PE1 and some to PE2. 154 ......... 155 +----------+ . . +----------+ 156 | PE1 MAC +------+ +------+ PE3 | 157 | Learning | . . | | 158 +----------+ . . +----------+ 159 / ^ . . | \ 160 +---+ | . EVPN . | +---+ 161 |CE1| | . MPLS . | |CE2| 162 +---+ | . . | +---+ 163 \ | . . | / 164 +----------+ . . +----------+ 165 | PE2 | . . | PE4 | 166 | +------+ +------+ | 167 +----------+ . . +----------+ 168 ......... 170 Figure 1. Current Situation 172 There are two problems associated with this situation that are 173 described in the subsections below. Section 3 describes the 174 mechanism to address these problems. 176 2.1 Problem 1: Traffic Bypassing 178 Since PE2 has not learning CE1's MAC(s), the MAC lookup at PE2 will 179 find that MAC address associated with PE1. PE2 will then tunnel the 180 traffic to PE1. 182 As an enhancement that solves this problem, PE1 can send MAC 183 address(es) with VLAN and ESI information. PE2 will then receive the 184 MAC address(es) and VLAN that PE1 associates with the ESI and PE2 can 185 use this to update its forwarding tables (see Figure 2). As a result, 186 when traffic addressed to a CE1 MAC arrives at PE2, it can send it on 187 the appropriate local interface and VLAN. This avoids the unnecessary 188 extra hop through PE1 for such traffic arriving at PE2. 190 ......... 191 +----------+ . . +----------+ 192 | PE1 MAC +------+ +------+ PE3 | 193 | Learning | . . | | 194 +----------+ . . +----------+ 195 / ^ . . | \ 196 +---+ | . EVPN . | +---+ 197 |CE1| Sy|nc . MPLS . | |CE2| 198 +---+ | . . | +---+ 199 \ v . . | / 200 +----------+ . . +----------+ 201 | PE2 | . . | PE4 | 202 | +------+ +------+ | 203 +----------+ . . +----------+ 204 ......... 206 Figure 2. With Enhancement 208 2.2 Problem 2: VID Encapsulation Confusion 210 If CE1 is connected through a VLAN and has only one VLAN under the 211 EVPN instance of PE2, the unicast traffic can be directly sent to the 212 appropriate interface and encapsulated with the appropriate VID and 213 forwarded to CE1. 215 However, there may be multiple ways for CE1 to connect to PE1 and 216 PE2, including Ethernet Tag, Ethernet Tag termination, and Q-in-Q. 217 PE2 cannot always obtain the appropriate VLANs and in such cases PE2 218 is missing the information needed to forward the unicast traffic to 219 CE1 directly. 221 3. VLAN-Redirect-Extended Community Attribute 223 This document defines a new BGP extended community attribute called 224 the VLAN-Redirect-Extended Community attribute as shown in Figure 3. 226 0 1 2 3 227 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 228 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 229 | 0x06 | Sub-Type=TBA | Flags | Reserved | 230 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 231 | S-VLAN | C-VLAN | 232 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 234 Figure 3. VLAN-Redirect-Extended Community Attribute 236 Where: 238 0x06: EVPN Extended Community Type field. 240 Sub-Type: Sub-Type field indicating that the extended community 241 attribute is a VLAN-Redirect-Extended Community attribute, and 242 the value is TBA as assigned by the IANA. 244 Flags: 8 bits of identification information. Bit 0 set to 0 245 indicates that the action is redirected to the VLANs in this 246 community 248 Reserved: Not used. MUST be sent as zero and ignored on receipt. 250 S-VLAN: Outer VLAN information, can not be 0, 0 is illegal value 252 C-VLAN: Inner VLAN information. When 0, it means there is no C- 253 VLAN. 255 4. Operation 257 Operation with the solution specified in Section 3 and the topology 258 shown in Figure 2 is described below. 260 4.1 Establishment 262 1. PE1 learns MAC addresses from CE1, advertises them to PE2, carries 263 the ESI value as ES1 and the next hop as PE1, and carries the 264 VLAN-Redirect-Extended Community attributes. 266 2. PE2 receives the MAC route advertised by PE1 and finds the 267 interface that connects to CE1 locally according to the ESI value. 268 At the same time, PE2 fills in the VLAN information according to 269 the VLAN-Redirect-Extended Community attributes 271 3. At the same time, PE2 generates a fast reroute (FRR) entry 272 according to the next hop information (PE1) of the MAC route, that 273 is, a MAC address entry on PE2, where the primary path points to 274 the CE1 link and the standby path points to PE1 276 4. PE2 also sends the MAC as a local MAC route to PE1 278 5. PE1 receives the MAC route advertised by PE2 and generates the FRR 279 entry with the MAC route learned by CE1, that is, the MAC address 280 entry on PE1, with the primary path pointing to the CE1 link and 281 the secondary path pointing to PE2 283 4.2 Handling Link Failure 285 1. When the link between PE1 and CE1 fails, PE1 withdraws the MAC 286 address that advertised to PE2 288 2. PE2 receives the MAC withdrawal from PE1, does not delete the MAC 289 immediately, but starts an aging timer, and does not withdraw the 290 MAC address that PE1 advertised to PE2. 292 3. When the aging timer expires, if PE2 cannot receive the traffic 293 from CE1, then PE2 withdraws the MAC address that was advertised 294 to PE2 by PE1 and deletes the MAC entry. If PE2 can communicate 295 directly with CE1, it just eliminates the FRR standby path to PE1. 297 5. IANA Considerations 299 IANA is requested to assign a new EVPN Extended Community SubType as 300 follows: 302 Sub-Type Value Name Reference 303 -------------- -------------------------------- ---------- 304 TBA VLAN-Redirect Extended Community [this doc] 306 6. Security Considerations 308 TBD 310 For general EVPN Security Considerations, see [RFC7432]. 312 Normative References 314 [RFC2119] - Bradner, S., "Key words for use in RFCs to Indicate 315 Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, 316 March 1997, . 318 [RFC7432] - Sajassi, A., Ed., Aggarwal, R., Bitar, N., Isaac, A., 319 Uttaro, J., Drake, J., and W. Henderickx, "BGP MPLS-Based 320 Ethernet VPN", RFC 7432, DOI 10.17487/RFC7432, February 2015, 321 . 323 [RFC8174] - Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 324 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 325 2017, . 327 Informative References 329 [RFC7209] - Sajassi, A., Aggarwal, R., Uttaro, J., Bitar, N., 330 Henderickx, W., and A. Isaac, "Requirements for Ethernet VPN 331 (EVPN)", RFC 7209, DOI 10.17487/RFC7209, May 2014, 332 . 334 Acknowledgements 336 The authors of this document would like to thank the following for 337 their comments and review of this document: 339 TBD 341 Authors' Addresses 343 Donald E. Eastlake, 3rd 344 Futurewei Technologies 345 2386 Panoramic Circle 346 Apopka, FL 32703 USA 348 Phone: +1-508-333-2270 349 Email: d3e3e3@gmail.com 351 Zhenbin Li 352 Huawei Technologies 353 Huawei Bldg., No. 156 Beiqing Road 354 Beijing 100095 China 356 Email: lizhenbin@huawei.com 358 Shunwan Zhang 359 Huawei Technologies 360 Huawei Bldg., No. 156 Beiqing Road 361 Beijing 100095 China 363 Email: zhuangshunwan@huawei.com 365 Haibo Wang 366 Huawei Technologies 367 Huawei Bldg., No. 156 Beiqing Road 368 Beijing 100095 China 370 Email: rainsword.wang@huawei.com 372 Copyright, Disclaimer, and Additional IPR Provisions 374 Copyright (c) 2020 IETF Trust and the persons identified as the 375 document authors. All rights reserved. 377 This document is subject to BCP 78 and the IETF Trust's Legal 378 Provisions Relating to IETF Documents 379 (http://trustee.ietf.org/license-info) in effect on the date of 380 publication of this document. Please review these documents 381 carefully, as they describe your rights and restrictions with respect 382 to this document. Code Components extracted from this document must 383 include Simplified BSD License text as described in Section 4.e of 384 the Trust Legal Provisions and are provided without warranty as 385 described in the Simplified BSD License. The definitive version of 386 an IETF Document is that published by, or under the auspices of, the 387 IETF. Versions of IETF Documents that are published by third parties, 388 including those that are translated into other languages, should not 389 be considered to be definitive versions of IETF Documents. The 390 definitive version of these Legal Provisions is that published by, or 391 under the auspices of, the IETF. Versions of these Legal Provisions 392 that are published by third parties, including those that are 393 translated into other languages, should not be considered to be 394 definitive versions of these Legal Provisions. For the avoidance of 395 doubt, each Contributor to the IETF Standards Process licenses each 396 Contribution that he or she makes as part of the IETF Standards 397 Process to the IETF Trust pursuant to the provisions of RFC 5378. No 398 language to the contrary, or terms, conditions or rights that differ 399 from or are inconsistent with the rights and licenses granted under 400 RFC 5378, shall have any effect and shall be null and void, whether 401 published or posted by such Contributor, or included with or in such 402 Contribution.