On Fri, Jul 29, 2016 at 5:49 PM, Jesse Gross <[email protected]> wrote: > >> On Jul 29, 2016, at 5:16 PM, Tom Herbert <[email protected]> wrote: >> >>> The only thing that I can say is that over the past several years since the >>> protocol was defined our experience with this tradeoff has been pretty >>> good. Both the number of uses of Geneve and implementations have increased >>> and as time has gone on, the uses have take more advantage of the >>> flexibility and have not run into any significant implementation issues >>> (either software or hardware). >> >> Jesse, >> >> In the list of TLV definitions you sent out I could only discern two >> actual TLVs that have been defined. Cilium and VmWare stuff are >> marketing slides, and an offhand reference to Geneve TLV in RCO draft >> is by no means a specification. For comparison GUE has six defined >> formally in I-Ds. So unless you're holding out a whole bunch of >> development, I'm not seeing that the "inability to have a significant >> number of extensions" is a material issue with GUE. > > Tom, I think that we’re going in circles here. All of the references I gave > with the exception of remote checksum have implementations behind them. Not > all of them are public. You can do as you wish with that information and the > other examples I gave. > > I think one practical difference between Geneve and GUE is that Geneve has > implementations and option definitions by a number of different parties. To > the best of my knowledge, all of the work on GUE has been done with your > involvement which makes it much easier to manage for your specific use cases. > I suspect that if GUE were to become a standard, you would find your > flexibility in this regard would be significantly reduced and might run into > some of the same issues as I’ve been describing. However, only time will tell.
I think it's equally possible that if Geneve becomes a standard you will wind up with a mess of vendor specific options that overlap in functionality but don't have any interoperability except between each vendors devices-- great for vendors, miserable for users. You might end up wishing that extensibility in Geneve had been limited in the first place. Only time will tell... Anyway, I suppose we can agree that extensibility is a strong requirement, but we'll have to agree to disagree on what form extensibility should take and how much an encapsulation protocol should allow! Tom _______________________________________________ nvo3 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nvo3
