idnits 2.17.1 draft-eastlake-bess-enhance-evpn-all-active-00.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 (March 3, 2018) is 2239 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 TRILL Working Group Donald Eastlake 2 INTERNET-DRAFT Zhenbin Li 3 Shunwan Zhuang 4 Haibo Wang 5 Huawei 6 Intended status: Proposed Standard 7 Expires: September 2, 2018 March 3, 2018 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 to IETF 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 is the ability to support multihoming 69 from a customer equipment (CE) to multiple provider edge equipment 70 (PE) with links used in an all-active redundancy mode. That mode is 71 where a device is multihomed to a group of two or more PEs and where 72 all PEs in such redundancy group can forward traffic to/from the 73 multihomed device or network for a given VLAN [RFC7209]. This draft 74 specifies an improvement in load balancing such PE to CE all-active 75 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 (Ethernet VPN [RFC7432]) introduces the 86 concept of "aliasing", which is the ability of a PE to signal that it 87 has reachability to an EVPN instance (EVI) on a given Ethernet 88 segment (ES) even when it has learned no MAC addresses from that 89 EVI/ES. The Ethernet A-D per EVI route is used for this purpose. A 90 remote PE that receives a MAC/IP Advertisement route with a non- 91 reserved ESI SHOULD consider the advertised MAC address to be 92 reachable via all PEs that have advertised reachability to that MAC 93 address's EVI/ES via the combination of an Ethernet A-D per EVI route 94 for that EVI/ES (and Ethernet tag, if applicable) AND Ethernet A-D 95 per ES routes for that ES with the "Single-Active" bit in the flags 96 of the ESI Label 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. 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 taffic from CE1 is 143 only sent to PE1, then PE1 will learn CE1's MAC address(es) and that 144 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 traffice 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 Situtation 170 There are two problems associated with this situation. Section 3 171 describes the mechanism to address these problems. 173 2.1 Problem 1: Traffic Bypassing 175 Since PE2 has not learning CE1's MAC(s), the MAC lookup at PE2 will 176 find that MAC address associated with PE1. PE2 will then tunnel the 177 traffic to PE1. 179 As an enchancement that solves this problem, PE1 can send MAC 180 address(es) with VLAN and ESI information. PE2 will then receive the 181 MAC address(es) and VLAN that PE1 associates with the ESI and can use 182 this to update its forwarding tables. (See Figure 2.) As a result, 183 when traffic addressed to a CE1 MAC arrives at PE2, it can send it on 184 the appropriate local interface and VLAN. This avoids the unncessary 185 extra hop through PE1 for such traffic arriving at PE2. 187 ......... 188 +----------+ . . +----------+ 189 | PE1 MAC +------+ +------+ PE3 | 190 | Learning | . . | | 191 +----------+ . . +----------+ 192 / ^ . . | \ 193 +---+ | . EVPN . | +---+ 194 |CE1| Sy|nc . MPLS . | |CE2| 195 +---+ | . . | +---+ 196 \ v . . | / 197 +----------+ . . +----------+ 198 | PE2 | . . | PE4 | 199 | +------+ +------+ | 200 +----------+ . . +----------+ 201 ......... 203 Figure 2. With Enhancement 205 2.2 Problem 2: VID Encapsulation Confusion 207 If CE1 is connected through a VLAN and has only one VLAN under the 208 EVPN instance of PE2, the unicast traffic can be directly sent to the 209 appropriate interface and encapsulated with the appropriate VID and 210 forwarded to CE1. 212 However, there may be multiple ways for CE1 to connect to PE1 and 213 PE2, including Ethernet Tag, Ethernet Tag termination, and QinQ. PE2 214 cannot obtain the appropriate VLANs and cannot forward the unicast 215 traffic to CE1 directly. 217 3. VLAN-Redirect-Extended Community Attribute 219 This document defines a new BGP extended community attribute called 220 the VLAN-Redirect-Extended Community attribute as shown in Figure 3. 222 0 1 2 3 223 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 224 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 225 | 0x06 | Sub-Type=TBA | Flags | Reserved | 226 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 227 | S-VLAN | C-VLAN | 228 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 230 Figure 3. VLAN-Redirect-Extended Community Attribute 232 Where: 234 0x06: EVPN Extended Community Type field. 236 Sub-Type: Sub-Type field indicating that the extended community 237 attribute is a VLAN-Redirect-Extended Community attribute, and 238 the value is TBA by the IANA. 240 Flags: 8 bits of identification information. Bit 0 set to 0 241 indicates that the action is redirected to the VLANs in this 242 community 244 Reserved: Not used. MUST be sent as zero and ignored on receipt. 246 S-VLAN: Outer VLAN information, can not be 0, 0 is illegal value 248 C-VLAN: Inner VLAN information. When 0, it means there is no C- 249 VLA. 251 4. Operation 253 Operation with the solution specified in Section 3 and the topology 254 shown in Figure 2 is described below. 256 4.1 Establishment 258 1. PE1 learns MAC addresses from CE1, advertises them to PE2, carries 259 the ESI value as ES1 and the next hop as PE1, and carries the 260 VLAN- Redirect-Extended Community attributes. 262 2. PE2 receives the MAC route advertised by PE1 and finds the 263 interface that connects to CE1 locally according to the ESI value. 264 At the same time, PE2 fill the VLAN information according to the 265 VLAN-Redirect-Extended Community attributes 267 3. At the same time, PE2 generates a fast reroute (FRR) entry 268 according to the next hop information (PE1) of the MAC route, that 269 is, a MAC address entry on PE2, where the primary path points to 270 the CE1 link and the standby path points to PE1 272 4. PE2 also sends the MAC as a local MAC route to PE1 274 5. PE1 receives the MAC route advertised by PE2 and generates the FRR 275 entry with the MAC route learned by CE1, that is, the MAC address 276 entry on PE1, with the primary path pointing to the CE1 link and 277 the secondary path pointing to PE2 279 4.2 Handling Link Failure 281 1. When the link between PE1 and CE1 fails, PE1 withdraws the MAC 282 address that advertised to PE2 284 2. PE2 receives the MAC withdrawal from PE1, does not delete the MAC 285 immediately, but starts an aging timer, and does not withdraw the 286 MAC address that PE2 advertised to PE1. 288 3. When the aging timer expires, and PE2 cannot receive the traffic 289 from CE1, then PE2 withdraws the MAC address that advertised to 290 PE1 and deletes the MAC entry. 292 5. IANA Considerations 294 IANA is requested to assign a new EVPN Extended Community SubType as 295 follows: 297 Sub-Type Value Name Reference 298 -------------- -------------------------------- ---------- 299 TBA VLAN-Redirect Extended Community [this doc] 301 6. Security Considerations 303 TBD 305 For general EVPN Security Considerations, see [RFC7432]. 307 Normative References 309 [RFC2119] - Bradner, S., "Key words for use in RFCs to Indicate 310 Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, 311 March 1997, . 313 [RFC7432] - Sajassi, A., Ed., Aggarwal, R., Bitar, N., Isaac, A., 314 Uttaro, J., Drake, J., and W. Henderickx, "BGP MPLS-Based 315 Ethernet VPN", RFC 7432, DOI 10.17487/RFC7432, February 2015, 316 . 318 [RFC8174] - Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 319 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 320 2017, . 322 Informative References 324 [RFC7209] - Sajassi, A., Aggarwal, R., Uttaro, J., Bitar, N., 325 Henderickx, W., and A. Isaac, "Requirements for Ethernet VPN 326 (EVPN)", RFC 7209, DOI 10.17487/RFC7209, May 2014, 327 . 329 Acknowledgements 331 The authors of this document would like to thank the following for 332 their comments and review of this document: 334 TBD 336 Authors' Addresses 338 Donald E. Eastlake, 3rd 339 Huawei Technologies 340 155 Beaver Street 341 Milford, MA 01757 USA 343 Phone: +1-508-333-2270 344 Email: d3e3e3@gmail.com 346 Zhenbin Li 347 Huawei Technologies 348 Huawei Bldg., No. 156 Beiqing Road 349 Beijing 100095 350 China 352 Email: lizhenbin@huawei.com 354 Shunwan Zhang 355 Huawei Technologies 356 Huawei Bldg., No. 156 Beiqing Road 357 Beijing 100095 358 China 360 Email: zhuangshunwan@huawei.com 362 Haibo Wang 363 Huawei Technologies 364 Huawei Bldg., No. 156 Beiqing Road 365 Beijing 100095 366 China 368 Email: rainsword.wang@huawei.com 370 Copyright, Disclaimer, and Additional IPR Provisions 372 Copyright (c) 2018 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.