>> Yes, security and identifiers are being defined as well known >> extensions. The reason for having a private data section is to allow >> implementations or sites to extend the protocol for their own >> purposes. They may or may not intend standardize. What we don't want >> to happen is that people randomly reserved bits for their own purposes >> so that in the future we we need to define a standard use for them we >> can't because there is some significant deployment already using them. >> This is especially a concern for an nvo3 protocol which is more of DC >> protocol then protocol used on the Internet so we anticipate more >> "customization". > > Yeah, I get the use case. I just don't like it :-) > It's a hard line to draw. There's payload and there's overhead. I don't see > that there is a way here to make people do the right thing - perhaps we > shouldn't worry about that? > > An option is to define a new payload protocol and put it all in there. It's > marginal. > > Anyway, I still think you might consider the use of an OID to help prevent > surprises while processing what is otherwise unstructured/unknown data. > If we go this route I would suggest we add a "TLVs present" bit that would indicate that the private data region contains well known TLVs. The TLV format and name space could be based on those defined in Geneve. With this Geneve protocol would then effectively be a subset of GUE functionality, and conceptually is a way to unify two of the three nvo3 proposed protocols.
Tom _______________________________________________ nvo3 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nvo3
