> [PG] Yes, which is what TLVs in NSH/Geneve do but these are part of the > format and not something we have to define on the side. Two independent > entities can attach their metadata on the same packet without conflicts etc. > Eventually, one can take either of these encap protocols and twist/turn them > to achieve what is needed, e.g. in Geneve one can define a standard first TLV > that has flag based options etc. as well. In GUE, I can create another IETF > draft to define "standard" TLV based usage of "private" data space. That is > why, I think many people on the alias feel that many of these encap don't > have any substantial value over one another, other than semantic differences. > That said, out of the box, IMHO, NSH has the most flexibility i.e. define new > MDType, using that MDType for flag based options in fixed header and TLVs for > variable length.
What I meant to say is that the format of private data could be typed in GUE via an option. For instance, we could define a data format for Geneve and then, presto, GUE can carry Geneve TLVs. While personally I am very leery about deploying any new use cases of TLVs in my data center (given the lessons learned with IP options and extension headers), if allowing them in GUE would achieve a compromise that pulls us closer to defining _one_ NVo3 protocol, then it seems like a reasonable direction. Tom _______________________________________________ nvo3 mailing list nvo3@ietf.org https://www.ietf.org/mailman/listinfo/nvo3
