idnits 2.17.1 draft-ietf-bess-evpn-ac-df-03.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 document seems to lack an Introduction section. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (January 18, 2018) is 2283 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'RFC2119' is mentioned on line 342, but not defined == Outdated reference: A later version (-05) exists of draft-ietf-bess-vpls-multihoming-01 Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 BESS Workgroup J. Rabadan, Ed. 3 Internet Draft K. Nagaraj 4 S. Sathappan 5 Intended status: Informational V. Prabhu 6 Nokia 8 A. Liu 9 Ciena 11 W. Lin 12 Juniper Networks 14 Expires: July 22, 2018 January 18, 2018 16 AC-Influenced Designated Forwarder Election for EVPN 17 draft-ietf-bess-evpn-ac-df-03 19 Abstract 21 The Designated Forwarder (DF) in EVPN networks is the PE responsible 22 for sending multicast, broadcast and unknown unicast traffic to a 23 multi-homed CE, on a given Ethernet Tag on a particular Ethernet 24 Segment (ES). The DF is selected based on the list of PEs that 25 advertise the Ethernet Segment Identifier (ESI) to the EVPN network. 26 While PE node or link failures trigger the DF re-election for a given 27 , individual Attachment Circuit (AC) or MAC-VRF failures do 28 not trigger such DF re-election and the traffic may therefore be 29 permanently impacted, even though there is an alternative path. This 30 document improves the DF election algorithm so that the AC status can 31 influence the result of the election and this type of "logical" 32 failures can be protected too. 34 Status of this Memo 36 This Internet-Draft is submitted in full conformance with the 37 provisions of BCP 78 and BCP 79. 39 Internet-Drafts are working documents of the Internet Engineering 40 Task Force (IETF), its areas, and its working groups. Note that 41 other groups may also distribute working documents as Internet- 42 Drafts. 44 Internet-Drafts are draft documents valid for a maximum of six months 45 and may be updated, replaced, or obsoleted by other documents at any 46 time. It is inappropriate to use Internet-Drafts as reference 47 material or to cite them other than as "work in progress." 49 The list of current Internet-Drafts can be accessed at 50 http://www.ietf.org/ietf/1id-abstracts.txt 52 The list of Internet-Draft Shadow Directories can be accessed at 53 http://www.ietf.org/shadow.html 55 This Internet-Draft will expire on July 22, 2018. 57 Copyright Notice 59 Copyright (c) 2018 IETF Trust and the persons identified as the 60 document authors. All rights reserved. 62 This document is subject to BCP 78 and the IETF Trust's Legal 63 Provisions Relating to IETF Documents 64 (http://trustee.ietf.org/license-info) in effect on the date of 65 publication of this document. Please review these documents 66 carefully, as they describe your rights and restrictions with respect 67 to this document. Code Components extracted from this document must 68 include Simplified BSD License text as described in Section 4.e of 69 the Trust Legal Provisions and are provided without warranty as 70 described in the Simplified BSD License. 72 Table of Contents 74 1. Problem Statement . . . . . . . . . . . . . . . . . . . . . . . 3 75 2. Solution Description . . . . . . . . . . . . . . . . . . . . . 4 76 2.1. Current DF Election Procedure And AC Failures . . . . . . . 5 77 2.2. The Attachment Circuit (AC) Influenced DF Election . . . . 6 78 2.3. AC-Influenced DF Election For VLAN-Aware Bundle Services . 7 79 3. Solution benefits . . . . . . . . . . . . . . . . . . . . . . . 8 80 4. Conventions used in this document . . . . . . . . . . . . . . . 8 81 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 9 82 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 9 83 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 84 7.1. Normative References . . . . . . . . . . . . . . . . . . . 9 85 7.2. Informative References . . . . . . . . . . . . . . . . . . 9 86 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 9 87 9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 9 88 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10 90 1. Problem Statement 92 [RFC7432] defines the Designated Forwarder (DF) as the EVPN PE 93 responsible for: 95 o Flooding Broadcast, Unknown unicast and Multicast traffic (BUM), on 96 a given Ethernet Tag on a particular Ethernet Segment (ES), to the 97 CE. This is valid for single-active and all-active EVPN 98 multi-homing. 100 o Sending unicast traffic on a given Ethernet Tag on a particular ES 101 to the CE. This is valid for single-active multi-homing. 103 The default DF election algorithm defined by [RFC7432] is called 104 service-carving and, for a given ES, is based on a (V mod N)= i 105 function that provides a local DF election of a PEi at 106 level. V is the Ethernet Tag associated to the EVI (the numerically 107 lowest Ethernet Tag value in case of multiple Ethernet Tags), whereas 108 N is the number of PEs for which ES routes have been successfully 109 imported. In other words, EVPN's service-carving takes into account 110 only two variables in the DF election for a given ESI: the existence 111 of the PE's IP address on the candidate list and the locally 112 provisioned Ethernet Tags. 114 If the DF for an fails (due to physical link/node 115 failures) an ES route withdrawn will make the Non-DF (NDF) PEs re- 116 elect the DF for that and the service will be recovered. 118 However the current DF election procedure does not provide a 119 protection against "logical" failures or human errors that may occur 120 at service level on the DF, while the list of active PEs for a given 121 ES does not change. These failures may have an impact not only on the 122 local PE where the issue happens, but also on the rest of the PEs of 123 the ES. Some examples of such logical failures are listed below: 125 a) A given individual Attachment Circuit (AC) defined in an ES is 126 accidentally shutdown or even not provisioned yet (hence the 127 Attachment Circuit Status - ACS - is DOWN), while the ES is 128 operationally active (since the ES route is active). 130 b) A given MAC-VRF - with an ES defined - is shutdown or not 131 provisioned yet, while the ES is operationally active (since the 132 ES route is active). In this case, the ACS of all the AC defined 133 in that MAC-VRF is considered to be DOWN. 135 Neither (a) nor (b) will trigger the DF re-election on the remote PEs 136 for a given ES since the ACS is not taken into account in the DF 137 election procedures. While the ACS is used as a DF election tie- 138 breaker and trigger in [VPLS-MH], there is no procedure defined in 139 [RFC7432] to trigger the DF re-election based on the ACS change on 140 the DF. 142 This document improves the [RFC7432] service-carving procedure so 143 that the ACS may be taken into account as a variable in the DF 144 election, and therefore EVPN can provide protection against logical 145 failures. 147 2. Solution Description 149 The ACS for a given Ethernet Tag on an ES is implicitly conveyed in 150 the corresponding EVPN A-D per EVI route for that given . This section describes how to use the A-D per EVI 152 routes to improve the DF election algorithm. 154 Figure 1 illustrates an example EVPN network that will be used to 155 describe the proposed solution. 157 EVI-1 is defined in PE-1, PE-2, PE-3 and PE-4. CE12 is a multi-homed 158 CE connected to ESI12 in PE-1 and PE-2. Similarly CE23 is multi-homed 159 to PE-2 and PE-3 using ESI23. Both, CE12 and CE23, are connected to 160 EVI-1 through VLAN-based service interfaces: CE12-VID 1 (VLAN ID 1 on 161 CE12) is associated to AC1 and AC2 in EVI-1, whereas CE23-VID 1 is 162 associated to AC3 and AC4 in EVI-1. Note that there are other ACs 163 defined on these ES mapped to different EVIs. 165 +---+ 166 |CE4| 167 +---+ 168 | 169 PE-4 | 170 +-----+-----+ 171 +---------------| +-----+ |---------------+ 172 | | |EVI-1| | | 173 | +-----------+ | 174 | | 175 | EVPN | 176 | | 177 | PE-1 PE-2 PE-3 | 178 | (NDF) (DF) (NDF)| 179 +-----------+ +-----------+ +-----------+ 180 | |EVI-1| | | |EVI-1| | | |EVI-1| | 181 | +-----+ |-------| +-----+ |-------| +-----+ | 182 +-----------+ +-----------+ +-----------+ 183 AC1\ ESI12 /AC2 AC3\ ESI23 /AC4 184 \ / \ / 185 \ / \ / 186 +----+ +----+ 187 |CE12| |CE23| 188 +----+ +----+ 190 Figure 1 EVPN network example 192 2.1. Current DF Election Procedure And AC Failures 194 After running the service-carving DF election algorithm, PE-2 turns 195 out to be the DF for ESI12 and ESI23 in EVI-1. The following two 196 examples illustrate the issues with the existing defined procedure in 197 [RFC7432]: 199 a) If AC2 is accidentally shutdown or even not configured, CE12 200 traffic will be impacted. In case of all-active multi-homing, the BUM 201 traffic to CE12 will be "black-holed", whereas for single-active 202 multi-homing all the traffic to/from CE12 will be discarded. This is 203 due to the fact that a logical failure in PE-2 AC2 may not trigger an 204 ES route withdrawn for ESI12 (since there are still other ACs active 205 on ESI12) and therefore PE-1 will not re-run the DF election 206 procedures. 208 b) If EVI-1 is administratively shutdown or even not configured yet 209 on PE-2, CE12 and CE23 will both be impacted: BUM traffic to both CEs 210 will be discarded in case of all-active multi-homing and all traffic 211 will be discarded to/from the CEs in case of single-active 212 multi-homing. This is due to the fact that PE-1 and PE-3 will not 213 re-run the DF election procedures and will keep assuming PE-2 is the 214 DF. 216 According to [RFC7432], "when an Ethernet tag is decommissioned on an 217 Ethernet segment, then the PE MUST withdraw the Ethernet A-D per EVI 218 route(s) announced for the that are impacted by 219 the decommissioning", however, while this A-D per EVI route 220 withdrawal is used at the remote PEs performing aliasing or backup 221 procedures, it is not used to influence the DF election for the 222 affected EVIs. 224 2.2. The Attachment Circuit (AC) Influenced DF Election 226 Modifying the service-carving DF election procedure in the following 227 way solves the issue: 229 1. When PE-1 and PE-2 discover ESI12, they advertise an ES route for 230 ESI12 with the associated ES-import extended community, starting a 231 timer at the same time. Likewise, PE-2 and PE-3 advertise an ES 232 route for ESI23 and start a timer. 234 2. Similarly, PE-1 and PE-2 advertise an Ethernet A-D per ES route 235 for ESI12, and PE-2/PE-3 advertise an Ethernet A-D per ES route 236 for ESI23. 238 3. In addition, PE-1/PE-2/PE-3 advertise an Ethernet A-D per EVI 239 route for AC1, AC2, AC3 and AC4 as soon as the ACs are enabled. 240 Note that the AC can be associated to a single customer VID (e.g. 241 VLAN-based service interfaces) or a bundle of customer VIDs (e.g. 242 VLAN-bundle service interfaces). 244 4. When the timer expires, each PE builds an ordered "candidate" list 245 of the IP addresses of all the PE nodes connected to the Ethernet 246 Segment (including itself), in increasing numeric order. The 247 candidate list is based on the Originator Router's IP addresses of 248 the ES routes, excluding all the PEs for which no Ethernet A-D per 249 ES route has been received. 251 5. When electing the DF for a given EVI, a PE will not be considered 252 candidate until an Ethernet A-D per EVI route has been received 253 from that PE. In other words, the ACS on the ESI for a given PE 254 must be UP so that the PE is considered as candidate for a given 255 EVI. For example, PE-1 will not consider PE-2 as candidate for DF 256 election for until an Ethernet A-D per EVI route is 257 received from PE-2 for . 259 6. Once the PEs with ACS = DOWN for a given EVI have been eliminated 260 from the candidate list, the (V mod N) = i function can be applied 261 for the remaining N candidates, as per [RFC7432]. 263 Note that this procedure does not modify the existing EVPN control 264 plane whatsoever. It only modifies the candidate list of PEs taken 265 into account for the DF election algorithm defined in [RFC7432]. 267 In addition to the procedure described above, the following events 268 SHALL modify the candidate PE list and trigger the DF re-election in 269 a PE for a given : 271 a) Local ES going DOWN due to a physical failure or reception of an 272 ES route withdraw for that ESI. 274 b) Local ES going UP due to its detection/configuration or reception 275 of a new ES route update for that ESI. 277 c) Local AC going DOWN/UP. 279 d) Reception of a new Ethernet A-D per EVI update/withdraw for the 280 . 282 e) Reception of a new Ethernet A-D per ES update/withdraw for the 283 ESI. 285 This procedure is backwards compatible with the DF election 286 procedures described in [RFC7432] since it does not add any new 287 extension in the control plane, however, a PE not supporting the 288 procedures in this document SHOULD NOT share a multi-homed ES with a 289 PE following this solution since both PEs may end up with an 290 inconsistent view on who the DF is. The AC influenced DF election 291 procedures SHOULD be enabled by an administrative option and only 292 used when all the PEs in the ES support it. 294 The procedure discussed in this section is applicable to the DF 295 Election in EVPN Services [RFC7432] and EVPN Virtual Private Wire 296 Services [RFC8214]. 298 2.3. AC-Influenced DF Election For VLAN-Aware Bundle Services 300 The procedure described section 2.2 works for VLAN-based and VLAN- 301 bundle service interfaces since, for those service types, a PE 302 advertises only one Ethernet A-D per EVI route per . The 303 withdrawal of such route means that the PE cannot forward traffic on 304 that particular . 306 In VLAN-aware bundle services, the PE advertises multiple Ethernet A- 307 D per EVI routes per (one route per Ethernet Tag). The 308 withdrawal of an individual route only indicates the unavailability 309 of a specific AC but not necessarily all the ACs in the . 311 For the specific case of VLAN-aware bundle services, the DF election 312 will be influenced by the update/withdraw of any of the Ethernet A-D 313 per EVI routes in the . 315 For example, assuming three bridge tables in PE-1 for the same MAC- 316 VRF (each one associated to a different Ethernet Tag), PE-1 will 317 advertise three Ethernet A-D per EVI routes for . Each of 318 the three routes will indicate the status of each AC in . 319 PE-1 will be considered as a valid candidate PE for DF election as 320 long as the three routes are active. If PE-1 withdraws one or more of 321 the Ethernet A-D per EVI routes for , the PEs in ESI12 322 will not consider PE-1 as a suitable DF candidate for . 324 3. Solution benefits 326 The solution described in this document provides the following 327 benefits: 329 a) Improves the DF election procedures for EVPN so that failures due 330 to human errors, logical failures or even delay in provisioning of 331 Attachment Circuits can be protected by multi-homing. 333 b) It does not modify or add any BGP new attributes or NLRI changes. 335 c) It is backwards compatible with the procedures defined in RFC7432. 337 4. Conventions used in this document 339 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 340 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 341 document are to be interpreted as described in RFC-2119 [RFC2119]. 343 In this document, these words will appear with that interpretation 344 only when in ALL CAPS. Lower case uses of these words are not to be 345 interpreted as carrying RFC-2119 significance. 347 In this document, the characters ">>" preceding an indented line(s) 348 indicates a compliance requirement statement using the key words 349 listed above. This convention aids reviewers in quickly identifying 350 or finding the explicit compliance requirements of this RFC. 352 5. Security Considerations 354 The same Security Considerations described in [RFC7432] are valid for 355 this document. 357 6. IANA Considerations 359 There are no new IANA considerations in this document. 361 7. References 363 7.1. Normative References 365 [RFC7432] Sajassi, A., Ed., Aggarwal, R., Bitar, N., Isaac, A., 366 Uttaro, J., Drake, J., and W. Henderickx, "BGP MPLS-Based Ethernet 367 VPN", RFC 7432, DOI 10.17487/RFC7432, February 2015, . 370 [RFC8214] Boutros, S., Sajassi, A., Salam, S., Drake, J., Rabadan, 371 J., "Virtual Private Wire Service Support in Ethernet VPN", RFC 8214, 372 DOI 10.17487/RFC8214, August 2017, . 375 7.2. Informative References 377 [VPLS-MH] Kothari, Henderickx et al., "BGP based Multi-homing in 378 Virtual Private LAN Service", draft-ietf-bess-vpls-multihoming- 379 01.txt, work in progress, January, 2016. 381 8. Acknowledgments 383 The authors want to thank Sriram Venkateswaran, Laxmi Padakanti, 384 Ranganathan Boovaraghavan and Ali Sajassi for their review and 385 contributions. 387 9. Contributors 389 In addition to the authors listed on the front page, the following 390 coauthors have also contributed to this document: 392 Wim Henderickx 393 Nokia 394 Email: wim.henderickx@nokia.com 395 Patrice Brissette 396 Cisco Systems 397 Email: pbrisset@cisco.com 399 Authors' Addresses 401 Jorge Rabadan 402 Nokia 403 777 E. Middlefield Road 404 Mountain View, CA 94043 USA 405 Email: jorge.rabadan@nokia.com 407 Kiran Nagaraj 408 Nokia 409 Email: kiran.nagaraj@nokia.com 411 Senthil Sathappan 412 Nokia 413 Email: senthil.sathappan@nokia.com 415 Vinod Prabhu 416 Nokia 417 Email: vinod.prabhu@nokia.com 419 Autumn Liu 420 Ciena 421 Email: hliu@ciena.com 423 Wen Lin 424 Juniper Networks, Inc. 425 Email: wlin@juniper.net