VPN4DC L. Dunbar Internet Draft Huawei Intended status: Information Track N. So Expires: April 2012 Verizon October 24, 2011 VPN4DC Problem Statement draft-dunbar-vpn4dc-problem-statement-00.txt Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. 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 This Internet-Draft will expire on April 24, 2011. 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 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. So Expires April 24, 2012 [Page 1] Internet-Draft Problem statement for VPN4DC 2011-10-05 Abstract VPN4DC is for extending an existing VPN to connect hosts in public data center(s) which are purchased or leased by VPN client. This draft describes the issues and problems associated with this kind of services. Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC-2119 0. Table of Contents 1. Introduction ................................................ 2 2. Terminology ................................................. 3 3. Connecting hosts in public Data Centers with a VPN .......... 4 4. Hosts connectivity for VPN Oriented Data Center Service...... 4 5. APIs between VPN PEs and Data Center Gateways ............... 6 5.1. What to be communicated between VPN PEs and Data Center Gateways? ................................................... 6 6. Conclusion and Recommendation................................ 7 7. Manageability Considerations................................. 7 8. Security Considerations...................................... 7 9. IANA Considerations ......................................... 8 10. Acknowledgments ............................................ 8 11. References ................................................. 8 Authors' Addresses ............................................. 8 Intellectual Property Statement................................. 8 Disclaimer of Validity ......................................... 9 1. Introduction VPN4DC lets VPN clients to connect to their leased or purchased computing resources in public data centers via their own VPNs. In another words, VPN4DC is elastic which allows a VPN to extend its connectivity to (or shrink its connectivity from) resources in one or multiple public data centers. This kind of service is attractive to VPN customers who often do not want to use public Internet to access purchased or leased resources in public data centers. Dunbar Expires April 24, 2012 [Page 2] Internet-Draft Problem statement for VPN4DC 2011-10-05 For ease of description, this problem statement focuses on making today's L3VPN to seamlessly extend to client's hosts in public data centers. 2. Terminology Aggregation Switch: A Layer 2 switch interconnecting ToR switches Bridge: IEEE802.1Q compliant device. In this draft, Bridge is used interchangeably with Layer 2 switch. DC: Data Center DA: Destination Address EOR: End of Row switches in data center. FDB: Filtering Database for Bridge or Layer 2 switch Public data center: internet data center which offers hosting or computing resources to many different clients SA: Source Address ToR: Top of Rack Switch. It is also known as access switch VDCS: VPN oriented data center services VM: Virtual Machines VPN: Virtual Private Network VPN-o-CS: VPN oriented Computing Service VPN4DC: Elastic VPN which can extend its VPN connectivity to, or shrink some of its connectivity's from, computing resources in public data centers Dunbar Expires April 24, 2012 [Page 3] Internet-Draft Problem statement for VPN4DC 2011-10-05 3. Connecting hosts in public Data Centers with a VPN Hosts in data centers are managed by data center operators which are assisted by their own resource and network management systems. VPNs are managed by network service providers, which are most likely different organizations. If enterprises want to offload their applications to public data centers and connect those purchased/leased resources with their own intranet via VPN, the enterprises have to do following steps separately: 1. Contact data center operators to purchase computing resources 2. Get network configuration from the data center operators on how and where their purchased hosts are placed 3. Ask their VPN operators to add attachment circuits on the PEs which are adjacent to the data centers in which their hosts reside. One big issue associated with this process is that the client VPN's network provider may not have PEs in close proximity to the data centers from which clients' remote hosts are purchased or leased. It can be very difficult to connect hosts in 3rd party data centers to a provider VPN. Under this scenario, the only option is to use tunnels, e.g. IPSec, between 3rd party data centers and VPN provider PEs. This approach will definitely turn away some enterprises that have paid premium for their VPNs. When VPN service providers do have PEs co-located, or via secure links connected, with the 3rd party data centers from which clients' remote hosts are purchased, proper configuration on the PEs can be very challenging. The VPN operator has to know how their PEs are connected to the 3rd party data center gateway routers, what protocols are supported on the connections, which network segments have the hosts belonging to a particular VPN client, etc.. To get all those information accurately, a lot of coordination is needed among VPN clients, VPN service providers, and 3rd party data center operators. This process can be very long and error prone. 4. Hosts connectivity for VPN Oriented Data Center Service The VPN oriented data center service [VDCS] describes a service model where VPN clients can assume the computing resources purchased from VPN service providers are already linked with their corresponding VPNs. Dunbar Expires April 24, 2012 [Page 4] Internet-Draft Problem statement for VPN4DC 2011-10-05 To enable those services, VPN service providers have PEs co-located with gateways of multiple data centers, which can be their own or 3rd party data centers. There are two cases of connectivity in VDCS service model: 1. Strictly connectivity: PE is provisioned (by its own operators) in the same fashion as today's L3VPN. When a group of hosts belonging to client X are added to Data Center Y, the PE adjacent to Y is configured properly so that Client X's VPN can exchange routes with Client X owned hosts in Y. 2. VPN attachment circuit configuration being triggered by data center gateway routers: When a group of hosts purchased by Client X are added to a Data Center Y, Y's gateway automatically triggers its adjacent PEs to add attachment circuits for the VPN which belongs to X, and then perform the Case #1 above for VPN- X's PEs to exchange routes with X's hosts in the data center Y. The Case #1 above will require a long and deep coordination between data center management systems and VPN management systems. The Data Center management systems have to pass out at least the following attributes associated with hosts belonging to Client X: - Which gateway routers from which Client X's hosts can be accessed - Which physical interfaces from which Client X's hosts can be accessed - Which logical interfaces, e.g. subnets, VLANs, or Data Center internal VPN ID, from which Client X's hosts can be accessed. Suppose those information can be provided by data center management systems, it is not a simple process for VPN management systems to map Client X's VPN ID with those network attributes from data center, figure out which PEs are actually connected with which Data Center Gateways and which ports on PEs are connected with DC gateway where Client X's hosts can be accessed. This process gets worse when a VPN client's hosts have to be placed in different data center locations for reasons like, regulatory, diverse locations for disaster recovery, etc. It is well known that network is only a small portion of the overall data center infrastructure. Most likely the data center networks are managed by a smaller separate team than their computing and storage services. Majority, if not all, Data Center's overall management Dunbar Expires April 24, 2012 [Page 5] Internet-Draft Problem statement for VPN4DC 2011-10-05 systems don't have proper mechanism to get and record the information on which network segments are assigned to which clients. Therefore, it can take extremely long process to configure the PE properly for Case #1 above to work. 5. APIs between VPN PEs and Data Center Gateways Different data centers can have different network designs. The network segments on which a VPN client's hosts reside in different data centers can be represented by very different ways. For example, some data centers use VID to differentiate different clients, some data centers could use different subnet addresses, while other data centers could use its internal VPN IDs. There are simply too many attributes from too many different places to be coordinated in order to configure VPN PEs manageably. There is no protocol between data center server management systems and network management systems, and there is no protocol for VPN management systems to retrieve the needed network attributes from data center management systems. In addition, data center management systems are part of computing industry which is different industry from networking. If Data Center gateway routers can inform their adjacent VPN PEs on network attributes associated with hosts of a VPN client, the steps to get PEs configured properly will be much shorter and simpler. Even though PEs' VPN attachment circuit may not be configured directly by adjacent DC Gateway routers for security reasons, the network attributes passed from DC can be used by VPN network management system to properly configure the VPN PEs after some level of authentication. Therefore, it is very beneficial to have some open APIs between VPN PEs and DC gateway to simplify the steps needed for VPN PE configurations. 5.1. What to be communicated between VPN PEs and Data Center Gateways? The APIs between VPN PEs and their directly connected data center gateway should at least include the request for a group of hosts in a data center to join (or leave) a specific client's VPN. If a DC Gateway and PE are directly connected via an Ethernet interface, the network segment for a group of hosts belonging to a VPN client in data center can be easily represented by a VLAN identifier. Dunbar Expires April 24, 2012 [Page 6] Internet-Draft Problem statement for VPN4DC 2011-10-05 If a data center gateway is connected with VPN PEs via OC-n interfaces, then the data center Gateway and VPN PEs have to reach agreement on how to differentiate traffic belonging to different VPN clients. If GRE encapsulation is used on the interfaces, the data center gateway and the VPN PE has to reach agreement on which outer IP address represents which VPN client. It is very common that Data Center network is not aware of provider VPN configuration, and vice versa. Provider VPN Management system has its own mapping between VPN client and its corresponding VPN identifier. Data Center Network management system also has its own mapping from client ID to a specific network segment, such as VLAN ID, ISID, or IP interface, etc. When Data Center Gateway sends a request to VPN PE for a network segment to be attached to a specific client's VPN, the information it has is the client identifier. Upon receiving the request, the PE has to authenticate the request with its own management system. Upon authenticating the request, the VPN management system has to map the client identifier, potentially a key, to the proper VPN identifier, and then configure the PE accordingly to get the VPN connected. As of now, there aren't any available solutions to enable this in- band communication between VPN and data center gateways. 6. Conclusion and Recommendation VPNs represent a major industry for service providers in the enterprise (revenues at billion dollar level). It is very important for VPN Service Providers to expand its VPN services with cloud Data Center services in a secure manner. Automation and end-to-end network integration is very important for VDCS. Therefore, we recommend IETF to investigate solutions to make it possible. 7. Manageability Considerations TBD 8. Security Considerations TBD. Dunbar Expires April 24, 2012 [Page 7] Internet-Draft Problem statement for VPN4DC 2011-10-05 9. IANA Considerations 10. Acknowledgments We want to acknowledge the following people for their valuable inputs to this draft: K.K.Ramakrishnan. This document was prepared using 2-Word-v2.0.template.dot. 11. References [VPN4DC-Req] So, et al, "Requirements of Layer 3 Virtual Private Network for Data Centers", draft-so-VPN4DC-00, Oct 2011. [VDCS] So, et al, "Requirement and Framework for VPN-Oriented Data Center Services", draft-so-vdcs-00, June 2011. Authors' Addresses Linda Dunbar Huawei Technologies 5340 Legacy Drive, Suite 175 Plano, TX 75024, USA Phone: (469) 277 5840 Email: ldunbar@huawei.com Ning So Verizon Inc. 2400 N. Glenville Ave., Richardson, TX75082 ning.so@verizonbusiness.com Intellectual Property Statement The IETF Trust takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in any IETF Document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Dunbar Expires April 24, 2012 [Page 8] Internet-Draft Problem statement for VPN4DC 2011-10-05 Copies of Intellectual Property disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement any standard or specification contained in an IETF Document. Please address the information to the IETF at ietf-ipr@ietf.org. Disclaimer of Validity All IETF Documents and the information contained therein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION THEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Dunbar Expires April 24, 2012 [Page 9]