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: [email protected] [mailto:[email protected]] On Behalf Of
> Robert Raszuk
> Sent: Friday, July 13, 2012 4:48 PM
> To: [email protected]
> 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
> [email protected]
> https://www.ietf.org/mailman/listinfo/nvo3
_______________________________________________
nvo3 mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/nvo3
