idnits 2.17.1 draft-eastlake-bess-enhance-evpn-all-active-04.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 (January 15, 2020) is 1563 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: July 14, 2020 January 15, 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 62 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 VPN - Virtual Private Network. 138 2. Improved Load Balancing 140 Consider the example in Figure 1. CE1 is multihomed to PE1 and PE2. 141 CE1 typically uses a hash algorithm to determine whether to send a 142 particular traffic to PE1 or to PE2. Thus, if such traffic from CE1 143 is only sent to PE1, then PE1 will learn CE1's MAC address(es) and 144 that PE2 will not. 146 PE3 and PE4 can do aliasing [RFC7432] because PE1 and PE2 will be 147 advertising the same ESI. Thus PE3 and PE4 will expect that a MAC 148 address reachable from PE1 will also be reachable from PE2. This 149 aliasing will cause PE3 and PE4 to load balance to CE1's MAC(s), 150 sending some traffic to PE1 and some to PE2. 152 ......... 153 +----------+ . . +----------+ 154 | PE1 MAC +------+ +------+ PE3 | 155 | Learning | . . | | 156 +----------+ . . +----------+ 157 / ^ . . | \ 158 +---+ | . EVPN . | +---+ 159 |CE1| | . MPLS . | |CE2| 160 +---+ | . . | +---+ 161 \ | . . | / 162 +----------+ . . +----------+ 163 | PE2 | . . | PE4 | 164 | +------+ +------+ | 165 +----------+ . . +----------+ 166 ......... 168 Figure 1. Current Situation 170 There are two problems associated with this situation that are 171 described in the subsections below. Section 3 describes the 172 mechanism to address these problems. 174 2.1 Problem 1: Traffic Bypassing 176 Since PE2 has not learning CE1's MAC(s), the MAC lookup at PE2 will 177 find that MAC address associated with PE1. PE2 will then tunnel the 178 traffic to PE1. 180 As an enhancement that solves this problem, PE1 can send MAC 181 address(es) with VLAN and ESI information. PE2 will then receive the 182 MAC address(es) and VLAN that PE1 associates with the ESI and PE2 can 183 use this to update its forwarding tables (see Figure 2). As a result, 184 when traffic addressed to a CE1 MAC arrives at PE2, it can send it on 185 the appropriate local interface and VLAN. This avoids the unnecessary 186 extra hop through PE1 for such traffic arriving at PE2. 188 ......... 189 +----------+ . . +----------+ 190 | PE1 MAC +------+ +------+ PE3 | 191 | Learning | . . | | 192 +----------+ . . +----------+ 193 / ^ . . | \ 194 +---+ | . EVPN . | +---+ 195 |CE1| Sy|nc . MPLS . | |CE2| 196 +---+ | . . | +---+ 197 \ v . . | / 198 +----------+ . . +----------+ 199 | PE2 | . . | PE4 | 200 | +------+ +------+ | 201 +----------+ . . +----------+ 202 ......... 204 Figure 2. With Enhancement 206 2.2 Problem 2: VID Encapsulation Confusion 208 If CE1 is connected through a VLAN and has only one VLAN under the 209 EVPN instance of PE2, the unicast traffic can be directly sent to the 210 appropriate interface and encapsulated with the appropriate VID and 211 forwarded to CE1. 213 However, there may be multiple ways for CE1 to connect to PE1 and 214 PE2, including Ethernet Tag, Ethernet Tag termination, and Q-in-Q. 215 PE2 cannot always obtain the appropriate VLANs and in such cases PE2 216 is missing the information needed to forward the unicast traffic to 217 CE1 directly. 219 3. VLAN-Redirect-Extended Community Attribute 221 This document defines a new BGP extended community attribute called 222 the VLAN-Redirect-Extended Community attribute as shown in Figure 3. 224 0 1 2 3 225 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 226 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 227 | 0x06 | Sub-Type=TBA | Flags | Reserved | 228 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 229 | S-VLAN | C-VLAN | 230 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 232 Figure 3. VLAN-Redirect-Extended Community Attribute 234 Where: 236 0x06: EVPN Extended Community Type field. 238 Sub-Type: Sub-Type field indicating that the extended community 239 attribute is a VLAN-Redirect-Extended Community attribute, and 240 the value is TBA as assigned by the IANA. 242 Flags: 8 bits of identification information. Bit 0 set to 0 243 indicates that the action is redirected to the VLANs in this 244 community 246 Reserved: Not used. MUST be sent as zero and ignored on receipt. 248 S-VLAN: Outer VLAN information, can not be 0, 0 is illegal value 250 C-VLAN: Inner VLAN information. When 0, it means there is no C- 251 VLAN. 253 4. Operation 255 Operation with the solution specified in Section 3 and the topology 256 shown in Figure 2 is described below. 258 4.1 Establishment 260 1. PE1 learns MAC addresses from CE1, advertises them to PE2, carries 261 the ESI value as ES1 and the next hop as PE1, and carries the 262 VLAN- Redirect-Extended Community attributes. 264 2. PE2 receives the MAC route advertised by PE1 and finds the 265 interface that connects to CE1 locally according to the ESI value. 266 At the same time, PE2 fills in the VLAN information according to 267 the VLAN-Redirect-Extended Community attributes 269 3. At the same time, PE2 generates a fast reroute (FRR) entry 270 according to the next hop information (PE1) of the MAC route, that 271 is, a MAC address entry on PE2, where the primary path points to 272 the CE1 link and the standby path points to PE1 274 4. PE2 also sends the MAC as a local MAC route to PE1 276 5. PE1 receives the MAC route advertised by PE2 and generates the FRR 277 entry with the MAC route learned by CE1, that is, the MAC address 278 entry on PE1, with the primary path pointing to the CE1 link and 279 the secondary path pointing to PE2 281 4.2 Handling Link Failure 283 1. When the link between PE1 and CE1 fails, PE1 withdraws the MAC 284 address that advertised to PE2 286 2. PE2 receives the MAC withdrawal from PE1, does not delete the MAC 287 immediately, but starts an aging timer, and does not withdraw the 288 MAC address that PE1 advertised to PE2. 290 3. When the aging timer expires, if PE2 cannot receive the traffic 291 from CE1, then PE2 withdraws the MAC address that was advertised 292 to PE2 by PE1 and deletes the MAC entry. If PE2 can communicate 293 directly with CE1, it just eliminates the FRR standby path to PE1. 295 5. IANA Considerations 297 IANA is requested to assign a new EVPN Extended Community SubType as 298 follows: 300 Sub-Type Value Name Reference 301 -------------- -------------------------------- ---------- 302 TBA VLAN-Redirect Extended Community [this doc] 304 6. Security Considerations 306 TBD 308 For general EVPN Security Considerations, see [RFC7432]. 310 Normative References 312 [RFC2119] - Bradner, S., "Key words for use in RFCs to Indicate 313 Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, 314 March 1997, . 316 [RFC7432] - Sajassi, A., Ed., Aggarwal, R., Bitar, N., Isaac, A., 317 Uttaro, J., Drake, J., and W. Henderickx, "BGP MPLS-Based 318 Ethernet VPN", RFC 7432, DOI 10.17487/RFC7432, February 2015, 319 . 321 [RFC8174] - Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 322 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 323 2017, . 325 Informative References 327 [RFC7209] - Sajassi, A., Aggarwal, R., Uttaro, J., Bitar, N., 328 Henderickx, W., and A. Isaac, "Requirements for Ethernet VPN 329 (EVPN)", RFC 7209, DOI 10.17487/RFC7209, May 2014, 330 . 332 Acknowledgements 334 The authors of this document would like to thank the following for 335 their comments and review of this document: 337 TBD 339 Authors' Addresses 341 Donald E. Eastlake, 3rd 342 Futurewei Technologies 343 2386 Panoramic Circle 344 Apopka, FL 32703 USA 346 Phone: +1-508-333-2270 347 Email: d3e3e3@gmail.com 349 Zhenbin Li 350 Huawei Technologies 351 Huawei Bldg., No. 156 Beiqing Road 352 Beijing 100095 China 354 Email: lizhenbin@huawei.com 356 Shunwan Zhang 357 Huawei Technologies 358 Huawei Bldg., No. 156 Beiqing Road 359 Beijing 100095 China 361 Email: zhuangshunwan@huawei.com 363 Haibo Wang 364 Huawei Technologies 365 Huawei Bldg., No. 156 Beiqing Road 366 Beijing 100095 China 368 Email: rainsword.wang@huawei.com 370 Copyright, Disclaimer, and Additional IPR Provisions 372 Copyright (c) 2020 IETF Trust and the persons identified as the 373 document authors. All rights reserved. 375 This document is subject to BCP 78 and the IETF Trust's Legal 376 Provisions Relating to IETF Documents 377 (http://trustee.ietf.org/license-info) in effect on the date of 378 publication of this document. Please review these documents 379 carefully, as they describe your rights and restrictions with respect 380 to this document. Code Components extracted from this document must 381 include Simplified BSD License text as described in Section 4.e of 382 the Trust Legal Provisions and are provided without warranty as 383 described in the Simplified BSD License. The definitive version of 384 an IETF Document is that published by, or under the auspices of, the 385 IETF. Versions of IETF Documents that are published by third parties, 386 including those that are translated into other languages, should not 387 be considered to be definitive versions of IETF Documents. The 388 definitive version of these Legal Provisions is that published by, or 389 under the auspices of, the IETF. Versions of these Legal Provisions 390 that are published by third parties, including those that are 391 translated into other languages, should not be considered to be 392 definitive versions of these Legal Provisions. For the avoidance of 393 doubt, each Contributor to the IETF Standards Process licenses each 394 Contribution that he or she makes as part of the IETF Standards 395 Process to the IETF Trust pursuant to the provisions of RFC 5378. No 396 language to the contrary, or terms, conditions or rights that differ 397 from or are inconsistent with the rights and licenses granted under 398 RFC 5378, shall have any effect and shall be null and void, whether 399 published or posted by such Contributor, or included with or in such 400 Contribution.