The diagram in the Geneve draft depicts tunnels terminating on both virtual switches in a Hypervisor, as well as physical switches connecting to non-virtual physical hosts. As such, the later brings the physical hosts into the overlay without any modification to the software stack on the physical hosts. This is already happening today with VXLAN, with commercial switching silicon providing line rate VXLAN encap/decap. The physical switch vendor can then provide interoperability with a third party control plane that can provision tunnels between the virtual and physical switches.
There's nothing preventing the physical hosts from implementing Geneve tunnels in their own software stack and bypassing the need for terminating tunnels on a physical switch. The diagram just depicts what the authors felt would be most common deployment scenario. As I see it, the point with Geneve is that the tunneling protocol is actually the least interesting part of the overall system. So perhaps the industry can work with a common tunneling format that provides both data plane interoperability and sufficient room in the header for implementation specific differentiation (metadata). Instead, perhaps the industry can focus on competing and differentiating at the control and management planes. Not too dissimilar from what happened when we agreed on Ethernet and IP encapsulation. Cheers, Brad ----- Original Message ----- From: "Anton Ivanov (antivano)" <[email protected]> To: [email protected] Sent: Friday, February 28, 2014 2:30:15 AM Subject: [nvo3] Draft Geneve Hi all, I just finished reading this draft. I am going to ignore the caption under the diagram at this point - it does not match to the diagram and neither does the rest of the draft (we will come back to it later). So, first and foremost, the diagram. I actually really like it. It is very close to what we have been showing to customers as a product prototype and will be shipping in the near future. Namely - I like the presence of the physical(s) in the top right corner. Physicals are an integral part of a datacenter and need to talk to the overlay too. It is quite sad that after getting this right, the draft cripples it by limiting the scope and failing to address what is actually shown on that diagram. In order for physicals to talk to the overlay they need to be able to connect to the overlay. In real life this means well known and well supported encapsulations - EoGRE, EoL2TPv3 and more recently VXLAN. The former two are supported on most "hosts" as well as nearly all network equipment. The latter is getting there too. A new and wonderful encapsulation which on top of all is not directly supported and mandates me to run a virtual switch everywhere is not a "well supported encapsulation". It does not fit the bill and does not match the diagram. There are two ways to approach this from here onwards. One is to continue the critique and discussion. IMHO this is pointless and violates the spirit of IETF: "We believe in rough consensus and working code". The consensus is there - most of the networking world uses either EoGRE or EoL2TPv3 (VXLAN has its established use cases too). These are established standards with RFCs. We will now _ADD_ _THE_ _CODE_ so we can get out of this "I'd like to invent a new encapsulation today" madness once and for all. * We just contributed a GPL2 EoL2TPv3 direct support for qemu-kvm to the qemu project. * We also made a binding promise to offer equivalent code to UML (we have the code there, just the patch-sets are too big to submit at once). * Containers can talk EoL2TPv3 directly already. All of these can use this to talk directly VM to VM, Physical to VM and Switch to VM (as on the diagram). It is fully supported for switching - you simply configure a EoL2TPv3 interface on your local host and bring it into OVS, Bridge or other local switching system of your choice. You can also switch remotely - the NVE is no longer mandatory co-hosted on the same machine. So if you want to do all of your datacenter switching on a "big router/switch" you can now do so. All of them can talk the encaps, most have support for running thousands (some up to tens and hundreds of thousands) of NVEs too. You also can talk to host - just configure a tunnel "to yourself". Most importantly you can talk VM to VM and VM to physical router as needed for service chaining. This brings me back to the caption under the diagram. That caption is complete nonsense. You can implement means of communicating between all the elements on it without a mandatory switch. Why on earth do you need to cripple the spec and specify it after that? I am aware that EoLT2Pv3 is not a candidate for NVO3 at present. We will address that by contribute equivalent GRE code at a later date (next couple months). In fact, anyone can take the driver we contributed and make it support GRE, Geneve or carrier pigeons. This is because this contribution has produced an interesting side effect - anyone who would like to implement in software a new encaps that can be presented as a socket interface on a host running Type 2 environment can now do so in an afternoon or less. It is no longer "state of the art" activity. The barrier to entry and the technical merit of "new encaps" if it is only an encaps (no control plane component) has just been lowered to somewhere around zero. It is now "boring". This is inclusive of Geneve itself. As it has no other merit besides being new encaps I do not see why it should be left to live under these circumstances. I'd rather have people include the remaining key encaps out there - L2TPv3 and concentrate on getting the control plane portion working. Some final clarifications: 1. Drafts - L2TPv3 is an RFC and has been around for many years. There is no need for extra drafts. 2. IPR - the same mechanics for overlay termination have been used in storage for many years providing a plethora of prior art. Similarly, non-standard versions of the same approach (VDE, socket,etc) have been around since the dawn of qemu and UML. There is nothing to patent here. A _______________________________________________ nvo3 mailing list [email protected] https://urldefense.proofpoint.com/v1/url?u=https://www.ietf.org/mailman/listinfo/nvo3&k=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0A&r=LfVwmzZtwW32snSTUvjgMl4EgksMaIQ6nBSzwpJYhxw%3D%0A&m=HIV6ylhSIvlBLF2JcY4AbvKIp4AytOoWy1TnXn9PrCc%3D%0A&s=4df281d1fecc67d941f33a355364c2e128de78da24a74dfa6af38f8f85e090d2 _______________________________________________ nvo3 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nvo3
