On 28/02/14 15:30, Pankaj Garg wrote: > Yes, the key differentiator in Geneve is to allow multiple variable length > options in the unit of 32-bits, _without_ breaking hardware offloads that are > critical for software endpoint performance. These options can be standard > options or vendor specific, to allow vendors to evolve their data plane and > experiment/innovate using meta-data, and standardize the useful ones at a > later point.
So how is that different from me specifying a different offset for data in l2tpv3 in multiples of 32 bits? We just specify what the meanings of those should be. The whole offload section of draft-geneve can be applied there to same effect. The only difference compared to an existing published and well supported RFC is that we have to standardize the way the configurable offset is handled. A. > > Thanks, > Pankaj > > -----Original Message----- > From: nvo3 [mailto:[email protected]] On Behalf Of Brad Hedlund > Sent: Friday, February 28, 2014 8:39 PM > To: Anton Ivanov (antivano) > Cc: [email protected] > Subject: Re: [nvo3] Draft Geneve > > 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/mailma >> n/listinfo/nvo3&k=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0A&r=LfVwmzZtwW32snST >> UvjgMl4EgksMaIQ6nBSzwpJYhxw%3D%0A&m=HIV6ylhSIvlBLF2JcY4AbvKIp4AytOoWy1 >> TnXn9PrCc%3D%0A&s=4df281d1fecc67d941f33a355364c2e128de78da24a74dfa6af3 >> 8f8f85e090d2 > _______________________________________________ > nvo3 mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/nvo3 _______________________________________________ nvo3 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nvo3
