> I object to GUE due to its inability to have a significant number of > extensions in a regular and interoperable way. The base flags structure is > limited (note 7 of 16 flags have already been used before the document has > been published) and requires specific knowledge in the dataplane of all prior > defined extensions to even parse a given field. The draft does have private > data but since this is unstructured and untyped, it will be very difficult to > make it interoperable between different users. In the past, ways around this > have been proposed such as a flag indicating that an extended set of flags > are present or overlaying the private data with some structure (such as > TLVs). However, having multiple extension mechanisms in a single protocol > seems overly complex and likely to result in incomplete implementations. > Jesse,
As described in the GUE draft an optional flag extension field can be added to provide another 32 bits of flags. That process could then be repeated in the flag extension header field to give another 32 bits of flags an so on. We have been running GUE for over three years now and beyond the basics extensions (security, checksum, RCO, fragmentation), I don't have reason believe we'll see new extensions in great numbers-- at most one or two added a year. It is true that GUE does not have an open ended extensibility format like Geneve. As you point out, it could be added, but I don't currently see the need for that. Can you maybe shed some light on the rationale and real use of TLVs in Geneve? How many TLVs have been defined? What kinds of TLVs are being defined? How many TLVs are present in individual packets? Are individual vendors creating their own TLVs, and if so how are these interoperable? Thanks, Tom _______________________________________________ nvo3 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nvo3
