Network Working Group Kireeti Kompella Internet Draft Juniper Networks Expiration Date: August 2001 Ronald Bonica WorldCom Whither Layer 2 VPNs? draft-kb-ppvpn-l2vpn-motiv-00.txt Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as ``work in progress.'' The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Abstract Virtual Private Networks (VPNs) based on Frame Relay or ATM circuits have been around a long time. While these VPNs work well, the costs of maintaining separate networks for Internet traffic and VPNs and the administrative burden of provisioning these VPNs have led Service Providers to look for alternative solutions. In this document, we review the good and bad of Layer 2 VPNs, and what it would take to make them viable to a Service Provider. Bonica/Kompella [Page 1] Internet Draft draft-kb-ppvpn-l2vpn-motiv-00.txt February 2001 1. Introduction The first corporate networks were based on dedicated leased lines interconnecting the various offices of the corporation. Such networks offered connectivity and little else: they didn't scale well, they were expensive for the service providers (and hence for their customers), and provisioning them was a slow and arduous task. The first Virtual Private Networks (VPNs) were based on Layer 2 circuits: X.25, Frame Relay and ATM (see [VPN]). Layer 2 VPNs were easier to provision, and virtual circuits allowed the service provider to share a common infrastructure for all the VPNs. These features were passed on to the customers in terms of cost savings. However, while Layer 2 VPNs were a significant step forward from dedicated lines, they still had their drawbacks. First, they tied the service provider VPN infrastructure to a single medium (e.g., ATM). This became even more of a burden if the Internet infrastructure was to share the same physical links. Second, the Internet infrastructure and the VPN infrastructure, even if they shared the same physical network, needed separate administration and maintenance. Third, while provisioning was much easier than for dedicated lines, it was still complex. This was especially evident in the effort to add a site to an existing VPN. This document describes the advantages and drawbacks of Layer 2 VPNs, and what it would to make this a viable approach from the Service Providers' point of view. 1.1. Terminology The terminology we use follows. A "customer" is a customer of a Service Provider seeking to interconnect the various "sites" (independently connected networks) through the Service Provider's network, while maintaining privacy of communication and address space. The device in a customer site that connects to a Service Provider router is termed the CE (customer edge device); this device may be a router or a switch. The Service Provider router to which a CE connects is termed a PE. This follows the terminology in [IPVPN]. Bonica/Kompella [Page 2] Internet Draft draft-kb-ppvpn-l2vpn-motiv-00.txt February 2001 2. Routing Properties of Layer 2 VPNs We define a Layer 2 VPN as one where a Service Provider provides a layer 2 network to the customer. As far as the customer is concerned, they have (say) Frame Relay circuits connecting the various sites; each CE is configured with a DLCI with which to talk to other CEs. As far as the Service Provider is concerned, routing within the SP network is based solely on layer 2 addresses. The Service Provider does not participate in the customer's layer 3 network, in particular, in the routing. This has several consequences, some of which will be discussed below. 2.1. Layer 3 Independence The first consequence of having a Layer 2 VPN is that the customer is free to run any Layer 3 protocols that they wish to, without regard for what Layer 3 protocols the Service Provider supports. In particular, the routing protocols used by the customer need not be supported by the SP. 2.2. Separation of Administrative Responsibilities In a Layer 2 VPN, the Service Provider is responsible for Layer 2 connectivity; the customer is responsible for Layer 3 connectivity, which includes routing. If the customer says that host x in site A cannot reach host y in site B, the Service Provider need only demonstrate that site A is connected to site B. The details of how routes for host y reach host x are the customer's responsibility. 2.3. Routing Scalability Say site A is attached to PE X. Then X only has to know what layer 2 address A will use to reach site B in order to route packets to B. This means that each PE must carry at most N routes for a VPN with N sites. This constrasts with carrying all of site B's layer 3 addresses in order to route packets to B at layer 3; here a PE must N*k routes if each site contains k subnets. A corollary to carrying more information is that more can change, making the impact of sites coming up or going down, and flapping in general, more of a burden. On the other hand, a full mesh of layer 2 circuits means that N**2 layer 2 addresses are needed; a naive approach would mean that the Bonica/Kompella [Page 3] Internet Draft draft-kb-ppvpn-l2vpn-motiv-00.txt February 2001 total number of routes for a layer 2 VPN would be quadratic in the size of the VPN. Note that it is possible that site A has 2 or more layer 2 addresses to reach site B, perhaps for reasons of Class-of-Service. See later for more discussion. 2.4. Privacy of Routing In a Layer 2 VPN, the privacy of customer routing is a natural fallout of the fact that the Service Provider does not participate in routing. The SP routers need not do anything special to keep customer routes separate from other customers or from the Internet; there is no need for per-VPN routing tables, and the additional complexity this imposes on PE routers. 2.5. Routing Adjacencies Since the customer is responsible for maintaining routing, it follows that the customer routers must maintain adjacencies to all the other sites to which they are connected. For example, in a full mesh configuration, each customer edge router will need to have routing adjacencies to every other customer edge router. In a hub-and-spoke topology, the "hub" router must maintain adjacencies with all the spoke routers. If, on the other hand, the Service Provider participates in customer routing, the CE router may only have to peer with the PE router; the PE router then takes on the task of distributing this CE's routes to all other CEs that need to know. 2.6. Class of Service Since Class of Service determination is almost always at layer 3 or above, the task of classifying packets devolves to the CE router. One way to achieve this is to have multiple layer 2 circuits between each pair of CE routers, one for each supported class of service. 2.7. Multicast Again, since multicast routing is a layer 3 activity, the burden of determining the destinations and replicating the packets as needed falls on the CE router. Furthermore, the optimization of packet traffic within the SP network is not possible, as the SP routers have Bonica/Kompella [Page 4] Internet Draft draft-kb-ppvpn-l2vpn-motiv-00.txt February 2001 no visibility into the multicast packets. On the other hand, multicast state is strictly kept in the CE routers. 3. Other Aspects 3.1. Infrastructure One aspect of Layer 2 VPNs that makes their administration complex and expensive is that they often require Service Providers to maintain multiple infrastructures. For example, if customers want Frame Relay circuits, then Service Providers not only have to have Frame Relay switches on the edge of the network, but also in the core. Similarly, SPs may need to have ATM switches, Ethernet switches and additionally a public Internet infrastructure. Having multiple infrastructures makes the SP network more expensive, and more complex to administer and monitor. Thus, a Layer 2 VPN solution should offer a means of converging the network to one infrastructure. 3.2. Ease of Configuration Configuring traditional Layer 2 VPNs is a burden. The primary problem is the O(N*N) nature of the task. If there are N CEs in a Frame Relay VPN, say full-mesh connected, N*(N-1)/2 DLCI PVCs must be provisioned across the SP network. At each CE, (N-1) DLCIs must be configured to reach each of the other CEs. Furthermore, when a new CE is added, N new DLCI PVCs must be provisioned; also, each existing CE must be updated with a new DLCI to reach the new CE. Exacerbating this problem is the fact that provisioning is largely manual; either appropriate signaling mechanisms are not available, or do not work adequately. To have a viable Layer 2 VPN solution requires that configuring a VPN be reasonably automated, and that the incremental work in adding sites be bounded, ideally to configuring one PE device. Bonica/Kompella [Page 5] Internet Draft draft-kb-ppvpn-l2vpn-motiv-00.txt February 2001 3.3. Security This is a real issue. The criterion "as secure as Frame Relay", or even "as secure as your phone service" is no longer sufficient in many if not most instances. Running away from the problem doesn't solve it, either. For now, though, punting will have to suffice. 3.4. Migration Since many customers have "traditional" Layer 2 VPNs (i.e., real Frame Relay circuits connecting sites), the issue of migrating from existing VPN solutions and transition plans to accommodate new VPN solutions are an important concern. A Layer 2 VPN solution that preserves the layer 2 nature on the customer front means that this issue is completely defused, at least as far as the SP customer is concerned. 4. Requirements Given that Layer 2 VPNs are in widespread use, and that the paradigm is a familiar one to many VPN customers, and given further that this approach has certain advantages for the Service Provider, coming up with a solution to those aspects of Layer 2 VPNs that make them unattractive while preserving the basic model seems like a useful approach. The following conditions should be met in the SP network: 1) A single network infrastructure should suffice for all services, public IP, VPNs, Traffic Engineering, Differentiated Services. 2) The additional routing burden that a Service Provider must carry should be strictly bounded. 3) Provisioning VPNs should be simple and automated. In particular, adding or removing sites should be as localized as possible. 4) Provisioning VPN services should be largely independent of provisioning network services. Bonica/Kompella [Page 6] Internet Draft draft-kb-ppvpn-l2vpn-motiv-00.txt February 2001 5. Security Considerations Some of the security aspects are discussed here, but this is by no means complete (understatement). 6. References [IPVPN] Rosen, E., and Rekhter, Y., "BGP/MPLS VPNs", RFC 2547, March 1999. [VPN] Kosiur, Dave, "Building and Managing Virtual Private Networks", Wiley Computer Publishing, 1998. 7. Full Copyright Statement Copyright (C) The Internet Society (2001). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Bonica/Kompella [Page 7] Internet Draft draft-kb-ppvpn-l2vpn-motiv-00.txt February 2001 8. Author Information Kireeti Kompella Juniper Networks 1194 N. Mathilda Ave Sunnyvale, CA 94089 kireeti@juniper.net Ronald P. Bonica WorldCom 22001 Loudoun County Pkwy Ashburn, Virginia, 20147 rbonica@mci.net Bonica/Kompella [Page 8]