You should ask the proponents of NVGRE, if they still have an investment in NVGRe. From what I hear, through the grapevine, those proponents use VXLAN to deliver services.
So with all due respect to the NVGRE advocates, would they object dropping NVGRE support from the nvo3 charter? Practically speaking, Dino > On Oct 28, 2015, at 1:42 AM, Manish Kumar (manishkr) <[email protected]> > wrote: > > Hi Tom, > > Any specific reason that we want to distinguish NVGRE from other usages of > GRE (except for the usage of last 8 bits for entropy). In fact, given that > the meaning of key was relatively open, many implementations have > optionally used the last 8 bits of the key for entropy even before NVGRE > (DC usage) came into picture (with both ends of the tunnel in agreement). > If needed, we could use one of the reserved bits at the beginning of the > header to indicate such usage. > > Alternatively, GRE over UDP gives all that we need. To be honest, I still > fail to find a reason of why we really needed VxLAN and VxLAN GPE(now) > given that GRE has already existed for so long (as well as some > implementations of GRE over UDP) - this is new learning (in terms of new > encap, new numbers, etc, etc!) and a lot of extra work for implementors > and users alike! Just carrying GRE over UDP (could be thought of as a > nested encap) along with using a few reserved bits (for OAM, etc) seems to > me to give all that we’ll get after a long arduous journey to VxLAN GPE > through VxLAN! May be my personal opinion but I haven’t seen anything > otherwise yet. > > Thanks, > Manish > > On 06/10/15 10:15 pm, "Tom Herbert" <[email protected]> wrote: > >> On Tue, Oct 6, 2015 at 9:31 AM, Lucy yong <[email protected]> wrote: >>> Hi Manish, >>> >>> I agree with you. >>> >>> GRE/UDP encapsulation protocol can apply to the Internet and a >>> well-managed operator network. NVGRE is adapted from GRE and made >>> specific for Ethernet/IP payload. We should not make them as two >>> distinct encap. protocols for this space. NVGRE can be benefit from >>> GRE/UDP for flow entropy and UDP checksum in IPv6; thus should be >>> considered as optional to use. >>> >> I you might still need to define NVGRE/UDP separately. In particular, >> I wonder if NVGRE/UDP necessitate port number? AFAIK there is no way >> to distinguish NVGRE from other uses of GRE, a different UDP port >> number could allow that. >> >> Tom >> >>> Lucy >>> >>> -----Original Message----- >>> From: nvo3 [mailto:[email protected]] On Behalf Of Manish Kumar >>> (manishkr) >>> Sent: Tuesday, October 06, 2015 1:02 AM >>> To: Pankaj Garg; Tom Herbert >>> Cc: [email protected] >>> Subject: Re: [nvo3] RFC 7637 on NVGRE: Network Virtualization Using >>> Generic Routing Encapsulation >>> >>> Hi Tom, Pankaj, >>> >>> The usage of the UDP header in such encapsulations is mostly for >>> entropy (load-balancing), aid NAT traversal, etc. This indirectly makes >>> the transport believe that the packet is a regular IP packet (with L4 >>> header following the IP header) rather than a tunnelled IP packet(some >>> systems/functionalities always assumed this). In this context, it makes >>> sense to stamp he UDP header only on the outer most encap, the ones >>> added on the inner encaps don¹t add much value. Hence, I¹m of the view >>> that the UDP header be dissociated with individual encaps and just >>> stamped after the outer most encap when needed - the destination UDP >>> port, as usual, identifies the encap protocol. Given that GRE is, by >>> far, the most commonly used general purpose encap deployed today, it may >>> be good to have GRE in UDP. I would like to see this as GRE in UDP >>> rather than GRE and >>> GRE+UDP as two different encaps conceptually (implementations may choose >>> to interpret based on what¹s convenient). Optional UDP would also mean, >>> those 8 bytes are only used when needed (which could be, for example, >>> communicated by the control plane if there is one). >>> >>> Just my two cents! >>> >>> Cheers, >>> Manish >>> >>> On 03/10/15 2:01 am, "nvo3 on behalf of Pankaj Garg" >>> <[email protected] on behalf of [email protected]> wrote: >>> >>>> Hi Tom, >>>> >>>> In my personal opinion, for network virtualization, I don't see much >>>> value in GRE in UDP. Each new encapsulation takes a lot of effort and >>>> time before it achieves ecosystem support (from software to hardware to >>>> offloads) to make it a viable option. We already have VXLAN/GPE so I am >>>> not sure what we gain with GRE in UDP over VXLAN/VXLAN-GPE. There may >>>> be scenarios outside of network virtualization, where this may be >>>> useful, but I am not familiar with those. >>>> >>>> Thanks >>>> Pankaj >>>> >>>>> -----Original Message----- >>>>> From: Tom Herbert [mailto:[email protected]] >>>>> Sent: Thursday, October 1, 2015 12:38 PM >>>>> To: Pankaj Garg <[email protected]> >>>>> Cc: [email protected] >>>>> Subject: Re: [nvo3] RFC 7637 on NVGRE: Network Virtualization Using >>>>> Generic Routing Encapsulation >>>>> >>>>> Hi Pankaj, >>>>> >>>>> Do you think there is any value, intent, or issue for doing NVGRE/UDP >>>>> (via >>>>> >>>>> https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2ftools >>>>> .ie >>>>> tf.org%2fhtml%2fdraft-ietf-tsvwg-gre-in-udp-encap- >>>>> 07&data=01%7c01%7cpankajg%40microsoft.com%7cb4e8bc27b4104053ac7d0 >>>>> 8d2ca97cf9d%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=mjLRy8EUy >>>>> dHFlg4CVx6wqAc0kuElYDl45P%2bNoPH2QaM%3d) >>>>> >>>>> Tom >>>>> >>>>> On Thu, Sep 24, 2015 at 1:43 PM, Pankaj Garg <[email protected]> >>>>> wrote: >>>>>> FYI, NVGRE is published as an information RFC 7637. Your documents >>>>> that >>>>> reference NVGRE, please use this RFC number. >>>>>> >>>>>> Thanks >>>>>> Pankaj >>>>>> >>>>>>> To: ietf-announce at >>>>>>> https://na01.safelinks.protection.outlook.com/?url=ietf.org&data=0 >>>>>>> 1%7 >>>>>>> >>>>> c01%7cpankajg%40microsoft.com%7cb4e8bc27b4104053ac7d08d2ca97cf9d% >>>>> 7c72 >>>>>>> >>>>> f988bf86f141af91ab2d7cd011db47%7c1&sdata=5hAuGhDIDQJKVz73tx1%2b7 >>>>> sWRI3 >>>>>>> KbhTGidy0PMcC2SHc%3d, rfc-dist at >>>>>>> https://na01.safelinks.protection.outlook.com/?url=rfc-editor.org&; >>>>>>> dat >>>>>>> >>>>> a=01%7c01%7cpankajg%40microsoft.com%7cb4e8bc27b4104053ac7d08d2ca9 >>>>> 7cf9 >>>>>>> >>>>> d%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=2cRTxuyq9Uzy4cM34 >>>>> %2fIi >>>>>>> jExLAgN8PbJp4WbdxMAk%2bNU%3d >>>>>>> Subject: RFC 7637 on NVGRE: Network Virtualization Using Generic >>>>>>> Routing Encapsulation >>>>>>> From: rfc-editor at >>>>>>> https://na01.safelinks.protection.outlook.com/?url=rfc-editor.org&; >>>>>>> dat >>>>>>> >>>>> a=01%7c01%7cpankajg%40microsoft.com%7cb4e8bc27b4104053ac7d08d2ca9 >>>>> 7cf9 >>>>>>> >>>>> d%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=2cRTxuyq9Uzy4cM34 >>>>> %2fIi >>>>>>> jExLAgN8PbJp4WbdxMAk%2bNU%3d >>>>>>> Date: Wed, 23 Sep 2015 15:16:09 -0700 (PDT) >>>>>>> Archived-at: >>>>>>> <https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fm >>>>>>> ail >>>>>>> archive.ietf.org%2farch%2fmsg%2fietf- >>>>> &data=01%7c01%7cpankajg%40micros >>>>>>> >>>>> oft.com%7cb4e8bc27b4104053ac7d08d2ca97cf9d%7c72f988bf86f141af91ab2d >>>>> 7c >>>>>>> >>>>> d011db47%7c1&sdata=awTaXvxdIhjCQwRST26DMgCILeQsfnypU%2bMcS%2 >>>>> bSn5QI%3d >>>>>>> announce/KPKrdzVjAGl5H931oM-D1ce71zQ> >>>>>>> Cc: rfc-editor at >>>>>>> https://na01.safelinks.protection.outlook.com/?url=rfc-editor.org&; >>>>>>> dat >>>>>>> >>>>> a=01%7c01%7cpankajg%40microsoft.com%7cb4e8bc27b4104053ac7d08d2ca9 >>>>> 7cf9 >>>>>>> >>>>> d%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=2cRTxuyq9Uzy4cM34 >>>>> %2fIi >>>>>>> jExLAgN8PbJp4WbdxMAk%2bNU%3d >>>>>>> Delivered-to: ietf-announce at >>>>>>> https://na01.safelinks.protection.outlook.com/?url=ietfa.amsl.com&; >>>>>>> dat >>>>>>> >>>>> a=01%7c01%7cpankajg%40microsoft.com%7cb4e8bc27b4104053ac7d08d2ca9 >>>>> 7cf9 >>>>>>> >>>>> d%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=M%2fe6ro1epcVueeV >>>>> 33Vce >>>>>>> gEClYlei0kGxPJJYjkyJgQQ%3d >>>>>>> List-archive: >>>>>>> >>>>> <https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fmai >>>>>>> larchive.ietf.org%2farch%2fbrowse%2fietf- >>>>> announce%2f&data=01%7c01%7cp >>>>>>> >>>>> ankajg%40microsoft.com%7cb4e8bc27b4104053ac7d08d2ca97cf9d%7c72f988 >>>>> bf8 >>>>>>> >>>>> 6f141af91ab2d7cd011db47%7c1&sdata=ewINwsulb7pgkBwQEfLPn2C%2fG8V >>>>> UJARLm >>>>>>> 0tUxt9hDE0%3d> >>>>>>> List-help: <mailto:[email protected]?subject=help> >>>>>>> List-id: "IETF announcement list. No discussions." >>>>>>> <https://na01.safelinks.protection.outlook.com/?url=ietf-announce. >>>>>>> iet >>>>>>> >>>>> f.org&data=01%7c01%7cpankajg%40microsoft.com%7cb4e8bc27b4104053ac7 >>>>> d08 >>>>>>> >>>>> d2ca97cf9d%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=1a9JG3L4tg >>>>> brZ >>>>>>> %2ff0QtyzPpamed6mC2jjDcg%2fKZe0To0%3d> >>>>>>> List-post: <mailto:[email protected]> >>>>>>> List-subscribe: >>>>>>> >>>>> <https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fwww >>>>>>> .ietf.org%2fmailman%2flistinfo%2fietf- >>>>> announce&data=01%7c01%7cpankajg >>>>>>> >>>>> %40microsoft.com%7cb4e8bc27b4104053ac7d08d2ca97cf9d%7c72f988bf86f1 >>>>> 41a >>>>>>> >>>>> f91ab2d7cd011db47%7c1&sdata=lpYAfNFCgD0wGuCjHWjgvf9iJkv2Dx0EywPx >>>>> 6ZJL3 >>>>>>> 7g%3d>, <mailto:[email protected]?subject=subscribe> >>>>>>> List-unsubscribe: >>>>>>> >>>>> <https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fwww >>>>>>> .ietf.org%2fmailman%2foptions%2fietf- >>>>> announce&data=01%7c01%7cpankajg% >>>>>>> >>>>> 40microsoft.com%7cb4e8bc27b4104053ac7d08d2ca97cf9d%7c72f988bf86f141 >>>>> af >>>>>>> >>>>> 91ab2d7cd011db47%7c1&sdata=mivKM9832k26InTio8KQsMLs3RPk4WX%2bN >>>>> 6hk3mbm >>>>>>> qbg%3d>, <mailto:ietf-announce- >>>>> [email protected]?subject=unsubscribe> >>>>>>> Reply-to: ietf at >>>>>>> https://na01.safelinks.protection.outlook.com/?url=ietf.org&data=0 >>>>>>> 1%7 >>>>>>> >>>>> c01%7cpankajg%40microsoft.com%7cb4e8bc27b4104053ac7d08d2ca97cf9d% >>>>> 7c72 >>>>>>> >>>>> f988bf86f141af91ab2d7cd011db47%7c1&sdata=5hAuGhDIDQJKVz73tx1%2b7 >>>>> sWRI3 >>>>>>> KbhTGidy0PMcC2SHc%3d >>>>>>> >>>>>>> A new Request for Comments is now available in online RFC >>>>> libraries. >>>>>>> >>>>>>> >>>>>>> RFC 7637 >>>>>>> >>>>>>> Title: NVGRE: Network Virtualization Using Generic >>>>>>> Routing Encapsulation >>>>>>> Author: P. Garg, Ed., >>>>>>> Y. Wang, Ed. >>>>>>> Status: Informational >>>>>>> Stream: Independent >>>>>>> Date: September 2015 >>>>>>> Mailbox: pankajg at >>>>> https://na01.safelinks.protection.outlook.com/?url=microsoft.com&data >>>>> =01 >>>>> %7c01%7cpankajg%40microsoft.com%7cb4e8bc27b4104053ac7d08d2ca97cf9 >>>>> d%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=Zv8JyiVSIMZ5jnuPJFa >>>>> 7Km8aQuyEl5l3%2f2oZ09GkrJo%3d, >>>>>>> yushwang at >>>>> https://na01.safelinks.protection.outlook.com/?url=microsoft.com&data >>>>> =01 >>>>> %7c01%7cpankajg%40microsoft.com%7cb4e8bc27b4104053ac7d08d2ca97cf9 >>>>> d%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=Zv8JyiVSIMZ5jnuPJFa >>>>> 7Km8aQuyEl5l3%2f2oZ09GkrJo%3d >>>>>>> Pages: 17 >>>>>>> Characters: 40042 >>>>>>> Updates/Obsoletes/SeeAlso: None >>>>>>> >>>>>>> I-D Tag: draft-sridharan-virtualization-nvgre-08.txt >>>>>>> >>>>>>> URL: >>>>> https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fwww. >>>>> rf >>>>> c- >>>>> editor.org%2finfo%2frfc7637&data=01%7c01%7cpankajg%40microsoft.com% >>>>> 7cb4e8bc27b4104053ac7d08d2ca97cf9d%7c72f988bf86f141af91ab2d7cd011db >>>>> 47%7c1&sdata=1gLcmNAgGpxjG%2fSQGunY3F6SM4UJR7RdnOdnof3zLLo%3 >>>>> d >>>>>>> >>>>>>> DOI: >>>>> https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fdx.do >>>>> i.o rg%2f10.17487%2fRFC7637&data=01%7c01%7cpankajg%40microsoft.com%7c >>>>> b4e8bc27b4104053ac7d08d2ca97cf9d%7c72f988bf86f141af91ab2d7cd011db47 >>>>> %7c1&sdata=ifenB7Oyzkra50G0JmwbU5aGPadkn877%2fCv3qSDxR2w%3d >>>>>>> >>>>>>> This document describes the usage of the Generic Routing >>>>>>> Encapsulation >>>>>>> (GRE) header for Network Virtualization (NVGRE) in multi-tenant >>>>>>> data centers. Network Virtualization decouples virtual networks >>>>>>> and addresses from physical network infrastructure, providing >>>>>>> isolation and concurrency between multiple virtual networks on the >>>>>>> same physical network infrastructure. This document also >>>>>>> introduces a Network Virtualization framework to illustrate the >>>>>>> use cases, but the focus is on specifying the data- plane aspect >>>>> of NVGRE. >>>>>>> >>>>>>> >>>>>>> INFORMATIONAL: This memo provides information for the Internet >>>>>>> community. >>>>>>> It does not specify an Internet standard of any kind. Distribution >>>>>>> of this memo is unlimited. >>>>>>> >>>>>>> This announcement is sent to the IETF-Announce and rfc-dist lists. >>>>>>> To subscribe or unsubscribe, see >>>>>>> >>>>> https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fwww. >>>>> i >>>>> etf.org%2fmailman%2flistinfo%2fietf- >>>>> announce&data=01%7c01%7cpankajg%40microsoft.com%7cb4e8bc27b41040 >>>>> 53ac7d08d2ca97cf9d%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=lpY >>>>> AfNFCgD0wGuCjHWjgvf9iJkv2Dx0EywPx6ZJL37g%3d >>>>>>> >>>>>>> https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fm >>>>>>> ail >>>>>>> man.rfc-editor.org%2fmailman%2flistinfo%2frfc- >>>>> dist&data=01%7c01%7cpan >>>>>>> >>>>> kajg%40microsoft.com%7cb4e8bc27b4104053ac7d08d2ca97cf9d%7c72f988bf >>>>> 86f >>>>>>> >>>>> 141af91ab2d7cd011db47%7c1&sdata=sUFsfHCWD56LRRX3uHF%2fn4%2f8LV5 >>>>> BBCr1M >>>>>>> qlLcxpAOEA%3d >>>>>>> >>>>>>> For searching the RFC series, see >>>>>>> >>>>> https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fwww. >>>>>>> rfc- >>>>> editor.org%2fsearch&data=01%7c01%7cpankajg%40microsoft.com%7cb4e8 >>>>>>> >>>>> bc27b4104053ac7d08d2ca97cf9d%7c72f988bf86f141af91ab2d7cd011db47%7c >>>>> 1&s >>>>>>> data=Dzfgq7%2fPmCe3QZQkLVAhawwqaC1%2flYiVFLNGdouOWr0%3d >>>>> For >>>>>>> downloading RFCs, see >>>>>>> >>>>> https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fwww. >>>>>>> rfc- >>>>> editor.org%2frfc.html&data=01%7c01%7cpankajg%40microsoft.com%7cb4 >>>>>>> >>>>> e8bc27b4104053ac7d08d2ca97cf9d%7c72f988bf86f141af91ab2d7cd011db47% >>>>> 7c1 >>>>>>> &sdata=yMHIW0ciMjjkpD5iwuIVYEIOE5%2bhOtchaHuyQiUJ9TU%3d >>>>>>> >>>>>>> Requests for special distribution should be addressed to either >>>>>>> the author of the RFC in question, or to rfc-editor at >>>>> rfc-editor.org. >>>>>>> Unless specifically noted otherwise on the RFC itself, all RFCs >>>>>>> are >>>>> for >>>>> unlimited distribution. >>>>>>> >>>>>>> >>>>>>> The RFC Editor Team >>>>>>> Association Management Solutions, LLC >>>>>> >>>>>> _______________________________________________ >>>>>> nvo3 mailing list >>>>>> [email protected] >>>>>> >>>>> https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fwww. >>>>> i >>>>>> >>>>> etf.org%2fmailman%2flistinfo%2fnvo3&data=01%7c01%7cpankajg%40micros >>>>> oft >>>>>> >>>>> .com%7cb4e8bc27b4104053ac7d08d2ca97cf9d%7c72f988bf86f141af91ab2d7c >>>>> d011 >>>>>> >>>>> db47%7c1&sdata=XquLeptMFXZ4doDoOE8cFJuIuPR5zWDWXK49awfESBg%3 >>>>> d >>>> _______________________________________________ >>>> nvo3 mailing list >>>> [email protected] >>>> https://www.ietf.org/mailman/listinfo/nvo3 >>> >>> _______________________________________________ >>> nvo3 mailing list >>> [email protected] >>> https://www.ietf.org/mailman/listinfo/nvo3 > > _______________________________________________ > nvo3 mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/nvo3 _______________________________________________ nvo3 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nvo3
