On 31/03/14 17:22, Black, David wrote: > 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.
I think you missed my point. 1. VM case - It is the hypervisor side of the vNIC and it is a classic L2 service. See most recent code drop: http://lists.gnu.org/archive/html/qemu-devel/2014-03/msg05830.html It is very clear in what it is - it is a L2 service attached through vNIC on the hypervisor side. VM has _NO_ code whatsoever of any shape or form that is service related. It is the same as if it was attached to a vswitch. 2. Bare metal case. For containers the kernel serves _IS_ the hypervisor. Representing an overlay interface as an "Ethernet" in a container is a classic L2 service. Same story as above - the VM (in this case LXC, Solaris container or BSD jail) sees an Ethernet and has _NO_ service specific code. It cannot in fact distinguish f.e. a GRE, L2TPv3 or VXLAN interface given by the kernel from a vETH coming from a switch or tap hooked up into OVS. > > 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, Yes? And? As I said - for containers the host kernel _IS_ the infrastructure and the container is getting a L2 service. As far as VMs and our proposed amendment if you directly decaps in the hypervisor side of the vNIC it is exactly a minor amendment as proposed. A. > 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
