Inline.
> -----Original Message-----
> From: Tom Herbert [mailto:[email protected]]
> Sent: Friday, October 30, 2015 4:26 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
>
> > [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.
>
> Tom
_______________________________________________
nvo3 mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/nvo3
