Internet DRAFT - draft-yong-vpn4dc-protocol-gap-analysis
draft-yong-vpn4dc-protocol-gap-analysis
Network Working Group L. Yong
Internet Draft S. Hares
Intended status: Informational Huawei
Expires: April 2012 October 24, 2011
L3VPN Protocol Gap Analysis for Data Centers
draft-yong-vpn4dc-protocol-gap-analysis-00
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with
the provisions of BCP 78 and BCP 79.
Distribution of this document is unlimited. Comments should be sent
to the DNSEXT working group mailing list: <rbridge@postel.org>.
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/1id-abstracts.html
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with
respect to this document. Code Components extracted from this
Yong & Hares Expires April 24, 2012 [Page 1]
Internet-Draft VPN4DC Protocol Gap October 2011
document must include Simplified BSD License text as described in
Section 4.e of the Trust Legal Provisions and are provided without
warranty as described in the BSD License.
Abstract
An enterprise may need to connect their applications hosted in
offsite provider data centers to their own premises via their
dedicated L3VPN. The draft reviews L3VPN protocols for this
application and discusses the protocol gaps to meet the requirements
of VPN4DC. [VPN4DC]
Table of Contents
1. Introduction...................................................2
2. Terminology....................................................3
3. L3VPN for an Enterprise........................................3
4. L3VPN for Enterprise and DC Provider Interconnection...........4
5. Protocol Gap Analysis..........................................6
6. Conclusion.....................................................7
7. Security Considerations........................................7
8. IANA Considerations............................................7
9. Acknowledgments................................................7
10. References....................................................7
10.1. Normative References.....................................7
10.2. Informative Reference....................................8
1. Introduction
IP/MPLS L3VPN provides IP Virtual Private Networks (VPNs) for its
customers and has been widely deployed globally for a long time. The
majority L3VPN applications are to interconnect various enterprise
locations. Data center providers want to provide virtual private
data center services (Virtual Private Cloud Services or VPCS) to
enterprise companies, which enables an enterprise to buy server and
storage resources and run its intranet applications in the
provider's multi-tenant data center facilities. This use case drives
enterprise companies' desire to connect hosts residing in provider
data centers to their own locations via a secure VPN, which most
likely is L3VPN. This requires network providers to extend existing
L3VPNs to DC provider locations and make this extranet access as a
secured "intranet" access. This document explores the L3VPN
protocols and discusses the protocol gaps to meet VPN4DC
requirements.[VPN4DC]
Yong & Hares Expires April 24, 2012 [Page 2]
Internet-Draft VPN4DC Protocol Gap October 2011
2. Terminology
AC: Attachment Circuit
CGR: Cloud Gateway Router
CE: Customer Edge
DC: Data Center
L3VPN: IP Virtual Private Network
PE: Provider Edge
VPN: Virtual Private Network
Virtual Data Center (vDC): a Data Center with the virtualization of
hardware and software resources.
VPN4DC: VPN which can extend its VPN connectivity to, or shrink
some of its connectivity's from, computing resources in provider
data centers
3. L3VPN for an Enterprise
Figure 1 illustrates a typical L3VPN for an enterprise. Two (or
more) enterprise sites are interconnected by a L3VPN constructed
over IP/MPLS backbone network. If PE based L3VPN is configured, two
enterprise sites form one IP private network without the awareness
of the backbone existence.
In this L3VPN configuration, one attachment circuit (AC) connects
Customer Edge Router (CE) and Provider Edge Router (PE). An L3VPN
instance (Route Target and Route Distinguisher) is configured on all
the PEs that connect to at least one CE belonging to the L3VPN. On
each PE, an iBGP session and an LSP tunnel to each remote PE is
configured to associate with this VPN. The iBGP is used to populate
the VPN routes among PEs. The LSP tunnel forwards the VPN traffic
between PEs. A PE in a L3VPN learns the routes from directly
connected CE and vice versa. Possible protocols between PE-CE for
route learning are static route, OSPF, RIP, or iBGP/eBGP.
[RFC4364][RFC4577][RFC6368] Both PE and CE can dynamically learn all
the routes from each other. Thus the L3VPN provides any-to-any host
connectivity within the enterprise intranet at multiple sites. It is
Yong & Hares Expires April 24, 2012 [Page 3]
Internet-Draft VPN4DC Protocol Gap October 2011
possible to have some policy control at PEs to constrain allowed
route.
.----------------------.
| IP/MPLS PSN |
*-------* | | *-------*
| +--+ AC +----+ iBGP +----+ AC +--+ |
| |CE+----| PE |............| PE |----+CE| |
|E. +--+ +----+ LSP Tunnel +----+ +--+ E. |
|Site 1 | | | |Site 2 |
*-------* | | *-------*
| |
.----------------------.
Figure 1 L3VPN for an Enterprise
IP/MPLS backbone network can support many L3VPN for different
customers. The separated route tables (VRF) for each VPN instance
ensure customer routes are completely separated and also separated
from IGP routes.
When enterprise DC operators add new hosts or a subnet in one of its
sites, or move a set of hosts from one site to another site, the PEs
learn the route changes from the CE and announce the changes to the
remote PEs; the remote PEs advertise the changes to connected CEs.
The L3VPN protocols are able to automate this routing and forwarding
process.
L3VPN protocols seems sufficient for this application. Operators
often manauly configure the PE-CE protoocl due to the different
requirements from customers.
4. L3VPN for Enterprise and Provider DC Interconnection
When an enterprise purchases computing resources such as servers and
storages from a DC provider, it needs the applications on these
purchased resources to run in the same way as if they reside in the
enterprise DC. Therefore, they would need their VPN service provider
to extend their own VPNs to hosts in provider data centers.
Figure 2 expands Figure 1 and illustrates this scenario. A L3VPN PE
at Site 3 connects to a provider DC. The PE has a physical interface
connecting DC provider cloud gateway router (CGR), which is like the
CE of L3VPN. DC provider constructs many virtual DCs (vDC) for
different customers and may configure many attachment circuits (AC)
over the physical interface attached to the PE. When a L3VPN
enterprise customer buys one vDC service (computing, storage,
Yong & Hares Expires April 24, 2012 [Page 4]
Internet-Draft VPN4DC Protocol Gap October 2011
network, etc) from DC provider, it wants the vDC attaching to its
L3VPN supported by the network provider. Existing technology
requires DC provider and network provider to agree on which AC
should be associated with the L3VPN in the provider network and the
vDC in provider DC. Then the provider and the customer will have to
configure the mappings on CE(CGR) and PE manually or through an
external device/system. Two providers also have to agree on the
routing protocol for PE-CE and configure them properly at its PE and
CE.
.----------------------.
| IP/MPLS PSN |
*-------* | | *-------*
| +--+ AC +----+ iBGP +----+ AC +--+ |
| |CE+----| PE |............| PE |----+CE| |
|E. +--+ +----+ LSP Tunnel +----+ +--+ E. |
|Site 1 | | . . | |Site 2 |
*-------* | . . | *-------*
| +---+ |
| |PE | |
.--------+-+-+---------.
eBGP |AC(s)
|
*---+-+--+----*
| | CGR| | Site 3
| +/--\+ |
| ./. .\. |
| .V. .V. | DC Provider
| .D. .D. |
| .C.~ .C. |
| .1. .n.
| ... ... |
*-------------*
Figure 2 L3VPN for Enterprise and Provider DC Interconnection
Regarding the routing protocol for PE-CE, since the Site 3 is not
controlled by the enterprise customer, it is natural for the
customer wanting the network provider to provide route admission
control and traffic filtering at the site for security reasons. For
example, an enterprise customer may want the PE at Site 3 to perform
VPN access control; only certain IP prefixes in the site are
advertised to other PEs and the packet with certain source IP
addresses can be forwarded to the VPN. This configuration can be
done by either implementing a) BGP policy that limits eBGP routes
accepted at the PE, or b) proxy aggregation at the PE, or c)
insertion of static routes that summarize the data center routes.
Yong & Hares Expires April 24, 2012 [Page 5]
Internet-Draft VPN4DC Protocol Gap October 2011
Thus, the configurations at Enterprise sites and DC provider sites
are very different; the routing protocol may be different as well.
For example, use OSPF or iBGP for PE-CE routing at Enterprise sites
and use eBGP at DC provider sites.
Note 1: A network provider can construct a L3VPN for an enterprise
with one intranet and some extranets today. However, the enterprise
has to manage extranet security itself by using firewall devices.
The traffic from an extranet access will be first routed to a
particulate site where the enterprise has the firewall and then be
routed within the intranet. [VPN4DC] requires that the applications
running at the provider DC sites appear in the same way as if
running in enterprise data center. This implies that the traffic
from a Provider DC site does not go through the enterprise firewall.
This requires the PE at site 3 perform the security access control
for the Intranet.
Note 2: Network provider L3VPN configuration has no assumption about
DC network configuration. DC may also use VPNs to separate
customers' traffic. DC VPN and Provider L3VPN are configured
independently for an enterprise customer. Two VPNs are stitching
together over PE-CGR interface. This document aims on this
architecture. Other architectures are outside the scope of this
analysis.
L3VPN for this application is new and is facing some challenges as
pointed out below.
5. Protocol Gap Analysis
Section 3-4 review the necessary configurations and protocols of a
L3VPN in IP/MPLS provider network for an enterprise customer, and a
L3VPN extension to a DC provider site for connecting to vDC offered
by DC provider. Such L3VPN provides routing and forwarding among
attached CEs, which is the need for VPN4DC. However, we have
identified at least the following VPN4DC requirements [VPN4DC] that
current L3VPN protocols cannot support.
o [VPN4DC] requires a CGR to signal the adjacent PE for the PE to
join a specific L3VPN in a provider network. This requires a DC
provider and network provider have a common agreed key for a
customer who buys a L3VPN and vDC. DC provider itself maintains
the key to vDC mappings; network provider maintains the key to
L3VPN ID mapping. CGR always uses the key to signal a request for
a particular L3VPN. For the security reason, it is necessary to
have a security ID associated with the key. [PROBLEM]
Yong & Hares Expires April 24, 2012 [Page 6]
Internet-Draft VPN4DC Protocol Gap October 2011
o [VPN4DC] requires a CGR to signal a "host join" or "host leave"
request to its adjacent PE for a set of host IDs (IP/MAC/VDC
addresses) to attach to or be away from a particular L3VPN
instance; and requires the network provider to authenticate the
request prior to populate the relevant host reachability within
the L3VPN. This implies that the PE performs route admission
control at DC provider sites.
o [VPN4DC] requires a CGR to signal one or a set of point-to-point
BW request for a particular L3VPN instance. This request is on-
demand basis. The PE needs to allocate the BW on the LSP
Tunnel(s) that associate to the L3VPN and are on the requested
path upon receiving the request.
o [VPN4DC] requires a CGR to inform L3VPN PE about the connectivity
within the DC network between PE and hosts.
Multiple protocols apply to PE-CE for L3VPN routing learning. None
of them is able to provide these capabilities.
6. Conclusion
L3VPN can apply to the interconnection among enterprise sites and DC
provider sites in supporting private cloud services. The key
challenge is the configuration of the PE at Provider DC site. The
document identifies several VPN4DC requirements that L3VPN protocols
cannot support yet.
7. Security Considerations
TBD.
8. IANA Considerations
The document does not require any IANA action.
9. Acknowledgments
Authors like to thanks Linda Dunbar, Ning So for their valuable
suggestions.
10. References
10.1. Normative References
[RFC4363] Rosen, E. and Rekhter, Y., "BGP/MPLS IP Virtual Private
Networks (VPNs)", February 2006.
Yong & Hares Expires April 24, 2012 [Page 7]
Internet-Draft VPN4DC Protocol Gap October 2011
[RFC4577] Rosen, E., Psenak, P., and Pillay-Esnault, P., "OSPF as
the Provider/Customer Edge Protocol for BGP/MPLS IP
Virtual Private Network (VPNs)", RFC4577, Jun 2006
[RFC6368] Marques, P., et al, "Internal BGP as the
Provider/Customer Edge Protocol for BGP/MPLS IP Virtual
Private Networks (VPNs)", RFC6368, September 2011.
10.2. Informative Reference
[VPN4DC] So, et al, "Requirement of Layer 3 Virtual Private Network
for Data Centers", draft-so-vpn4dc-00, October 2011.
[PROBLEM] L. Dunbar, et al, "Problem Statement for VPN for Data
Centers", draft-dunbar-vpn4dc-problem-statement-00,
October 2011.
Authors' Addresses
Lucy Yong
Huawei Technologies (USA)
5340 Legacy Drive
Plano, TX75025
Phone: +1-469-277-5873
Email: lucy.yong@huawei.com
Susan Hares
Huawei Technologies (USA)
2330 Central Expressway
Santa Clara, CA 95050
Phone: +408-330-4581
Email: susan.hares@huawei.com
Yong & Hares Expires April 24, 2012 [Page 8]
