>> As for "safely extend using TLVs" have you actually verified that works with >> HW, performance is unaffected, and this does not create new vectors of DOS >> attacks? (Given the unmitigated disappointment with IP options I'm very >> skeptical of and deployment of TLVs at L3 or below in the data center.) > [PG] We have not tested it but maybe some IHVs who are supporting Geneve (or > NSH) offload can comment. I have no technical evidence, though, as to why it > would _not_ work (sans some implementation constraints on maximum header size > etc, which is pretty reasonable).
The technical evidence can be found in evaluating mechanisms of similar protocols at the same layer. In particular, Geneve TLVs like IP options and NSH is similar to IP extension headers. Both IP options and extension headers are currently undeployable in the data center due to insufficient or incorrect HW support in switches an NICs, and I haven't (yet) seen a reasonable explanation or implementation showing that the fate of Geneve TLVs or NSH will be any different. GUE follows the model of extensibility of GRE. In developing GUE, we already had a lot of deployment experience with GRE fields (keyid, csum, seq). The various HW we tested had no issues with them, so we do believe GUE extensions can be deployed at scale. Anyway, the model of extensibility is a significant differentiator in the three NVo3 protocols. I hope there will be some detailed discussion around this at some point! Thanks, Tom >> >> Thanks, >> Tom >> >> >> >> >> Tom _______________________________________________ nvo3 mailing list nvo3@ietf.org https://www.ietf.org/mailman/listinfo/nvo3
