idnits 2.17.1 draft-rabadan-bess-evpn-ac-df-04.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 7, 2016) is 2850 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'RFC2119' is mentioned on line 300, but not defined == Unused Reference: 'RFC4684' is defined on line 323, but no explicit reference was found in the text == Outdated reference: A later version (-05) exists of draft-ietf-bess-vpls-multihoming-01 Summary: 1 error (**), 0 flaws (~~), 4 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: Informational V. Prabhu 6 W. Henderickx 7 Nokia 9 A. Liu 10 Ericsson 12 Expires: January 8, 2017 July 7, 2016 14 AC-influenced Designated Forwarder Election for EVPN 15 draft-rabadan-bess-evpn-ac-df-04 17 Abstract 19 The Designated Forwarder (DF) in EVPN networks is the PE responsible 20 for sending multicast, broadcast and unknown unicast traffic to a 21 multi-homed CE, on a given Ethernet Tag on a particular Ethernet 22 Segment (ES). The DF is selected based on the list of PEs that 23 advertise the Ethernet Segment Identifier (ESI) to the EVPN network. 24 While PE node or link failures trigger the DF re-election for a given 25 , individual Attachment Circuit (AC) or MAC-VRF failures do 26 not trigger such DF re-election and the traffic may therefore be 27 permanently impacted, even though there is an alternative path. This 28 document improves the DF election algorithm so that the AC status can 29 influence the result of the election and this type of "logical" 30 failures can be protected too. 32 Status of this Memo 34 This Internet-Draft is submitted in full conformance with the 35 provisions of BCP 78 and BCP 79. 37 Internet-Drafts are working documents of the Internet Engineering 38 Task Force (IETF), its areas, and its working groups. Note that 39 other groups may also distribute working documents as Internet- 40 Drafts. 42 Internet-Drafts are draft documents valid for a maximum of six months 43 and may be updated, replaced, or obsoleted by other documents at any 44 time. It is inappropriate to use Internet-Drafts as reference 45 material or to cite them other than as "work in progress." 46 The list of current Internet-Drafts can be accessed at 47 http://www.ietf.org/ietf/1id-abstracts.txt 49 The list of Internet-Draft Shadow Directories can be accessed at 50 http://www.ietf.org/shadow.html 52 This Internet-Draft will expire on January 8, 2017. 54 Copyright Notice 56 Copyright (c) 2016 IETF Trust and the persons identified as the 57 document authors. All rights reserved. 59 This document is subject to BCP 78 and the IETF Trust's Legal 60 Provisions Relating to IETF Documents 61 (http://trustee.ietf.org/license-info) in effect on the date of 62 publication of this document. Please review these documents 63 carefully, as they describe your rights and restrictions with respect 64 to this document. Code Components extracted from this document must 65 include Simplified BSD License text as described in Section 4.e of 66 the Trust Legal Provisions and are provided without warranty as 67 described in the Simplified BSD License. 69 Table of Contents 71 1. Problem Statement . . . . . . . . . . . . . . . . . . . . . . . 2 72 2. Solution description . . . . . . . . . . . . . . . . . . . . . 4 73 2.1. Current DF election procedure and AC failures . . . . . . . 5 74 2.2. The Attachment Circuit (AC) influenced DF election . . . . 5 75 3. Solution benefits . . . . . . . . . . . . . . . . . . . . . . . 7 76 4. Conventions used in this document . . . . . . . . . . . . . . . 7 77 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 7 78 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7 79 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 80 7.1. Normative References . . . . . . . . . . . . . . . . . . . 7 81 7.2. Informative References . . . . . . . . . . . . . . . . . . 8 82 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 8 83 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8 85 1. Problem Statement 87 [RFC7432] defines the Designated Forwarder (DF) as the EVPN PE 88 responsible for: 90 o Flooding Broadcast, Unknown unicast and Multicast traffic (BUM), on 91 a given Ethernet Tag on a particular Ethernet Segment (ES), to the 92 CE. This is valid for single-active and all-active EVPN 93 multi-homing. 95 o Sending unicast traffic on a given Ethernet Tag on a particular ES 96 to the CE. This is valid for single-active multi-homing. 98 The default DF election algorithm defined by [RFC7432] is called 99 service-carving and, for a given ESI, is based on a (V mod N)= i 100 function that provides a local DF election of a PEi at 101 level. V is the Ethernet Tag associated to the EVI (the numerically 102 lowest Ethernet Tag value in case of multiple Ethernet Tags), whereas 103 N is the number of PEs for which ES routes have been successfully 104 imported. In other words, EVPN's service-carving takes into account 105 only two variables in the DF election for a given ESI: the existence 106 of the PE's IP address on the candidate list and the locally 107 provisioned Ethernet Tags. 109 If the DF for an fails (due to physical link/node 110 failures) an ES route withdrawn will make the Non-DF (NDF) PEs re- 111 elect the DF for that and the service will be recovered. 113 However the current DF election procedure does not provide a 114 protection against "logical" failures or human errors that may occur 115 at service level on the DF, while the list of active PEs for a given 116 ES does not change. These failures may have an impact not only on the 117 local PE where the issue happens, but also on the rest of the PEs of 118 the ES. Some examples of such logical failures are listed below: 120 a) A given individual Attachment Circuit (AC) defined in an ES is 121 accidentally shutdown or even not provisioned yet (hence the 122 Attachment Circuit Status - ACS - is DOWN), while the ES is 123 operationally active (since the ES route is active). 125 b) A given MAC-VRF - with an ES defined - is shutdown or not 126 provisioned yet, while the ES is operationally active (since the 127 ES route is active). In this case, the ACS of all the AC defined 128 in that MAC-VRF is considered to be DOWN. 130 Neither (a) nor (b) will trigger the DF re-election on the remote PEs 131 for a given ES since the ACS is not taken into account in the DF 132 election procedures. While the ACS is used as a DF election tie- 133 breaker and trigger in [VPLS-MH], there is no procedure defined in 134 [RFC7432] to trigger the DF re-election based on the ACS change on 135 the DF. 137 This document improves the [RFC7432] service-carving procedure so 138 that the ACS may be taken into account as a variable in the DF 139 election, and therefore EVPN can provide protection against logical 140 failures. 142 2. Solution description 144 The ACS for a given Ethernet Tag on an ESI is implicitly conveyed in 145 the corresponding EVPN A-D per EVI route for that given . This section describes how to use the A-D per EVI 147 routes to improve the DF election algorithm. 149 Figure 1 illustrates an example EVPN network that will be used to 150 describe the proposed solution. 152 EVI-1 is defined in PE-1, PE-2, PE-3 and PE-4. CE12 is a multi-homed 153 CE connected to ESI12 in PE-1 and PE-2. Similarly CE23 is multi-homed 154 to PE-2 and PE-3 using ESI23. CE12-VID 1 (VLAN ID 1 on CE12) is 155 associated to AC1 and AC2 in EVI-1, whereas CE23-VID 1 is associated 156 to AC3 and AC4 in EVI-1. Note that there are other ACs defined on 157 these ESIs mapped to different EVIs. 159 +---+ 160 |CE4| 161 +---+ 162 | 163 PE-4 | 164 +-----+-----+ 165 +---------------| +-----+ |---------------+ 166 | | |EVI-1| | | 167 | +-----------+ | 168 | | 169 | EVPN | 170 | | 171 | PE-1 PE-2 PE-3 | 172 | (NDF) (DF) (NDF)| 173 +-----------+ +-----------+ +-----------+ 174 | |EVI-1| | | |EVI-1| | | |EVI-1| | 175 | +-----+ |-------| +-----+ |-------| +-----+ | 176 +-----------+ +-----------+ +-----------+ 177 AC1\ ESI12 /AC2 AC3\ ESI23 /AC4 178 \ / \ / 179 \ / \ / 180 +----+ +----+ 181 |CE12| |CE23| 182 +----+ +----+ 184 Figure 1 EVPN network example 186 2.1. Current DF election procedure and AC failures 188 After running the service-carving DF election algorithm, PE-2 turns 189 out to be the DF for ESI12 and ESI23 in EVI-1. The following two 190 examples illustrate the issues with the existing defined procedure in 191 [RFC7432]: 193 a) If AC2 is accidentally shutdown or even not configured, CE12 194 traffic will be impacted. In case of all-active multi-homing, only 195 the BUM traffic to CE12 will be impacted, whereas for single-active 196 multi-homing all the traffic to/from CE12 will be discarded. This is 197 due to the fact that a logical failure in PE-2 AC2 will not trigger 198 an ES route withdrawn for ESI12 (since there are still other ACs 199 active on ESI12) and therefore PE-1 will not re-run the DF election 200 procedures. 202 b) If EVI-1 is administratively shutdown or even not configured yet 203 on PE-2, CE12 and CE23 will both be impacted: BUM traffic to both CEs 204 will be discarded in case of all-active multi-homing and all traffic 205 will be discarded to/from the CEs in case of single-active 206 multi-homing. This is due to the fact that PE-1 and PE-3 will not 207 re-run the DF election procedures and will keep assuming PE-2 is the 208 DF. 210 According to [RFC7432], "when an Ethernet tag is decommissioned on an 211 Ethernet segment, then the PE MUST withdraw the Ethernet A-D per EVI 212 route(s) announced for the that are impacted by 213 the decommissioning", however, while this A-D per EVI route 214 withdrawal is used at the remote PEs performing aliasing or backup 215 procedures, it is not used to influence the DF election for the 216 affected EVIs. 218 2.2. The Attachment Circuit (AC) influenced DF election 220 Modifying the service-carving DF election procedure in the following 221 way solves the issue: 223 1. When PE-1 and PE-2 discover ESI12, they advertise an ES route for 224 ESI12 with the associated ES-import extended community, starting a 225 timer at the same time. Likewise, PE-2 and PE-3 advertise an ES 226 route for ESI23 and start a timer. 228 2. Similarly, PE-1 and PE-2 advertise an Ethernet A-D per ES route 229 for ESI12, and PE-2/PE-3 advertise an Ethernet A-D per ES route 230 for ESI23. 232 3. In addition, PE-1/PE-2/PE-3 advertise an Ethernet A-D per EVI 233 route for AC1, AC2, AC3 and AC4 as soon as the ACs are enabled. 234 Note that the AC can be associated to a single customer VID (e.g. 235 VLAN-based interfaces) or a bundle of customer VIDs (e.g. VLAN- 236 bundle interfaces). 238 4. When the timer expires, each PE builds an ordered "candidate" list 239 of the IP addresses of all the PE nodes connected to the Ethernet 240 Segment (including itself), in increasing numeric order. The 241 candidate list is based on the Originator Router's IP addresses of 242 the ES routes, excluding all the PEs for which no Ethernet A-D per 243 ES route has been received. 245 5. When electing the DF for a given EVI, a PE will not be considered 246 candidate until an Ethernet A-D per EVI route has been received 247 from that PE. In other words, the ACS on the ESI for a given PE 248 must be UP so that the PE is considered as candidate for a given 249 EVI. For example, PE-1 will not consider PE-2 as candidate for DF 250 election for until an Ethernet A-D per EVI route is 251 not received from PE-2 for . 253 6. Once the PEs with ACS = DOWN for a given EVI have been eliminated 254 from the candidate list, the (V mod N) = i function can be applied 255 for the remaining N candidates, as per [RFC7432]. 257 Note that this procedure does not modify the existing EVPN control 258 plane whatsoever. It only modifies the candidate list of PEs taken 259 into account for the DF election algorithm defined in [RFC7432]. 261 In addition to the procedure described above, the following events 262 SHALL modify the candidate PE list and trigger the DF re-election in 263 a PE for a given : 265 a) Local ES going DOWN due to a physical failure or reception of an 266 ES route withdraw for that ESI. 268 b) Local ES going UP due to its detection/configuration or reception 269 of a new ES route update for that ESI. 271 c) Local AC going DOWN/UP. 273 d) Reception of a new Ethernet A-D per EVI update/withdraw for the 274 . 276 e) Reception of a new Ethernet A-D per ES update/withdraw for the 277 ESI. 279 This procedure is backwards compatible with the DF election 280 procedures described in [RFC7432]. 282 3. Solution benefits 284 The solution described in this document provides the following 285 benefits: 287 a) Improves the DF election procedures for EVPN so that failures due 288 to human errors, logical failures or even delay in provisioning of 289 Attachment Circuits can be protected by multi-homing. 291 b) It does not modify or add any BGP new attributes or NLRI changes. 293 c) It is backwards compatible with the procedures defined in RFC7432. 295 4. Conventions used in this document 297 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 298 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 299 document are to be interpreted as described in RFC-2119 [RFC2119]. 301 In this document, these words will appear with that interpretation 302 only when in ALL CAPS. Lower case uses of these words are not to be 303 interpreted as carrying RFC-2119 significance. 305 In this document, the characters ">>" preceding an indented line(s) 306 indicates a compliance requirement statement using the key words 307 listed above. This convention aids reviewers in quickly identifying 308 or finding the explicit compliance requirements of this RFC. 310 5. Security Considerations 312 The same Security Considerations described in [RFC7432] are valid for 313 this document. 315 6. IANA Considerations 317 There are no new IANA considerations in this document. 319 7. References 321 7.1. Normative References 323 [RFC4684] Marques, P., Bonica, R., Fang, L., Martini, L., Raszuk, 324 R., Patel, K., and J. Guichard, "Constrained Route Distribution for 325 Border Gateway Protocol/MultiProtocol Label Switching (BGP/MPLS) 326 Internet Protocol (IP) Virtual Private Networks (VPNs)", RFC 4684, 327 DOI 10.17487/RFC4684, November 2006, . 330 [RFC7432] Sajassi, A., Ed., Aggarwal, R., Bitar, N., Isaac, A., 331 Uttaro, J., Drake, J., and W. Henderickx, "BGP MPLS-Based Ethernet 332 VPN", RFC 7432, DOI 10.17487/RFC7432, February 2015, . 335 7.2. Informative References 337 [VPLS-MH] Kothari, Henderickx et al., "BGP based Multi-homing in 338 Virtual Private LAN Service", draft-ietf-bess-vpls-multihoming- 339 01.txt, work in progress, January, 2016. 341 8. Acknowledgments 343 Will be added. 345 Authors' Addresses 347 Jorge Rabadan 348 Nokia 349 777 E. Middlefield Road 350 Mountain View, CA 94043 USA 351 Email: jorge.rabadan@nokia.com 353 Kiran Nagaraj 354 Nokia 355 Email: kiran.nagaraj@nokia.com 357 Senthil Sathappan 358 Nokia 359 Email: senthil.sathappan@nokia.com 361 Vinod Prabhu 362 Nokia 363 Email: vinod.prabhu@nokia.com 365 Wim Henderickx 366 Nokia 367 Email: wim.henderickx@nokia.com 369 Autumn Liu 370 Ericsson 371 Email: autumn.liu@ericsson.com