idnits 2.17.1 draft-sajassi-l2vpn-evpn-vpls-integration-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 date (October 21, 2013) is 3840 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: 'RFC4761' is mentioned on line 167, but not defined == Missing Reference: 'RFC6074' is mentioned on line 168, but not defined == Unused Reference: 'RFC4448' is defined on line 349, but no explicit reference was found in the text == Outdated reference: A later version (-03) exists of draft-ietf-pwe3-rfc4447bis-02 -- Possible downref: Normative reference to a draft: ref. 'RFC4447' == Outdated reference: A later version (-11) exists of draft-ietf-l2vpn-evpn-04 == Outdated reference: A later version (-10) exists of draft-ietf-l2vpn-pbb-evpn-05 == Outdated reference: A later version (-06) exists of draft-ietf-l2vpn-pbb-vpls-interop-05 Summary: 0 errors (**), 0 flaws (~~), 8 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT Ali Sajassi 3 Intended Status: Standard Track Samer Salam 4 Cisco 6 Nick Del Regno 7 Verizon 9 Expires: April 21, 2014 October 21, 2013 11 (PBB-)EVPN Seamless Integration with (PBB-)VPLS 12 draft-sajassi-l2vpn-evpn-vpls-integration-00 14 Abstract 16 This draft discusses the backward compatibility of the (PBB-)EVPN 17 solution with (PBB-)VPLS and provides mechanisms for seamless 18 integration of the two technologies in the same MPLS/IP network on a 19 per-VPN-instance basis. 21 Status of this Memo 23 This Internet-Draft is submitted to IETF in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF), its areas, and its working groups. Note that 28 other groups may also distribute working documents as 29 Internet-Drafts. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 The list of current Internet-Drafts can be accessed at 37 http://www.ietf.org/1id-abstracts.html 39 The list of Internet-Draft Shadow Directories can be accessed at 40 http://www.ietf.org/shadow.html 42 Copyright and License Notice 44 Copyright (c) 2013 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (http://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 1.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . . 3 61 2. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 3 62 3 PBB-VPLS Integration with PBB-EVPN . . . . . . . . . . . . . . . 4 63 3.1 Capability Discovery . . . . . . . . . . . . . . . . . . . . 4 64 3.2 Forwarding Setup and Unicast Operation . . . . . . . . . . . 5 65 3.3 Multicast Operation . . . . . . . . . . . . . . . . . . . . 6 66 3.3.1 Ingress Replication . . . . . . . . . . . . . . . . . . 6 67 3.3.2 LSM . . . . . . . . . . . . . . . . . . . . . . . . . . 6 68 4 VPLS Integration with EVPN . . . . . . . . . . . . . . . . . . . 6 69 4.1 Capability Discovery . . . . . . . . . . . . . . . . . . . . 6 70 4.2 Forwarding Setup and Unicast Operation . . . . . . . . . . . 6 71 4.3 Multicast Operation . . . . . . . . . . . . . . . . . . . . 7 72 4.3.1 Ingress Replication . . . . . . . . . . . . . . . . . . 7 73 4.3.2 LSM . . . . . . . . . . . . . . . . . . . . . . . . . . 7 74 5 VPLS Integration with PBB-EVPN . . . . . . . . . . . . . . . . . 7 75 5.1 Capability Discovery . . . . . . . . . . . . . . . . . . . . 7 76 5.2 Forwarding Setup and Unicast Operation . . . . . . . . . . . 7 77 5.3 Multicast Operation . . . . . . . . . . . . . . . . . . . . 7 78 5.3.1 Ingress Replication . . . . . . . . . . . . . . . . . . 7 79 5.3.2 LSM . . . . . . . . . . . . . . . . . . . . . . . . . . 7 80 6 Solution Advantages . . . . . . . . . . . . . . . . . . . . . . 7 81 7 Security Considerations . . . . . . . . . . . . . . . . . . . . 8 82 8 IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 8 83 9 References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 84 9.1 Normative References . . . . . . . . . . . . . . . . . . . 8 85 9.2 Informative References . . . . . . . . . . . . . . . . . . 8 86 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9 88 1 Introduction 90 VPLS and PBB-VPLS are widely-deployed L2VPN technologies. Many SPs 91 who are looking at adopting EVPN and PBB-EVPN want to preserve their 92 investment in the (PBB-)VPLS networks. Hence, it is required to 93 provide mechanisms by which (PBB-)EVPN technology can be introduced 94 into existing L2VPN networks without requiring a fork-lift upgrade. 95 This document discusses mechanisms for the seamless integration of 96 the two technologies in the same MPLS/IP network. 98 Section 2 provides the details of the requirements. Section 3 99 discusses PBB-VPLS integration with PBB-EVPN. Section 4 discusses the 100 integration of VPLS and EVPN. Section 5 discusses the integration of 101 VPLS and PBB-EVPN, and finally Section 6 discusses the solution 102 advantages. 104 It is worth noting that the scenario where PBB-VPLS is integrated 105 with EVPN, is for future study and upon market validation. The reason 106 for that is that deployments which employ PBB-VPLS typically require 107 PBB encapsulation for various reasons. Hence, it is expected that for 108 those deployments the evolution path would be from PBB-VPLS towards 109 PBB-EVPN, rather than EVPN. 111 1.1 Terminology 113 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 114 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 115 document are to be interpreted as described in RFC 2119 [KEYWORDS]. 117 2. Requirements 119 Following are the key requirements for backward compatibility between 120 (PBB-)EVPN and (PBB-)VPLS: 122 1. The solution MUST allow for staged migration towards (PBB-)EVPN on 123 a site-by-site basis per VPN instance - e.g., new EVPN sites to be 124 provisioned on (PBB-)EVPN PEs. 126 2. The solution MUST require no changes to existing VPLS or PBB-VPLS 127 PEs, not even a software upgrade. 129 3. The solution MUST allow for the coexistence of PE nodes running 130 (PBB-)EVPN and (PBB-)VPLS for the same VPN instance and single-homed 131 segments. 133 4. The solution MUST support single-active redundancy of multi-homed 134 networks and multi-homed devices for (PBB-)EVPN PEs. 136 5. In case of single-active redundancy, the participant VPN instances 137 MAY span across both (PBB-)EVPN PEs and (PBB-)VPLS PEs as long as 138 single-active redundancy is employed by (PBB-)EVPN PEs. 140 6. The solution SHOULD support all-active redundancy of multi-homed 141 networks and multi-homed devices for (PBB-)EVPN PEs. 143 7. In case of all-active redundancy, the participant VPN instances 144 SHOULD be confined to (PBB-)EVPN PEs only. 146 8. In case of all-active redundancy, the participant VPN instances 147 MAY span across (PBB-)EVPN and (PBB-)VPLS PEs. 149 These requirements collectively allow for the seamless insertion of 150 the (PBB-)EVPN technology into brown-field (PBB-)VPLS deployments. 152 3 PBB-VPLS Integration with PBB-EVPN 154 In order to support seamless integration with (PBB-)VPLS, the (PBB- 155 )EVPN PEs MUST support EVPN BGP routes (EVPN SAFI) and SHOULD support 156 VPLS AD route (VPLS SAFI). All the logic for the integration will 157 reside on the (PBB-)EVPN PEs side. However, if a VPLS instance is 158 setup without the use of BGP auto-discovery, it is still possible 159 (but cumbersome) for (PBB-)EVPN PEs to integrate into that VPLS 160 instance. 162 3.1 Capability Discovery 164 The (PBB-)EVPN PEs must advertise both the BGP VPLS auto-discovery 165 (AD) route as well as the BGP EVPN Inclusive Multicast route for a 166 given VPN instance. The (PBB-)VPLS PEs only advertise the BGP VPLS AD 167 route, per current standard procedures specified in [RFC4761] and 168 [RFC6074]. The operator may decide to use the same BGP RT for both 169 (PBB-)EVPN and (PBB-)VPLS. In this case, when a (PBB-)VPLS PE 170 receives the EVPN Inclusive Multicast route, it will ignore it on the 171 basis that it belongs to an unknown SAFI. However, the operator may 172 use two RTs (one for (PBB-)VPLS and another for (PBB-)EVPN) and 173 employ RT-constraint in order to prevent EVPN BGP routes from 174 reaching the (PBB-)VPLS PEs. This provides an optimization in case 175 required by the scale of the network. 177 When a (PBB-)EVPN PE receives both a VPLS AD route as well as an EVPN 178 Inclusive Multicast route from a given remote PE for the same VPN 179 instance, it MUST give preference to the EVPN route for the purpose 180 of discovery. This ensures that, at the end of the route exchanges, 181 all (PBB-)EVPN capable PEs discover other (PBB-)EVPN capable PEs as 182 well as the (PBB-)VPLS-only PEs for that VPN instance. Furthermore, 183 all the (PBB-)VPLS-only PEs would discover the (PBB-)EVPN PEs as if 184 they were standard (PBB-)VPLS nodes. In other words, when the 185 discovery phase is complete, the (PBB-)EVPN PEs would have discovered 186 all the PEs in the VPN instance, and their associated capability: 187 (PBB-)EVPN or VPLS-only. Whereas the (PBB-)VPLS PEs would have 188 discovered all the PEs in the VPN instance, as if they were all VPLS- 189 only nodes. 191 3.2 Forwarding Setup and Unicast Operation 193 The procedures for forwarding setup and unicast operation on the 194 (PBB-)VPLS PE are per [RFC4447] and [PBB-VPLS]. 196 The procedures for forwarding state setup and unicast operation on 197 the (PBB-)EVPN PE are as follows: 199 - The (PBB-)EVPN PE must establish a pseudowire to a remote PE from 200 which it has received only a VPLS AD route, for the VPN instance in 201 question, and set up the label stack corresponding to the pseudowire 202 FEC. This PW is between B-components of PBB-EVPN PE and PBB-VPLS PE 203 per section 4 of [PBB-VPLS-PE-MODEL]. 205 - The (PBB-)EVPN PE must set up the label stack corresponding to the 206 MP2P (PBB-)VPN unicast FEC to any remote PE that has advertised EVPN 207 AD route. 209 - If a (PBB-)EVPN PE receives a VPLS AD route followed by an EVPN AD 210 route from the same PE and a pseudowire is setup to that PE, then the 211 (PBB-)EVPN PE MUST deactivate that pseudowire. 213 - If a (PBB-)EVPN PE receives an EVPN AD route followed by a VPLS AD 214 route from the same PE, then the (PBB-)EVPN PE MUST ignore the VPLS 215 AD route. 217 When the (PBB-)EVPN PE receives traffic over the pseudowires, it 218 learns the associated MAC addresses in the data-plane. This is 219 analogous to dynamic learning in IEEE bridges. The (PBB-)EVPN PE 220 learns MAC addresses in the control plane, via the EVPN MAC 221 Advertisement routes sent by remote (PBB-)EVPN PEs, and updates its 222 MAC forwarding table accordingly. This is analogous to static 223 learning in IEEE bridges. In PBB-EVPN, a given B-MAC address can be 224 learnt either over the BGP control-plane from a remote PBB-EVPN PE, 225 or in the data-plane over a pseudowire from a remote PBB-VPLS PE. 226 There is no mobility associated with B-MAC addresses in this context. 227 Hence, when the same B-MAC address shows up behind both a remote PBB- 228 VPLS PE as well as a PBB-EVPN PE, the local PE can deduce that there 229 is an anomaly in the network. 231 3.3 Multicast Operation 233 3.3.1 Ingress Replication The procedures for multicast operation on the 234 (PBB-)VPLS PE, using ingress replication, are per [RFC4447] and [PBB- 235 VPLS]. 237 The procedures for multicast operation on the PBB-EVPN PE, for 238 ingress replication, are as follows: 240 - The PBB-EVPN PE builds a replication sub-list per I-SID to all the 241 remote PBB-EVPN PEs in a given VPN instance, as a result of the 242 exchange of the EVPN Inclusive multicast routes, as described in 243 [PBB-EVPN]. This will be referred to as sub-list A. It comprises MP2P 244 tunnels used for delivering PBB-EVPN BUM traffic [EVPN]. 246 - The PBB-EVPN PE builds a replication sub-list per VPN instance to 247 all the remote PBB-VPLS PEs , as a result of the exchange of the VPLS 248 AD routes. This will be referred to as sub-list B. It comprises 249 pseudowires from the PBB-EVPN PE in question to all the remote PBB- 250 VPLS PEs in the same VPN instance. 252 - The PBB-EVPN PE may further prune sub-list B, on a per I-SID basis, 253 if [MMRP] is run over the PBB-VPLS network. This will be referred to 254 as sub-list C. This list comprises a pruned set of the pseudowires in 255 sub-list B. 257 The replication list, maintained per I-SID, on a given PBB-EVPN PE 258 will be the union of sub-list A and sub-list B if [MMRP] is NOT used, 259 and the union of sub-list A and sub-list C if [MMRP] is used. Note 260 that the PE must enable split-horizon over all the entries in the 261 replication list, across both pseudowires and MP2P tunnels. 263 3.3.2 LSM Will be covered in a future revision of this document. 265 4 VPLS Integration with EVPN 267 4.1 Capability Discovery 269 The procedures for capability discovery are per Section 3.1 above. 271 4.2 Forwarding Setup and Unicast Operation 273 The operation here is largely similar to that of PBB-EVPN integration 274 with PBB-VPLS, with the exception of the need to handle MAC mobility, 275 the details of which will be covered in a future revision of this 276 document. 278 4.3 Multicast Operation 280 4.3.1 Ingress Replication 282 The operation is per the procedures of Section 3.3.1 above for the 283 scenario WITHOUT [MMRP]. The replication list is maintained per VPN 284 instance, rather than per I-SID. 286 4.3.2 LSM Will be covered in a future revision of this document. 288 5 VPLS Integration with PBB-EVPN 290 5.1 Capability Discovery 292 The procedures for capability discovery are per Section 3.1 above. 294 5.2 Forwarding Setup and Unicast Operation 296 The operation here is largely similar to that of PBB-EVPN integration 297 with PBB-VPLS, with a few exceptions listed below: 299 - When a PW is setup between a PBB-EVPN PE and a VPLS PE, it gets 300 setup between the I-component of PBB-EVPN PE and the bridge component 301 of VPLS PE. 303 - The MAC mobility needs to be handled. The details of which will be 304 covered in a future revision of this document. 306 5.3 Multicast Operation 308 5.3.1 Ingress Replication 310 The operation is per the procedures of Section 3.3.1 above for the 311 scenario WITHOUT [MMRP]. The replication list is maintained per I-SID 312 on the PBB-EVPN PEs and per VPN instance on the VPLS PEs. 314 5.3.2 LSM Will be covered in a future revision of this document. 316 6 Solution Advantages 318 The solution for seamless integration of (PBB-)EVPN with (PBB-)VPLS 319 has the following advantages: 321 - When ingress replication is used for multi-destination traffic 322 delivery, the solution reduces the scope of [MMRP] (which is a soft- 323 state protocol) to only that of existing VPLS PEs, and uses the more 324 robust BGP-based mechanism for multicast pruning among new EVPN PEs. 326 - It is completely backward compatible. 328 - New PEs can leverage the extensive multi-homing mechanisms and 329 provisioning simplifications of PBB-EVPN: 330 1. Auto-sensing of MHN / MHD 331 2. Auto-discovery of redundancy group 332 3.Auto-provisioning of DF election and VLAN carving 334 7 Security Considerations 336 No new security considerations beyond those for VPLS and EVPN. 338 8 IANA Considerations 340 This document has no actions for IANA. 342 9 References 344 9.1 Normative References 346 [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate 347 Requirement Levels", BCP 14, RFC 2119, March 1997. 349 [RFC4448] Martini, L., Ed., Rosen, E., El-Aawar, N., and G. Heron, 350 "Encapsulation Methods for Transport of Ethernet over MPLS 351 Networks", RFC 4448, April 2006. 353 [RFC4447] Martini, et al., "Pseudowire Setup and Maintenance using 354 the Label Distribution Protocol", draft-ietf-pwe3- 355 rfc4447bis-02.txt, October 2013. 357 [EVPN] Sajassi et al., "BGP MPLS Based Ethernet VPN", draft-ietf- 358 l2vpn-evpn-04.txt, work in progress, July, 2013. 360 [PBB-EVPN] Sajassi et al., "PBB-EVPN", draft-ietf-l2vpn-pbb-evpn- 361 05.txt, work in progress, October, 2013. 363 9.2 Informative References 365 [MMRP] Clause 10 of "IEEE Standard for Local and metropolitan area 366 networks - Media Access Control (MAC) Bridges and Virtual Bridged 367 Local Area Networks", IEEE Std 802.1Q, 2013. 369 [PBB-VPLS-PE-MODEL] Balus, F., Sajassi, S., Bitar, N., "Extensions to 370 VPLS PE model for Provider Backbone Bridging", RFC xxxx, June 2013. 372 [PBB-VPLS] Sajassi, et al., "VPLS Interoperability with Provider 373 Backbone Bridges", draft-ietf-l2vpn-pbb-vpls-interop-05.txt, work in 374 progress, October, 2013. 376 Authors' Addresses 378 Ali Sajassi 379 Cisco 380 170 West Tasman Drive 381 San Jose, CA 95134, US 382 Email: sajassi@cisco.com 384 Samer Salam 385 Cisco 386 595 Burrard Street, Suite 2123 387 Vancouver, BC V7X 1J1, Canada 388 Email: ssalam@cisco.com 390 Nick Del Regno 391 Verizon 392 400 International Pkwy 393 Richardson, TX 75089, US 394 Email: nick.delregno@verizon.com