Inline.
> -----Original Message----- > From: Tom Herbert [mailto:[email protected]] > Sent: Friday, October 30, 2015 2:48 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 > > On Fri, Oct 30, 2015 at 1:38 PM, Pankaj Garg <[email protected]> > wrote: > > Inline. > > > >> -----Original Message----- > >> From: Tom Herbert [mailto:[email protected]] > >> Sent: Friday, October 30, 2015 11:57 AM > >> 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] 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. > >> > >> Well, we have already defined seven extensions to GUE. AFAICT adding > >> these was quite straightforward none of these can break forward > >> compatibility, nor NIC offloads, and is amenable to efficient header > >> parsing in both software and hardware. GUE also allows for private > >> data in the header section for a site or application to insert data > >> with whatever format is suitable (for instance, if SPUD uses GUE > >> format CBOR data could go here). But, if you really do see an > >> deficiency in this model that would "tie your hands" please elaborate, we > appreciate the feedback! > > [PG] Our network stack consists of multiple layers, where layers can be > developed independently (and can even be from separate vendors). Using > Geneve/NSH style TLV provides us flexibility of a non-conflicting private data > space, where different layers can insert their own data on transmit and > process that on reception. How would one achieve this flexibility in GUE? > > You can define proprietary options (TLVs or other format) in the private data > space. The interpretation of the this space is agreement between the sender > and the receiver so there should be no ambiguity or limits to what can be > placed there (subject only to header size constraints). [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. > > Tom > > >> > >> Thanks, > >> Tom _______________________________________________ nvo3 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nvo3
