> To follow up on Pankaj’s mention of ecosystem support, one comment about the > viability of TLVs is that whether they are a useful extension mechanism is > mostly based on the implementer’s perception. If they are seen as an add-on > that is not really core functionality (as in IPv4 and IPv6), then sure, > people won’t bother to support them. However, in the case of Geneve, they > are obviously the major goal of the protocol and they are being implemented, > in both software and hardware. > Jesse,
Your point that TLVs are major goal of Geneve would be much stronger if you could reference defined TLVs that are critical to the protocol function. Maybe I'm missing something, but I can't find any defined TLVs for Geneve on the web at all. As for efficient hardware implementation, section 2.2.1 of the Geneve draft does acknowledge the problem for VLH at least: "The use of a variable length header and options in a protocol often raises questions about whether it is truly efficiently implementable in hardware." Unfortunately, the rest of the section offers no practical guidance to HW or SW vendors on how to do efficient implementation. The closest thing to a mitigation for the potential performance problem is: "As new functionality becomes sufficiently well defined to add to endpoints, supporting options can be designed using ordering restrictions and other techniques to ease parsing." This is obviously vague. I suppose the ordering restrictions are the proposed solution for the combinatorial parsing problem of TLVs. But without details on how there is no teeth behind this idea. As for these "other techniques"...???? > As a result, it’s not an inherent property of TLVs that they are implemented > or not. In order to make them useful, they need to be used and considered > important from day 1. Making them available as an additional extensibility > mechanism pretty much guarantees that they won’t be available in the future, > as we’ve seen. Put the VNID into a TLV then you are guaranteed that people will implement them! Tom _______________________________________________ nvo3 mailing list nvo3@ietf.org https://www.ietf.org/mailman/listinfo/nvo3
