Anton, This doesn't look like a minor amendment. It looks like the NVE is being split across the TS and the NVO3 infrastructure, with the encap/decap processing moved into the TS.
When a VM is "attach[ed] directly to an overlay", the service provided to that VM (encap/decap code is in the VM, or the bare metal server, per your 5.2 comments), the service is neither L2 nor L3 - it's something new, and NVO3-specific, as opposed to virtualization of a native network service. The real issue here is "where is the service boundary?". NVO3 puts the service boundary at the interface presented *to* the vNIC (or pNIC) by the infrastructure, not at some higher layer in the TS (e.g., VM). Thanks, --David > -----Original Message----- > From: nvo3 [mailto:[email protected]] On Behalf Of Anton Ivanov (antivano) > Sent: Tuesday, March 04, 2014 3:11 AM > To: [email protected] > Subject: [nvo3] Proposal for some minor amendments of the arch draft > > Hi all, > > We have now published the code which allows a VM to attach directly to > an overlay and decouples the virtual switch from host (in fact the > switch can now become physical). This has been possible using containers > all along so there is nothing new and revolutionary in this. > > Based on that (as well as working on that codebase for a while) I have a > few comments: > > Section 3.1 - Presenting unicast point to point as an Ethernet is a > hideous ugly hack which does not necessarily need to be there. Its sole > right to exist is saving IP addresses in hosting. It can and should be > augmented at a later date with native tunneling interface drivers where > applicable. > > Section 3.2. - We have posted the code that does the encapsulation and > decapsulation in the vNIC. The code has existed for containers for quite > a few years now. The architecture diagram is generic enough to > accommodate it - all it is is colocating the VAP with the Tenant in the > Tenant vNIC. No rocket science. The text however is too prohibitive in > its present form. > > Section 3.3 - Same. I believe we have demonstrated how you can locate > (without the co) the NVE function in an off-host big fat router/switch > of your choice with the VAPs being colocated with the VMs. We have also > open sourced the relevant kvm code for the VAP portion so everyone can > use that now. > > Section 5.2. Overly restrictive. What exactly prevents me even today to > originate a GRE tunnel (which is the current arch)? Nothing. Besides the > sysadmin not being bothered to read "man ip". If the protocol is > supported and if it can be presented as a vNIC there is nothing to > restrict the physical host from originating the overlay. > > I am not going to barge in with "here we have this wonderful new > protocol" and support it by marketing slides. However, I also have to > note - you have missed a wonderful _OLD_ protocol - L2TPv3 static > tunnels and we have a working implementation which has been > open-sourced. We will be augmenting that with GRE at a later date too. > > > Well, > _______________________________________________ > nvo3 mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/nvo3 _______________________________________________ nvo3 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nvo3
