Hi, I noticed this post, and wanted to give some general feedback.
First, I'm not sure I understand this as a standards-track document; it seems more Informational at best. Second, while the systems cited all focus on hypervisor and/or vxlan configuration, we had a long project here at ISI that basically accomplished most of the goals set out in this document at the IP layer. It might be useful to take a look there; we had a discovery protocol configuration managers, fault tolerance, etc. - and running code in 2000. That might provide an example of the kind of system you're trying to indicate here. The website is www.isi.edu/x-bone Joe On 3/20/2015 1:12 AM, [email protected] wrote: > Dear ALL, > > About the automatic VN services provisioning requirements, we’ve > submitted a draft draft-gu-nvo3-auto-provisioning-reqs-00(and -01 with > minor modification) to NVO3 website. We've received e-mail and oral > responses from some experts. Their initial impression are the goal maybe > somehow too ambitious, because of the broad domain of NVO3 VN service > automation, including VM automatic creation and interaction with > Virtualization orchestration system etc., but, they agree the > requirements are good for the VN service providing. > > Generally speaking, automatic service providing may be good for every > service if it’s possible, because of: 1), quick service provision to > customer and/or shorten the time to market; 2), less manual > configuration and lower operation cost; 3), eliminate the possibility > of manual configuration errors, and so on. > > So, we initiate this discussion, hope, in a narrower but still practical > and useful scope to implement NVO3 automatic VN services provisioning. > > First, we need to clarify what VN is and what kind of VN shall be > supported in NVO3, then we will show the VN can be implemented by two > different mechanism, in the scope of NVO3. > > For what kinds of VN shall be supported, we can obtain the related > information from the draft-ietf-nvo3-use-case-05, it includes many kinds > of VN, we summary them as following: > > 1), Virtual Network in DC (Section 2); > > 2), Virtual Network accessed by enterprise network through secure > Gateway (Section 3.1); > > 3), Virtual Network accessed by enterprise network through VPN/PE > (Section 3.2); > > 4), Multiple/Multi-tier Virtual Networks (Section 4.1); > > 5), Multiple Virtual Networks connected by other Virtual Network > (Section 4.2); > > 6), Multiple Virtual Networks accessed by enterprise network and > Internet through secure Gateway (Section 4.3). > > In all these typical usage scenarios, the VN can be abstracted as basic > VN(s) and the Gateway(s). The basic VN consists of some VMs which > connect to NVE and multiple NVE connect to each other by underlay > network in one data center site. And the gateway may be any one or > combination of NAT, firewall, secure gateway, load balancer, etc. > > For virtual network automatic provisioning, if the basic VN(s) and the > Gateway(s) can be automatically created(and automatically connected) > then the VN can be automatic provided. > > For Gateway automatic provisioning, we already know that the firewall or > NAT or Gateway can be virtualized to support lots of virtual devices on > these devices, so we can define some interface to distribute the > automatic creation command to these devices to realize the gateway > automatic provision. > > One method is, it can be done or supported by using the NVE-NVA > protocol, because the gateway and the NVE can be resided in the same > datacenter gateway generally. Please note that this may need more > investigation and may be out of the NVO3 scope. > > For basic VN automatic creation, we have proposed the NVE auto-discovery > protocol to support VM automatic join the VN. [For simplicity, and it’s > reasonable, we assume that VM is prepared by Hypervisor and is ready > been configured with some basic parameters such as MAC address and/or IP > address or VLAN-ID etc.] > > For other VM/Hypervisor-NVE protocol candidate, e.g. VDP, it can also be > extended to support VM automatically join the VN. > > The main point of this method is, using reserved VDP TLV Type to define > some associate commands with auto join VN commands; or using a new > filter information format to define this function, e.g. automatic join > the VN, for the existing associate commands. > > When the EVB bridge, which also works as NVE, received the extended VDP > commands it associates the VSI with a SBP, and further to create VN > context for the VN which the VM wants to join, if the VN context does > not exist; and further create an entry for the VM in the VRF, if this > entry does not exists. The associate can be done by choosing one SBP > from the SBP list which are configured by network administrator for > automatic service provisioning purposes. > > After that, the NVE using NVE-NVA protocol to synchronize with other > NVEs in the same VN to realize the VN. > > So we have two different mechanisms to realize the automatic VN > provisioning. > > Based on above discussion, we suggest the working group accept the VN > automatic service provision requirements. > > Any comments or suggestions? > > Thanks in advance! > > Zhongyu > > > > _______________________________________________ > nvo3 mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/nvo3 > _______________________________________________ nvo3 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nvo3
