Subject: RE: RE: VPN4DC Scope

From: "So, Ning" <[email-masked]>
Date: Mon, 7 Nov 2011 15:18:25 -0500

Lucy,

Thanks for your input.  Luyuan summarized pretty well the discussions we have had in the past week.  I combined the 1st two items she listed and generalized the goal of VPN4DC effort as follows:  leverage BGP/MPLS VPN technologies and L3VPN signaling protocols, extending and/or interworking them with DC virtual networks so that the hosts in DC can automatically join the L3VPN to form any-host-to-any-host connections through L3VPN.

That goal is the foundation for all the other discussions around this topic, and there seems to be common agreement to it.  Please let me know your thoughts.  
 
Best regards,
 
Ning So
Verizon Corporate Technology
(office) 972-729-7905
(Cell) 972-955-0914

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:[email-masked]]
Sent: Sunday, November 06, 2011 6:19 PM
To: Lucy yong; Luyuan Fang (lufang); [email-masked]
Subject: Re: VPN4DC Scope

Lucy:

That draft is older, try:  http://tools.ietf.org/html/draft-so-vdcs-02

Derick

________________________________
From: Lucy yong <[email-masked]>
To: Luyuan Fang (lufang) <[email-masked]>; "[email-masked]" <[email-masked]>
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: [email-masked] [mailto:[email-masked]] On Behalf Of Luyuan Fang (lufang)
Sent: Saturday, November 05, 2011 1:25 AM
To: [email-masked]
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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.ietf.org/mail-archive/web/l3vpn/attachments/20111107/4050a702/attachment.htm>

------------------------------

_______________________________________________
L3VPN mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/l3vpn

End of L3VPN Digest, Vol 89, Issue 25
*************************************

---

From: "[email-masked]" <[email-masked]>
Date: Tue, 08 Nov 2011 11:42:56 +0900

s/like uparcie/like ipsec/

Sorry android's fault ;(

R.

----- Reply message -----
From: "[email-masked]" <[email-masked]>
To: <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: VPN4DC Scope
Date: Tue, Nov 8, 2011 11:39 am

Hi,

Just to clarify one nit here. I am not saying to use vcider as is nor I am saying that attaching a group of VM to your L3 VPN is a bad thing.

However what I am pointing out that scope of the VPN4DC should not stop on just extending 2547. Rather then that standardizing vcider like approach with supplements like uparcie or routing will serve to much broader customer space.

So while extending l3vpn to the host is a neat idea and lets push it forward in the same time let's not halt equally simple solutions which can address the problem for many more real cases.

Rgds,
R.----- Reply message -----
From: "Derick Winkworth" <[email-masked]>
To: "[email-masked]" <[email-masked]>
Subject: VPN4DC Scope
Date: Tue, Nov 8, 2011 11:25 am

Rob:

vCider does not provide for the secure interconnection of sites.  It is software that is installed on the VMs themselves which allows them to talk to each other as if they were on the same VLAN on a switch regardless of where the VMs exists.  Typically these are public-cloud provisioned VMs that are exposed to the internet.

In the context of VPN4DC, the customer could very well be running vCider on the VMs in the Provider's DC but neither the provider nor the customer should require software like this for attachment of the VM to the customer's L3VPN (which this particular software would not do, BTW).  The goal, again, is not secure host-to-host connectivity (we really shouldn't say that).  I don't care what the VM is talking to per se.  The VMs' vNIC should be bound by path isolation to the VRF on the provider's PE in the provider's Data Center.  The customer only needs to put an IP on the VM as far as the SP is concerned.  Whatever the customer does on top of that (IPSec or vCider) is up to the customer.

Derick

________________________________
From: Robert Raszuk <[email-masked]>
To: Luyuan Fang (lufang) <[email-masked]>
Cc: [email-masked]
Sent: Monday, November 7, 2011 6:04 PM
Subject: Re: VPN4DC Scope

Hi Luyuan,

As we are getting down to the scope debate I think it would be quite 
productive to discuss one solution apparently already available for 
arbitrary secured interconnection of host or sites.

http://vcider.com/

In particular I think it would be quite interesting to know what is 
missing from the above solution or this class of solutions in general 
for the problem space we are discussing here.

It seems to me that this class of solutions is sufficiently flexible to 
address number of VPN4DC and beyond needs without any prerequisites reg 
topology or connectivity requirements.

Many thx,
R.

> I think we observed good interests/enthusiasm on solving the problems in
> this space..
>
>
>
> 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
>
> 4.      Extending/creating or reuse/managing security protocols for DC
> connections, including encryption, key distribution, key management
>
> 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.
>
> 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.
>