Subject: VPN4DC Scope

From: "Luyuan Fang (lufang)" <[email-masked]>
Date: Sat, 5 Nov 2011 01:25:28 -0500

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: Lucy yong <[email-masked]>
Date: Sun, 06 Nov 2011 18:45:14 +0000

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.

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

Some of you prefer to focus on one of the options, while others like to include multiple options.

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: Derick Winkworth <[email-masked]>
Date: Sun, 6 Nov 2011 16:19:10 -0800 (PST)

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

 
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,

 
 
2.      Using BGP/MPLS VPN exactly ‘as it is’ into DC VM virtual networks

 
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: Yudelei <[email-masked]>
Date: Mon, 07 Nov 2011 10:00:03 +0000

Dear Luyuan,
Is it proved a mature technology for DC VM virtual network to support L3 routing and L3VPN? But L3VPN can be supported well on a general router device. When talking about VPN4DC, I think it’s better to assume L3VPNs are processed at router device in DC, e.g. DC gateway router.

Thanks
Delei

[email-masked] [mailto:[email-masked]] Luyuan Fang (lufang)
2011年11月5日 14:25
[email-masked]
VPN4DC Scope

Dear colleagues,

Thanks,
Luyuan

---

From: Lucy yong <[email-masked]>
Date: Mon, 07 Nov 2011 16:04:13 +0000

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:

Derick

Regards,
Lucy

Dear colleagues,

Thanks,
Luyuan

---

From: Pedro Marques <[email-masked]>
Date: Mon, 7 Nov 2011 09:24:13 -0800

Lucy,

On Sun, Nov 6, 2011 at 10:45 AM, Lucy yong <[email-masked]> wrote:

> The draft objective is to enhance network service provider L3VPN services
>  for Enterprise DCs and Provider DC interconnection.

Does "Enhancing L3VPN services" describe a business model concept or a
specific technical problem ?

>   Enterprise can use
> virtual resources in Provider DC as if the resources are in its own
> datacenter and run Enterprise intranet applications.

Business model aside, that sounds perfectly doable with today's set of
standards.

>  It does not constraint
> any architecture in Enterprise DC and Provider DC.

Section 5 of the document you referred to as a set of requirements
that seem to imply an architecture for the DC connectivity although
i'm not able to understand the context where they fit.

For example:
      o  Once the hypervisor or Top Of Rack switch is configured to
      connect the host to a DC gateway, the hosts in DC SHALL be
      able to signal to DC gateway switch/router (L3VPN CE) to
      join a specific VPN.  The join request CAN include the
      basic service requirements such as bandwidth and QoS.

In this context it is unclear to me what the "host" is or the set of
assumptions that lead the author to specify that the hosts SHALL be
able to signal the gateway.

If one does assume, for instance, that the VPN network associated with
a given DC tenant is implemented as an isolated VLAN, which is a
common assumption made by lots of solutions, why would there be the
need to "signal" a "join" request ? What does that mean in that
context ?

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

I don't understand the assumption that there is any need for in-band
signaling. Please explain why do you believe there is such a need. It
is also unclear what is being signaled.

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

You do seem to see a requirement for "signaling". That probably means
that you have some assumption of how the DC network provides network
virtualization for a given tenant. It would be interesting if you
could share that assumption and at least compare it with the minimum
common denominator which seems to be the assumption of a VLAN per
tenant.

regards,
  Pedro.

---

From: Lucy yong <[email-masked]>
Date: Mon, 07 Nov 2011 17:57:23 +0000

Hi Pedro,

See inline.

-----Original Message-----
From: Pedro Marques [mailto:[email-masked]] 
Sent: Monday, November 07, 2011 11:24 AM
To: Lucy yong
Cc: Luyuan Fang (lufang); [email-masked]
Subject: Re: VPN4DC Scope

Lucy,

Does "Enhancing L3VPN services" describe a business model concept or a
specific technical problem ?
[[LY]] It is both. There is a business model that can't be supported with today's technology. 

Business model aside, that sounds perfectly doable with today's set of
standards.
[[LY]] How does a customer ensure the virtual resource in Provider DC it buys to attach the L3VPN it uses?

For example:

I don't understand the assumption that there is any need for in-band
signaling. Please explain why do you believe there is such a need. It
is also unclear what is being signaled.
[[LY]] VPN4DC and VDCS draft express the need clear.

> Will this be network service providers' requirement
> or DC providers' requirement? I don't see such requirement anywhere.

[[LY]] what I mean is DC virtualization is not VPN4DC goal. But I agree that DC host/network virtualization has some technical problems today. IEEE is working on it and your draft also proposes one solution.

Regards,
Lucy

regards,
  Pedro.

---

From: Pedro Marques <[email-masked]>
Date: Mon, 7 Nov 2011 11:10:22 -0800

Lucy,

> [[LY]] How does a customer ensure the virtual resource in Provider DC it buys to attach the L3VPN it uses?

I'll assume that you question is "how does an enterprise VPN
interconnect with the corresponding data-center VPN for that tennant",
assuming the customer uses an l3vpn. This is no different from VPN
interconnection between multiple service providers. Both inter-as
option A and option B would work to establish the interconnect.

> [[LY]] VPN4DC and VDCS draft express the need clear.

It is not clear to me. Can you please elaborate ? For instance assume
that the DC uses a VLAN per tenant and uses option B interconnect to a
carrier. That would be a reasonable starting point, i believe.

> [[LY]] what I mean is DC virtualization is not VPN4DC goal. But I agree that DC host/network virtualization has some technical problems today. IEEE is working on it and your draft also proposes one…

As far as i can see you do assume some solution to the DC network
virtualization problem that is neither IEEE based or what is described
in the l3vpn-end-system draft since you have identified the need from
signaling from the "host". That need is not present in either of these
approaches.

  Pedro.

---

From: Robert Raszuk <[email-masked]>
Date: Tue, 08 Nov 2011 01:04:07 +0100

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.

---

From: Derick Winkworth <[email-masked]>
Date: Mon, 7 Nov 2011 18:12:21 -0800 (PST)

Lucy:

----------

-----------

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 <[email-masked]>
To: Derick Winkworth <[email-masked]>; Luyuan Fang (lufang) <[email-masked]>; "[email-masked]" <[email-masked]>
Sent: Monday, November 7, 2011 10:04 AM
Subject: RE: VPN4DC Scope

Derick and Luyuan,

 
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:

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,

 

 
Regards,
Lucy

Dear colleagues,

 

 

Thanks,
Luyuan

---

From: Derick Winkworth <[email-masked]>
Date: Mon, 7 Nov 2011 18:25:14 -0800 (PST)

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,

http://vcider.com/

Many thx,
R.