idnits 2.17.1 draft-ietf-bess-evpn-vpls-seamless-integ-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 (February 20, 2015) is 3350 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 257, but not defined == Missing Reference: 'RFC6074' is mentioned on line 188, but not defined == Missing Reference: 'RFC4762' is mentioned on line 258, but not defined == Missing Reference: 'EVPN' is mentioned on line 267, but not defined == Unused Reference: 'RFC4448' is defined on line 372, but no explicit reference was found in the text == Unused Reference: 'RFC7432' is defined on line 380, 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 (-10) exists of draft-ietf-l2vpn-pbb-evpn-09 Summary: 0 errors (**), 0 flaws (~~), 9 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 Jorge Rabadan 10 Alcatel-Lucent 12 Expires: August 20, 2015 February 20, 2015 14 (PBB-)EVPN Seamless Integration with (PBB-)VPLS 15 draft-ietf-bess-evpn-vpls-seamless-integ-00 17 Abstract 19 This draft discusses the backward compatibility of the (PBB-)EVPN 20 solution with (PBB-)VPLS and provides mechanisms for seamless 21 integration of the two technologies in the same MPLS/IP network on a 22 per-VPN-instance basis. 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) 2013 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 2. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 4 64 3 PBB-VPLS Integration with PBB-EVPN . . . . . . . . . . . . . . . 4 65 3.1 Capability Discovery . . . . . . . . . . . . . . . . . . . . 4 66 3.2 Forwarding Setup and Unicast Operation . . . . . . . . . . . 5 67 3.3 Multicast Operation . . . . . . . . . . . . . . . . . . . . 6 68 3.3.1 Ingress Replication . . . . . . . . . . . . . . . . . . 6 69 3.3.2 LSM . . . . . . . . . . . . . . . . . . . . . . . . . . 7 70 4 VPLS Integration with EVPN . . . . . . . . . . . . . . . . . . . 7 71 4.1 Capability Discovery . . . . . . . . . . . . . . . . . . . . 7 72 4.2 Forwarding Setup and Unicast Operation . . . . . . . . . . . 7 73 4.3 Multicast Operation . . . . . . . . . . . . . . . . . . . . 7 74 4.3.1 Ingress Replication . . . . . . . . . . . . . . . . . . 7 75 4.3.2 LSM . . . . . . . . . . . . . . . . . . . . . . . . . . 7 76 5 VPLS Integration with PBB-EVPN . . . . . . . . . . . . . . . . . 7 77 5.1 Capability Discovery . . . . . . . . . . . . . . . . . . . . 7 78 5.2 Forwarding Setup and Unicast Operation . . . . . . . . . . . 7 79 5.3 Multicast Operation . . . . . . . . . . . . . . . . . . . . 8 80 5.3.1 Ingress Replication . . . . . . . . . . . . . . . . . . 8 81 5.3.2 LSM . . . . . . . . . . . . . . . . . . . . . . . . . . 8 82 6 Solution Advantages . . . . . . . . . . . . . . . . . . . . . . 8 83 7 Security Considerations . . . . . . . . . . . . . . . . . . . . 8 84 8 IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 8 85 9 References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 86 9.1 Normative References . . . . . . . . . . . . . . . . . . . 8 87 9.2 Informative References . . . . . . . . . . . . . . . . . . 9 88 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9 90 1 Introduction 92 VPLS and PBB-VPLS are widely-deployed L2VPN technologies. Many SPs 93 who are looking at adopting EVPN and PBB-EVPN want to preserve their 94 investment in the (PBB-)VPLS networks. Hence, it is required to 95 provide mechanisms by which (PBB-)EVPN technology can be introduced 96 into existing L2VPN networks without requiring a fork-lift upgrade. 97 This document discusses mechanisms for the seamless integration of 98 the two technologies in the same MPLS/IP network. 100 VPLS PE 101 +---+ 102 |PE1| 103 +---+ 104 / 105 EVPN/VPLS PE +---------------+ EVPN/VPLS PE 106 +---+ | | +---+ 107 |PE4|----| MPLS/IP |---|PE5| 108 +---+ | Core | +---+ 109 | | 110 +---------------+ 111 / \ 112 +---+ +---+ 113 |PE2| |PE3| 114 +---+ +---+ 115 VPLS PE VPLS PE 117 Figure 1: Seamless Integration of (PBB-)EVPN PEs & (PBB-)VPLS 119 Section 2 provides the details of the requirements. Section 3 120 discusses PBB-VPLS integration with PBB-EVPN. Section 4 discusses the 121 integration of VPLS and EVPN. Section 5 discusses the integration of 122 VPLS and PBB-EVPN, and finally Section 6 discusses the solution 123 advantages. 125 It is worth noting that the scenario where PBB-VPLS is integrated 126 with EVPN, is for future study and upon market validation. The reason 127 for that is that deployments which employ PBB-VPLS typically require 128 PBB encapsulation for various reasons. Hence, it is expected that for 129 those deployments the evolution path would be from PBB-VPLS towards 130 PBB-EVPN, rather than EVPN. 132 1.1 Terminology 134 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 135 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 136 document are to be interpreted as described in RFC 2119 [KEYWORDS]. 138 2. Requirements 140 Following are the key requirements for backward compatibility between 141 (PBB-)EVPN and (PBB-)VPLS: 143 1. The solution MUST allow for staged migration towards (PBB-)EVPN on 144 a site-by-site basis per VPN instance - e.g., new EVPN sites to be 145 provisioned on (PBB-)EVPN PEs. 147 2. The solution MUST require no changes to existing VPLS or PBB-VPLS 148 PEs, not even a software upgrade. 150 3. The solution MUST allow for the coexistence of PE nodes running 151 (PBB-)EVPN and (PBB-)VPLS for the same VPN instance and single-homed 152 segments. 154 4. The solution MUST support single-active redundancy of multi-homed 155 networks and multi-homed devices for (PBB-)EVPN PEs. 157 5. In case of single-active redundancy, the participant VPN instances 158 MAY span across both (PBB-)EVPN PEs and (PBB-)VPLS PEs as long as 159 single-active redundancy is employed by (PBB-)EVPN PEs. In case of an 160 ES link failure, the (PBB-)EVPN PEs will send a BGP mass-withdraw to 161 the EVPN peers OR MAC advertisement with MAC Mobility extended 162 community for PBB-EVPN AND an LDP MAC withdrawal to the VPLS peers. 164 6. The solution SHOULD support all-active redundancy of multi-homed 165 networks and multi-homed devices for (PBB-)EVPN PEs. 167 7. In case of all-active redundancy, the participant VPN instances 168 SHOULD be confined to (PBB-)EVPN PEs only. 170 These requirements collectively allow for the seamless insertion of 171 the (PBB-)EVPN technology into brown-field (PBB-)VPLS deployments. 173 3 PBB-VPLS Integration with PBB-EVPN 175 In order to support seamless integration with (PBB-)VPLS, the (PBB- 176 )EVPN PEs MUST support EVPN BGP routes (EVPN SAFI) and SHOULD support 177 VPLS AD route (VPLS SAFI). All the logic for the integration will 178 reside on the (PBB-)EVPN PEs side. However, if a VPLS instance is 179 setup without the use of BGP auto-discovery, it is still possible 180 (but cumbersome) for (PBB-)EVPN PEs to integrate into that VPLS 181 instance. 183 3.1 Capability Discovery 184 The (PBB-)EVPN PEs must advertise both the BGP VPLS auto-discovery 185 (AD) route as well as the BGP EVPN Inclusive Multicast route for a 186 given VPN instance. The (PBB-)VPLS PEs only advertise the BGP VPLS AD 187 route, per current standard procedures specified in [RFC4761] and 188 [RFC6074]. The operator may decide to use the same BGP RT for both 189 (PBB-)EVPN and (PBB-)VPLS. In this case, when a (PBB-)VPLS PE 190 receives the EVPN Inclusive Multicast route, it will ignore it on the 191 basis that it belongs to an unknown SAFI. However, the operator may 192 use two RTs (one for (PBB-)VPLS and another for (PBB-)EVPN) and 193 employ RT-constraint in order to prevent EVPN BGP routes from 194 reaching the (PBB-)VPLS PEs. This provides an optimization in case 195 required by the scale of the network. 197 When a (PBB-)EVPN PE receives both a VPLS AD route as well as an EVPN 198 Inclusive Multicast route from a given remote PE for the same VPN 199 instance, it MUST give preference to the EVPN route for the purpose 200 of discovery. This ensures that, at the end of the route exchanges, 201 all (PBB-)EVPN capable PEs discover other (PBB-)EVPN capable PEs as 202 well as the (PBB-)VPLS-only PEs for that VPN instance. Furthermore, 203 all the (PBB-)VPLS-only PEs would discover the (PBB-)EVPN PEs as if 204 they were standard (PBB-)VPLS nodes. In other words, when the 205 discovery phase is complete, the (PBB-)EVPN PEs would have discovered 206 all the PEs in the VPN instance, and their associated capability: 207 (PBB-)EVPN or VPLS-only. Whereas the (PBB-)VPLS PEs would have 208 discovered all the PEs in the VPN instance, as if they were all VPLS- 209 only nodes. 211 3.2 Forwarding Setup and Unicast Operation 213 The procedures for forwarding setup and unicast operation on the 214 (PBB-)VPLS PE are per [RFC4447] and [RFC7080]. 216 The procedures for forwarding state setup and unicast operation on 217 the (PBB-)EVPN PE are as follows: 219 - The (PBB-)EVPN PE must establish a pseudowire to a remote PE from 220 which it has received only a VPLS AD route, for the VPN instance in 221 question, and set up the label stack corresponding to the pseudowire 222 FEC. This PW is between B-components of PBB-EVPN PE and PBB-VPLS PE 223 per section 4 of [RFC7041]. 225 - The (PBB-)EVPN PE must set up the label stack corresponding to the 226 MP2P (PBB-)VPN unicast FEC to any remote PE that has advertised EVPN 227 AD route. 229 - If a (PBB-)EVPN PE receives a VPLS AD route followed by an EVPN AD 230 route from the same PE and a pseudowire is setup to that PE, then the 231 (PBB-)EVPN MUST bring that pseudowire operationally down. 233 - If a (PBB-)EVPN PE receives an EVPN AD route followed by a VPLS AD 234 route from the same PE, then the (PBB-)EVPN PE will setup the 235 pseudowire but MUST keep it operationally down. 237 When the (PBB-)EVPN PE receives traffic over the pseudowires, it 238 learns the associated MAC addresses in the data-plane. This is 239 analogous to dynamic learning in IEEE bridges. If the PW belongs to 240 the same split-horizon group as the EVPN mesh, then the MAC addresses 241 learnt and associated to the PW will NOT be advertised in the control 242 plane to any remote (PBB-)EVPN PE. The (PBB-)EVPN PE learns MAC 243 addresses in the control plane, via the EVPN MAC Advertisement routes 244 sent by remote (PBB-)EVPN PEs, and updates its MAC forwarding table 245 accordingly. This is analogous to static learning in IEEE bridges. In 246 PBB-EVPN, a given B-MAC address can be learnt either over the BGP 247 control-plane from a remote PBB-EVPN PE, or in the data-plane over a 248 pseudowire from a remote PBB-VPLS PE. There is no mobility associated 249 with B-MAC addresses in this context. Hence, when the same B-MAC 250 address shows up behind both a remote PBB-VPLS PE as well as a PBB- 251 EVPN PE, the local PE can deduce that there is an anomaly in the 252 network. 254 3.3 Multicast Operation 256 3.3.1 Ingress Replication The procedures for multicast operation on the 257 (PBB-)VPLS PE, using ingress replication, are per [RFC4761], 258 [RFC4762], and [RFC7080]. 260 The procedures for multicast operation on the PBB-EVPN PE, for 261 ingress replication, are as follows: 263 - The PBB-EVPN PE builds a replication sub-list per I-SID to all the 264 remote PBB-EVPN PEs in a given VPN instance, as a result of the 265 exchange of the EVPN Inclusive multicast routes, as described in 266 [PBB-EVPN]. This will be referred to as sub-list A. It comprises MP2P 267 tunnels used for delivering PBB-EVPN BUM traffic [EVPN]. 269 - The PBB-EVPN PE builds a replication sub-list per VPN instance to 270 all the remote PBB-VPLS PEs , as a result of the exchange of the VPLS 271 AD routes. This will be referred to as sub-list B. It comprises 272 pseudowires from the PBB-EVPN PE in question to all the remote PBB- 273 VPLS PEs in the same VPN instance. 275 - The PBB-EVPN PE may further prune sub-list B, on a per I-SID basis, 276 if [MMRP] is run over the PBB-VPLS network. This will be referred to 277 as sub-list C. This list comprises a pruned set of the pseudowires in 278 sub-list B. 280 The replication list, maintained per I-SID, on a given PBB-EVPN PE 281 will be the union of sub-list A and sub-list B if [MMRP] is NOT used, 282 and the union of sub-list A and sub-list C if [MMRP] is used. Note 283 that the PE must enable split-horizon over all the entries in the 284 replication list, across both pseudowires and MP2P tunnels. 286 3.3.2 LSM Will be covered in a future revision of this document. 288 4 VPLS Integration with EVPN 290 4.1 Capability Discovery 292 The procedures for capability discovery are per Section 3.1 above. 294 4.2 Forwarding Setup and Unicast Operation 296 The operation here is largely similar to that of PBB-EVPN integration 297 with PBB-VPLS, with the exception of the need to handle MAC mobility, 298 the details of which will be covered in a future revision of this 299 document. 301 4.3 Multicast Operation 303 4.3.1 Ingress Replication 305 The operation is per the procedures of Section 3.3.1 above for the 306 scenario WITHOUT [MMRP]. The replication list is maintained per VPN 307 instance, rather than per I-SID. 309 4.3.2 LSM Will be covered in a future revision of this document. 311 5 VPLS Integration with PBB-EVPN 313 5.1 Capability Discovery 315 The procedures for capability discovery are per Section 3.1 above. 317 5.2 Forwarding Setup and Unicast Operation 319 The operation here is largely similar to that of PBB-EVPN integration 320 with PBB-VPLS, with a few exceptions listed below: 322 - When a PW is setup between a PBB-EVPN PE and a VPLS PE, it gets 323 setup between the I-component of PBB-EVPN PE and the bridge component 324 of VPLS PE. 326 - The MAC mobility needs to be handled. The details of which will be 327 covered in a future revision of this document. 329 5.3 Multicast Operation 331 5.3.1 Ingress Replication 333 The operation is per the procedures of Section 3.3.1 above for the 334 scenario WITHOUT [MMRP]. The replication list is maintained per I-SID 335 on the PBB-EVPN PEs and per VPN instance on the VPLS PEs. 337 5.3.2 LSM Will be covered in a future revision of this document. 339 6 Solution Advantages 341 The solution for seamless integration of (PBB-)EVPN with (PBB-)VPLS 342 has the following advantages: 344 - When ingress replication is used for multi-destination traffic 345 delivery, the solution reduces the scope of [MMRP] (which is a soft- 346 state protocol) to only that of existing VPLS PEs, and uses the more 347 robust BGP-based mechanism for multicast pruning among new EVPN PEs. 349 - It is completely backward compatible. 351 - New PEs can leverage the extensive multi-homing mechanisms and 352 provisioning simplifications of PBB-EVPN: 353 1. Auto-sensing of MHN / MHD 354 2. Auto-discovery of redundancy group 355 3.Auto-provisioning of DF election and VLAN carving 357 7 Security Considerations 359 No new security considerations beyond those for VPLS and EVPN. 361 8 IANA Considerations 363 This document has no actions for IANA. 365 9 References 367 9.1 Normative References 369 [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate 370 Requirement Levels", BCP 14, RFC 2119, March 1997. 372 [RFC4448] Martini, L., Ed., Rosen, E., El-Aawar, N., and G. Heron, 373 "Encapsulation Methods for Transport of Ethernet over MPLS 374 Networks", RFC 4448, April 2006. 376 [RFC4447] Martini, et al., "Pseudowire Setup and Maintenance using 377 the Label Distribution Protocol", draft-ietf-pwe3- 378 rfc4447bis-02.txt, October 2013. 380 [RFC7432] Sajassi et al., "BGP MPLS Based Ethernet VPN", RFC 7432, 381 February, 2015. 383 [PBB-EVPN] Sajassi et al., "PBB-EVPN", draft-ietf-l2vpn-pbb-evpn- 384 09.txt, work in progress, October, 2014. 386 9.2 Informative References 388 [MMRP] Clause 10 of "IEEE Standard for Local and metropolitan area 389 networks - Media Access Control (MAC) Bridges and Virtual Bridged 390 Local Area Networks", IEEE Std 802.1Q, 2013. 392 [RFC7041] Balus et al., "Extensions to VPLS PE model for Provider 393 Backbone Bridging", RFC 7041, November 2013. 395 [RFC7080] Sajassi et al., "VPLS Interoperability with Provider 396 Backbone Bridges", RFC 7080, December, 2013. 398 Authors' Addresses 400 Ali Sajassi 401 Cisco 402 Email: sajassi@cisco.com 404 Samer Salam 405 Cisco 406 595 Burrard Street, Suite 2123 407 Vancouver, BC V7X 1J1, Canada 408 Email: ssalam@cisco.com 410 Nick Del Regno 411 Verizon 412 400 International Pkwy 413 Richardson, TX 75089, US 414 Email: nick.delregno@verizon.com 416 Jorge Rabadan 417 Alcatel-Lucent 418 400 International Pkwy 419 Richardson, TX 75089, US 420 Email: jorge.rabadan@alcatel-lucent.com