Re: [nvo3] Comments on draft-kompella-nvo3-server2nve

I also have a similar fundamental issue with this document.  The document seems to be dictating provisioning process for a VM. What service/cloud computing providers need are the building blocks, i.e. standard APIs and protocols to create and manage virtual networks in cloud computing environment. Most of those APIs already exist (e.g., OpenStack REST API, IF-MAP API, etc.). How to put the solution blocks together will be individually decided by the providers. There already exist OpenStack Tenant/Project and Quantum Project that allow creation and management of Virtual Networks. There are many available Quantum plugins. Actually, such models are proven to scale and have been already used by many large cloud computing providers. As Robert said, let's not "reinvent the wheel".

Besides this fundamental issue (which, in fact, makes any other comments less relevant) I would like to point out the following:

Section 1.
   "This document focuses on the case where the network elements in Step
   4 are not co-resident with the server, and shows how the provisioning
   in Step 4 can be replaced by signaling between server and network,"

Allowing network elements to signal provisioning information directly to each other is not a secure approach, especially if one of those elements is carrying guest workloads. It is especially insecure if the signaling protocol used cannot be authenticated. It is much more secure to delegate such coordination to a management system. Hence, devoting entire draft to this single, narrow issue, which for majority, especially large Service or Cloud Providers would be irrelevant, seems to miss the mark.
It is much more relevant to address the case where NVE is in the end-system and to address the signaling used between the end-system and its controller.

Section 2.3
   "There are several options for protocols to use to signal the above
   messages.  One could invent a new protocol for this purpose.  One
   could reuse existing protocols, among them LLDP, XMPP, HTTP REST, and
   VDP [VDP], a new protocol standardized for the purposes of signaling
   a VM's network parameters from server to lNVE"

I don't think that these protocols should be listed as "equal". There are major differences between them from security, extensibility, and applicability point of view.

Section 3
    "DCVPNs may be realized using BGP-based VPNs, for example, BGP/MPLS
     "VPNs ([RFC4364]),"

This approach is addressed in draft-fang-vpn4dc-problem-statement-01.

> -----Original Message-----
> From: nvo3-bounces@ietf.org [mailto:nvo3-bounces@ietf.org] On Behalf Of
> Robert Raszuk
> Sent: Friday, July 13, 2012 4:48 PM
> To: nvo3@ietf.org
> Subject: Re: [nvo3] Comments on draft-kompella-nvo3-server2nve
> 
> All,
> 
> Since we are starting to discuss this document I have one fundamental
> comment/question.
> 
> The part of it's abstract says:
> 
>     This document proposes a "single-touch" approach for provisioning
> the
>     networking parameters related to Virtual Machine creation,
> migration
>     and termination on servers.
> 
> I would like to observe that in the tenant data center VMs are only a
> small part of the tenant network.
> 
> Single-touch is of course great idea and that is why extension to one
> of
> the common and very popular data center orchestration environments
> (openstack) developed a module called Quantum.
> 
> This module is exactly targeting to not only provision networking
> parameters to VMs but also to other network appliances including
> virtual
> routers, firewalls, loadbalancers etc .. which are part of the tenant
> DC
> network.
> 
> Ref: http://wiki.openstack.org/Quantum
> 
> So I would like to ask the authors of the draft-kompella-nvo3-
> server2nve
> why there is the an attempt to reinvent the wheel and how far they are
> going to maintain the vision of "single-touch" considering that much
> broader aspect of this has been already solved ?
> 
> Best regards,
> R.
> 
> PS. I am perfectly fine to hear that NVO3 does not want to adopt any
> work which is done outside of IETF. However I think that such message
> needs to be clearly weighted against current deployments as well as
> existing market adoption of such solutions.
> 
> 
> _______________________________________________
> nvo3 mailing list
> nvo3@ietf.org
> https://www.ietf.org/mailman/listinfo/nvo3