idnits 2.17.1 draft-wang-bess-evpn-ac-df-per-evi-01.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 ([RFC8584]), 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 (11 July 2021) is 1020 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) == Unused Reference: 'I-D.ietf-bess-srv6-services' is defined on line 373, but no explicit reference was found in the text == Unused Reference: 'RFC7041' is defined on line 399, but no explicit reference was found in the text == Unused Reference: 'RFC7348' is defined on line 405, but no explicit reference was found in the text == Unused Reference: 'RFC8365' is defined on line 412, but no explicit reference was found in the text == Outdated reference: A later version (-21) exists of draft-ietf-bess-evpn-igmp-mld-proxy-09 == Outdated reference: A later version (-15) exists of draft-ietf-bess-srv6-services-07 Summary: 1 error (**), 0 flaws (~~), 7 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 11 July 2021 5 Expires: 12 January 2022 7 AC-Influenced DF Election per EVI 8 draft-wang-bess-evpn-ac-df-per-evi-01 10 Abstract 12 The AC-influenced DF Election (AC-DF) per [RFC8584] is too dependent 13 on EAD/EVI routes. For example, when no failures occured on an ESI, 14 that AC-DF procedures will give incorrect results if no EAD/EVI 15 routes are advertised. But in some light-weighted EVPNs (i.e. PBB 16 EVPNs), no EAD/EVI routes will be advertised at all. 18 This draft proposes some new extensions to support AC-influenced DF 19 Election without any EAD/EVI routes advertised in advance of any 20 failures. 22 Status of This Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at https://datatracker.ietf.org/drafts/current/. 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 This Internet-Draft will expire on 12 January 2022. 39 Copyright Notice 41 Copyright (c) 2021 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 46 license-info) in effect on the date of publication of this document. 47 Please review these documents carefully, as they describe your rights 48 and restrictions with respect to this document. Code Components 49 extracted from this document must include Simplified BSD License text 50 as described in Section 4.e of the Trust Legal Provisions and are 51 provided without warranty as described in the Simplified BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 56 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 57 2. AC-DF per EVI . . . . . . . . . . . . . . . . . . . . . . . . 3 58 2.1. Use Case . . . . . . . . . . . . . . . . . . . . . . . . 3 59 2.2. AC-DF per EVI Capability . . . . . . . . . . . . . . . . 4 60 2.2.1. Capability Negotiation Procedures . . . . . . . . . . 4 61 2.2.2. AC-DF Capability vs AC-DF per EVI Capability . . . . 4 62 2.3. DF Election Procedures . . . . . . . . . . . . . . . . . 4 63 2.3.1. Initiation of AC-DF per EVI Mode . . . . . . . . . . 4 64 2.3.2. Reverse EAD/EVI Route . . . . . . . . . . . . . . . . 5 65 2.3.3. DF Election Rules . . . . . . . . . . . . . . . . . . 5 66 2.3.4. Route Filtering and RT Constraints Mechanism . . . . 6 67 3. Other considerations . . . . . . . . . . . . . . . . . . . . 6 68 3.1. Reverse EAD/EVI Route in PBB EVPNs . . . . . . . . . . . 6 69 3.2. Why no EAD/EVI Routes Advertised . . . . . . . . . . . . 6 70 4. Comparison with other solutions . . . . . . . . . . . . . . . 7 71 5. Security Considerations . . . . . . . . . . . . . . . . . . . 8 72 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 73 6.1. New DF Election Capability . . . . . . . . . . . . . . . 8 74 6.2. New EVPN Layer 2 Attributes Control Flags . . . . . . . . 8 75 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 76 8. Normative References . . . . . . . . . . . . . . . . . . . . 8 77 9. Informative References . . . . . . . . . . . . . . . . . . . 9 78 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 9 80 1. Introduction 82 When the EAD/EVI route is not advertised before the corresponding ESI 83 sub-interface fails, The AC-influenced DF Election procedures should 84 elect the right DF before and after that failure. 86 Note that according to [RFC8584], the AC-influenced DF Election will 87 be incorrect when no EAD/EVI route is advertised, even if no ESI sub- 88 interface has failed at all. 90 This draft proposes some extension to DF-Capability negotiation and 91 DF-Election procedures to support AC-influenced DF-election when no 92 EAD/EVI routes are advertised. 94 1.1. Terminology 96 Most of the terminology used in this documents comes from [RFC8584] 97 and [RFC7623] except for the following: 99 * Light-weighted EVPN: The EVPN solution without EAD/EVI Route 100 advertisedment. 102 * EAD/ES: Ethernet A-D route per EVI, or RT-1 per ES route. 104 * EAD/EVI: Ethernet A-D route per EVI, or RT-1 per EVI route. 106 2. AC-DF per EVI 108 2.1. Use Case 110 The ethernet segment ES1's ESI is ESI1, AC1/AC2 is two sub-interfaces 111 on ES1, and AC3/AC4 is two sub-interfaces on ES2. AC1 and AC3 are 112 attached to EVPN Instance EVI1, while AC2 and AC4 are attached to 113 EVI2. The redundancy mode of ES1 is all-active. 115 +----------+ 116 PE1 | | 117 +-------------+ | | 118 | AC1 | | | PE3 119 /| AC2 |----| | +-------------+ 120 / | | | | | | 121 LAG / +-------------+ | | | AC3 |---CE2 122 CE1===== | PSN | | AC4 | 123 \ +-------------+ | |---| | 124 \ | | | | +-------------+ 125 \| AC2 |----| | 126 | AC1 | | | 127 +-------------+ | | 128 PE2 | | 129 +----------+ 131 Figure 1: AC-DF per EVI Usecase 133 EVI1 and EVI2 are two EVPN Instances, and there are no EAD/EVI routes 134 advertised for them. Such EVPN Instances are called Light-weighted 135 EVPNs in this draft. For example, EVI1 and EVI2 can be the 136 I-Components of PBB EVPNs, because no EAD/EVI routes are advertised 137 for these I-Components. 139 Initially PE1 is the DF for , and PE2 is the DF for 140 . When the AC1 of PE1 fails (but ESI1 and AC2 of PE1 141 still works well), the DF for should switch to PE2. 143 The DF-election should be done without any EAD/EVI routes advertised 144 before any ESI sub-interface fails. Otherwise those EAD/EVI routes 145 are advertised just for the adaptation of AC-influenced DF-election 146 procedures per [RFC8584], but will do nothing good for the unicast 147 packet forwarding in data plane (because data plane MAC learning 148 don't use EAD/EVI routes). 150 2.2. AC-DF per EVI Capability 152 We introduce a new bit named "AC-DF per EVI" in the "bitmap" field of 153 the DF Election extended community. The "AC-DF per EVI" bit means 154 that the DF-Election for an will not take EAD/EVI routes 155 into considerations untill a Reverse EAD/EVI route for that is received from any of the PEs. 158 2.2.1. Capability Negotiation Procedures 160 Only when all RT-4 routes of the same ESI indicate the "AC-DF per 161 EVI" Capability, The DF Election will be executed in "AC-DF per EVI" 162 mode. We can say that the DF Election mode for that ESI is 163 negotiated as "AC-DF per EVI" mode. 165 Note that when any of the PEs on that ES is an old PE that don't 166 support "AC-DF per EVI" mode, the RT-4 route from that PE will not 167 indicate the "AC-DF per EVI" Capability, So the DF election will not 168 be executed in "AD-DF per EVI" mode. This is for compatibility 169 purpose. 171 2.2.2. AC-DF Capability vs AC-DF per EVI Capability 173 When all RT-4 routes of the same ESI indicate both the "AC-DF per 174 EVI" Capability and the old AC-DF Capability, The DF Election will be 175 executed in "AD-DF per EVI" mode. 177 Note that when any of the PEs on that ES is an old PE that don't 178 support "AC-DF per EVI" mode, the RT-4 route from that PE may 179 indicate the "old AC-DF" Capability only, So the DF election will 180 still be executed in old AD-DF mode per [RFC8584]. This is for 181 compatibility purpose. 183 2.3. DF Election Procedures 185 2.3.1. Initiation of AC-DF per EVI Mode 187 According to [RFC8584], the AC-influenced DF Election will be 188 incorrect when no EAD/EVI route is advertised, even if no ESI sub- 189 interface has failed at all. 191 But when the DF Election mode for an ESI is negotiated as AC-DF per 192 EVI mode, no normal EAD/EVI routes can impact the DF Election 193 procedures. The DF election will be done following that ESI's RT-4 194 routes only until at least one reverse EAD/EVI route is received. 196 2.3.2. Reverse EAD/EVI Route 198 In order to do AC-influenced DF election after a sub-interface of 199 that ES fails, we introduce the "Reverse EAD/EVI Route". The reverse 200 EAD/EVI Route is a special type of EAD/EVI Route that is advertised 201 on the failure of corresponding , not on the activation of 202 that . 204 Reverse EAD/EVI routes can use the same format as EAD/EVI Routes 205 except for the following differences: 207 * A Reverse EAD/EVI Route carries an EVPN Layer 2 Attributes 208 Extended Community whose "Control Flags" field includes a new flag 209 named "AC Down". The "AC Down" flag means that the corresponding 210 AC (for which the Reverse EAD/EVI route is advertised) is down. 212 * It is recommended to carry an ES-Import RT ([RFC7432]) and an EVI- 213 RT ([I-D.ietf-bess-evpn-igmp-mld-proxy]) along with a reverse EAD/ 214 EVI route, no traditional Route-Targets have to be carried for DF- 215 election purpose. 217 * A Reverse EAD/EVI Route should make its MPLS label field be set to 218 zero. 220 Note that when the corresponding sub-interface fails, the 221 MP_REACH_NLRI of the reverse EAD/EVI route is advertised, and when 222 the corresponding sub-interface recovers, the MP_UNREACH_NLRI of the 223 reverse EAD/EVI route is sent. This is the opposite of normal EAD/ 224 EVI route. So it is called as reverse EAD/EVI route. 226 2.3.3. DF Election Rules 228 When a Reverse EAD/EVI Route for an is received from a 229 remote PE X, the RT-4 Route of that PE x are expelled from that 's DF election. Then the DF election for that will be 231 updated according to the corresponding DF Alg. 233 Note that the DF election for other s will not be affected 234 by that Reverse EAD/EVI Route. 236 2.3.4. Route Filtering and RT Constraints Mechanism 238 When PE Y receives a reverse EAD/EVI route from PE X, and the ES- 239 Import RT of that route can't match any local ES of PE Y, PE Y will 240 not import that route into the EVI that is identified by that route's 241 EVI-RT. 243 When RT Constraints Mechanism is enabled, each reverse EAD/EVI route 244 will be distributed to the adjacent PEs of its ES only. Because that 245 only the ES-Import RT are visible to the RT Constraints Mechanism, 246 The EVI-RT is not visible to the RT Constraints Mechanism. 248 3. Other considerations 250 3.1. Reverse EAD/EVI Route in PBB EVPNs 252 The AC-DF per EVI mode is not confined to PBB EVPN which is just an 253 example of light-weighted EVPNs. But in PBB EVPN, the construction 254 of reverse EAD/EVI route need some special considerations. 256 * It's EVI-RT should be the export route-target of the B-Component, 257 not the C-Component. 259 * It's Ethernet Tag ID (ETI) should be the I-SID of the I-Component. 261 Note that when PE Z receives a reverse EAD/EVI route whose EVI-RT 262 matches a local B-Component but whose ETI matches none of the 263 I-Components of that B-Component, PE Z may not import that reverse 264 EAD/EVI route. 266 Note that the reverse EAD/EVI route don't have to carry any B-MAC 267 along with it. Because that the B-MAC can do nothing helpful for the 268 DF election. 270 3.2. Why no EAD/EVI Routes Advertised 272 When no RT-2 Routes advertised, no EAD/EVI routes need to be 273 advertised either. PBB EVPN is an example of that. In PBB EVPN, the 274 C-MACs are learnt in the data plane. 276 Other light-weighted EVPNs also do data plane C-MAC learning, so they 277 don't have to advertise EAD/EVI routes either. In such EVPNs, AC-DF 278 per EVI will help. 280 4. Comparison with other solutions 282 PBB EVPN can assign a deicated vES to each sub-interface, in such 283 case, the RT-4 routes are advertised per each sub-interface (or 284 vESI). But this will bring out some other disadvantages: 286 * The uniformity of service carving can't be achieved without 287 careful configuring. 289 With service carving, it is possible to elect multiple DFs per ES 290 (one per EVI) in order to perform load balancing of traffic 291 destined to a given ES. The objective is that the load-balancing 292 procedures should carve up the BD space among the redundant PE 293 nodes evenly, in such a way that every PE is the DF for a distinct 294 set of EVIs. 296 When each EVI use a dedicated vESI to advertise the corresponding 297 Ethernet Segment Routes for that , The service carving 298 mechanisms can not work without manual configuration. 300 * The amount of B-MACs will be greatly increased. 302 The brief comparisons are listed as the following table: 304 +====================+================+=======================+ 305 | Items | AC-DF per EVI | vESI | 306 +====================+================+=======================+ 307 | ESIs | one per port | one per sub-interface | 308 +--------------------+----------------+-----------------------+ 309 | RT-4 Routes | one per port | one per sub-interface | 310 +--------------------+----------------+-----------------------+ 311 | B-MACs | one per port | one per sub-interface | 312 +--------------------+----------------+-----------------------+ 313 | Service Carving | auto | manual-configured | 314 +--------------------+----------------+-----------------------+ 315 | EAD per EVI routes | none | none | 316 +--------------------+----------------+-----------------------+ 317 | Reverse EAD per | one per failed | none | 318 | EVI routes | sub-interfaces | | 319 +--------------------+----------------+-----------------------+ 321 Table 1: Comparisons with vESI for PBB-EVPN 323 Using AC-DF per EVI mode, the service-carving is automatically 324 achieved, and no extra B-MACs should be configured and advertised. 326 5. Security Considerations 328 Security considerations will be added in future versions. 330 6. IANA Considerations 332 6.1. New DF Election Capability 334 IANA will be requested to allocate a new DF Election Capability in 335 the "DF Election Capabilities" Registry. This capability is called 336 "AC-DF per EVI Capability". 338 Bit Name Reference 339 ---- ---------------- ------------- 340 4 AC-DF per EVI Capability This draft 342 Figure 2: AC-DF per EVI Capability 344 6.2. New EVPN Layer 2 Attributes Control Flags 346 IANA will be requested to allocate a new Control Flag in the "EVPN 347 Layer 2 Attributes Control Flags" Registry. This Control Flag is 348 called "D" Flag, where "D" means AC-Down. 350 Bit Name Reference 351 ---- ---------------- ------------- 352 D AC-Down on Advertising PE This Draft 354 Figure 3: AC Failure Flag 356 7. Acknowledgements 358 The authors would like to thank the following for their comments and 359 review of this document: 361 Chunning Dai. 363 8. Normative References 365 [I-D.ietf-bess-evpn-igmp-mld-proxy] 366 Sajassi, A., Thoria, S., Mishra, M. P., Patel, K., Drake, 367 J., and W. Lin, "IGMP and MLD Proxy for EVPN", Work in 368 Progress, Internet-Draft, draft-ietf-bess-evpn-igmp-mld- 369 proxy-09, 19 April 2021, 370 . 373 [I-D.ietf-bess-srv6-services] 374 Dawra, G., Filsfils, C., Talaulikar, K., Raszuk, R., 375 Decraene, B., Zhuang, S., and J. Rabadan, "SRv6 BGP based 376 Overlay Services", Work in Progress, Internet-Draft, 377 draft-ietf-bess-srv6-services-07, 11 April 2021, 378 . 381 [RFC7432] Sajassi, A., Ed., Aggarwal, R., Bitar, N., Isaac, A., 382 Uttaro, J., Drake, J., and W. Henderickx, "BGP MPLS-Based 383 Ethernet VPN", RFC 7432, DOI 10.17487/RFC7432, February 384 2015, . 386 [RFC7623] Sajassi, A., Ed., Salam, S., Bitar, N., Isaac, A., and W. 387 Henderickx, "Provider Backbone Bridging Combined with 388 Ethernet VPN (PBB-EVPN)", RFC 7623, DOI 10.17487/RFC7623, 389 September 2015, . 391 [RFC8584] Rabadan, J., Ed., Mohanty, S., Ed., Sajassi, A., Drake, 392 J., Nagaraj, K., and S. Sathappan, "Framework for Ethernet 393 VPN Designated Forwarder Election Extensibility", 394 RFC 8584, DOI 10.17487/RFC8584, April 2019, 395 . 397 9. Informative References 399 [RFC7041] Balus, F., Ed., Sajassi, A., Ed., and N. Bitar, Ed., 400 "Extensions to the Virtual Private LAN Service (VPLS) 401 Provider Edge (PE) Model for Provider Backbone Bridging", 402 RFC 7041, DOI 10.17487/RFC7041, November 2013, 403 . 405 [RFC7348] Mahalingam, M., Dutt, D., Duda, K., Agarwal, P., Kreeger, 406 L., Sridhar, T., Bursell, M., and C. Wright, "Virtual 407 eXtensible Local Area Network (VXLAN): A Framework for 408 Overlaying Virtualized Layer 2 Networks over Layer 3 409 Networks", RFC 7348, DOI 10.17487/RFC7348, August 2014, 410 . 412 [RFC8365] Sajassi, A., Ed., Drake, J., Ed., Bitar, N., Shekhar, R., 413 Uttaro, J., and W. Henderickx, "A Network Virtualization 414 Overlay Solution Using Ethernet VPN (EVPN)", RFC 8365, 415 DOI 10.17487/RFC8365, March 2018, 416 . 418 Author's Address 419 Yubao Wang 420 ZTE Corporation 421 No.68 of Zijinghua Road, Yuhuatai Distinct 422 Nanjing 423 China 425 Email: wang.yubao2@zte.com.cn