idnits 2.17.1 draft-wang-bess-evpn-cmac-overload-reduction-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 : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([RFC7623], [I-D.dawra-bess-srv6-services], [RFC7041]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (May 17, 2020) is 1412 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: 'RFC7041' is mentioned on line 387, but not defined == Missing Reference: 'RFC7623' is mentioned on line 393, but not defined == Missing Reference: 'I-D.snr-bess-pbb-evpn-isid-cmacflush' is mentioned on line 381, but not defined Summary: 1 error (**), 0 flaws (~~), 4 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 ZTE Corporation 4 Intended status: Standards Track May 17, 2020 5 Expires: November 18, 2020 7 Reduction of EVPN C-MAC Overload 8 draft-wang-bess-evpn-cmac-overload-reduction-00 10 Abstract 12 When there are too many customer-MACs (C-MACs), the RRs and/or ASBRs 13 will be overloaded by the RT-2 routes for these MACs according to 14 [I-D.dawra-bess-srv6-services]. This issue can be simply solved by 15 making the remote C-MAC entries learnt via data-plane MAC learning 16 (like what PBB VPLS have been done since [RFC7041]) rather than 17 received from RT-2 routes. This simplified solution will works as 18 well as PBB VPLS. But this simplified solution will lose many 19 important features that based on the ESI concept. Because the 20 ingress-ESI can't be learnt via data-plane MAC learning at the egress 21 PE. So when the data packets is forwarded following these MAC 22 entries, they can't benefit from the EAD/EVI routes as per RFC7432. 23 So the All-Active Redundancy mode for ES can't be supported. This 24 make the simplified solution can't work as well as PBB EVPN 25 ([RFC7623]). 27 This document proposes a new SRv6 function type and an extension to 28 [I-D.dawra-bess-srv6-services] to achieve all-active mode ES 29 redundancy on TPEs and reduce the C-MAC loads for RRs and ASBRs. The 30 new solution will work even more better than PBB EVPN under the help 31 of these extensions. 33 Status of This Memo 35 This Internet-Draft is submitted in full conformance with the 36 provisions of BCP 78 and BCP 79. 38 Internet-Drafts are working documents of the Internet Engineering 39 Task Force (IETF). Note that other groups may also distribute 40 working documents as Internet-Drafts. The list of current Internet- 41 Drafts is at https://datatracker.ietf.org/drafts/current/. 43 Internet-Drafts are draft documents valid for a maximum of six months 44 and may be updated, replaced, or obsoleted by other documents at any 45 time. It is inappropriate to use Internet-Drafts as reference 46 material or to cite them other than as "work in progress." 48 This Internet-Draft will expire on November 18, 2020. 50 Copyright Notice 52 Copyright (c) 2020 IETF Trust and the persons identified as the 53 document authors. All rights reserved. 55 This document is subject to BCP 78 and the IETF Trust's Legal 56 Provisions Relating to IETF Documents 57 (https://trustee.ietf.org/license-info) in effect on the date of 58 publication of this document. Please review these documents 59 carefully, as they describe your rights and restrictions with respect 60 to this document. Code Components extracted from this document must 61 include Simplified BSD License text as described in Section 4.e of 62 the Trust Legal Provisions and are provided without warranty as 63 described in the Simplified BSD License. 65 Table of Contents 67 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 68 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 69 2. Control Plane . . . . . . . . . . . . . . . . . . . . . . . . 4 70 3. Dataplane . . . . . . . . . . . . . . . . . . . . . . . . . . 5 71 3.1. PE1 forward ARP Request to PE2/PE3 . . . . . . . . . . . 5 72 3.2. PE2/PE3's Dataplane MAC Learning . . . . . . . . . . . . 5 73 3.3. PE2 Discard ARP Request to CE1 . . . . . . . . . . . . . 6 74 3.4. PE3 Forward ARP Replay to PE1/PE2 . . . . . . . . . . . . 6 75 3.5. PE1 Forward ARP Replay to CE1 . . . . . . . . . . . . . . 6 76 4. ESI Indicator Advertisement Optimization . . . . . . . . . . 6 77 5. C-MAC Flush Notification Procedure . . . . . . . . . . . . . 7 78 6. E-Tree Support Considerations . . . . . . . . . . . . . . . . 7 79 7. EVPN IRB Support Considerations . . . . . . . . . . . . . . . 7 80 8. Use End.ESI SID in MAC/IP Advertisement Routes . . . . . . . 7 81 9. Security Considerations . . . . . . . . . . . . . . . . . . . 8 82 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 83 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 84 11.1. Normative References . . . . . . . . . . . . . . . . . . 8 85 11.2. Informative References References . . . . . . . . . . . 8 86 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 9 88 1. Introduction 90 In [I-D.dawra-bess-srv6-services], an extension to [RFC7432] is 91 proposed for SRv6 EVPN control-plane. In this control-plane the 92 C-MACs is advertised via RT-2 route, but in order to solve the C-MAC 93 overload problem for RRs and ASBRs, we have to return to a PBB-like 94 dataplane C-MAC learning procedures. 96 This document introduce an "ESI Indicator" concept to the EVPN data- 97 plane. We can recognize an ESI from its ESI-indicator. But an ESI 98 may have a few ESI-indicators, each for a TPE, espacially in the 99 single-active mode of ES redundancy. 101 Then we introduce a SRv6 function named End.ESI to carry the ESI- 102 indicator in SRv6 dataplane. A SID with the End.ESI function is 103 called as an "ESI SID" in this document. The ESI-indicator is the 104 locator and fuction part of its ESI SID. The argument part of the 105 ESI SID is a Global Discreminating Value (GDV) for an EVI. The GDV 106 works like the function part of an End.DT2U/DT2M SID. But the GDV 107 has a global meaning like a global VNI or an PBB ISID but the 108 function part for an End.DT2U/DT2M SID typically is only a local 109 discreminator on the egress PE. The argument part of the ESI SID is 110 called as Arg.GED in this document, where the Global EVI 111 discreminator is abbreviated as GED. 113 1.1. Terminology 115 Most of the terminology used in this documents comes from [RFC7432] 116 and [I-D.dawra-bess-srv6-services] except for the following: 118 C-MAC: Customer MAC, it is the same as the C-MAC of PBB EVPN, But 119 there is no B-MAC in this document. 121 ISID: a broadcast domain identifier in PBB I-Component. 123 LDV: Local Discreminating Value. It is similar to the Local 124 Discreminating Value of type 3 ESI. 126 GDV: Global Discreminating Value. An identifier with global 127 uniqueness. 129 GED: Global EVI Discreminator, a GDV for an EVI instance. 131 ESI Indicator: A Global ID for an ESI. Note that different PE may 132 assign different ESI-indicator for the same ESI, espacially when the 133 ES redundancy mode is single-active. 135 GEI: Global ESI Indicator. It is the same as the "ESI Indicator" 136 except for the emphasization to its global uniqueness. 138 EAD/EVI: An Ethernet A-D route per EVI. 140 GEI/EVI: An EAD/EVI route with an Gloabal ESI Indicator. 142 Arg.GED: The argument part of a SID of the End.ESI function. 144 RT-2: MAC/IP Advertise Route. 146 ESI/IP: RT-2 Route whose IP field of the NLRI is a ESI-indicator. 148 MAC Entry: An entry in the EVPN MAC table in data-plane. 150 ESI IP: An End.ESI SID with its Argument part being set to zero. 152 2. Control Plane 154 We assign a GED to an EVI instance EVI_1, the GED is a number 155 consists of N bits. We assign an ESI-indicator I1 with ESI1 on PE1, 156 and we assign an ESI-indicator I2 with ESI1 on PE2. We call the 157 relationship between ESI1 and its two ESI-indicators as ESI1_I1 and 158 ESI1_I2 respectively. 160 +----------+ 161 PE1 | | 162 +-------------+ | | 163 | ESI1_I1 | | | PE3 164 /| |----| | +-------------+ 165 / | | | IP | | | 166 LAG / +-------------+ | Backbone | | ESI2_I3 |---CE2 167 CE1===== | with | | | 168 \ +-------------+ | EVPN |---| | 169 \ | | | RRs | +-------------+ 170 \| |----| and | 171 | ESI1_I2 | | ASBRs | 172 +-------------+ | | 173 PE2 | | 174 +----------+ 176 Figure 1: EVPN MAC Reduction Usecase 178 We use IMET routes to build a broadcast-list. The broadcast-list is 179 used to forward BUM traffics. The data-plane MAC learning for BUM 180 traffics produces the first batch of C-MAC entries. The subsequent 181 C-MAC entries can be learnt from Unicast traffics and/or BUM 182 traffics. It is clear that we don't use MAC/IP routes as usual for 183 fear that the RRs and/or ASBRs are overloaded by these C-MACs. 185 The SRv6 SID in IMET route is an End.DT2M SID with a zero argument 186 length. The I1 and I2 are SRv6 SID of End.ESI function that is 187 defined in the following figure. We use IGP protocols to advertise 188 I1 and I2 to PE3 respectively in SRv6 underlay. So we don't use EAD/ 189 ES route or EAD/EVI route in SRv6 EVPN in this section. If ESI1 is 190 single-active mode, I1 is different from I2, but if ESI1 is all- 191 active mode, I1 is the same as I2. 193 | ESI-Indicator(128-N bits) | N bits | 194 +------------+------------+-----------+-------------------------+ 195 | Block | Node | ESI.LDV | Arg.GED | 196 +------------+------------+-----------+-------------------------+ 198 Figure 2: End.ESI SID Format 200 Note that an ESI-indicator is composed of Locator and Function, an 201 ESI IP is an 128 bits SID with a zero argument. The function part is 202 a Local Discreminating Value on that PE for the ESI. The argument 203 part is a Global EVI Discreminator (GED) for the data packet. The 204 argument part is also called Arg.GED in this document. 206 3. Dataplane 208 3.1. PE1 forward ARP Request to PE2/PE3 210 When CE1 requests CE2's ARP, PE1 will receive the ARP Request from a 211 AC of ESI1. PE1 will forward the ARP Request following the 212 broadcast-list for the AC's EVI instance. The broadcast-list is 213 constructed by IMET routes from PE2/PE3. 215 PE1 will forward the ARP Request to PE2/PE3 with the following SRv6 216 BE encapsulation: It's underlay Source IP is the End.ESI SID on PE1 217 for ESI1; It's underlay Destination IP is the End.DT2M SID on PE2/ 218 PE3. The locator and function part of the End.ESI SID is I1. The 219 Argument part of the End.ESI SID is 0. The SMAC of the ARP request 220 is M1 which is CE1's MAC address. 222 Note that the underlay SIP will be the End.DT2U SID for the single- 223 homed ingress ACs. The multi-homed ingress ACs with single-active 224 behavior may not be assigned with an ESI-indicator either. In such 225 situations, the underlay SIP will be the End.DT2U SID too. 227 3.2. PE2/PE3's Dataplane MAC Learning 229 When PE2/PE3 receives the ARP Request packet, they do dataplane MAC 230 learning independently. They will learn that M1 is behind I1, which 231 is determined by underlay SIP of the ARP Request packet. 233 Note that when PE2 learns that M1 is behind I1, it will assume that 234 M1 is behind the local AC with an ESI-indicator I1 too. The local AC 235 may have more higher priority than the ESI-IP. 237 After the dataplane MAC learning, the ARP request packet is 238 broadcasted to the local ACs, behind one of which is CE2. 240 3.3. PE2 Discard ARP Request to CE1 242 When ESI1 is all-active mode and PE2 is about to forward the ARP 243 request to CE1, PE2 will find that the ESI indicator for the outgoing 244 AC is also I1, so PE2 discards it for ESI loop-free considerations. 246 When ESI1 is single-active mode, the outgoing AC may be in blocking 247 state, otherwise its corresponding sub-interface on CE1 will take 248 charge of packet-drop behavior instead. So alghough the ESI 249 indicator for the outgoing AC is not the same as I1, no loop will 250 arise in the Ethernet Segment. 252 3.4. PE3 Forward ARP Replay to PE1/PE2 254 When CE2 replies to CE1 for the ARP request, PE3 will forward the ARP 255 reply according to the MAC entry M1 learned previously as above. 257 PE3 will forward the ARP reply to PE1 with the following SRv6 BE 258 encapsulation: It's underlay Source IP is the End.ESI SID on PE3 for 259 ESI2; It's underlay Destination IP is the End.ESI SID on PE1 for ESI1 260 according to the MAC entry M1. The Arg.GED for the End.ESI SID in 261 DIP is the Global EVI Discreminator (GED) configured on PE3. Note 262 that the GED for the same EVI is configured with the same value on 263 PE1/PE2/PE3. 265 When ESI1 is all-active mode, I1 will be the same as I2, so we call 266 both of them I21 instead. The traffics to M1 will be load-balanced 267 between PE1 and PE2 by the underlay network on PE3. Because I21 is 268 advertised by both PE1 and PE2 in the underlay IGP protocol. 270 3.5. PE1 Forward ARP Replay to CE1 272 Whe PE1 received the SRv6 encapsulated ARP reply packet from PE3, PE1 273 first match the packet to the End.ESI SID of ESI1 by DIP, then match 274 the packet to the EVI instance EVI_1 by Arg.GED. And PE1 will not 275 discard it because the egress ESI indicator I1 is not the same as the 276 ingress ESI indicator I3 in the SIP of the packet. 278 4. ESI Indicator Advertisement Optimization 280 Although we can advertise End.ESI SID in underlay IGP protocols, But 281 it is better to use the SRv6 SID Structure Sub-Sub-TLV to indicate 282 the length of the Arg.GED in the End.ESI SID. 284 So we can use EAD/EVI route to advertise Global ESI Indicator (GEI), 285 these EAD/EVI routes is called as GEI/EVI route in this document. 286 But we also can use MAC/IP route to advertise GEI, like what have 287 been done by PBB EVPN's B-MAC advertisement procedures as per 289 [RFC7623]. When the MAC/IP route is used to advertise GEI, only the 290 IP field in its NLRI is used to identify a GEI, so the MAC field in 291 its NLRI can be set to zero. Such MAC/IP route is called as ESI/IP 292 route in this document. When the GEI/EVI route is used to advertise 293 GEI, the End.ESI SID is encapsulated its SRv6 L2 Service TLV, not in 294 its nexthop. 296 Either GEI/EVI routes or ESI/IP routes will be advertised/imported 297 for Global Routing Table (GRT), so their Route-Targets (RT) will be 298 configured with GRT. Because there isn't a dedicated B-component 299 like PBB VPLS and PBB EVPN. 301 Although GEIs is imported to GRT, they are awared only on PE nodes, 302 the transit nodes in underlay network won't be aware of GEIs in order 303 to reduce the FIB consumption. We can use the argument length in the 304 SRv6 SID Structure Sub-Sub-TLV to check whether the GED is too big 305 for the End.ESI SID, So we can avoid the destruction to the function 306 part of the End.ESI and we can use flexible GED length. 308 5. C-MAC Flush Notification Procedure 310 The withdraw of ESI Indicator Advertisement can be used as C-MAC 311 flush notification like what have been done by [RFC8317] and 312 [I-D.snr-bess-pbb-evpn-isid-cmacflush]. 314 6. E-Tree Support Considerations 316 E-tree Supprot extensions is similar to [RFC8317] section 5 except 317 for the following notable differences: The B-MAC is replaced by GEIs, 318 the PBB encapsulation is replaced by SRv6 encapsulation, the 319 B-component is replaced by underlay GRT. The B-MAC Advertisement 320 Route is replaced by GEI/EVI route or ESI/IP Route. 322 7. EVPN IRB Support Considerations 324 The PBB-VPLS/PBB-EVPN is not friendly to IRB usecase because of its 325 complicated Protocol Stack, so it is used only in pure L2VPN usecase 326 up to now in the industry. But the dataplane in this draft is no 327 more complex with typical SRv6 EVPN. So it will work as efficient as 328 we should expect in SRv6 EVPN IRB usecase. 330 8. Use End.ESI SID in MAC/IP Advertisement Routes 332 In [I-D.dawra-bess-srv6-services] the downstream assigned ESI label 333 is encapsulated in the Arg.FE2 part of End.DT2M SID, And the ESI 334 label present as Arg.FE2 only when the egress PE is adjacent with the 335 ingress ESI. So it is difficult (if not impossible) to do data-plane 336 C-MAC learning via End.DT2M SID and its unwarranted Arg.FE2 presence. 338 Alghough upstream assigned ESI label may be used to learn ingress 339 ESI-indicator on egress PE node, other issues will arise together. 341 But the End.ESI SID can be used in MAC/IP advertisement route, only 342 if C-MAC overload is not a real threat. By doing this, the data- 343 plane can be unified among these usecases. The details for using 344 End.ESI SID in MAC/IP Advertisement Route will be described in future 345 versions. 347 9. Security Considerations 349 This document does not introduce any new security considerations 350 other than already discussed in [RFC7432] and [RFC7623]. 352 10. IANA Considerations 354 There is no IANA consideration. 356 11. References 358 11.1. Normative References 360 [I-D.dawra-bess-srv6-services] 361 Dawra, G., Filsfils, C., Brissette, P., Agrawal, S., 362 Leddy, J., daniel.voyer@bell.ca, d., 363 daniel.bernier@bell.ca, d., Steinberg, D., Raszuk, R., 364 Decraene, B., Matsushima, S., Zhuang, S., and J. Rabadan, 365 "SRv6 BGP based Overlay services", draft-dawra-bess- 366 srv6-services-02 (work in progress), July 2019. 368 [RFC7432] Sajassi, A., Ed., Aggarwal, R., Bitar, N., Isaac, A., 369 Uttaro, J., Drake, J., and W. Henderickx, "BGP MPLS-Based 370 Ethernet VPN", RFC 7432, DOI 10.17487/RFC7432, February 371 2015, . 373 [RFC8317] Sajassi, A., Ed., Salam, S., Drake, J., Uttaro, J., 374 Boutros, S., and J. Rabadan, "Ethernet-Tree (E-Tree) 375 Support in Ethernet VPN (EVPN) and Provider Backbone 376 Bridging EVPN (PBB-EVPN)", RFC 8317, DOI 10.17487/RFC8317, 377 January 2018, . 379 11.2. Informative References References 381 [I-D.snr-bess-pbb-evpn-isid-cmacflush] 382 Rabadan, J., Sathappan, S., Nagaraj, K., Miyake, M., and 383 T. Matsuda, "PBB-EVPN ISID-based CMAC-Flush", draft-snr- 384 bess-pbb-evpn-isid-cmacflush-06 (work in progress), July 385 2019. 387 [RFC7041] Balus, F., Ed., Sajassi, A., Ed., and N. Bitar, Ed., 388 "Extensions to the Virtual Private LAN Service (VPLS) 389 Provider Edge (PE) Model for Provider Backbone Bridging", 390 RFC 7041, DOI 10.17487/RFC7041, November 2013, 391 . 393 [RFC7623] Sajassi, A., Ed., Salam, S., Bitar, N., Isaac, A., and W. 394 Henderickx, "Provider Backbone Bridging Combined with 395 Ethernet VPN (PBB-EVPN)", RFC 7623, DOI 10.17487/RFC7623, 396 September 2015, . 398 Author's Address 400 Yubao(Bob) Wang 401 ZTE Corporation 402 No. 50 Software Ave, Yuhuatai Distinct 403 Nanjing 404 China 406 Email: yubao.wang2008@hotmail.com