From: nvo3 on behalf of Pankaj Garg Date: Saturday, October 31, 2015 at 8:17 AM To: Tom Herbert Cc: "[email protected]<mailto:[email protected]>", "Manish Kumar (manishkr)", Dino Farinacci, Lucy yong Subject: Re: [nvo3] RFC 7637 on NVGRE: Network Virtualization Using Generic Routing Encapsulation
Inline. -----Original Message----- From: Tom Herbert [mailto:[email protected]] Sent: Friday, October 30, 2015 4:26 PM To: Pankaj Garg <[email protected]<mailto:[email protected]>> Cc: Dino Farinacci <[email protected]<mailto:[email protected]>>; Manish Kumar (manishkr) <[email protected]<mailto:[email protected]>>; Lucy Yong <[email protected]<mailto:[email protected]>>; [email protected]<mailto:[email protected]> Subject: Re: [nvo3] RFC 7637 on NVGRE: Network Virtualization Using Generic Routing Encapsulation > [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. [PG] Yes, if there is a standard option to carry TLVs then it would meet the flexible extension requirement and make it similar to Geneve and NSH from flexible extension perspective. In terms of industry adoption, there may be other factors like hardware and software ecosystem support, but from purely format perspective, it would certainly make GUE meeting flexibility requirements better. 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. 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.
_______________________________________________ nvo3 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nvo3
