Hi Joe, Thanks for your feedback and very helpful information.
For first point, yes, it's for Informational, hope it accepted by WG as one requirement docu. For second point, as you pointed out, the post is mainly focused on Hypervisor/Tenant system/VM initiated automatic service provision. But there are other flavor of the automatic service provision that not included in this post but in the draft, one of which is management initiated, -(NVA) accept the customer's request for VN, mapping the request to physical devices, and figure out and deliver the configuration commands to those devices, and the devices executing the commands and realize the VN deployment. The X-Bone can be used as an example to support the management initiated mechanism of VN automatic provision, although the usage environment is somehow different. From the viewpoint of standardization, the management initiated mechanism may be difficult if not impractical. This is why we try the post to discuss the practical mechanism. Best regards, Zhongyu Joe Touch <[email protected]> 2015/03/26 02:43 收件人 [email protected], "[email protected]" <[email protected]>, 抄送 主题 Re: [nvo3] Automatic VN service provisioning discussion 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
