Re: VPN4DC Scope

[Derick Winkworth <[e-mail]>]

Lucy:

----------
In VDCS, some DCs are owned by customer and some by DC provider DC. It is not practical to require customer private datacenter to implement L2/L3VPN for getting a VDCS service.

-----------

The customer is not required to manage their own MPLS network (i.e., label-switching 'P' nodes and 'PE' nodes).  However, in the scenario we are proposing the customer would be using an L3VPN service provided by an SP such as Verizon or twTelecom (i.e., the customer has CE devices in their locations connecting to service-provider's PE devices over a circuit). 

Derick



 



________________________________
From: Lucy yong <[e-mail]>
To: Derick Winkworth <[e-mail]>; Luyuan Fang (lufang) <[e-mail]>; "[e-mail]" <[e-mail]>
Sent: Monday, November 7, 2011 10:04 AM
Subject: RE: VPN4DC Scope


 
Derick and Luyuan,
 
The newer draft has one requirement for extending VPNs into datacenter networks with L2/L3VPN, and a large portion of requirements for using VPN gateway for VPN extension into datacenter. We should include VPN gateway case in the scope too. 
 
In VDCS, some DCs are owned by customer and some by DC provider DC. It is not practical to require customer private datacenter to implement L2/L3VPN for getting a VDCS service. 
 
Thanks,
Lucy
 
From:Derick Winkworth [mailto:[e-mail]] 
Sent: Sunday, November 06, 2011 6:19 PM
To: Lucy yong; Luyuan Fang (lufang); [e-mail]
Subject: Re: VPN4DC Scope
 
Lucy:
 
That draft is older, try:  http://tools.ietf.org/html/draft-so-vdcs-02
 
Derick
 

________________________________
 
From:Lucy yong <[e-mail]>
To: Luyuan Fang (lufang) <[e-mail]>; "[e-mail]" <[e-mail]>
Sent: Sunday, November 6, 2011 12:45 PM
Subject: RE: VPN4DC Scope
Luyuan,
 
I don’t think this matches VPN4DC objective and requirements.  (draft-so-vpn4dc) 
 
The draft objective is to enhance network service provider L3VPN services  for Enterprise DCs and Provider DC interconnection.   Enterprise can use virtual resources in Provider DC as if the resources are in its own datacenter and run Enterprise intranet applications.  It does not constraint any architecture in Enterprise DC and Provider DC. The in-band signaling capability for host joining a L3VPN in a service provider network does not mean the DC that host resides need to implement L3VPN.
 
The proposals you put here aims on extending L3VPN technologies into DC or DC VM virtual networks. Will this be network service providers’ requirement or DC providers’ requirement? I don’t see such requirement anywhere.
 
Today, Enterprise DC rarely implement L3VPN as well as DC provider. For getting some virtual resources in Provider DC, why does Enterprise need to change their DC architecture? Do I miss something?
 
I agree that DC VPN or DC VM virtual network are potential subject to work on, but this is not what VPN4DC target for. Are we changing the direction?
 
Regards,
Lucy
 
From:[e-mail] [mailto:[e-mail]] On Behalf Of Luyuan Fang (lufang)
Sent: Saturday, November 05, 2011 1:25 AM
To: [e-mail]
Subject: VPN4DC Scope
 
Dear colleagues,
 
Thank you all for the constructive discussion/suggestions over the last few weeks on VPN4DC. 
 
I think we observed good interests/enthusiasm on solving the problems in this space. 
 
We need to narrow down the scope as the next step.
I summarized the proposals sent on the list as the following:  
 
1.      Leverage BGP/MPLS VPN technologies, extending it with l3vpn signaling protocols into DC VM virtual networks.
2.      Using BGP/MPLS VPN exactly ‘as it is’ into DC VM virtual networks
3.      Extending/creating any IP VPN technologies into DC 
4.      Extending/creating or reuse/managing security protocols for DC connections, including encryption, key distribution, key management
5.      Extending/creating or reuse L2VPN based technologies into DC 
 
Some of you prefer to focus on one of the options, while others like to include multiple options.
 
Here is my observation and thought.
 
1 – It seems a common denominator. Did not hear no on this.  It is exactly the problem Derick wanting to solve, it is Ning’s starting point, and it is included in the requirements drafts.
2 – It does not need to create or extend protocols, should go to Operation and Management Area for any ops issues and best practice.
3 - The scope looks big to me, the list is potentially very long.
4 - If new encryption algorithm, better key distribution mechanism are needed,  the work should go to Security Area; if nothing new, ops issues go to Operation and Management Area.
5 - L2VPN for DC work should go to L2VPN WG, it is defined in L2VPN charter.
 
Thanks,
Luyuan