> On Jul 29, 2016, at 3:31 PM, Tom Herbert <[email protected]> wrote: > > On Fri, Jul 29, 2016 at 3:13 PM, Jesse Gross <[email protected]> wrote: >> >>> On Jul 29, 2016, at 2:59 PM, Tom Herbert <[email protected]> wrote: >>> >>>> As a hypothetical question, how would you handle a situation where the >>>> security token you have defined for GUE is shown to be broken and needs to >>>> be replaced with a new option? I’m sure that in that case, you would feel >>>> the need to react immediately. It seems like the two choices would be to >>>> start using one of the unallocated flag fields and standardize and migrate >>>> before there is a collision with another option or resort to the private >>>> data field. Both seem to have some downsides. >>> >>> The security option is defined with length(s) but no semantics. The >>> particular security algorithm used between two hosts is done out of >>> band agreement (key exchange is needed anyway). The only case where we >>> need to reconsider security this is when we need a larger token, in >>> that case we can define an extended security field option (but we >>> already have a 32 bit option, more than that and we're starting to >>> majorly impact MTU).. >>> >>> The transform option contains an 8 bit transform type. Right now the >>> value for DTLS is defined, more transform types can be defined as >>> needed (we allow for private transform types also). >> >> Sorry, I should have been clearer - security was mostly just framing for the >> question on extensibility. The general point that I was trying to make was >> that there are a variety of cases where having open ended extensibility is >> useful. At least in some situations it’s probably important to be able to >> react to and deploy new options very quickly. > > True, but if I'm using a new extension that means I need end points to > understand and use these extensions. The fact the option is in a > flag-field shouldn't have any bearing on speed of deployment, in any > case some method of extending the protocol is done that presumably > changes the bits on the wire.
In this case, I’m mostly talking about “speed of consensus” vs. “speed of implementation”. I agree that flag fields shouldn't affect how long it takes to implement but it does make a difference in whether it is necessary to have central coordination for the extension space. Geneve effectively has a much sparser address space for its extensions compared to GUE, which means that it’s possible to define new options independently. As a side note, the Geneve implementation in Open vSwitch actually does allow new TLVs to be defined in some cases without changing any code (specifically those that can be handled on a flow basis, which is OVS’s basic unit of work). This is a nice property of having a regular and self-describing format for parsing. > I don't deny that open ended extensibility can be useful in some > situations, but I do think you need to also acknowledge that this > flexibility is not without cost. Items like security and RCO checksum > offload might be sent in every packet within the data center. An > additional four bytes overhead, the type lookup, and validation of the > TLVs is overkill in that context. Extensibility is a requirement, but > so is an efficient and low overhead encapsulation. Sure, there are certainly tradeoffs to be made in this area. I think that extensibility (in general) is probably more difficult to implement compared to a fixed version of the same thing but this is often compensated by the fact that only a single implementation of it is necessary. Similarly, while a more open ended format has some costs, it also has the benefit of a consistent datapath that only needs to know how to parse the TLVs that it cares about and not all options that have been defined. However, I absolutely agree that there are pros and cons to each approach and it depends on the use case. 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). _______________________________________________ nvo3 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nvo3
