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: . 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]