Subject: Re: VPN4DC Scope

From: Derick Winkworth <[email-masked]>
Date: Mon, 7 Nov 2011 19:09:49 -0800 (PST)

See comments in-line

________________________________
From: "[email-masked]" <[email-masked]>
To: [email-masked]; "[email-masked]" <[email-masked]>
Sent: Monday, November 7, 2011 8:39 PM
Subject: Re: VPN4DC Scope

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.

-----------
Ok, understood.  I think it has been asked of the VPN4DC contributors to narrow the scope and be specific.  At this stage MPLS/L3VPN integration within a provider DC has been chosen as the scope, thus the L3VPN mailing list has been chosen for this discussion.  Personally, I think there will be multiple ways of connecting VMs to different kinds of networks.  I think multiple tools will be necessary.
-----------

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

I'm not sure what you mean by "many more."  If you are indicating that the current scope of VPN4DC is too narrow and only addresses a minority of cases, I would disagree. 

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

> 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
>
>

---

From: Robert Raszuk <[email-masked]>
Date: Tue, 08 Nov 2011 15:13:34 +0100

Hi Derick,

> --------- 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.
> ---------
>
> I'm not sure what you mean by "many more."  If you are indicating
> that the current scope of VPN4DC is too narrow and only addresses a
> minority of cases, I would disagree.

I think we do not need to argue if this is minority or majority which 
extending L3VPN to the host would address.

However to do that you really do not need any new protocol extension. As 
you very well know you can install a software router (either public 
domain or from commercial vendors) in your DC host or TOR and treat it 
as fully functional PE.

No changes to host OS/kernel needed. You configure VRFs of such software 
router and simply bridge to VMs virtual interfaces directly or via 
VLANs. Zero touch to VMs and your customers see their VMs as part of 
L3VPN service you are offering.

So I really do not think we need to duplicate solutions to solve the 
already solved problem.

I would rather see L3VPN or new group focusing more on problems which 
still need to be solved.

And either online or offline I would be glad to hear why the above 
proposal would not address today your needs to extend L3VPN service to 
the data center you own and want to offer to your L3VPN customers.

Best regards,
R.