> 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. _______________________________________________ nvo3 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nvo3
