idnits 2.17.1 draft-wang-bess-evpn-ac-df-per-evi-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 ([RFC8584]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 282: '... C Control word [RFC4448] MUST be present. [RFC8214]...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (7 May 2021) is 1084 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: 'RFC8214' is mentioned on line 282, but not defined == Missing Reference: 'RFC4448' is mentioned on line 282, but not defined == Unused Reference: 'I-D.ietf-bess-srv6-services' is defined on line 303, but no explicit reference was found in the text == Unused Reference: 'RFC7041' is defined on line 329, but no explicit reference was found in the text == Unused Reference: 'RFC7348' is defined on line 335, but no explicit reference was found in the text == Unused Reference: 'RFC8365' is defined on line 342, but no explicit reference was found in the text == Outdated reference: A later version (-21) exists of draft-ietf-bess-evpn-igmp-mld-proxy-06 == Outdated reference: A later version (-15) exists of draft-ietf-bess-srv6-services-06 Summary: 2 errors (**), 0 flaws (~~), 9 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 7 May 2021 5 Expires: 8 November 2021 7 AC-Influenced DF Election per EVI 8 draft-wang-bess-evpn-ac-df-per-evi-00 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 8 November 2021. 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 . . . . . . . . . . . . . . . . . . . . . . . 2 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 . . . . 5 67 3. Other considerations . . . . . . . . . . . . . . . . . . . . 6 68 3.1. Why no EAD/EVI Routes Advertised . . . . . . . . . . . . 6 69 4. Security Considerations . . . . . . . . . . . . . . . . . . . 6 70 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 71 5.1. New DF Election Capability . . . . . . . . . . . . . . . 6 72 5.2. New EVPN Layer 2 Attributes Control Flags . . . . . . . . 6 73 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 74 7. Normative References . . . . . . . . . . . . . . . . . . . . 7 75 8. Informative References . . . . . . . . . . . . . . . . . . . 8 76 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 8 78 1. Introduction 80 When the EAD/EVI route is not advertised before the corresponding ESI 81 sub-interface fails, The AC-influenced DF Election procedures should 82 elect the right DF before and after that failure. 84 Note that according to [RFC8584], the AC-influenced DF Election will 85 be incorrect when no EAD/EVI route is advertised, even if no ESI sub- 86 interface has failed at all. 88 This draft proposes some extension to DF-Capability negotiation and 89 DF-Election procedures to support AC-influenced DF-election when no 90 EAD/EVI routes are advertised. 92 1.1. Terminology 94 Most of the terminology used in this documents comes from [RFC8584] 95 and [RFC7623] except for the following: 97 * Light-weighted EVPN: The EVPN solution without EAD/EVI Route 98 advertisedment. 100 * EAD/ES: Ethernet A-D route per EVI, or RT-1 per ES route. 102 * EAD/EVI: Ethernet A-D route per EVI, or RT-1 per EVI route. 104 2. AC-DF per EVI 106 2.1. Use Case 108 The ethernet segment ES1's ESI is ESI1, AC1/AC2 is two sub-interfaces 109 on ES1, and AC3/AC4 is two sub-interfaces on ES2. AC1 and AC3 are 110 attached to EVPN Instance EVI1, while AC2 and AC4 are attached to 111 EVI2. The redundancy mode of ES1 is all-active. 113 +----------+ 114 PE1 | | 115 +-------------+ | | 116 | AC1 | | | PE3 117 /| AC2 |----| | +-------------+ 118 / | | | | | | 119 LAG / +-------------+ | | | AC3 |---CE2 120 CE1===== | PSN | | AC4 | 121 \ +-------------+ | |---| | 122 \ | | | | +-------------+ 123 \| AC2 |----| | 124 | AC1 | | | 125 +-------------+ | | 126 PE2 | | 127 +----------+ 129 Figure 1: AC-DF per EVI Usecase 131 EVI1 and EVI2 are two EVPN Instances, and there are no EAD/EVI routes 132 advertised for them. Such EVPN Instances are called Light-weighted 133 EVPNs in this draft. For example, EVI1 and EVI2 can be the 134 I-Components of PBB EVPNs, because no EAD/EVI routes are advertised 135 for these I-Components. 137 Initially PE1 is the DF for , and PE2 is the DF for 138 . When the AC1 of PE1 fails (but ESI1 and AC2 of PE1 139 still works well), the DF for should switch to PE2. 141 The DF-election should be done without any EAD/EVI routes advertised 142 before any ESI sub-interface fails. Otherwise those EAD/EVI routes 143 are advertised just for the adaptation of AC-influenced DF-election 144 procedures per [RFC8584], but will do nothing good for the unicast 145 packet forwarding in data plane (because data plane MAC learning 146 don't use EAD/EVI routes). 148 2.2. AC-DF per EVI Capability 150 We introduce a new bit named "AC-DF per EVI" in the "bitmap" field of 151 the DF Election extended community. The "AC-DF per EVI" bit means 152 that the DF-Election for an will not take EAD/EVI routes 153 into considerations untill a Reverse EAD/EVI route for that is received from any of the PEs. 156 2.2.1. Capability Negotiation Procedures 158 Only when all RT-4 routes of the same ESI indicate the "AC-DF per 159 EVI" Capability, The DF Election will be executed in "AD-DF per EVI" 160 mode. We can say that the DF Election mode for that ESI is 161 negotiated as "AC-DF per EVI" mode. 163 Note that when any of the PEs on that ES is an old PE that don't 164 support "AC-DF per EVI" mode, the RT-4 route from that PE will not 165 indicate the "AC-DF per EVI" Capability, So the DF election will not 166 be executed in "AD-DF per EVI" mode. This is for compatibility 167 purpose. 169 2.2.2. AC-DF Capability vs AC-DF per EVI Capability 171 When all RT-4 routes of the same ESI indicate both the "AC-DF per 172 EVI" Capability and the old AC-DF Capability, The DF Election will be 173 executed in "AD-DF per EVI" mode. 175 Note that when any of the PEs on that ES is an old PE that don't 176 support "AC-DF per EVI" mode, the RT-4 route from that PE may 177 indicate the "old AC-DF" Capability only, So the DF election will 178 still be executed in old AD-DF mode per [RFC8584]. This is for 179 compatibility purpose. 181 2.3. DF Election Procedures 183 2.3.1. Initiation of AC-DF per EVI Mode 185 According to [RFC8584], the AC-influenced DF Election will be 186 incorrect when no EAD/EVI route is advertised, even if no ESI sub- 187 interface has failed at all. 189 But when the DF Election mode for an ESI is negotiated as AC-DF per 190 EVI mode, no normal EAD/EVI routes can impact the DF Election 191 procedures. The DF election will be done following that ESI's RT-4 192 routes only until at least one reverse EAD/EVI route is received. 194 2.3.2. Reverse EAD/EVI Route 196 In order to do AC-influenced DF election after a sub-interface of 197 that ES fails, we introduce the "Reverse EAD/EVI Route". The reverse 198 EAD/EVI Route is a special type of EAD/EVI Route that is advertised 199 on the failure of corresponding , not on the activation of 200 that . 202 Reverse EAD/EVI routes can use the same format as EAD/EVI Routes 203 except for the following differences: 205 * A Reverse EAD/EVI Route carries an EVPN Layer 2 Attributes 206 Extended Community whose "Control Flags" field includes a new flag 207 named "AC Failure". The "AC Failure" flag means that the 208 corresponding AC (for which the Reverse EAD/EVI route is 209 advertised) is in failure. 211 * A Reverse EAD/EVI Route carries an ES-Import RT ([RFC7432]) and an 212 EVI-RT ([I-D.ietf-bess-evpn-igmp-mld-proxy]), no traditional 213 Route-Targets have to be carried. 215 * A Reverse EAD/EVI Route should make its MPLS label field be set to 216 zero. 218 2.3.3. DF Election Rules 220 When a Reverse EAD/EVI Route for an is received from a 221 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 223 updated according to the corresponding DF Alg. 225 Note that the DF election for other s will not be affected 226 by that Reverse EAD/EVI Route. 228 2.3.4. Route Filtering and RT Constraints Mechanism 230 When PE Y receives a reverse EAD/EVI route from PE X, and the ES- 231 Import RT of that route can't match any local ES of PE Y, PE Y will 232 not import that route into the EVI that is identified by that route's 233 EVI-RT. 235 When RT Constraints Mechanism is enabled, each reverse EAD/EVI route 236 will be distributed to the adjacent PEs of its ES only. Because that 237 only the ES-Import RT are visible to the RT Constraints Mechanism, 238 The EVI-RT is not visible to the RT Constraints Mechanism. 240 3. Other considerations 242 3.1. Why no EAD/EVI Routes Advertised 244 When no RT-2 Routes advertised, no EAD/EVI routes need to be 245 advertised either. PBB EVPN is an example of that. In PBB EVPN, the 246 C-MACs are learnt in the data plane. 248 Other light-weighted EVPNs also do data plane C-MAC learning, so they 249 don't have to advertise EAD/EVI routes either. In such EVPNs, AC-DF 250 per EVI will help. 252 4. Security Considerations 254 Security considerations will be added in future versions. 256 5. IANA Considerations 258 5.1. New DF Election Capability 260 IANA will be requested to allocate a new DF Election Capability in 261 the "DF Election Capabilities" Registry. This capability is called 262 "AC-DF per EVI Capability". 264 Bit Name Reference 265 ---- ---------------- ------------- 266 0 Unassigned 267 1 AC-DF Capability [RFC8584] 268 4 AC-DF per EVI Capability This draft 270 Figure 2: AC-DF per EVI Capability 272 5.2. New EVPN Layer 2 Attributes Control Flags 274 IANA will be requested to allocate a new Control Flag in the "EVPN 275 Layer 2 Attributes Control Flags" Registry. This Control Flag is 276 called "F" Flag, where "F" means AC-Failure. 278 Bit Name Reference 279 ---- ---------------- ------------- 280 P Advertising PE is the primary PE. [RFC8214] 281 B Advertising PE is the backup PE. [RFC8214] 282 C Control word [RFC4448] MUST be present. [RFC8214] 283 F AC-Failure on Advertising PE This Draft 285 Figure 3: AC Failure Flag 287 6. Acknowledgements 289 The authors would like to thank the following for their comments and 290 review of this document: 292 Chunning Dai. 294 7. Normative References 296 [I-D.ietf-bess-evpn-igmp-mld-proxy] 297 Sajassi, A., Thoria, S., Drake, J., and W. Lin, "IGMP and 298 MLD Proxy for EVPN", Work in Progress, Internet-Draft, 299 draft-ietf-bess-evpn-igmp-mld-proxy-06, 25 January 2021, 300 . 303 [I-D.ietf-bess-srv6-services] 304 Dawra, G., Filsfils, C., Talaulikar, K., Raszuk, R., 305 Decraene, B., Zhuang, S., and J. Rabadan, "SRv6 BGP based 306 Overlay services", Work in Progress, Internet-Draft, 307 draft-ietf-bess-srv6-services-06, 9 March 2021, 308 . 311 [RFC7432] Sajassi, A., Ed., Aggarwal, R., Bitar, N., Isaac, A., 312 Uttaro, J., Drake, J., and W. Henderickx, "BGP MPLS-Based 313 Ethernet VPN", RFC 7432, DOI 10.17487/RFC7432, February 314 2015, . 316 [RFC7623] Sajassi, A., Ed., Salam, S., Bitar, N., Isaac, A., and W. 317 Henderickx, "Provider Backbone Bridging Combined with 318 Ethernet VPN (PBB-EVPN)", RFC 7623, DOI 10.17487/RFC7623, 319 September 2015, . 321 [RFC8584] Rabadan, J., Ed., Mohanty, S., Ed., Sajassi, A., Drake, 322 J., Nagaraj, K., and S. Sathappan, "Framework for Ethernet 323 VPN Designated Forwarder Election Extensibility", 324 RFC 8584, DOI 10.17487/RFC8584, April 2019, 325 . 327 8. Informative References 329 [RFC7041] Balus, F., Ed., Sajassi, A., Ed., and N. Bitar, Ed., 330 "Extensions to the Virtual Private LAN Service (VPLS) 331 Provider Edge (PE) Model for Provider Backbone Bridging", 332 RFC 7041, DOI 10.17487/RFC7041, November 2013, 333 . 335 [RFC7348] Mahalingam, M., Dutt, D., Duda, K., Agarwal, P., Kreeger, 336 L., Sridhar, T., Bursell, M., and C. Wright, "Virtual 337 eXtensible Local Area Network (VXLAN): A Framework for 338 Overlaying Virtualized Layer 2 Networks over Layer 3 339 Networks", RFC 7348, DOI 10.17487/RFC7348, August 2014, 340 . 342 [RFC8365] Sajassi, A., Ed., Drake, J., Ed., Bitar, N., Shekhar, R., 343 Uttaro, J., and W. Henderickx, "A Network Virtualization 344 Overlay Solution Using Ethernet VPN (EVPN)", RFC 8365, 345 DOI 10.17487/RFC8365, March 2018, 346 . 348 Author's Address 350 Yubao Wang 351 ZTE Corporation 352 No.68 of Zijinghua Road, Yuhuatai Distinct 353 Nanjing 354 China 356 Email: wang.yubao2@zte.com.cn