On Fri, Jul 29, 2016 at 3:13 PM, Jesse Gross <jgr...@vmware.com> wrote: > >> On Jul 29, 2016, at 2:59 PM, Tom Herbert <t...@herbertland.com> 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. 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. Tom _______________________________________________ nvo3 mailing list nvo3@ietf.org https://www.ietf.org/mailman/listinfo/nvo3
