idnits 2.17.1 draft-rabadan-bess-evpn-ac-df-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 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 (October 24, 2014) is 3466 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 350, but not defined == Missing Reference: 'RFC2119' is mentioned on line 464, 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 W. Henderickx 6 Alcatel-Lucent 8 Expires: April 27, 2015 October 24, 2014 10 AC-influenced Designated Forwarder Election for (PBB-)EVPN 11 draft-rabadan-bess-evpn-ac-df-00 13 Abstract 15 The Designated Forwarder (DF) in (PBB-)EVPN networks is the PE 16 responsible for sending multicast, broadcast and unknown unicast 17 traffic to a multi-homed CE, on a given Ethernet Tag on a particular 18 Ethernet Segment (ES). The DF is selected based on the list of PEs 19 that advertise the Ethernet Segment Identifier (ESI) to the EVPN 20 network. While PE node or link failures trigger the DF re-election 21 for a given , individual Attachment Circuit (AC) or MAC-VRF 22 failures do not trigger such DF re-election and the traffic may 23 therefore be permanently impacted, even though there is an 24 alternative path. This document improves the DF election algorithm so 25 that the AC status can influence the result of the election and this 26 type of "logical" failures can be protected too. 28 Status of this Memo 30 This Internet-Draft is submitted in full conformance with the 31 provisions of BCP 78 and BCP 79. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF), its areas, and its working groups. Note that 35 other groups may also distribute working documents as Internet- 36 Drafts. 38 Internet-Drafts are draft documents valid for a maximum of six months 39 and may be updated, replaced, or obsoleted by other documents at any 40 time. It is inappropriate to use Internet-Drafts as reference 41 material or to cite them other than as "work in progress." 43 The list of current Internet-Drafts can be accessed at 44 http://www.ietf.org/ietf/1id-abstracts.txt 45 The list of Internet-Draft Shadow Directories can be accessed at 46 http://www.ietf.org/shadow.html 48 This Internet-Draft will expire on April 27, 2015. 50 Copyright Notice 52 Copyright (c) 2014 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 (http://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. Problem Statement . . . . . . . . . . . . . . . . . . . . . . . 2 68 2. Solution description . . . . . . . . . . . . . . . . . . . . . 4 69 2.1. AC-influenced DF Election for EVPN . . . . . . . . . . . . 4 70 2.1.1. Current DF election procedure and AC failures . . . . . 5 71 2.1.2. The Attachment Circuit (AC) influenced DF election . . 6 72 2.2. AC-influenced DF Election for PBB-EVPN . . . . . . . . . . 7 73 2.2.1. Current DF election procedure and AC failures . . . . . 8 74 2.2.2. BGP encoding for advertising ACS per . . . 9 75 2.2.3. The AC-influenced DF Election . . . . . . . . . . . . . 10 76 3. Solution benefits . . . . . . . . . . . . . . . . . . . . . . . 11 77 4. Conventions used in this document . . . . . . . . . . . . . . . 11 78 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 11 79 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 12 80 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 81 7.1. Normative References . . . . . . . . . . . . . . . . . . . 12 82 7.2. Informative References . . . . . . . . . . . . . . . . . . 12 83 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 12 84 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 86 1. Problem Statement 88 [EVPN] defines the Designated Forwarder (DF) as the (PBB-)EVPN PE 89 responsible for: 91 o Flooding Broadcast, Unknown unicast and Multicast traffic (BUM), on 92 a given Ethernet Tag on a particular Ethernet Segment (ES), to the 93 CE. This is valid for single-active and all-active EVPN 94 multi-homing. 96 o Sending unicast traffic on a given Ethernet Tag on a particular ES 97 to the CE. This is valid for single-active multi-homing. 99 The default DF election algorithm defined by [EVPN] is called 100 service-carving and, for a given ESI, is based on a (V mod N)= i 101 function that provides a local DF election of a PEi at 102 level (for EVPN) and at level for PBB-EVPN. V is the 103 Ethernet Tag associated to the EVI (the numerically lowest Ethernet 104 Tag value in case of multiple Ethernet Tags), whereas N is the number 105 of PEs for which ES routes have been successfully imported. In other 106 words, EVPN's service-carving takes into account only two variables 107 in the DF election for a given ESI: the existence of the PE's IP 108 address on the candidate list and the locally provisioned Ethernet 109 Tags (ISID identifiers in the case of PBB-EVPN). 111 If the DF for an fails (due to physical link/node 112 failures) an ES route withdrawn will make the Non-DF (NDF) PEs re- 113 elect the DF for that and the service will be 114 recovered. 116 However the current DF election procedure does not provide a 117 protection against "logical" failures or human errors that may occur 118 at service level on the DF, while the list of active PEs for a given 119 ESI does not change. These failures may have an impact not only on 120 the local PE where the issue happens, but also on the rest of the PEs 121 of the ESI. Some examples of such logical failures are listed below: 123 a) A given individual Attachment Circuit (AC) defined in an ESI is 124 accidentally shutdown or even not provisioned yet (hence the 125 Attachment Circuit Status - ACS - is DOWN), while the ESI is 126 operationally active (since the ES route is active). 128 b) A given MAC-VRF - with an ESI defined - is shutdown or not 129 provisioned yet, while the ESI is operationally active (since the 130 ES route is active). In this case, the ACS of all the AC defined 131 in that MAC-VRF is considered to be DOWN. 133 Neither (a) nor (b) will trigger the DF re-election on the remote PEs 134 for a given ESI since the ACS is not taken into account in the DF 135 election procedures. While the ACS is used as a DF election tie- 136 breaker and trigger in [VPLS-MH], there is no procedure defined in 137 [EVPN] to trigger the DF re-election based on the ACS change on the 138 DF. 140 This document improves the [EVPN] service-carving procedure so that 141 the ACS may be taken into account as a variable in the DF election, 142 and therefore EVPN can provide protection against logical failures. 144 2. Solution description 146 The ACS for a given Ethernet Tag on an ESI is implicitly conveyed in 147 the corresponding EVPN A-D per EVI route for that given . This section describes how to use the A-D per EVI 149 routes to improve the DF election algorithm in both cases, EVPN and 150 PBB-EVPN. 152 2.1. AC-influenced DF Election for EVPN 154 Figure 1 illustrates an example EVPN network that will be used to 155 describe the proposed solution for EVPN. 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. CE12-VID 1 (VLAN ID 1 on CE12) is 160 associated to AC1 and AC2 in EVI-1, whereas CE23-VID 1 is associated 161 to AC3 and AC4 in EVI-1. Note that there are other ACs defined on 162 these ESIs mapped to different EVIs. 164 +---+ 165 |CE4| 166 +---+ 167 | 168 PE-4 | 169 +-----+-----+ 170 +---------------| +-----+ |---------------+ 171 | | |EVI-1| | | 172 | +-----------+ | 173 | | 174 | EVPN | 175 | | 176 | PE-1 PE-2 PE-3 | 177 | (NDF) (DF) (NDF)| 178 +-----------+ +-----------+ +-----------+ 179 | |EVI-1| | | |EVI-1| | | |EVI-1| | 180 | +-----+ |-------| +-----+ |-------| +-----+ | 181 +-----------+ +-----------+ +-----------+ 182 AC1\ ESI12 /AC2 AC3\ ESI23 /AC4 183 \ / \ / 184 \ / \ / 185 +----+ +----+ 186 |CE12| |CE23| 187 +----+ +----+ 189 Figure 1 EVPN network example 191 2.1.1. Current DF election procedure and AC failures 193 After running the service-carving DF election algorithm, PE-2 turns 194 out to be the DF for ESI12 and ESI23 in EVI-1. The following two 195 examples illustrate the issues with the existing defined procedure in 196 [EVPN]: 198 a) If AC2 is accidentally shutdown or even not configured, CE12 199 traffic will be impacted. In case of all-active multi-homing, only 200 the BUM traffic to CE12 will be impacted, whereas for single-active 201 multi-homing all the traffic to/from CE12 will be discarded. This is 202 due to the fact that a logical failure in PE-2 AC2 will not trigger 203 an ES route withdrawn for ESI12 (since there are still other ACs 204 active on ESI12) and therefore PE-1 will not re-run the DF election 205 procedures. 207 b) If EVI-1 is administratively shutdown or even not configured yet 208 on PE-2, CE12 and CE23 will both be impacted: BUM traffic to both CEs 209 will be discarded in case of all-active multi-homing and all traffic 210 will be discarded to/from the CEs in case of single-active 211 multi-homing. This is due to the fact that PE-1 and PE-3 will not 212 re-run the DF election procedures and will keep assuming PE-2 is the 213 DF. 215 2.1.2. The Attachment Circuit (AC) influenced DF election 217 Modifying the service-carving DF election procedure in the following 218 way solves the issue: 220 1. When PE-1 and PE-2 discover ESI12, they advertise an ES route for 221 ESI12 with the associated ES-import extended community, starting a 222 timer at the same time. Likewise, PE-2 and PE-3 advertise an ES 223 route for ESI23 and start a timer. 225 2. Similarly PE-1 and PE-2 advertise an Ethernet A-D per ES route for 226 ESI12, and PE-2/PE-3 advertise an Ethernet A-D per ES route for 227 ESI23. 229 3. In addition, PE-1/PE-2/PE-3 advertise an Ethernet A-D per EVI 230 route for AC1, AC2, AC3 and AC4 as soon as the ACs are enabled. 232 4. When the timer expires, each PE builds an ordered "candidate" list 233 of the IP addresses of all the PE nodes connected to the Ethernet 234 Segment (including itself), in increasing numeric order. The 235 candidate list is based on the Originator Router's IP addresses of 236 the ES routes, excluding all the PEs for which no Ethernet A-D per 237 ES route has been received. 239 5. When electing the DF for a given EVI, a PE will not be considered 240 candidate until an Ethernet A-D per EVI route has been received 241 from that PE. In other words, the ACS on the ESI for a given PE 242 must be UP so that the PE is considered as candidate for a given 243 EVI. For example, PE-1 will not consider PE-2 as candidate for DF 244 election for until an Ethernet A-D per EVI route is 245 not received from PE-2 for . 247 6. Once the PEs with ACS = DOWN for a given EVI have been eliminated 248 from the candidate list, the (V mod N) = i function can be applied 249 for the remaining N candidates, as per [EVPN]. 251 Note that this procedure does not modify the existing EVPN control 252 plane whatsoever. It only modifies the candidate list of PEs taken 253 into account for the DF election algorithm defined in [EVPN]. 255 In addition to the procedure described above, the following events 256 SHALL modify the candidate PE list and trigger the DF re-election in 257 a PE for a given : 259 a) Local ESI going DOWN due to a physical failure or reception of an 260 ES route withdraw for that ESI. 262 b) Local ESI going UP due to its detection/configuration or reception 263 of a new ES route update for that ESI. 265 c) Local AC going DOWN/UP. 267 d) Reception of a new Ethernet A-D per EVI update/withdraw for the 268 . 270 e) Reception of a new Ethernet A-D per ES update/withdraw for the 271 ESI. 273 2.2. AC-influenced DF Election for PBB-EVPN 275 Figure 2 illustrates an example PBB-EVPN network that will be used to 276 describe the proposed solution for PBB-EVPN. 278 In this case, the B-component EVI-B is defined in BEB-1, BEB-2, BEB- 279 3 and BEB-4 and runs EVPN. An I-component with ISID-N is also defined 280 in all the BEBs and attached to EVI-B as per [PBB-EVPN]. As in the 281 previous section, CE12 and CE 23 are multi-homed CEs connected to 282 ESI12 and ESI23 respectively, but in this case the ACs are associated 283 to the I-component on each BEB. Note that there are other ACs defined 284 on these ESIs mapped to different ISIDs. 286 +---+ 287 |CE4| 288 +---+ 289 | 290 BEB-4 | 291 +-----+-----+ 292 | ISID-N | 293 | | | 294 +---------------| +-----+ |---------------+ 295 | | |EVI-B| | | 296 | +-----------+ | 297 | | 298 | PBB-EVPN | 299 | | 300 | BEB-1 BEB-2 BEB-3 | 301 | (NDF) (DF) (NDF) | 302 +-----------+ +-----------+ +-----------+ 303 | |EVI-B| | | |EVI-B| | | |EVI-B| | 304 | +-----+ | | +-----+ | | +-----+ | 305 | | |-------| | |-------| | | 306 | ISID-N | | ISID-N | | ISID-N | 307 +-----------+ +-----------+ +-----------+ 308 AC1\ ESI12 /AC2 AC3\ ESI23 /AC4 309 \ / \ / 310 \ / \ / 311 +----+ +----+ 312 |CE12| |CE23| 313 +----+ +----+ 315 Figure 2 PBB-EVPN network example 317 2.2.1. Current DF election procedure and AC failures 319 After running the service-carving DF election algorithm, BEB-2 turns 320 out to be the DF for ESI12 and ESI23 in ISID-N. The following two 321 examples illustrate the issues with the existing defined procedure in 322 [EVPN] when applied to PBB-EVPN: 324 a) If AC2 is accidentally shutdown or even not configured, CE12 325 traffic will be impacted - only the BUM traffic to CE12 if all- 326 active multi-homing or all the traffic in case of single-active 327 multi-homing. This is due to the fact that a logical failure in 328 BEB- 2 AC2 will not trigger an ES route withdrawn for ESI12 (since 329 there are still other ACs active on ESI12) and therefore BEB-1 330 will not re-run the DF election procedures. 332 b) If ISID-N is administratively shutdown or even not configured yet 333 on BEB-2, CE12 and CE23 will both be impacted - again only BUM or 334 all the traffic depending on the multi-homing type. This is due to 335 the fact that BEB-1 and BEB-3 will not re-run the DF election 336 procedures and they will keep assuming BEB-2 is the DF. 338 Note that regardless the B-MAC address assignment the user chooses 339 for a PE (shared B-MAC for multiple ES or dedicated B-MAC per ES), 340 the withdrawal of a B-MAC cannot be used as an indication of an 341 individual AC going UP/DOWN. For instance, assuming a dedicated B- 342 MAC per ES is used, when AC2 goes down, BEB-2 will not withdraw the 343 B-MAC for ESI12 since there might be some other ACs in the same ESI 344 using the B-MAC. 346 2.2.2. BGP encoding for advertising ACS per 348 This document proposes the use of an Ethernet A-D per ISID route to 349 advertise the ACS of a given ISID in a given ESI. Note that the 350 Ethernet A-D routes are not used in [PBB-EVPN] hence the procedure 351 described here is OPTIONAL and, if enabled, it MUST be supported in 352 all the BEBs part of the same ESI. The advertisement of ACS SHOULD be 353 administratively enabled at system level and MAY be administratively 354 enabled at ESI level. 356 When enabled, the BEB will advertise an Ethernet A-D per ISID route 357 as per [EVPN] with the following fields: 359 - RD = B-component EVI's RD 360 - ESI = non-reserved ESI where the ISID is defined 361 - Ethernet Tag ID = ISID 362 - MPLS Label = 0 363 - The ES-Import Route Target used by the ES route for the same ESI 365 The ES-Import Route Target will be used in the same way it is used 366 with ES routes. It will only be imported by the BEBs where the ESI is 367 defined and it is subject to RT Constraint procedures [RFC4684]. 369 In the example of Figure 2, BEB-2 will advertise an Ethernet A-D per 370 ISID route for AC2 with the following fields: 372 - RD = EVI-B RD 373 - ESI = ESI12 374 - Ethernet Tag ID = ISID-N 376 And similarly it will send an Ethernet A-D per ISID route for AC3. 378 If AC2 is shutdown, BEB-2 will withdraw the A-D per ISID route for 379 AC2. That will be an indication for BEB-1 that AC2's status is DOWN. 381 If ISID-N is administratively shutdown, BEB-2 will withdraw the A-D 382 per ISID routes for AC2 and AC3. This will be interpreted by BEB-1 383 and BEB-3 respectively as ACS DOWN indications. 385 2.2.3. The AC-influenced DF Election 387 When this procedure is enabled for a given ESI, the BEBs will 388 advertise Ethernet A-D per ISID routes and the DF election procedure 389 will be modified in the following way: 391 1. When BEB-1 and BEB-2 discover ESI12, they advertise an ES route 392 for ESI12 with the associated ES-import extended community, 393 starting a timer at the same time. Likewise, BEB-2 and BEB-3 394 advertise an ES route for ESI23 and start a timer. 396 2. In addition, BEB-1/BEB-2/BEB-3 advertise an Ethernet A-D per ISID 397 route for AC1, AC2, AC3 and AC4 as soon as the ACs are enabled. 399 3. When the timer expires, each PE builds an ordered "candidate" list 400 of the IP addresses of all the PE nodes connected to the Ethernet 401 Segment (including itself), in increasing numeric order. The 402 candidate list is based on the Originator Router's IP addresses of 403 the ES routes. 405 4. When electing the DF for a given ISID, a PE will not be considered 406 candidate until an Ethernet A-D per ISID route has been received 407 from that PE. In other words, the ACS on the ESI for a given PE 408 must be UP so that the PE is considered as candidate for a given 409 ISID. For example, BEB-1 will not consider BEB-2 as candidate for 410 DF election for until an Ethernet A-D per ISID 411 route is not received from BEB-2 for . 413 5. Once the PEs with ACS = DOWN for a given ISID have been eliminated 414 from the candidate list, the (V mod N) = i function can be applied 415 for the remaining N candidates, as per [EVPN]. 417 This procedure modifies the PBB-EVPN control plane procedures, but 418 does not define new routes or attributes. It reuses the components 419 already existing in [EVPN] in order to define a DF election procedure 420 that is consistent for EVPN and PBB-EVPN and protects the network 421 against "logical" failures. 423 In addition to the procedure described above, the following events 424 SHALL modify the candidate PE list and trigger the DF re-election in 425 a PE for a given : 427 a) Local ESI going DOWN due to a physical failure or reception of an 428 ES route withdraw for that ESI. 430 b) Local ESI going UP due to its detection/configuration or reception 431 of a new ES route update for that ESI. 433 c) Local AC going DOWN/UP. 435 d) Reception of a new Ethernet A-D per ISID update/withdraw for the 436 . 438 3. Solution benefits 440 The solution described in this document provides the following 441 benefits: 443 a) Improves the DF election procedures for EVPN so that failures due 444 to human errors, logical failures or even delay in provisioning of 445 Attachment Circuits can be protected by multi-homing. 447 b) The above benefit is added to EVPN without the need to modify or 448 add any BGP new attributes or NLRI changes. 450 c) Improves the DF election procedures for PBB-EVPN so that the same 451 failures as in (a) can be protected by multi-homing also in a 452 PBB-EVPN network. 454 d) The above benefit is provided without adding any BGP new 455 attributes or NLRI changes. It simply re-uses the existing 456 Ethernet A-D route in PBB-EVPN. PBB-EVPN implementations not 457 supporting this document SHOULD ignore Ethernet A-D routes. 459 4. Conventions used in this document 461 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 462 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 463 document are to be interpreted as described in RFC-2119 [RFC2119]. 465 In this document, these words will appear with that interpretation 466 only when in ALL CAPS. Lower case uses of these words are not to be 467 interpreted as carrying RFC-2119 significance. 469 In this document, the characters ">>" preceding an indented line(s) 470 indicates a compliance requirement statement using the key words 471 listed above. This convention aids reviewers in quickly identifying 472 or finding the explicit compliance requirements of this RFC. 474 5. Security Considerations 476 Will be added. 478 6. IANA Considerations 480 Will be added. 482 7. References 484 7.1. Normative References 486 [RFC4684] Marques, P., Bonica, R., Fang, L., Martini, L., Raszuk, 487 R., Patel, K., and J. Guichard, "Constrained Route Distribution for 488 Border Gateway Protocol/MultiProtocol Label Switching (BGP/MPLS) 489 Internet Protocol (IP) Virtual Private Networks (VPNs)", RFC 4684, 490 November 2006, . 492 7.2. Informative References 494 [EVPN] Sajassi et al., "BGP MPLS Based Ethernet VPN", draft-ietf- 495 l2vpn-evpn-11.txt, work in progress, October, 2014 497 [VPLS-MH] Kothari, Henderickx et al., "BGP based Multi-homing in 498 Virtual Private LAN Service", draft-ietf-l2vpn-vpls-multihoming- 499 07.txt, work in progress, July, 2014 501 8. Acknowledgments 503 Will be added. 505 Authors' Addresses 507 Jorge Rabadan 508 Alcatel-Lucent 509 777 E. Middlefield Road 510 Mountain View, CA 94043 USA 511 Email: jorge.rabadan@alcatel-lucent.com 513 Kiran Nagaraj 514 Alcatel-Lucent 515 Email: kiran.nagaraj@alcatel-lucent.com 517 Senthil Sathappan 518 Alcatel-Lucent 519 Email: senthil.sathappan@alcatel-lucent.com 520 Wim Henderickx 521 Alcatel-Lucent 522 Email: wim.henderickx@alcatel-lucent.com