idnits 2.17.1 draft-rabadan-bess-evpn-ac-df-02.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 (July 4, 2015) is 3219 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: 'PBB-EVPN' is mentioned on line 355, but not defined == Missing Reference: 'RFC2119' is mentioned on line 474, but not defined 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 3 Internet Draft K. Nagaraj 4 S. Sathappan 5 Intended status: Standards Track V. Prabhu 6 W. Henderickx 7 Alcatel-Lucent 9 Expires: January 5, 2016 July 4, 2015 11 AC-influenced Designated Forwarder Election for (PBB-)EVPN 12 draft-rabadan-bess-evpn-ac-df-02 14 Abstract 16 The Designated Forwarder (DF) in (PBB-)EVPN networks is the PE 17 responsible for sending multicast, broadcast and unknown unicast 18 traffic to a multi-homed CE, on a given Ethernet Tag on a particular 19 Ethernet Segment (ES). The DF is selected based on the list of PEs 20 that advertise the Ethernet Segment Identifier (ESI) to the EVPN 21 network. While PE node or link failures trigger the DF re-election 22 for a given , individual Attachment Circuit (AC) or MAC-VRF 23 failures do not trigger such DF re-election and the traffic may 24 therefore be permanently impacted, even though there is an 25 alternative path. This document improves the DF election algorithm so 26 that the AC status can influence the result of the election and this 27 type of "logical" failures can be protected too. 29 Status of this Memo 31 This Internet-Draft is submitted in full conformance with the 32 provisions of BCP 78 and BCP 79. 34 Internet-Drafts are working documents of the Internet Engineering 35 Task Force (IETF), its areas, and its working groups. Note that 36 other groups may also distribute working documents as Internet- 37 Drafts. 39 Internet-Drafts are draft documents valid for a maximum of six months 40 and may be updated, replaced, or obsoleted by other documents at any 41 time. It is inappropriate to use Internet-Drafts as reference 42 material or to cite them other than as "work in progress." 44 The list of current Internet-Drafts can be accessed at 45 http://www.ietf.org/ietf/1id-abstracts.txt 46 The list of Internet-Draft Shadow Directories can be accessed at 47 http://www.ietf.org/shadow.html 49 This Internet-Draft will expire on January 5, 2015. 51 Copyright Notice 53 Copyright (c) 2015 IETF Trust and the persons identified as the 54 document authors. All rights reserved. 56 This document is subject to BCP 78 and the IETF Trust's Legal 57 Provisions Relating to IETF Documents 58 (http://trustee.ietf.org/license-info) in effect on the date of 59 publication of this document. Please review these documents 60 carefully, as they describe your rights and restrictions with respect 61 to this document. Code Components extracted from this document must 62 include Simplified BSD License text as described in Section 4.e of 63 the Trust Legal Provisions and are provided without warranty as 64 described in the Simplified BSD License. 66 Table of Contents 68 1. Problem Statement . . . . . . . . . . . . . . . . . . . . . . . 2 69 2. Solution description . . . . . . . . . . . . . . . . . . . . . 4 70 2.1. AC-influenced DF Election for EVPN . . . . . . . . . . . . 4 71 2.1.1. Current DF election procedure and AC failures . . . . . 5 72 2.1.2. The Attachment Circuit (AC) influenced DF election . . 6 73 2.2. AC-influenced DF Election for PBB-EVPN . . . . . . . . . . 7 74 2.2.1. Current DF election procedure and AC failures . . . . . 8 75 2.2.2. BGP encoding for advertising ACS per . . . 9 76 2.2.3. The AC-influenced DF Election . . . . . . . . . . . . . 10 77 3. Solution benefits . . . . . . . . . . . . . . . . . . . . . . . 11 78 4. Conventions used in this document . . . . . . . . . . . . . . . 11 79 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 12 80 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 12 81 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 82 7.1. Normative References . . . . . . . . . . . . . . . . . . . 12 83 7.2. Informative References . . . . . . . . . . . . . . . . . . 12 84 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 12 85 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 87 1. Problem Statement 89 [RFC7432] defines the Designated Forwarder (DF) as the (PBB-)EVPN PE 90 responsible for: 92 o Flooding Broadcast, Unknown unicast and Multicast traffic (BUM), on 93 a given Ethernet Tag on a particular Ethernet Segment (ES), to the 94 CE. This is valid for single-active and all-active EVPN 95 multi-homing. 97 o Sending unicast traffic on a given Ethernet Tag on a particular ES 98 to the CE. This is valid for single-active multi-homing. 100 The default DF election algorithm defined by [RFC7432] is called 101 service-carving and, for a given ESI, is based on a (V mod N)= i 102 function that provides a local DF election of a PEi at 103 level (for EVPN) and at level for PBB-EVPN. V is the 104 Ethernet Tag associated to the EVI (the numerically lowest Ethernet 105 Tag value in case of multiple Ethernet Tags), whereas N is the number 106 of PEs for which ES routes have been successfully imported. In other 107 words, EVPN's service-carving takes into account only two variables 108 in the DF election for a given ESI: the existence of the PE's IP 109 address on the candidate list and the locally provisioned Ethernet 110 Tags (ISID identifiers in the case of PBB-EVPN). 112 If the DF for an fails (due to physical link/node 113 failures) an ES route withdrawn will make the Non-DF (NDF) PEs re- 114 elect the DF for that and the service will be 115 recovered. 117 However the current DF election procedure does not provide a 118 protection against "logical" failures or human errors that may occur 119 at service level on the DF, while the list of active PEs for a given 120 ESI does not change. These failures may have an impact not only on 121 the local PE where the issue happens, but also on the rest of the PEs 122 of the ESI. Some examples of such logical failures are listed below: 124 a) A given individual Attachment Circuit (AC) defined in an ESI is 125 accidentally shutdown or even not provisioned yet (hence the 126 Attachment Circuit Status - ACS - is DOWN), while the ESI is 127 operationally active (since the ES route is active). 129 b) A given MAC-VRF - with an ESI defined - is shutdown or not 130 provisioned yet, while the ESI is operationally active (since the 131 ES route is active). In this case, the ACS of all the AC defined 132 in that MAC-VRF is considered to be DOWN. 134 Neither (a) nor (b) will trigger the DF re-election on the remote PEs 135 for a given ESI since the ACS is not taken into account in the DF 136 election procedures. While the ACS is used as a DF election tie- 137 breaker and trigger in [VPLS-MH], there is no procedure defined in 138 [RFC7432] to trigger the DF re-election based on the ACS change on 139 the DF. 141 This document improves the [RFC7432] service-carving procedure so 142 that the ACS may be taken into account as a variable in the DF 143 election, and therefore EVPN can provide protection against logical 144 failures. 146 2. Solution description 148 The ACS for a given Ethernet Tag on an ESI is implicitly conveyed in 149 the corresponding EVPN A-D per EVI route for that given . This section describes how to use the A-D per EVI 151 routes to improve the DF election algorithm in both cases, EVPN and 152 PBB-EVPN. 154 2.1. AC-influenced DF Election for EVPN 156 Figure 1 illustrates an example EVPN network that will be used to 157 describe the proposed solution for EVPN. 159 EVI-1 is defined in PE-1, PE-2, PE-3 and PE-4. CE12 is a multi-homed 160 CE connected to ESI12 in PE-1 and PE-2. Similarly CE23 is multi-homed 161 to PE-2 and PE-3 using ESI23. CE12-VID 1 (VLAN ID 1 on CE12) is 162 associated to AC1 and AC2 in EVI-1, whereas CE23-VID 1 is associated 163 to AC3 and AC4 in EVI-1. Note that there are other ACs defined on 164 these ESIs mapped to different EVIs. 166 +---+ 167 |CE4| 168 +---+ 169 | 170 PE-4 | 171 +-----+-----+ 172 +---------------| +-----+ |---------------+ 173 | | |EVI-1| | | 174 | +-----------+ | 175 | | 176 | EVPN | 177 | | 178 | PE-1 PE-2 PE-3 | 179 | (NDF) (DF) (NDF)| 180 +-----------+ +-----------+ +-----------+ 181 | |EVI-1| | | |EVI-1| | | |EVI-1| | 182 | +-----+ |-------| +-----+ |-------| +-----+ | 183 +-----------+ +-----------+ +-----------+ 184 AC1\ ESI12 /AC2 AC3\ ESI23 /AC4 185 \ / \ / 186 \ / \ / 187 +----+ +----+ 188 |CE12| |CE23| 189 +----+ +----+ 191 Figure 1 EVPN network example 193 2.1.1. Current DF election procedure and AC failures 195 After running the service-carving DF election algorithm, PE-2 turns 196 out to be the DF for ESI12 and ESI23 in EVI-1. The following two 197 examples illustrate the issues with the existing defined procedure in 198 [RFC7432]: 200 a) If AC2 is accidentally shutdown or even not configured, CE12 201 traffic will be impacted. In case of all-active multi-homing, only 202 the BUM traffic to CE12 will be impacted, whereas for single-active 203 multi-homing all the traffic to/from CE12 will be discarded. This is 204 due to the fact that a logical failure in PE-2 AC2 will not trigger 205 an ES route withdrawn for ESI12 (since there are still other ACs 206 active on ESI12) and therefore PE-1 will not re-run the DF election 207 procedures. 209 b) If EVI-1 is administratively shutdown or even not configured yet 210 on PE-2, CE12 and CE23 will both be impacted: BUM traffic to both CEs 211 will be discarded in case of all-active multi-homing and all traffic 212 will be discarded to/from the CEs in case of single-active 213 multi-homing. This is due to the fact that PE-1 and PE-3 will not 214 re-run the DF election procedures and will keep assuming PE-2 is the 215 DF. 217 2.1.2. The Attachment Circuit (AC) influenced DF election 219 Modifying the service-carving DF election procedure in the following 220 way solves the issue: 222 1. When PE-1 and PE-2 discover ESI12, they advertise an ES route for 223 ESI12 with the associated ES-import extended community, starting a 224 timer at the same time. Likewise, PE-2 and PE-3 advertise an ES 225 route for ESI23 and start a timer. 227 2. Similarly PE-1 and PE-2 advertise an Ethernet A-D per ES route for 228 ESI12, and PE-2/PE-3 advertise an Ethernet A-D per ES route for 229 ESI23. 231 3. In addition, PE-1/PE-2/PE-3 advertise an Ethernet A-D per EVI 232 route for AC1, AC2, AC3 and AC4 as soon as the ACs are enabled. 234 4. When the timer expires, each PE builds an ordered "candidate" list 235 of the IP addresses of all the PE nodes connected to the Ethernet 236 Segment (including itself), in increasing numeric order. The 237 candidate list is based on the Originator Router's IP addresses of 238 the ES routes, excluding all the PEs for which no Ethernet A-D per 239 ES route has been received. 241 5. When electing the DF for a given EVI, a PE will not be considered 242 candidate until an Ethernet A-D per EVI route has been received 243 from that PE. In other words, the ACS on the ESI for a given PE 244 must be UP so that the PE is considered as candidate for a given 245 EVI. For example, PE-1 will not consider PE-2 as candidate for DF 246 election for until an Ethernet A-D per EVI route is 247 not received from PE-2 for . 249 6. Once the PEs with ACS = DOWN for a given EVI have been eliminated 250 from the candidate list, the (V mod N) = i function can be applied 251 for the remaining N candidates, as per [RFC7432]. 253 Note that this procedure does not modify the existing EVPN control 254 plane whatsoever. It only modifies the candidate list of PEs taken 255 into account for the DF election algorithm defined in [RFC7432]. 257 In addition to the procedure described above, the following events 258 SHALL modify the candidate PE list and trigger the DF re-election in 259 a PE for a given : 261 a) Local ESI going DOWN due to a physical failure or reception of an 262 ES route withdraw for that ESI. 264 b) Local ESI going UP due to its detection/configuration or reception 265 of a new ES route update for that ESI. 267 c) Local AC going DOWN/UP. 269 d) Reception of a new Ethernet A-D per EVI update/withdraw for the 270 . 272 e) Reception of a new Ethernet A-D per ES update/withdraw for the 273 ESI. 275 Other DF election algorithm optimizations based on the AC will be 276 added in future versions of this document. 278 2.2. AC-influenced DF Election for PBB-EVPN 280 Figure 2 illustrates an example PBB-EVPN network that will be used to 281 describe the proposed solution for PBB-EVPN. 283 In this case, the B-component EVI-B is defined in BEB-1, BEB-2, BEB- 284 3 and BEB-4 and runs EVPN. An I-component with ISID-N is also defined 285 in all the BEBs and attached to EVI-B as per [PBB-EVPN]. As in the 286 previous section, CE12 and CE 23 are multi-homed CEs connected to 287 ESI12 and ESI23 respectively, but in this case the ACs are associated 288 to the I-component on each BEB. Note that there are other ACs defined 289 on these ESIs mapped to different ISIDs. 291 +---+ 292 |CE4| 293 +---+ 294 | 295 BEB-4 | 296 +-----+-----+ 297 | ISID-N | 298 | | | 299 +---------------| +-----+ |---------------+ 300 | | |EVI-B| | | 301 | +-----------+ | 302 | | 303 | PBB-EVPN | 304 | | 305 | BEB-1 BEB-2 BEB-3 | 306 | (NDF) (DF) (NDF) | 307 +-----------+ +-----------+ +-----------+ 308 | |EVI-B| | | |EVI-B| | | |EVI-B| | 309 | +-----+ | | +-----+ | | +-----+ | 310 | | |-------| | |-------| | | 311 | ISID-N | | ISID-N | | ISID-N | 312 +-----------+ +-----------+ +-----------+ 313 AC1\ ESI12 /AC2 AC3\ ESI23 /AC4 314 \ / \ / 315 \ / \ / 316 +----+ +----+ 317 |CE12| |CE23| 318 +----+ +----+ 320 Figure 2 PBB-EVPN network example 322 2.2.1. Current DF election procedure and AC failures 324 After running the service-carving DF election algorithm, BEB-2 turns 325 out to be the DF for ESI12 and ESI23 in ISID-N. The following two 326 examples illustrate the issues with the existing defined procedure in 327 [RFC7432] when applied to PBB-EVPN: 329 a) If AC2 is accidentally shutdown or even not configured, CE12 330 traffic will be impacted - only the BUM traffic to CE12 if all- 331 active multi-homing or all the traffic in case of single-active 332 multi-homing. This is due to the fact that a logical failure in 333 BEB- 2 AC2 will not trigger an ES route withdrawn for ESI12 (since 334 there are still other ACs active on ESI12) and therefore BEB-1 335 will not re-run the DF election procedures. 337 b) If ISID-N is administratively shutdown or even not configured yet 338 on BEB-2, CE12 and CE23 will both be impacted - again only BUM or 339 all the traffic depending on the multi-homing type. This is due to 340 the fact that BEB-1 and BEB-3 will not re-run the DF election 341 procedures and they will keep assuming BEB-2 is the DF. 343 Note that regardless the B-MAC address assignment the user chooses 344 for a PE (shared B-MAC for multiple ES or dedicated B-MAC per ES), 345 the withdrawal of a B-MAC cannot be used as an indication of an 346 individual AC going UP/DOWN. For instance, assuming a dedicated B- 347 MAC per ES is used, when AC2 goes down, BEB-2 will not withdraw the 348 B-MAC for ESI12 since there might be some other ACs in the same ESI 349 using the B-MAC. 351 2.2.2. BGP encoding for advertising ACS per 353 This document proposes the use of an Ethernet A-D per ISID route to 354 advertise the ACS of a given ISID in a given ESI. Note that the 355 Ethernet A-D routes are not used in [PBB-EVPN] hence the procedure 356 described here is OPTIONAL and, if enabled, it MUST be supported in 357 all the BEBs part of the same ESI. The advertisement of ACS SHOULD be 358 administratively enabled at system level and MAY be administratively 359 enabled at ESI level. 361 When enabled, the BEB will advertise an Ethernet A-D per ISID route 362 as per [RFC7432] with the following fields: 364 - RD = B-component EVI's RD 365 - ESI = non-reserved ESI where the ISID is defined 366 - Ethernet Tag ID = ISID 367 - MPLS Label = 0 368 - The ES-Import Route Target used by the ES route for the same ESI 370 The ES-Import Route Target will be used in the same way it is used 371 with ES routes. It will only be imported by the BEBs where the ESI is 372 defined and it is subject to RT Constraint procedures [RFC4684]. 374 In the example of Figure 2, BEB-2 will advertise an Ethernet A-D per 375 ISID route for AC2 with the following fields: 377 - RD = EVI-B RD 378 - ESI = ESI12 379 - Ethernet Tag ID = ISID-N 381 And similarly it will send an Ethernet A-D per ISID route for AC3. 383 If AC2 is shutdown, BEB-2 will withdraw the A-D per ISID route for 384 AC2. That will be an indication for BEB-1 that AC2's status is DOWN. 386 If ISID-N is administratively shutdown, BEB-2 will withdraw the A-D 387 per ISID routes for AC2 and AC3. This will be interpreted by BEB-1 388 and BEB-3 respectively as ACS DOWN indications. 390 Note that, in order to guarantee backwards compatibility with PBB- 391 EVPN PEs not supporting the AC-influenced DF Election, an indication 392 MAY be used along with the ES route. More details will be added in 393 future versions of this document. 395 2.2.3. The AC-influenced DF Election 397 When this procedure is enabled for a given ESI, the BEBs will 398 advertise Ethernet A-D per ISID routes and the DF election procedure 399 will be modified in the following way: 401 1. When BEB-1 and BEB-2 discover ESI12, they advertise an ES route 402 for ESI12 with the associated ES-import extended community, 403 starting a timer at the same time. Likewise, BEB-2 and BEB-3 404 advertise an ES route for ESI23 and start a timer. 406 2. In addition, BEB-1/BEB-2/BEB-3 advertise an Ethernet A-D per ISID 407 route for AC1, AC2, AC3 and AC4 as soon as the ACs are enabled. 409 3. When the timer expires, each PE builds an ordered "candidate" list 410 of the IP addresses of all the PE nodes connected to the Ethernet 411 Segment (including itself), in increasing numeric order. The 412 candidate list is based on the Originator Router's IP addresses of 413 the ES routes. 415 4. When electing the DF for a given ISID, a PE will not be considered 416 candidate until an Ethernet A-D per ISID route has been received 417 from that PE. In other words, the ACS on the ESI for a given PE 418 must be UP so that the PE is considered as candidate for a given 419 ISID. For example, BEB-1 will not consider BEB-2 as candidate for 420 DF election for until an Ethernet A-D per ISID 421 route is not received from BEB-2 for . 423 5. Once the PEs with ACS = DOWN for a given ISID have been eliminated 424 from the candidate list, the (V mod N) = i function can be applied 425 for the remaining N candidates, as per [RFC7432]. 427 This procedure modifies the PBB-EVPN control plane procedures, but 428 does not define new routes or attributes. It reuses the components 429 already existing in [RFC7432] in order to define a DF election 430 procedure that is consistent for EVPN and PBB-EVPN and protects the 431 network against "logical" failures. 433 In addition to the procedure described above, the following events 434 SHALL modify the candidate PE list and trigger the DF re-election in 435 a PE for a given : 437 a) Local ESI going DOWN due to a physical failure or reception of an 438 ES route withdraw for that ESI. 440 b) Local ESI going UP due to its detection/configuration or reception 441 of a new ES route update for that ESI. 443 c) Local AC going DOWN/UP. 445 d) Reception of a new Ethernet A-D per ISID update/withdraw for the 446 . 448 3. Solution benefits 450 The solution described in this document provides the following 451 benefits: 453 a) Improves the DF election procedures for EVPN so that failures due 454 to human errors, logical failures or even delay in provisioning of 455 Attachment Circuits can be protected by multi-homing. 457 b) The above benefit is added to EVPN without the need to modify or 458 add any BGP new attributes or NLRI changes. 460 c) Improves the DF election procedures for PBB-EVPN so that the same 461 failures as in (a) can be protected by multi-homing also in a 462 PBB-EVPN network. 464 d) The above benefit is provided without adding any BGP new 465 attributes or NLRI changes. It simply re-uses the existing 466 Ethernet A-D route in PBB-EVPN. PBB-EVPN implementations not 467 supporting this document SHOULD ignore Ethernet A-D routes. 469 4. Conventions used in this document 471 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 472 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 473 document are to be interpreted as described in RFC-2119 [RFC2119]. 475 In this document, these words will appear with that interpretation 476 only when in ALL CAPS. Lower case uses of these words are not to be 477 interpreted as carrying RFC-2119 significance. 479 In this document, the characters ">>" preceding an indented line(s) 480 indicates a compliance requirement statement using the key words 481 listed above. This convention aids reviewers in quickly identifying 482 or finding the explicit compliance requirements of this RFC. 484 5. Security Considerations 486 Will be added. 488 6. IANA Considerations 490 Will be added. 492 7. References 494 7.1. Normative References 496 [RFC4684] Marques, P., Bonica, R., Fang, L., Martini, L., Raszuk, 497 R., Patel, K., and J. Guichard, "Constrained Route Distribution for 498 Border Gateway Protocol/MultiProtocol Label Switching (BGP/MPLS) 499 Internet Protocol (IP) Virtual Private Networks (VPNs)", RFC 4684, 500 DOI 10.17487/RFC4684, November 2006, . 503 [RFC7432] Sajassi, A., Ed., Aggarwal, R., Bitar, N., Isaac, A., 504 Uttaro, J., Drake, J., and W. Henderickx, "BGP MPLS-Based Ethernet 505 VPN", RFC 7432, DOI 10.17487/RFC7432, February 2015, . 508 7.2. Informative References 510 [VPLS-MH] Kothari, Henderickx et al., "BGP based Multi-homing in 511 Virtual Private LAN Service", draft-ietf-l2vpn-vpls-multihoming- 512 07.txt, work in progress, July, 2014 514 8. Acknowledgments 516 Will be added. 518 Authors' Addresses 520 Jorge Rabadan 521 Alcatel-Lucent 522 777 E. Middlefield Road 523 Mountain View, CA 94043 USA 524 Email: jorge.rabadan@alcatel-lucent.com 526 Kiran Nagaraj 527 Alcatel-Lucent 528 Email: kiran.nagaraj@alcatel-lucent.com 530 Senthil Sathappan 531 Alcatel-Lucent 532 Email: senthil.sathappan@alcatel-lucent.com 534 Vinod Prabhu 535 Alcatel-Lucent 536 Email: vinod.prabhu@alcatel-lucent.com 538 Wim Henderickx 539 Alcatel-Lucent 540 Email: wim.henderickx@alcatel-lucent.com