idnits 2.17.1 draft-brissette-bess-evpn-l2gw-proto-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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 20, 2018) is 2013 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: 'EVPN-IRB' is mentioned on line 352, but not defined Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT Patrice Brissette 3 Intended Status: Proposed Standard Ali Sajassi 4 Luc Andre Burdet 5 Cisco Systems 7 Daniel Voyer 8 Bell Canada 10 Expires: April 23, 2019 October 20, 2018 12 EVPN Multi-Homing Mechanism for Layer-2 Gateway Protocols 13 draft-brissette-bess-evpn-l2gw-proto-03 15 Abstract 17 The existing EVPN multi-homing load-balancing modes defined are 18 Single-Active and All-Active. Neither of these multi-homing 19 mechanisms are appropriate to support access networks with Layer-2 20 Gateway protocols such as G.8032, MPLS-TP, STP, etc. These Layer-2 21 Gateway protocols require a new multi-homing mechanism defined in 22 this draft. 24 Status of this Memo 26 This Internet-Draft is submitted to IETF in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF), its areas, and its working groups. Note that 31 other groups may also distribute working documents as 32 Internet-Drafts. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 The list of current Internet-Drafts can be accessed at 40 http://www.ietf.org/1id-abstracts.html 42 The list of Internet-Draft Shadow Directories can be accessed at 43 http://www.ietf.org/shadow.html 45 Copyright and License Notice 46 Copyright (c) 2018 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (http://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. Code Components extracted from this document must 55 include Simplified BSD License text as described in Section 4.e of 56 the Trust Legal Provisions and are provided without warranty as 57 described in the Simplified BSD License. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 62 1.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . . 3 63 1.2 Acronyms . . . . . . . . . . . . . . . . . . . . . . . . . 3 64 2. Solution . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 65 3. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 6 66 4. Handling of Topology Change Notification (TCN) . . . . . . . . 7 67 5. ESI-label Extended Community Extension . . . . . . . . . . . . 8 68 6. EVPN MAC Flush Extcomm . . . . . . . . . . . . . . . . . . . . 8 69 7. EVPN Inter-subnet Forwarding . . . . . . . . . . . . . . . . . 9 70 8. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 9 71 9. Security Considerations . . . . . . . . . . . . . . . . . . . 10 72 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10 73 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 74 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 75 12.1 Normative References . . . . . . . . . . . . . . . . . . . 10 76 12.2 Informative References . . . . . . . . . . . . . . . . . . 10 78 1. Introduction 80 Existing EVPN multi-homing mechanisms of Single-Active and All-Active 81 are not sufficient to support access Layer-2 Gateway protocols such 82 as G.8032, MPLS-TP, STP, etc. 84 These Layer-2 Gateway protocols require that a given flow of a VLAN 85 (represented by {MAC-SA, MAC-DA}) to be only active on one of the PEs 86 in the multi-homing group. This is in contrast with Single-Active 87 redundancy mode where all flows of a VLAN are active on one of the 88 multi-homing PEs and it is also in contrast with All-Active 89 redundancy mode where all L2 flows of a VLAN are active on all PEs in 90 the redundancy group. 92 This draft defines a new multi-homing mechanism "Single-Flow-Active" 93 which defines that a VLAN can be active on all PEs in the redundancy 94 group but a single given flow of that VLAN can be active on only one 95 of the PEs in the redundancy group. In fact, the carving scheme, 96 performed by the DF(Designated Forwarder) election algorithm for 97 these L2 Gateway protocols, is not per VLAN but rather for a given 98 VLAN. A selected PE in the redundancy group can be the only 99 Designated Forwarder for a specific L2 flow but the decision is not 100 taken by the PE. The loop-prevention blocking scheme occurs in the 101 access network. 103 EVPN multi-homing procedures need to be enhanced to support 104 Designated Forwarder election for all traffic (both known unicast and 105 BUM) on a per L2 flow basis. This new multi-homing mechanism also 106 requires new EVPN considerations for aliasing, mass-withdraw, fast- 107 switchover and [EVPN-IRB] as described in the solution section. 109 1.1 Terminology 111 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 112 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 113 document are to be interpreted as described in RFC 2119 [RFC2119]. 115 1.2 Acronyms 117 AC : Attachment Circuit 118 BUM : Broadcast, Unknown unicast, Multicast 119 DF : Designated Forwarder 120 EVLAG : EVPN LAG (equivalent to EVPN MC-LAG) 121 GW : Gateway 122 L2 Flow : a given flow of a VLAN, represented by (MAC-SA, MAC-DA) 123 L2GW : Layer-2 Gateway 124 G.8032 : Ethernet Ring Protection 125 MST-AG : Multi-Spanning Tree Access Gateway 126 REP-AG : Resilient Ethernet Protocol Access Gateway 127 TCN : Topology Change Notification 129 2. Solution 131 +---+ 132 |CE4| 133 +---+ 134 | 135 | 136 +-----+ 137 | PE3 | 138 +-----+ 139 +-----------------+ 140 | | 141 | MPLS/IP | 142 | CORE | 143 | | 144 +-----------------+ 145 +-----+ +-----+ 146 | PE1 | | PE2 | 147 +-----+ +-----+ 148 AC1| |AC2 149 | | 150 +---+ +---+ 151 |CE1| |CE3| 152 +---+ +---+ 153 | | 154 | +---+ | 155 +----|CE2|----/---+ 156 +---+ 158 Figure 1 EVPN network with L2 access GW protocols 160 Figure 1. shows a typical EVPN network with an access network running 161 a L2GW protocol; typically one of the following: G.8032, STP, MPLS- 162 TP, etc. The L2GW protocol usually starts from AC1 (on PE1) up to AC2 163 (on PE2) in an open "ring" manner. AC1 and AC2 interfaces of PE1 and 164 PE2 are participants in the access protocol. PE1 and PE2 are peering 165 PEs (EVLAG capable) in a redundancy group sharing a same ESI. The 166 L2GW protocol is used for loop avoidance. In above example, the loop 167 is broken on the right side of CE2. In the proposed Single-Flow- 168 Active mode, PE1 and PE2 'Access Gateway' load-balancing mode shares 169 similarities with both Single-Active and All-Active. DF election must 170 not result in blocked ports or portions of the access may become 171 isolated. Additionally, the reachability between CE1/CE2 and CE3 is 172 achieved with the forwarding path through the EVPN MPLS/IP core side. 173 Thus, the ESI-Label filtering of [RFC7432] is disabled for Single- 174 Flow-Active Ethernet segments. 176 Finally, PE3 behaves according to EVPN rules for traffic to/from 177 PE1/PE2. Peering PE, selected per L2 flow, is chosen by the L2GW 178 protocol in the access, and is out of EVPN control. From PE3 point of 179 view, some of the L2 flows coming from PE3 may reach CE3 via PE2 and 180 some of the L2 flows may reach CE1/CE2 via PE1. A specific L2 flow 181 never goes to both peering PEs. Therefore, aliasing cannot be 182 performed by PE3. That node operates in a single-active fashion for 183 these L2 flows. The backup path which is also setup for rapid 184 convergence, is not applicable here. For example, in Figure 1, if a 185 failure happens between CE1 and CE2, L2 flows coming from CE4 behind 186 PE3 destined to CE1 still goes through PE1 and shall not switch to 187 PE2 as a backup path. On PE3, there is no way to know which L2 flow 188 specifically is affected. During the transition time, PE3 may flood 189 until unicast traffic recovers properly. 191 3. Requirements 193 The EVPN L2GW framework for L2GW protocols in Access-Gateway mode, 194 consists of the following rules: 196 o Peering PEs MUST share the same ESI. 198 o The Ethernet-Segment DF election MUST NOT be performed and 199 forwarding state MUST be dictated by the L2GW protocol. In Access 200 Gateway mode, both PEs are usually in forwarding state. In fact, 201 access protocol guarantees drive that state. 203 o Split-horizon filtering is NOT needed because L2GW protocol 204 ensures there will never be loop in the access network. The 205 forwarding between peering PEs MUST also be preserved. In figure 206 1, CE1/CE2 device may need reachability with CE3 device. ESI- 207 filtering capability MUST be disabled. PE MUST NOT advertise 208 corresponding ESI-label to other PEs in the redundancy group, or 209 apply it if it is received. 211 o ESI-label BGP-extcomm MUST support a new multi-homing mode named 212 "Single-Flow-Active" corresponding to the single-active behaviour 213 of [RFC7432], applied per flow. 215 o Upon receiving ESI-label BGP-Extcomm with the single-flow-active 216 load-balancing mode, remote PE MUST: 217 - Disable ESI-Label processing 218 - Disable aliasing (at Layer-2 and Layer-3 [EVPN-IRB]) 220 o The Ethernet-Segment procedures in the EVPN core such as per 221 ES/EAD and per EVI/EAD routes advertisement/withdraw, as well as 222 MAC and MAC+IP advertisement, remains as explained in [RFC7432] 223 and [EVPN-IRB]. 225 o For fast-convergence, remote PE3 MAY set up two distinct backup 226 paths on a per-flow basis: 228 - { PE1 active, PE2 backup } 229 - { PE2 active, PE1 backup } 231 o MAC mobility procedures SHALL have precedence in Single-Flow- 232 Active for tracking host reachability over backup path procedure. 234 4. Handling of Topology Change Notification (TCN) 236 In order to address rapid Layer-2 convergence requirement, topology 237 change notification received from the L2GW protocols must be sent 238 across the EVPN network to perform the equivalent of legacy L2VPN 239 remote MAC flush. 241 The generation of TCN is done differently based on the access 242 protocol. In the case of STP (REP-AG) and G.8032, TCN gets generated 243 in both directions and thus both of the dual-homing PEs receive it. 244 However, with STP (MST-AG), TCN gets generated only in one direction 245 and thus only a single PE can receive it. That TCN is propagated to 246 the other peering PE for local MAC flushing, and relaying back into 247 the access. 249 In fact, PEs have no direct visibility on failures happening in the 250 access network neither on the impact of those failures over the 251 connectivity between CE devices. Hence, both peering PEs require to 252 perform a local MAC flush on corresponding interfaces. 254 There are two options to relay the access protocol's TCN to the 255 peering PE: in-band or out-of-band messaging. The first method is 256 better for rapid convergence, and requires a dedicated channel 257 between peering PEs. An EVPN-VPWS connection MAY be dedicated for 258 that purpose, connecting the Untagged ACs of both PEs. The latter 259 choice relies on a new MAC flush extended community in the Ethernet 260 Auto-discovery per EVI route, defined below. It is a slower method 261 but has the advantage of avoid the usage of a dedicated channel 262 between peering PEs. 264 Peering PE, upon receiving TCN from access, MUST: 266 o As per legacy VPLS, perform a local MAC flush on the access-facing 267 interfaces. An ARP probe is also sent for all hosts previously 268 locally-attached. 270 o Advertise per EVI/EAD route along with a new MAC-flush BGP Extended 271 Community in order to perform a remote MAC flush and steer L2 traffic 272 to proper peering PE. The sequence number is incremented by one as a 273 flushing indication to remote PEs. 275 o Ensure MAC and MAC/IP route re-advertisement, with incremented 276 sequence number when host reachability is NOT moving to peering PE. 277 This is to ensure a re-advertisement of current MAC and MAC/IP which 278 may have been flushed remotely upon MAC Flush extcomm reception. In 279 theory, it should happen automatically since peering PE, receiving 280 TCN from the access, performs local MAC flush on corresponding 281 interface and will re-learn that local MAC or MAC/IP at ARP probe 282 reply. 284 o When MST-AG runs in the access, a dedicated EVPN-VPWS connection 285 MAY be used as an in-band channel to relay TCN between peering PEs. 286 That connection may be auto-generated or can simply be directly 287 configured by user. 289 5. ESI-label Extended Community Extension 291 In order to support the new EVPN load-balancing mode (single-flow- 292 active), the ESI-label extcomm is extended. The 1 octet flag field, 293 as part of the ESI-label Extcomm, is updated as follow: 295 Each ESI Label extended community is encoded as an 8-octet value, as 296 follows: 297 1 2 3 298 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 299 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 300 | Type=0x06 | Sub-Type=0x01 | Flags(1 octet)| Reserved=0 | 301 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 302 | Reserved=0 | ESI Label | 303 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 305 Low-order bit: [7:0] 306 [2:0]- 000 = all-active, 307 001 = single-active, 308 010 = single-flow-active, 309 others = unassigned 310 [7:3]- Reserved 312 6. EVPN MAC Flush Extcomm 314 A new BGP Extended community, similar to MAC mobility BGP-extcomm, is 315 required by the TCN procedure. It may get advertised along with 316 Ethernet Auto-discovery routes (per EVI/EAD) upon reception of TCN 317 from the access. When this extended community is used, it indicates, 318 to all remote PEs that all MAC addresses associated with that EVI/ESI 319 are "flushed" i.e. unresolved. They remain unresolved until remote PE 320 receives a route update / withdraw for those MAC addresses; the MAC 321 may be readvertised by the same PE, or by another, in the same ESI. 323 The sequence number used is of local significance from the 324 originating PE, and is not used for comparison between peering PEs. 325 Rather, it is used to signal via BGP successive MAC Flush requests 326 from a given PE. 328 1 2 3 329 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 330 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 331 | Type=0x06 | Sub-Type=0x?? | Reserved = 0 | 332 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 333 | Sequence Number | 334 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 336 7. EVPN Inter-subnet Forwarding 338 EVPN Inter-subnet forwarding procedures in [EVPN-IRB] works with the 339 current proposal and does not require any extension. Host routes 340 continue to be installed at PE3 with a single remote nexthop, no 341 aliasing. 343 8. Conclusion 345 EVPN Multi-Homing Mechanism for Layer-2 gateway Protocols solves a 346 true problem due to the wide legacy deployment of these access L2GW 347 protocols in Service Provider networks. The current draft has the 348 main advantage to be fully compliant with [RFC7432] and [EVPN-IRB]. 350 9. Security Considerations 352 The same Security Considerations described in [RFC7432] and [EVPN- 353 IRB] remain valid for this document. 355 10. Acknowledgements 357 Authors would like to thank Thierry Couture for valuable review and 358 inputs with respect to access protocol deployments related to 359 procedures proposed in this document. 361 11. IANA Considerations 363 A new allocation of Extended Community Sub-Type for EVPN is required 364 to support the new EVPN MAC flush mechanism. 366 12. References 368 12.1 Normative References 370 [RFC7432] Sajassi, A., Ed., Aggarwal, R., Bitar, N., Isaac, A., 371 Uttaro, J., Drake, J., and W. Henderickx, "BGP MPLS-Based 372 Ethernet VPN", RFC 7432, DOI 10.17487/RFC7432, February 373 2015, . 375 12.2 Informative References 377 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 378 Requirement Levels", BCP 14, RFC 2119, DOI 379 10.17487/RFC2119, March 1997, . 382 Authors' Addresses 384 Patrice Brissette 385 Cisco Systems 386 EMail: pbrisset@cisco.com 388 Ali Sajassi 389 Cisco Systems 390 EMail: sajassi@cisco.com 392 Luc Andre Burdet 393 Cisco Systems 394 EMail: lburdet@cisco.com 395 Daniel Voyer 396 Bell Canada 397 EMail: daniel.voyer@bell.ca