Inline.
> -----Original Message----- > From: Tom Herbert [mailto:[email protected]] > Sent: Thursday, October 29, 2015 10:33 PM > To: Pankaj Garg <[email protected]> > Cc: Dino Farinacci <[email protected]>; Manish Kumar (manishkr) > <[email protected]>; Lucy Yong <[email protected]>; > [email protected] > Subject: Re: [nvo3] RFC 7637 on NVGRE: Network Virtualization Using > Generic Routing Encapsulation > > >> 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. [PG] I think you are mixing two things hardware and software extensibility. TLV mechanism is perfect for software extensibility. For hardware extensions (as and when they are needed), we can define new MDType that uses fixed format headers to provide hardware interop or having first TLV as hardware extension TLV etc. This is unlike IP options or extension headers. I believe Intel has already implemented offload support for Geneve so maybe they can share their performance numbers but if I recall right (and maybe I am wrong), it is similar to VXLAN performance. So no, I don't think there is any technical evidence against using TLVs for extensions for the purpose of network virtualization. > > 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. > [PG] I don't think GUE provides flexibility that is needed for future encapsulation. Network virtualization is mostly used with-in datacenters and in such environments, flexibility is needed to change and innovate rapidly. We need an encapsulation format that provides such flexibility and does not tie our hands. > 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! [PG] Yes, we should have a discussion on this and I _really_ hope, we pick one protocol as standard for network virtualization as opposed to 3 or 4. > > Thanks, > Tom > > > >> > >> Thanks, > >> Tom > >> > >> >> > >> >> Tom _______________________________________________ nvo3 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nvo3
