The Geneve draft proposes a 24-bit VNI, in addition to 32-bits of "Variable Length Options". Those later 32 bits can be used entirely by the system designer for carrying implementation specific metadata, such as for example carrying service chaining relevant information from one middle-box to the next.
Cheers, Brad ----- Original Message ----- From: "Anton Ivanov (antivano)" <[email protected]> To: "Brad Hedlund" <[email protected]> Cc: [email protected] Sent: Friday, February 28, 2014 8:40:51 AM Subject: Re: [nvo3] Draft Geneve On 28/02/14 14:14, Brad Hedlund wrote: > 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. Correct. I am not questioning that. My point is that in the case of L2TPv3 and GRE it _HAS_ happened. Many years ago. Different platforms though (BNG, Carrier systems, etc). Also your VXLAN interpretation still means that the host does not participate in the overlay. It is mediated by an off-host switch through an interim step as raw Ethernet and you just added a silicon requirement for that switch as well. This is not the host participating in the overlay. There is a benefit for the host understanding the overlay. Trivial example - if the host can understand the overlay it can present an overlay endpoint as an ethernet interface to a lightweight container. No overhead. Direct overlay to visualization instance. Thousands of instances on a host too if you want to. > > 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. We are in complete agreement. However I am taking this one step further. It is not just the least interesting part - it has already been done. It is in the stack on most OSes. It has been in the stack on most OSes for 5 years running. There is no reason whatsoever to reinvent the wheel. The protocols are there, present, usable and should be used. > 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). L2TPv3 has 32 bits of what can be used as VNID (session). I do not see how a proposal with a 24 bit VNID space has any merit over that. If 24 bits are enough, there should be a valid argument on how suddenly 32 bit have become smaller than 24. > 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. Again - completely agree. In between themselves VXLAN, L2TPv3 and GRE cover all key encaps basics and are supported on all platforms of interest. There is no need for yet another unoriginal encapsulation. A. > > 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
