idnits 2.17.1 draft-brissette-bess-evpn-l2gw-proto-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 : ---------------------------------------------------------------------------- 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 (February 26, 2018) is 2251 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) No issues found here. Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 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: August 30, 2018 February 26, 2018 12 EVPN Multi-Homing Mechanism for Layer-2 Gateway Protocols 13 draft-brissette-bess-evpn-l2gw-proto-01 15 Abstract 17 Existing EVPN multi-homing load-balancing modes are limited to 18 Single-Active and All-Active. Neither of these multi-homing 19 mechanisms are sufficient to support access networks with Layer-2 20 Gateway protocols such as MST-AG, REP-AG, and G.8032. 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) . . . . . . . . 6 67 5. ESI-label Extended Community Extension . . . . . . . . . . . . 7 68 6. EVPN MAC Flush Extcomm . . . . . . . . . . . . . . . . . . . . 8 69 7. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 8 70 8. Security Considerations . . . . . . . . . . . . . . . . . . . 10 71 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 72 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 73 10.1 Normative References . . . . . . . . . . . . . . . . . . . 10 74 10.2 Informative References . . . . . . . . . . . . . . . . . . 10 75 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10 77 1. Introduction 79 EVPN existing multi-homing mechanisms of Single-Active and All-Active 80 is not sufficient to support access Layer-2 Gateway protocols such as 81 MST-AG, REP-AG, and G.8032. 83 These Layer-2 Gateway protocols require that a given flow of a VLAN 84 (represented by {MAC-SA, MAC-DA}) to be only active on one of the PEs 85 in the multi-homing group. This is in contrast with Single-Active 86 redundancy mode where all flows of a VLAN are active on one of the 87 multi-homing PEs and it is also in contrast with All-Active 88 redundancy mode where all L2 flows of a VLAN are active on all PEs in 89 the redundancy group. 91 This draft defines a new multi-homing mechanism "Single-Flow-Active" 92 which means a given VLAN can be active on all PEs in the redundancy 93 group but a single flow of that VLAN can only be active on only one 94 of the PEs in the redundancy group. In fact, the carving scheme, 95 performed by the DF election algorithm for these L2GW protocols, is 96 not per VLAN but rather for a given VLAN. A given PE in the 97 redundancy group can be the only Designated Forwarder for a specific 98 L2 flow. The loop-prevention blocking scheme occurs somewhere in the 99 access network. 101 EVPN multi-homing procedures need to be enhanced to support 102 Designated Forwarder Election for all traffic (both known unicast and 103 BUM) on a per L2 flow basis. This new multi-homing mechanism also 104 requires new EVPN considerations for aliasing, mass-withdraw and 105 fast-switchover as described in the solution section. 107 1.1 Terminology 109 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 110 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 111 document are to be interpreted as described in RFC 2119 [RFC2119]. 113 1.2 Acronyms 115 AC : Attachment Circuit 116 BUM : Broadcast, Unknown unicast, Multicast 117 DF : Designated Forwarder 118 EVLAG : EVPN LAG (equivalent to EVPN MC-LAG) 119 GW : Gateway 120 L2 Flow : a given flow of a VLAN, represented by (MAC-SA, MAC-DA) 121 L2GW : Layer-2 Gateway 122 G.8032 : Ethernet Ring Protection 123 MST-AG : Multi-Spanning Tree Access Gateway 124 REP-AG : Resilient Ethernet Protocol Access Gateway 125 TCN : Topology Change Notification 127 2. Solution 129 +---+ 130 |CE4| 131 +---+ 132 | 133 | 134 +-----+ 135 | PE3 | 136 +-----+ 137 +-------------+ 138 | | 139 | MPLS/IP | 140 | CORE | 141 | | 142 +-------------+ 143 +-----+ +-----+ 144 | PE1 | | PE2 | 145 +-----+ +-----+ 146 AC1| |AC2 147 | | 148 +---+ +---+ 149 |CE1| |CE3| 150 +---+ +---+ 151 | | 152 | +---+ | 153 +----|CE2|-/--+ 154 +---+ 156 Figure 1 EVPN network with L2 access GW protocols 158 Figure 1. shows a typical EVPN network with an access network running 159 a L2GW protocol; typically one of the following: MST-AG, REP-AG or 160 G.8032. The L2GW protocol usually starts from AC1 (on PE1) up to AC2 161 (on PE2) in an open "ring" manner. AC1 and AC2 interfaces of PE1 and 162 PE2 are participant in the access protocol. PE1 and PE2 are peering 163 PEs in a redundancy group and EVLAG capable. The L2GW protocol is 164 used for loop avoidance. In above example, the loop is broken on the 165 right side of CE2. Due to them running in 'Access Gateway' mode, PE1 166 and PE2 EVLAG load-balancing runs in a way very-similar to all- 167 active. Additionally, the reachability between CE1/CE2 and CE3 that 168 is required is achieved with the forwarding path through the EVPN 169 MPLS/IP core side. 171 Finally, PE3 behaves according to EVPN rules for traffic to/from 172 PE1/PE2. Peering PE, selected per L2 flow, is chosen by the L2GW 173 protocol in the access, and is out of EVPN control. From PE3 point of 174 view, some of the L2 flow coming from PE3 may reach CE3 via PE2 and 175 some of the L2 flow may reach CE1/CE2 via PE1. A specific L2 flow 176 never goes to both peering PEs. Therefore, aliasing cannot be 177 performed by PE3. That node operates in a single-active fashion for 178 these L2 flow. The backup path which is also setup for rapid 179 convergence, is not applicable here. For example, in Figure 1, if a 180 failure happens between CE1 and CE2, L2 flow coming from CE4 destined 181 to CE1 still goes through PE1 and shall not switch to PE2 as a backup 182 path. On PE3, there is no way to know which L2 flow specifically is 183 affected. During the transition time, PE3 will flood until unicast 184 traffic recovers properly. 186 3. Requirements 188 The EVPN L2GW framework for L2GW protocols in Access-Gateway mode, 189 consists of the following rules: 191 o Peering PEs MUST share the same ESI. 193 o The Ethernet-Segment forwarding state MUST be dictated by the L2GW 194 protocol. 196 o Split-horizon filtering capability is NOT needed because L2GW 197 protocol ensures there will never be loop in the access network. The 198 forwarding between peering PEs MUST also be preserved. In figure 1, 199 CE1/CE2 device may need reachability with CE3 device. ESI-filtering 200 capability MUST be disable. PE MUST NOT advertise corresponding ESI- 201 label to other PEs in the redundancy group. 203 o ESI-label BGP-extcomm MUST support a new multi-homing mode named 204 "Single-Flow-Active" corresponding to the single-active behaviour of 205 [RFC7432], applied per flow. 207 o Upon receiving ESI-label BGP-Extcomm with the single-flow-active 208 load-balancing mode, remote PE MUST: 209 - Disable aliasing (at Layer-2 and Layer-3) 210 - Disable ESI-label processing 211 - Disable backup path programming 213 The Ethernet-Segment DF election backend procedure such as per ES/EAD 214 and per EVI/EAD routes advertisement/withdraw remains as explained in 215 [RFC7432]. 217 4. Handling of Topology Change Notification (TCN) 219 In order to address rapid Layer-2 convergence requirement, topology 220 change notification received from the L2GW protocols must be sent 221 across the EVPN network to perform the equivalent of legacy L2VPN 222 remote MAC flush. 224 The generation of topology change notification is done differently 225 based on the access protocol. In the case of REP-AG and G.8032, TCN 226 gets generated in both directions and thus both of the dual-homing 227 PEs receive it. However, with MST-AG, TCN gets generated only in one 228 direction and thus only a single PE can receive it. That TCN ie 229 propagated to the other peering PE for local MAC flushing, and 230 relaying back into the access. 232 In fact, PEs have no direct visibility on failures happening in the 233 access network neither on the impact of those failures over the 234 connectivity between CE devices. Hence, both peering PEs require to 235 perform a local MAC flush on corresponding interfaces. 237 There are two options to relay the access protocol's TCN to the 238 peering PE: in-band or out-of-band messaging. The first method is 239 better for rapid convergence, and requires a dedicated channel 240 between peering PEs. An EVPN-VPWS connection is dedicated for that 241 purpose. The latter choice relies on the newly defined MAC flush 242 extended community in the Ethernet Auto-discovery per EVI route. It 243 is a slower method but has the advantage of avoid the usage of a 244 dedicated channel between peering PEs. 246 Peering PE, upon receiving TCN from access, MUST: 248 o As per legacy VPLS, perform a local MAC flush on the access-facing 249 interfaces. 251 o Advertise per EVI/EAD route along with a new MAC-flush BGP Extended 252 Community in order to perform a remote MAC flush and steer L2 traffic 253 to proper peering PE. The sequence number is incremented by one as a 254 flushing indication to remote PEs. 256 o Ensure MAC/IP route re-advertisement with sequence number is bump 257 up when host reachability is NOT moving to peering PE. This is to 258 ensure a re-advertisement of current MAC which may have been flushed 259 remotely upon MAC Flush extcomm reception. In theory, it should 260 happen automatically since peering PE, receiving TCN from the access, 261 performs local MAC flush on corresponding interface and will re-learn 262 that local MAC. 264 o When MST-AG runs in the access, a dedicated EVPN-VPWS connection 265 MAY be used as an in-band channel to relay TCN between peering PEs. 266 That connection may be auto-generated or can simply be directly 267 configured by user. 269 5. ESI-label Extended Community Extension 270 In order to support the new EVPN load-balancing mode (single-flow- 271 active), the ESI-label extcomm is extended. The 1 octet flag field, 272 as part of the ESI-label Extcomm, is updated as follow: 274 Each ESI Label extended community is encoded as an 8-octet value, as 275 follows: 277 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 278 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 279 | Type=0x06 | Sub-Type=0x01 | Flags(1 octet)| Reserved=0 | 280 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 281 | Reserved=0 | ESI Label | 282 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 284 Low-order bit: [7:0] 285 [2:0]- 000 = all-active, 286 001 = single-active, 287 010 = single-flow-active, 288 others = reserved 289 [7:3]- Reserved 291 6. EVPN MAC Flush Extcomm 293 A new BGP Extended community, similar to MAC mobility BGP-extcomm, is 294 required by the TCN procedure. It may get advertised along with 295 Ethernet Auto-discovery routes (per EVI/EAD) upon reception of TCN 296 from the access. When this extended community is used, it indicates, 297 to all remote PEs that all MAC addresses associated with that EVI/ESI 298 are "flushed" i.e. unresolved. They remain unresolved until remote PE 299 receives a route update / withdraw for those MAC addresses; the MAC 300 may be readvertised by the same PE, or by another, in the same ESI. 302 The sequence number used is of local significance from the 303 originating PE, and is not used for comparison between peering PEs. 304 Rather, it is used to signal via BGP successive MAC Flush requests 305 from a given PE. 307 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 308 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 309 + Type = ?? | Sub-Type = ?? | Reserved = 0 | 310 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 311 | Sequence Number | 312 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 314 7. Conclusion 316 EVPN Multi-Homing Mechanism for Layer-2 gateway Protocols solves a 317 true problem due to the wide legacy deployment of these access L2GW 318 protocols in Service Provider networks. The current draft has the 319 main advantage to be fully compliant with [RFC7432] and [draft-ietf- 320 bess-evpn-inter-subnet-forwarding]. EVPN-IRB works with the current 321 proposal and does not require any extension. 323 8. Security Considerations 325 The same Security Considerations described in [RFC7432] are valid for 326 this document. 328 9. IANA Considerations 330 A new allocation of Extended Community Sub-Type for EVPN is required 331 to support the new EVPN MAC flush mechanism. 333 10. References 335 10.1 Normative References 337 [RFC7432] Sajassi, A., Ed., Aggarwal, R., Bitar, N., Isaac, A., 338 Uttaro, J., Drake, J., and W. Henderickx, "BGP MPLS-Based 339 Ethernet VPN", RFC 7432, DOI 10.17487/RFC7432, February 340 2015, . 342 10.2 Informative References 344 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 345 Requirement Levels", BCP 14, RFC 2119, DOI 346 10.17487/RFC2119, March 1997, . 349 Authors' Addresses 351 Patrice Brissette 352 Cisco Systems 353 EMail: pbrisset@cisco.com 355 Ali Sajassi 356 Cisco Systems 357 EMail: sajassi@cisco.com 359 Luc Andre Burdet 360 Cisco Systems 361 EMail: lburdet@cisco.com 363 Daniel Voyer 364 Bell Canada 365 EMail: daniel.voyer@bell.ca