RE: VPN4DC Scope

[Lucy yong <[e-mail]>]

Hi Pedro,

See inline.

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

Lucy,

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

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

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. 

>   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.
[[LY]] How does a customer ensure the virtual resource in Provider DC it buys to attach the L3VPN it uses?

>  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.
[[LY]] VPN4DC and VDCS draft express the need clear.

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

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