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
