idnits 2.17.1 draft-sajassi-bess-evpn-vpls-all-active-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 : ---------------------------------------------------------------------------- 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 doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (July 2, 2017) is 2490 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: 'RFC2119' is mentioned on line 100, but not defined == Unused Reference: 'KEYWORDS' is defined on line 329, but no explicit reference was found in the text == Outdated reference: A later version (-07) exists of draft-ietf-bess-evpn-vpls-seamless-integ-00 Summary: 0 errors (**), 0 flaws (~~), 5 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 BESS Working Group A. Sajassi 3 Internet Draft S. Salam 4 Category: Standard Track P. Brissette 5 Cisco 7 L. Jalil 8 Verizon 10 Expires: January 2, 2018 July 2, 2017 12 (PBB-)EVPN Integration with (PBB-)VPLS in All-Active Mode 13 draft-sajassi-bess-evpn-vpls-all-active-00 15 Abstract 17 This draft discusses the backward compatibility of the (PBB-)EVPN 18 solution with (PBB-)VPLS in all-active redundancy mode. 20 Status of this Memo 22 This Internet-Draft is submitted to IETF in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF), its areas, and its working groups. Note that 27 other groups may also distribute working documents as 28 Internet-Drafts. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 The list of current Internet-Drafts can be accessed at 36 http://www.ietf.org/1id-abstracts.html 38 The list of Internet-Draft Shadow Directories can be accessed at 39 http://www.ietf.org/shadow.html 41 Copyright and License Notice 43 Copyright (c) 2017 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (http://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 1.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . . 3 60 2 Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . 3 61 3 Solution for MAC Flip-Flopping . . . . . . . . . . . . . . . . . 4 62 3.1 Load-Balancing . . . . . . . . . . . . . . . . . . . . . . . 5 63 4 Changes on EVPN PEs . . . . . . . . . . . . . . . . . . . . . . 5 64 4.1 Control Plane Changes . . . . . . . . . . . . . . . . . . . 5 65 4.2 Data Plane Changes . . . . . . . . . . . . . . . . . . . . . 6 66 4.2.1 Known Unicast Traffic . . . . . . . . . . . . . . . . . 6 67 4.2.2 BUM Traffic . . . . . . . . . . . . . . . . . . . . . . 6 68 5 Failure Handling . . . . . . . . . . . . . . . . . . . . . . . . 7 69 6 EVPN-VPWS termination onto multi-homing EVPN PEs . . . . . . . . 7 70 7 Security Considerations . . . . . . . . . . . . . . . . . . . . 8 71 8 IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 8 72 9 References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 73 9.1 Normative References . . . . . . . . . . . . . . . . . . . 8 74 9.2 Informative References . . . . . . . . . . . . . . . . . . 8 75 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8 77 1 Introduction 79 VPLS and PBB-VPLS are widely-deployed L2VPN technologies. Many SPs 80 who are looking at adopting EVPN and PBB-EVPN want to preserve their 81 investment in the (PBB-)VPLS networks. Hence, it is required to 82 provide mechanisms by which (PBB-)EVPN technology can be introduced 83 into existing L2VPN networks without requiring a fork-lift upgrade. 84 [EVPN-VPLS] discusses mechanisms for the seamless integration of the 85 two technologies in the same MPLS/IP network, however, operation is 86 limited to single-active redundancy mode. In this document, we extend 87 the solution to support all-active redundancy. 89 Section 2 provides the limitations in the current (PBB-)EVPN/(PBB- 90 )VPLS interoperability solution. Section 3 discusses the solution for 91 addressing those limitations. Section 4 describes the required 92 control and data plane changes to support all-active redundancy. 93 Section 5 covers the failure handling. 95 1.1 Terminology 97 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 98 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 99 document are to be interpreted as described in RFC 2119 [RFC2119]. 101 2 Limitations 103 [EVPN-VPLS] defines mechanisms for (PBB-)EVPN seamless 104 interoperability with (PBB-)VPLS. The solution defined in [EVPN-VPLS] 105 suffers from a major limitation that hinders brown-field deployment 106 of EVPN solution: It provides support for all-active redundancy only 107 for VPN instances confined to (PBB-)EVPN PEs. For VPN instances that 108 span both (PBB-)EVPN as well as (PBB-)VPLS PEs only single-active 109 redundancy mode is supported. This eliminates one of the key value 110 propositions of inserting EVPN solution in existing networks. 112 The reason why this capability is not currently supported is due to 113 the issue of MAC address flip-flopping on the VPLS PEs. This is best 114 explained with an example: Consider the example network of Figure 1 115 below. Assume that CE1 is connected over an all-active link 116 aggregation group (LAG) to EVPN-capable PEs (PE2 and PE3). For 117 traffic destined from CE1 to CE2, different flows from the same 118 source MAC address MAC-A will be load-balanced over the LAG to PE2 119 and PE3. PE2 will forward the traffic over its own pseudowire (call 120 it PW-Blue) to PE5, whereas PE3 will forward the traffic over its own 121 pseudowire (call it PW-Red) to PE5. As such, VPLS PE (PE5) will learn 122 the same MAC address (MAC-A) over both PW-Red and PW-Blue, depending 123 on the load-balancing. This MAC flip-flopping will continue 124 indefinitely depending on traffic patterns. 126 VPLS PE 127 +---+ 128 |PE1| 129 +---+ 130 / 131 EVPN/VPLS PE +---------------+ VPLS PE 132 +---+ | | +---+ +---+ 133 |PE4|----| MPLS/IP |---|PE5|----|CE2| MAC-D 134 +---+ | Core | +---+ +---+ 135 | | 136 +---------------+ 137 / \ 138 +---+ +---+ 139 |PE2| |PE3| 140 +---+ +---+ 141 EVPN/VPLS PE EVPN/VPLS PE 142 \ / 143 \ / 144 \ / 145 +---+ 146 |CE1| MAC-A 147 +---+ 149 Figure 1: Seamless Integration of (PBB-)EVPN PEs & (PBB-)VPLS 151 The focus of this draft is on providing a solution that addresses the 152 above limitation, thereby enabling the support of all-active 153 redundancy in mixed (PBB-)EVPN/(PBB-)VPLS deployments. 155 3 Solution for MAC Flip-Flopping 157 In order to address the MAC flip-flopping problem on the VPLS PEs, 158 these PEs must learn the traffic originating from a given source MAC 159 address over the same pseudowire consistently, regardless of which 160 remote EVPN-capable PE forwarded the traffic in a given multi-homed 161 setup. To that end, every multi-homed EVPN-capable PE must maintain, 162 in addition to its own pseudowires, a set of shadow or "alias" 163 pseudowires for each of its peers in a given Redundancy Group (RG). 164 For instance, in the example network of Figure 1, PE2 maintains its 165 own pseudowire towards PE5 in addition to an "alias" pseudowire 166 corresponding to the pseudowire between PE3 and PE5. 168 When traffic arrives from a multi-homed CE over a multi-chassis LAG, 169 the EVPN-capable PE then examines whether or not it is the Designated 170 Forwarder (DF) for the Ethernet Segment (ES) in question. In the case 171 where the PE is the DF for the ES, it would use its own pseudowire 172 label to forward traffic towards a remote VPLS PE. However, in the 173 case where the PE is not the DF for the ES, it would then use the 174 "alias" pseudowire label associated with the DF PE in order to 175 forward traffic towards the remote VPLS PE. To illustrate this using 176 the example of Figure 1, consider that PE3 is the DF for the ES 177 associated with CE1. Furthermore, assume that the pseudowire labels 178 from PE2 and PE3 to PE5 are Label-Blue and Label-Red, respectively. 179 When CE1 load-balances traffic destined to CE2 towards PE3, the 180 latter will use its own pseudowire label (Label-Red) to forward 181 traffic to PE5. Whereas, when CE1 forwards traffic destined to CE2 182 towards PE2, it will use the alias pseudowire label (Label-Red) 183 instead of its own pseudowire label to forward traffic towards PE5. 184 This is because PE2 is not the DF for the Ethernet Segment associated 185 with CE1. 187 3.1 Load-Balancing 189 For traffic flowing from the EVPN-capable PEs towards the MPLS 190 network, the load-balancing is on a per-flow granularity, regardless 191 of whether the traffic is destined towards remote EVPN or VPLS PEs. 193 For traffic flowing from the VPLS PEs towards the EVPN-capable PEs, 194 the load-balancing is on a per-VLAN per destination site granularity. 195 That is, the traffic for a given VLAN in a destination site is sent 196 to only one of the multi-homed EVPN-capable PEs. This is because all 197 the EVPN-capable PEs in a given redundancy group will use the the 198 pseudowire label associated with the DF to forward traffic towards 199 remote VPLS PEs (recall, also, that EVPN DF election is per VLAN per 200 ES). 202 4 Changes on EVPN PEs 204 The changes to support the mechanisms of this draft are confined to 205 the EVPN-capable PEs. In the following two sub-sections we cover both 206 the control plane as well as data plane changes required. 208 4.1 Control Plane Changes 210 In order for the EVPN-capable PEs to maintain the alias pseudowires, 211 it is required to synchronize the VPLS pseudowire labels among the 212 PEs in the same Redundancy Group. For VPLS-BGP [RFC4761], this is 213 straight-forward to achieve because the VE-IDs and label blocks 214 associated with all PEs are advertised in BGP. Hence, a PE in an EVPN 215 RG can easily extract the alias pseudowire labels associated with its 216 peers in the same RG. For VPLS-LDP [RFC4762], protocol message 217 extensions are required but are outside the scope of the current 218 document. 220 Another control plane extension that is required is to synchronize 221 the MAC addresses learnt over the active pseudowire at DF EVPN PEs to 222 the non-DF EVPN PEs with alias pseudowire using BGP. This can be done 223 using the existing EVPN MAC Advertisement route. The identity of the 224 pseudowire over which the address was learnt is encoded in the ESI 225 field. This can be done using a Type 4 ESI, where the Router ID holds 226 the IP address of the remote pseudowire endpoint IP address (i.e. 227 VPLS PE address) and the high-order 2 octets of the Local 228 Discriminator encode the VE-ID of the remote pseudowire endpoint 229 (i.e. EVPN-capable PE that is the DF). 231 4.2 Data Plane Changes 233 4.2.1 Known Unicast Traffic 235 After DF election is complete, the EVPN-capable PE programs its data 236 plane based on the outcome of DF election as follows: 238 If known unicast traffic is received by the PE from an Ethernet 239 Segment for which it is the DF, then it uses its own pseudowire label 240 in the label stack when forwarding traffic to remote VPLS PEs. 242 If known unicast traffic is received by the PE from an Ethernet 243 Segment for which is non-DF, then it uses the alias pseudowire label 244 (associated with the DF) instead of its own pseudowire label in the 245 label stack when forwarding traffic to remote VPLS PEs. 247 In other words, the EVPN-capable PE must use the DF/non-DF status of 248 the incoming attachment circuit interface in order to choose the 249 correct label stack for VPLS forwarding. 251 4.2.2 BUM Traffic 253 The EVPN-capable PEs must maintain two replication lists: one that 254 uses their own pseudowires, and another that uses the alias 255 pseudowires. When BUM traffic is received from the attachment 256 circuit, the PE examines the DF status of the incoming interface to 257 identify which of the two replication lists to use: If the PE is the 258 DF, then it uses the replication list which encompasses its own 259 pseudowires. Whereas, if the PE is non-DF, then it uses the 260 replication list encompassing the alias pseudowires. 262 BUM traffic received over a VPLS pseudowire is handled as follows: 264 Broadcast and multicast traffic is identified as such by inspecting 265 the destination MAC address, and is handled as usual per EVPN MPLS 266 ingress flooding mechanisms. At egress to the attachment circuit, all 267 broadcast and multicast VPLS traffic is subjected to DF filtering 268 procedures per existing EVPN procedures. 270 Unknown unicast traffic cannot be identified as such by the 271 disposition PE on egress from the pseudowire, since nothing in the 272 Ethernet frame or the MPLS label stack (unlike EVPN) distinguishes 273 this traffic from known unicast. Furthermore, the disposition PE 274 cannot rely on its own MAC forwarding table to infer whether the 275 frame was flooded or not - i.e., an unknown MAC address on the 276 imposition PE cannot be known to the disposition PE. Due to this, the 277 egress (disposition) PE will treat unicast MAC addresses based on its 278 own local forwarding state - i.e., if the MAC address is known 279 locally, then it is treated as such and if the MAC address is unknown 280 locally, then it is treated as BUM traffic and will apply DF 281 filtering. This can lead to a side-effect for a very specific 282 scenario where the MAC-DA is unknown at the ingress PE but it is 283 known to the egress multi-homing PEs (i.e., there is no issue when 284 MAC-DA is known at the ingress and unknown at the egress, or MAC-DA 285 is unknown at both the ingress and egress PEs). In such a specific 286 scenario, a multi-homed CE will experience duplicate packets for an 287 interim period of time until the remote VPLS PE learns the MAC 288 address from reverse traffic. The CE's application layer will handle 289 the discard of transient duplicate frames. While it is acknowledged 290 that this behavior deviates from classical Ethernet, which guarantees 291 the absence of packet duplication, the side-effect occurs in very 292 specific scenario and it is both short-lived and confined in scope to 293 the PE/CE links. Hence, it is a reasonable trade-off to accept in 294 favor of enabling all-active redundancy in the solution. 296 5 Failure Handling 298 Failure handling follows standard EVPN and VPLS procedures: 300 For link failure on DF EVPN-capable PE, the PE sends a mass withdraw 301 indication using per ES Ethernet A-D route to other EVPN PEs, causing 302 them to update their forwarding entries to point to only the non-DF 303 PE. The DF PE also sends VPLS MAC address flush message to remote 304 VPLS PEs, causing them to flush their entries. The non-DF EVPN PE 305 takes over and assumes the DF role. It uses its own VPLS pseudowire 306 labels for sending traffic towards the VPLS PEs. 308 For link failure on non-DF EVPN PE, the PE sends mass withdraw per ES 309 Ethernet A-D route to other EVPN PEs, causing them to update their 310 forwarding entries to point to only the DF PE. Nothing is done with 311 respect to the VPLS PEs, as this failure is transparent to them. 313 6 EVPN-VPWS termination onto multi-homing EVPN PEs This section will be 314 added in the future revision to describe how the MAC synchroniation 315 mechanism over PW described above can be used for this scenario. 317 7 Security Considerations 319 No new security considerations beyond those for VPLS and EVPN. 321 8 IANA Considerations 323 This document has no actions for IANA. 325 9 References 327 9.1 Normative References 329 [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate 330 Requirement Levels", BCP 14, RFC 2119, March 1997. 332 [RFC4761] Kompella, K., Ed., and Y. Rekhter, Ed., "Virtual Private 333 LAN Service (VPLS) Using BGP for Auto-Discovery and 334 Signaling", RFC 4761, January 2007. 336 [RFC4762] Lasserre, M., Ed., and V. Kompella, Ed., "Virtual Private 337 LAN Service (VPLS) Using Label Distribution Protocol (LDP) 338 Signaling", RFC 4762, January 2007. 340 [EVPN-VPLS] Sajassi, A., Salam, S., Del Regno, N., and Rabadan, J., 341 "(PBB-)EVPN Seamless Integration with (PBB-)VPLS", draft- 342 ietf-bess-evpn-vpls-seamless-integ-00, work in progress, 343 February 2015, 344 . 347 9.2 Informative References 349 Authors' Addresses 351 Ali Sajassi 352 Cisco 353 170 West Tasman Drive 354 San Jose, CA 95134, US 355 Email: sajassi@cisco.com 357 Samer Salam 358 Cisco 359 595 Burrard Street, Suite 2123 360 Vancouver, BC V7X 1J1, Canada 361 Email: ssalam@cisco.com 363 Patrice Brissette 364 Cisco 365 Email: pbrisset@cisco.com 367 Luay Jalil 368 Cisco 369 Email: luay.jalil@verizon.com