On Fri, Oct 30, 2015 at 1:38 PM, Pankaj Garg <pank...@microsoft.com> wrote: > Inline. > >> -----Original Message----- >> From: Tom Herbert [mailto:t...@herbertland.com] >> Sent: Friday, October 30, 2015 11:57 AM >> To: Pankaj Garg <pank...@microsoft.com> >> Cc: Dino Farinacci <farina...@gmail.com>; Manish Kumar (manishkr) >> <manis...@cisco.com>; Lucy Yong <lucy.y...@huawei.com>; >> nvo3@ietf.org >> 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). Tom >> >> Thanks, >> Tom _______________________________________________ nvo3 mailing list nvo3@ietf.org https://www.ietf.org/mailman/listinfo/nvo3
