idnits 2.17.1 draft-rabadan-bess-evpn-ac-df-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 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 27, 2014) is 3463 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 354, but not defined == Missing Reference: 'RFC2119' is mentioned on line 468, 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: April 30, 2015 October 27, 2014 11 AC-influenced Designated Forwarder Election for (PBB-)EVPN 12 draft-rabadan-bess-evpn-ac-df-01 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 April 30, 2015. 51 Copyright Notice 53 Copyright (c) 2014 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 . . . . . . . . . . . . . . . . . . . . 11 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 [EVPN] 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 [EVPN] 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 [EVPN] to trigger the DF re-election based on the ACS change on the 139 DF. 141 This document improves the [EVPN] service-carving procedure so that 142 the ACS may be taken into account as a variable in the DF election, 143 and therefore EVPN can provide protection against logical failures. 145 2. Solution description 147 The ACS for a given Ethernet Tag on an ESI is implicitly conveyed in 148 the corresponding EVPN A-D per EVI route for that given . This section describes how to use the A-D per EVI 150 routes to improve the DF election algorithm in both cases, EVPN and 151 PBB-EVPN. 153 2.1. AC-influenced DF Election for EVPN 155 Figure 1 illustrates an example EVPN network that will be used to 156 describe the proposed solution for EVPN. 158 EVI-1 is defined in PE-1, PE-2, PE-3 and PE-4. CE12 is a multi-homed 159 CE connected to ESI12 in PE-1 and PE-2. Similarly CE23 is multi-homed 160 to PE-2 and PE-3 using ESI23. CE12-VID 1 (VLAN ID 1 on CE12) is 161 associated to AC1 and AC2 in EVI-1, whereas CE23-VID 1 is associated 162 to AC3 and AC4 in EVI-1. Note that there are other ACs defined on 163 these ESIs 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.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 [EVPN]: 199 a) If AC2 is accidentally shutdown or even not configured, CE12 200 traffic will be impacted. In case of all-active multi-homing, only 201 the BUM traffic to CE12 will be impacted, 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 will not trigger 204 an ES route withdrawn for ESI12 (since there are still other ACs 205 active 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 2.1.2. The Attachment Circuit (AC) influenced DF election 218 Modifying the service-carving DF election procedure in the following 219 way solves the issue: 221 1. When PE-1 and PE-2 discover ESI12, they advertise an ES route for 222 ESI12 with the associated ES-import extended community, starting a 223 timer at the same time. Likewise, PE-2 and PE-3 advertise an ES 224 route for ESI23 and start a timer. 226 2. Similarly PE-1 and PE-2 advertise an Ethernet A-D per ES route for 227 ESI12, and PE-2/PE-3 advertise an Ethernet A-D per ES route for 228 ESI23. 230 3. In addition, PE-1/PE-2/PE-3 advertise an Ethernet A-D per EVI 231 route for AC1, AC2, AC3 and AC4 as soon as the ACs are enabled. 233 4. When the timer expires, each PE builds an ordered "candidate" list 234 of the IP addresses of all the PE nodes connected to the Ethernet 235 Segment (including itself), in increasing numeric order. The 236 candidate list is based on the Originator Router's IP addresses of 237 the ES routes, excluding all the PEs for which no Ethernet A-D per 238 ES route has been received. 240 5. When electing the DF for a given EVI, a PE will not be considered 241 candidate until an Ethernet A-D per EVI route has been received 242 from that PE. In other words, the ACS on the ESI for a given PE 243 must be UP so that the PE is considered as candidate for a given 244 EVI. For example, PE-1 will not consider PE-2 as candidate for DF 245 election for until an Ethernet A-D per EVI route is 246 not received from PE-2 for . 248 6. Once the PEs with ACS = DOWN for a given EVI have been eliminated 249 from the candidate list, the (V mod N) = i function can be applied 250 for the remaining N candidates, as per [EVPN]. 252 Note that this procedure does not modify the existing EVPN control 253 plane whatsoever. It only modifies the candidate list of PEs taken 254 into account for the DF election algorithm defined in [EVPN]. 256 In addition to the procedure described above, the following events 257 SHALL modify the candidate PE list and trigger the DF re-election in 258 a PE for a given : 260 a) Local ESI going DOWN due to a physical failure or reception of an 261 ES route withdraw for that ESI. 263 b) Local ESI going UP due to its detection/configuration or reception 264 of a new ES route update for that ESI. 266 c) Local AC going DOWN/UP. 268 d) Reception of a new Ethernet A-D per EVI update/withdraw for the 269 . 271 e) Reception of a new Ethernet A-D per ES update/withdraw for the 272 ESI. 274 Other DF election algorithm optimizations based on the AC will be 275 added in future versions of this document. 277 2.2. AC-influenced DF Election for PBB-EVPN 279 Figure 2 illustrates an example PBB-EVPN network that will be used to 280 describe the proposed solution for PBB-EVPN. 282 In this case, the B-component EVI-B is defined in BEB-1, BEB-2, BEB- 283 3 and BEB-4 and runs EVPN. An I-component with ISID-N is also defined 284 in all the BEBs and attached to EVI-B as per [PBB-EVPN]. As in the 285 previous section, CE12 and CE 23 are multi-homed CEs connected to 286 ESI12 and ESI23 respectively, but in this case the ACs are associated 287 to the I-component on each BEB. Note that there are other ACs defined 288 on these ESIs mapped to different ISIDs. 290 +---+ 291 |CE4| 292 +---+ 293 | 294 BEB-4 | 295 +-----+-----+ 296 | ISID-N | 297 | | | 298 +---------------| +-----+ |---------------+ 299 | | |EVI-B| | | 300 | +-----------+ | 301 | | 302 | PBB-EVPN | 303 | | 304 | BEB-1 BEB-2 BEB-3 | 305 | (NDF) (DF) (NDF) | 306 +-----------+ +-----------+ +-----------+ 307 | |EVI-B| | | |EVI-B| | | |EVI-B| | 308 | +-----+ | | +-----+ | | +-----+ | 309 | | |-------| | |-------| | | 310 | ISID-N | | ISID-N | | ISID-N | 311 +-----------+ +-----------+ +-----------+ 312 AC1\ ESI12 /AC2 AC3\ ESI23 /AC4 313 \ / \ / 314 \ / \ / 315 +----+ +----+ 316 |CE12| |CE23| 317 +----+ +----+ 319 Figure 2 PBB-EVPN network example 321 2.2.1. Current DF election procedure and AC failures 323 After running the service-carving DF election algorithm, BEB-2 turns 324 out to be the DF for ESI12 and ESI23 in ISID-N. The following two 325 examples illustrate the issues with the existing defined procedure in 326 [EVPN] when applied to PBB-EVPN: 328 a) If AC2 is accidentally shutdown or even not configured, CE12 329 traffic will be impacted - only the BUM traffic to CE12 if all- 330 active multi-homing or all the traffic in case of single-active 331 multi-homing. This is due to the fact that a logical failure in 332 BEB- 2 AC2 will not trigger an ES route withdrawn for ESI12 (since 333 there are still other ACs active on ESI12) and therefore BEB-1 334 will not re-run the DF election procedures. 336 b) If ISID-N is administratively shutdown or even not configured yet 337 on BEB-2, CE12 and CE23 will both be impacted - again only BUM or 338 all the traffic depending on the multi-homing type. This is due to 339 the fact that BEB-1 and BEB-3 will not re-run the DF election 340 procedures and they will keep assuming BEB-2 is the DF. 342 Note that regardless the B-MAC address assignment the user chooses 343 for a PE (shared B-MAC for multiple ES or dedicated B-MAC per ES), 344 the withdrawal of a B-MAC cannot be used as an indication of an 345 individual AC going UP/DOWN. For instance, assuming a dedicated B- 346 MAC per ES is used, when AC2 goes down, BEB-2 will not withdraw the 347 B-MAC for ESI12 since there might be some other ACs in the same ESI 348 using the B-MAC. 350 2.2.2. BGP encoding for advertising ACS per 352 This document proposes the use of an Ethernet A-D per ISID route to 353 advertise the ACS of a given ISID in a given ESI. Note that the 354 Ethernet A-D routes are not used in [PBB-EVPN] hence the procedure 355 described here is OPTIONAL and, if enabled, it MUST be supported in 356 all the BEBs part of the same ESI. The advertisement of ACS SHOULD be 357 administratively enabled at system level and MAY be administratively 358 enabled at ESI level. 360 When enabled, the BEB will advertise an Ethernet A-D per ISID route 361 as per [EVPN] with the following fields: 363 - RD = B-component EVI's RD 364 - ESI = non-reserved ESI where the ISID is defined 365 - Ethernet Tag ID = ISID 366 - MPLS Label = 0 367 - The ES-Import Route Target used by the ES route for the same ESI 369 The ES-Import Route Target will be used in the same way it is used 370 with ES routes. It will only be imported by the BEBs where the ESI is 371 defined and it is subject to RT Constraint procedures [RFC4684]. 373 In the example of Figure 2, BEB-2 will advertise an Ethernet A-D per 374 ISID route for AC2 with the following fields: 376 - RD = EVI-B RD 377 - ESI = ESI12 378 - Ethernet Tag ID = ISID-N 380 And similarly it will send an Ethernet A-D per ISID route for AC3. 382 If AC2 is shutdown, BEB-2 will withdraw the A-D per ISID route for 383 AC2. That will be an indication for BEB-1 that AC2's status is DOWN. 385 If ISID-N is administratively shutdown, BEB-2 will withdraw the A-D 386 per ISID routes for AC2 and AC3. This will be interpreted by BEB-1 387 and BEB-3 respectively as ACS DOWN indications. 389 2.2.3. The AC-influenced DF Election 391 When this procedure is enabled for a given ESI, the BEBs will 392 advertise Ethernet A-D per ISID routes and the DF election procedure 393 will be modified in the following way: 395 1. When BEB-1 and BEB-2 discover ESI12, they advertise an ES route 396 for ESI12 with the associated ES-import extended community, 397 starting a timer at the same time. Likewise, BEB-2 and BEB-3 398 advertise an ES route for ESI23 and start a timer. 400 2. In addition, BEB-1/BEB-2/BEB-3 advertise an Ethernet A-D per ISID 401 route for AC1, AC2, AC3 and AC4 as soon as the ACs are enabled. 403 3. When the timer expires, each PE builds an ordered "candidate" list 404 of the IP addresses of all the PE nodes connected to the Ethernet 405 Segment (including itself), in increasing numeric order. The 406 candidate list is based on the Originator Router's IP addresses of 407 the ES routes. 409 4. When electing the DF for a given ISID, a PE will not be considered 410 candidate until an Ethernet A-D per ISID route has been received 411 from that PE. In other words, the ACS on the ESI for a given PE 412 must be UP so that the PE is considered as candidate for a given 413 ISID. For example, BEB-1 will not consider BEB-2 as candidate for 414 DF election for until an Ethernet A-D per ISID 415 route is not received from BEB-2 for . 417 5. Once the PEs with ACS = DOWN for a given ISID have been eliminated 418 from the candidate list, the (V mod N) = i function can be applied 419 for the remaining N candidates, as per [EVPN]. 421 This procedure modifies the PBB-EVPN control plane procedures, but 422 does not define new routes or attributes. It reuses the components 423 already existing in [EVPN] in order to define a DF election procedure 424 that is consistent for EVPN and PBB-EVPN and protects the network 425 against "logical" failures. 427 In addition to the procedure described above, the following events 428 SHALL modify the candidate PE list and trigger the DF re-election in 429 a PE for a given : 431 a) Local ESI going DOWN due to a physical failure or reception of an 432 ES route withdraw for that ESI. 434 b) Local ESI going UP due to its detection/configuration or reception 435 of a new ES route update for that ESI. 437 c) Local AC going DOWN/UP. 439 d) Reception of a new Ethernet A-D per ISID update/withdraw for the 440 . 442 3. Solution benefits 444 The solution described in this document provides the following 445 benefits: 447 a) Improves the DF election procedures for EVPN so that failures due 448 to human errors, logical failures or even delay in provisioning of 449 Attachment Circuits can be protected by multi-homing. 451 b) The above benefit is added to EVPN without the need to modify or 452 add any BGP new attributes or NLRI changes. 454 c) Improves the DF election procedures for PBB-EVPN so that the same 455 failures as in (a) can be protected by multi-homing also in a 456 PBB-EVPN network. 458 d) The above benefit is provided without adding any BGP new 459 attributes or NLRI changes. It simply re-uses the existing 460 Ethernet A-D route in PBB-EVPN. PBB-EVPN implementations not 461 supporting this document SHOULD ignore Ethernet A-D routes. 463 4. Conventions used in this document 465 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 466 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 467 document are to be interpreted as described in RFC-2119 [RFC2119]. 469 In this document, these words will appear with that interpretation 470 only when in ALL CAPS. Lower case uses of these words are not to be 471 interpreted as carrying RFC-2119 significance. 473 In this document, the characters ">>" preceding an indented line(s) 474 indicates a compliance requirement statement using the key words 475 listed above. This convention aids reviewers in quickly identifying 476 or finding the explicit compliance requirements of this RFC. 478 5. Security Considerations 480 Will be added. 482 6. IANA Considerations 484 Will be added. 486 7. References 488 7.1. Normative References 490 [RFC4684] Marques, P., Bonica, R., Fang, L., Martini, L., Raszuk, 491 R., Patel, K., and J. Guichard, "Constrained Route Distribution for 492 Border Gateway Protocol/MultiProtocol Label Switching (BGP/MPLS) 493 Internet Protocol (IP) Virtual Private Networks (VPNs)", RFC 4684, 494 November 2006, . 496 7.2. Informative References 498 [EVPN] Sajassi et al., "BGP MPLS Based Ethernet VPN", draft-ietf- 499 l2vpn-evpn-11.txt, work in progress, October, 2014 501 [VPLS-MH] Kothari, Henderickx et al., "BGP based Multi-homing in 502 Virtual Private LAN Service", draft-ietf-l2vpn-vpls-multihoming- 503 07.txt, work in progress, July, 2014 505 8. Acknowledgments 507 Will be added. 509 Authors' Addresses 511 Jorge Rabadan 512 Alcatel-Lucent 513 777 E. Middlefield Road 514 Mountain View, CA 94043 USA 515 Email: jorge.rabadan@alcatel-lucent.com 517 Kiran Nagaraj 518 Alcatel-Lucent 519 Email: kiran.nagaraj@alcatel-lucent.com 521 Senthil Sathappan 522 Alcatel-Lucent 523 Email: senthil.sathappan@alcatel-lucent.com 524 Vinod Prabhu 525 Alcatel-Lucent 526 Email: vinod.prabhu@alcatel-lucent.com 528 Wim Henderickx 529 Alcatel-Lucent 530 Email: wim.henderickx@alcatel-lucent.com