idnits 2.17.1 draft-dunbar-vpn4dc-problem-statement-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Sep 2009 rather than the newer Notice from 28 Dec 2009. (See https://trustee.ietf.org/license-info/) Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (October 24, 2011) is 4566 days in the past. Is this intentional? Checking references for intended status: None ---------------------------------------------------------------------------- == Unused Reference: 'VPN4DC-Req' is defined on line 340, but no explicit reference was found in the text -- No information found for draft-so-VPN4DC - is the name correct? == Outdated reference: A later version (-02) exists of draft-so-vdcs-00 Summary: 2 errors (**), 0 flaws (~~), 4 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 VPN4DC L. Dunbar 2 Internet Draft Huawei 3 Intended status: Information Track N. So 4 Expires: April 2012 Verizon 5 October 24, 2011 7 VPN4DC Problem Statement 8 draft-dunbar-vpn4dc-problem-statement-00.txt 10 Status of this Memo 12 This Internet-Draft is submitted to IETF in full conformance with the 13 provisions of BCP 78 and BCP 79. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that 17 other groups may also distribute working documents as Internet- 18 Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet-Drafts as reference 23 material or to cite them other than as "work in progress." 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html 31 This Internet-Draft will expire on April 24, 2011. 33 Copyright Notice 35 Copyright (c) 2011 IETF Trust and the persons identified as the 36 document authors. All rights reserved. 38 This document is subject to BCP 78 and the IETF Trust's Legal 39 Provisions Relating to IETF Documents 40 (http://trustee.ietf.org/license-info) in effect on the date of 41 publication of this document. Please review these documents 42 carefully, as they describe your rights and restrictions with respect 43 to this document. Code Components extracted from this document must 44 include Simplified BSD License text as described in Section 4.e of 45 the Trust Legal Provisions and are provided without warranty as 46 described in the BSD License. 48 Internet-Draft Problem statement for VPN4DC 2011-10-05 50 Abstract 52 VPN4DC is for extending an existing VPN to connect hosts in public 53 data center(s) which are purchased or leased by VPN client. This 54 draft describes the issues and problems associated with this kind of 55 services. 57 Conventions used in this document 59 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 60 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 61 document are to be interpreted as described in RFC-2119 0. 63 Table of Contents 65 1. Introduction ................................................ 2 66 2. Terminology ................................................. 3 67 3. Connecting hosts in public Data Centers with a VPN .......... 4 68 4. Hosts connectivity for VPN Oriented Data Center Service...... 4 69 5. APIs between VPN PEs and Data Center Gateways ............... 6 70 5.1. What to be communicated between VPN PEs and Data Center 71 Gateways? ................................................... 6 72 6. Conclusion and Recommendation................................ 7 73 7. Manageability Considerations................................. 7 74 8. Security Considerations...................................... 7 75 9. IANA Considerations ......................................... 8 76 10. Acknowledgments ............................................ 8 77 11. References ................................................. 8 78 Authors' Addresses ............................................. 8 79 Intellectual Property Statement................................. 8 80 Disclaimer of Validity ......................................... 9 82 1. Introduction 84 VPN4DC lets VPN clients to connect to their leased or purchased 85 computing resources in public data centers via their own VPNs. In 86 another words, VPN4DC is elastic which allows a VPN to extend its 87 connectivity to (or shrink its connectivity from) resources in one or 88 multiple public data centers. 90 This kind of service is attractive to VPN customers who often do not 91 want to use public Internet to access purchased or leased resources 92 in public data centers. 94 Internet-Draft Problem statement for VPN4DC 2011-10-05 96 For ease of description, this problem statement focuses on making 97 today's L3VPN to seamlessly extend to client's hosts in public data 98 centers. 100 2. Terminology 102 Aggregation Switch: A Layer 2 switch interconnecting ToR switches 104 Bridge: IEEE802.1Q compliant device. In this draft, Bridge is used 105 interchangeably with Layer 2 switch. 107 DC: Data Center 109 DA: Destination Address 111 EOR: End of Row switches in data center. 113 FDB: Filtering Database for Bridge or Layer 2 switch 115 Public data center: internet data center which offers hosting or 116 computing resources to many different clients 118 SA: Source Address 120 ToR: Top of Rack Switch. It is also known as access switch 122 VDCS: VPN oriented data center services 124 VM: Virtual Machines 126 VPN: Virtual Private Network 128 VPN-o-CS: VPN oriented Computing Service 130 VPN4DC: Elastic VPN which can extend its VPN connectivity to, or 131 shrink some of its connectivity's from, computing resources 132 in public data centers 134 Internet-Draft Problem statement for VPN4DC 2011-10-05 136 3. Connecting hosts in public Data Centers with a VPN 138 Hosts in data centers are managed by data center operators which are 139 assisted by their own resource and network management systems. VPNs 140 are managed by network service providers, which are most likely 141 different organizations. If enterprises want to offload their 142 applications to public data centers and connect those 143 purchased/leased resources with their own intranet via VPN, the 144 enterprises have to do following steps separately: 146 1. Contact data center operators to purchase computing resources 148 2. Get network configuration from the data center operators on how 149 and where their purchased hosts are placed 151 3. Ask their VPN operators to add attachment circuits on the PEs 152 which are adjacent to the data centers in which their hosts 153 reside. 155 One big issue associated with this process is that the client VPN's 156 network provider may not have PEs in close proximity to the data 157 centers from which clients' remote hosts are purchased or leased. It 158 can be very difficult to connect hosts in 3rd party data centers to a 159 provider VPN. Under this scenario, the only option is to use tunnels, 160 e.g. IPSec, between 3rd party data centers and VPN provider PEs. This 161 approach will definitely turn away some enterprises that have paid 162 premium for their VPNs. 164 When VPN service providers do have PEs co-located, or via secure 165 links connected, with the 3rd party data centers from which clients' 166 remote hosts are purchased, proper configuration on the PEs can be 167 very challenging. The VPN operator has to know how their PEs are 168 connected to the 3rd party data center gateway routers, what 169 protocols are supported on the connections, which network segments 170 have the hosts belonging to a particular VPN client, etc.. To get all 171 those information accurately, a lot of coordination is needed among 172 VPN clients, VPN service providers, and 3rd party data center 173 operators. This process can be very long and error prone. 175 4. Hosts connectivity for VPN Oriented Data Center Service 177 The VPN oriented data center service [VDCS] describes a service model 178 where VPN clients can assume the computing resources purchased from 179 VPN service providers are already linked with their corresponding 180 VPNs. 182 Internet-Draft Problem statement for VPN4DC 2011-10-05 184 To enable those services, VPN service providers have PEs co-located 185 with gateways of multiple data centers, which can be their own or 3rd 186 party data centers. 188 There are two cases of connectivity in VDCS service model: 190 1. Strictly connectivity: PE is provisioned (by its own operators) 191 in the same fashion as today's L3VPN. When a group of hosts 192 belonging to client X are added to Data Center Y, the PE 193 adjacent to Y is configured properly so that Client X's VPN can 194 exchange routes with Client X owned hosts in Y. 196 2. VPN attachment circuit configuration being triggered by data 197 center gateway routers: When a group of hosts purchased by 198 Client X are added to a Data Center Y, Y's gateway automatically 199 triggers its adjacent PEs to add attachment circuits for the VPN 200 which belongs to X, and then perform the Case #1 above for VPN- 201 X's PEs to exchange routes with X's hosts in the data center Y. 203 The Case #1 above will require a long and deep coordination between 204 data center management systems and VPN management systems. The Data 205 Center management systems have to pass out at least the following 206 attributes associated with hosts belonging to Client X: 208 - Which gateway routers from which Client X's hosts can be 209 accessed 211 - Which physical interfaces from which Client X's hosts can be 212 accessed 214 - Which logical interfaces, e.g. subnets, VLANs, or Data Center 215 internal VPN ID, from which Client X's hosts can be accessed. 217 Suppose those information can be provided by data center management 218 systems, it is not a simple process for VPN management systems to map 219 Client X's VPN ID with those network attributes from data center, 220 figure out which PEs are actually connected with which Data Center 221 Gateways and which ports on PEs are connected with DC gateway where 222 Client X's hosts can be accessed. This process gets worse when a VPN 223 client's hosts have to be placed in different data center locations 224 for reasons like, regulatory, diverse locations for disaster 225 recovery, etc. 227 It is well known that network is only a small portion of the overall 228 data center infrastructure. Most likely the data center networks are 229 managed by a smaller separate team than their computing and storage 230 services. Majority, if not all, Data Center's overall management 232 Internet-Draft Problem statement for VPN4DC 2011-10-05 234 systems don't have proper mechanism to get and record the information 235 on which network segments are assigned to which clients. Therefore, 236 it can take extremely long process to configure the PE properly for 237 Case #1 above to work. 239 5. APIs between VPN PEs and Data Center Gateways 241 Different data centers can have different network designs. The 242 network segments on which a VPN client's hosts reside in different 243 data centers can be represented by very different ways. For example, 244 some data centers use VID to differentiate different clients, some 245 data centers could use different subnet addresses, while other data 246 centers could use its internal VPN IDs. 248 There are simply too many attributes from too many different places 249 to be coordinated in order to configure VPN PEs manageably. There is 250 no protocol between data center server management systems and network 251 management systems, and there is no protocol for VPN management 252 systems to retrieve the needed network attributes from data center 253 management systems. In addition, data center management systems are 254 part of computing industry which is different industry from 255 networking. 257 If Data Center gateway routers can inform their adjacent VPN PEs on 258 network attributes associated with hosts of a VPN client, the steps 259 to get PEs configured properly will be much shorter and simpler. Even 260 though PEs' VPN attachment circuit may not be configured directly by 261 adjacent DC Gateway routers for security reasons, the network 262 attributes passed from DC can be used by VPN network management 263 system to properly configure the VPN PEs after some level of 264 authentication. 266 Therefore, it is very beneficial to have some open APIs between VPN 267 PEs and DC gateway to simplify the steps needed for VPN PE 268 configurations. 270 5.1. What to be communicated between VPN PEs and Data Center Gateways? 272 The APIs between VPN PEs and their directly connected data center 273 gateway should at least include the request for a group of hosts in a 274 data center to join (or leave) a specific client's VPN. 276 If a DC Gateway and PE are directly connected via an Ethernet 277 interface, the network segment for a group of hosts belonging to a 278 VPN client in data center can be easily represented by a VLAN 279 identifier. 281 Internet-Draft Problem statement for VPN4DC 2011-10-05 283 If a data center gateway is connected with VPN PEs via OC-n 284 interfaces, then the data center Gateway and VPN PEs have to reach 285 agreement on how to differentiate traffic belonging to different VPN 286 clients. If GRE encapsulation is used on the interfaces, the data 287 center gateway and the VPN PE has to reach agreement on which outer 288 IP address represents which VPN client. 290 It is very common that Data Center network is not aware of provider 291 VPN configuration, and vice versa. Provider VPN Management system has 292 its own mapping between VPN client and its corresponding VPN 293 identifier. Data Center Network management system also has its own 294 mapping from client ID to a specific network segment, such as VLAN 295 ID, ISID, or IP interface, etc. 297 When Data Center Gateway sends a request to VPN PE for a network 298 segment to be attached to a specific client's VPN, the information it 299 has is the client identifier. Upon receiving the request, the PE has 300 to authenticate the request with its own management system. Upon 301 authenticating the request, the VPN management system has to map the 302 client identifier, potentially a key, to the proper VPN identifier, 303 and then configure the PE accordingly to get the VPN connected. 305 As of now, there aren't any available solutions to enable this in- 306 band communication between VPN and data center gateways. 308 6. Conclusion and Recommendation 310 VPNs represent a major industry for service providers in the 311 enterprise (revenues at billion dollar level). It is very important 312 for VPN Service Providers to expand its VPN services with cloud Data 313 Center services in a secure manner. Automation and end-to-end 314 network integration is very important for VDCS. 316 Therefore, we recommend IETF to investigate solutions to make it 317 possible. 319 7. Manageability Considerations 321 TBD 323 8. Security Considerations 325 TBD. 327 Internet-Draft Problem statement for VPN4DC 2011-10-05 329 9. IANA Considerations 331 10. Acknowledgments 333 We want to acknowledge the following people for their valuable inputs 334 to this draft: K.K.Ramakrishnan. 336 This document was prepared using 2-Word-v2.0.template.dot. 338 11. References 340 [VPN4DC-Req] So, et al, "Requirements of Layer 3 Virtual Private 341 Network for Data Centers", draft-so-VPN4DC-00, Oct 2011. 343 [VDCS] So, et al, "Requirement and Framework for VPN-Oriented Data 344 Center Services", draft-so-vdcs-00, June 2011. 346 Authors' Addresses 348 Linda Dunbar 349 Huawei Technologies 350 5340 Legacy Drive, Suite 175 351 Plano, TX 75024, USA 352 Phone: (469) 277 5840 353 Email: ldunbar@huawei.com 355 Ning So 356 Verizon Inc. 357 2400 N. Glenville Ave., 358 Richardson, TX75082 359 ning.so@verizonbusiness.com 361 Intellectual Property Statement 363 The IETF Trust takes no position regarding the validity or scope of 364 any Intellectual Property Rights or other rights that might be 365 claimed to pertain to the implementation or use of the technology 366 described in any IETF Document or the extent to which any license 367 under such rights might or might not be available; nor does it 368 represent that it has made any independent effort to identify any 369 such rights. 371 Internet-Draft Problem statement for VPN4DC 2011-10-05 373 Copies of Intellectual Property disclosures made to the IETF 374 Secretariat and any assurances of licenses to be made available, or 375 the result of an attempt made to obtain a general license or 376 permission for the use of such proprietary rights by implementers or 377 users of this specification can be obtained from the IETF on-line IPR 378 repository at http://www.ietf.org/ipr 380 The IETF invites any interested party to bring to its attention any 381 copyrights, patents or patent applications, or other proprietary 382 rights that may cover technology that may be required to implement 383 any standard or specification contained in an IETF Document. Please 384 address the information to the IETF at ietf-ipr@ietf.org. 386 Disclaimer of Validity 388 All IETF Documents and the information contained therein are provided 389 on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 390 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE 391 IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL 392 WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY 393 WARRANTY THAT THE USE OF THE INFORMATION THEREIN WILL NOT INFRINGE 394 ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS 395 FOR A PARTICULAR PURPOSE. 397 Acknowledgment 399 Funding for the RFC Editor function is currently provided by the 400 Internet Society.