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]