But not talking about one assures there will never be one. Dino
> On Oct 30, 2015, at 11:07 AM, Fedyk, Don <[email protected]> wrote: > > +1 Although the dream to have "One Encap to Unite them all" may not be > achievable within this Realm :-) > > Don > >> -----Original Message----- >> From: nvo3 [mailto:[email protected]] On Behalf Of Dino Farinacci >> Sent: Friday, October 30, 2015 3:05 AM >> To: Pankaj Garg >> Cc: Tom Herbert; [email protected]; Manish Kumar (manishkr); Lucy Yong >> Subject: Re: [nvo3] RFC 7637 on NVGRE: Network Virtualization Using >> Generic Routing Encapsulation >> >> Pankaj, you have shown precisely the point I have been hounding this >> mailing list. There are just way too many combinations of encapsulation >> solutions with little or no *real* incremental benefit. >> >> Enough with the data-planes. Once they are implemented and people stop >> the urge to keep changing something so basic, we can get on with what really >> matters in building data center overlay networks. That is the control-plane. >> That will require a lot more thought, experimentation, experience, and >> deployment. >> >> Dino >> >>> On Oct 29, 2015, at 12:10 PM, Pankaj Garg <[email protected]> >> wrote: >>> >>> NVGRE and VXLAN >>> NVGRE is widely used in datacenter networks and there is wide hardware >> support available for it (both in terms of NICs and Switches). The key >> advantage VXLAN has over NVGRE is that it allows larger entropy and doesn't >> require any change in middle boxes to calculate hash and do ECMP. Most >> network virtualization solutions are supporting both of these today. Even >> though in long term, things may settle on a single encap format, that is not >> practically possible in the short term. In my opinion, both NVGRE and VXLAN >> are here to stay for quite a while given the investment and usage of these >> technologies. Could we have settled on just one? Yes, we could have, but I >> am not sure either of these would be the one (read further). >>> >>> Shortcomings: >>> Around maybe 2-3 years back, we identified that both of these encap have >> one severe limitation (well VXLAN had two) i.e. ability (or lack thereof) to >> extend them. In addition, VXLAN even did not allow encap of non-ethernet >> inner packet. The main problem for network virtualization, however was >> extensibility. There are a lot of use cases where such extensibility can add >> significant advantage to encapsulation. It seems other people were thinking >> of the same at the same time. This resulted in 3 encap options for "future" >> encap. VXLAN-GPE + NSH, Geneve and GUE. >>> >>> VXLAN-GPE + NSH, Geneve and GUE >>> Out of the three, I personally prefer the first two, partly because I have >> been deeply involved in the extensibility design of these but more >> importantly I feel they offer advantage over GUE. VXLAN-GPE + NSH seems >> to be the most flexible of the present options as it allows extensibility in >> hardware and software friendly manner. When we think about extensibility, >> there is always struggle between hardware and software. While software >> can evolve much faster, hardware cannot and we have to design something >> that does not restrict software to innovate but eventually let hardware catch >> up and use those innovations as well. >>> >>> A key limitation that prevents software from using extensions is NIC >> offloads. Both Geneve and VXLAN-GPE+NSH allows extension of these >> protocols without breaking NIC offloads. This is a huge advantage given that >> in a network virtualization environment, typically most endpoints are >> software. This allows software vendors to do faster innovation without >> worrying about the whole ecosystem aspects of it. Both Geneve and NSH >> provide this extensibility using TLV format and they both use exact same TLV >> format (by choice). >>> >>> However, not all endpoints can be software and eventually for some of >> those innovations (such as security or OAM etc.) it would be required (or >> useful) to have hardware participate. The key limitation of TLV format (that >> I >> have heard of) is that it is harder to parse in hardware at line rate. This >> is >> where I think NSH has an advantage. NSH allows us to define new MDType >> so that we can create fixed format headers (that are easier for hardware to >> parse than TLV). This allows faster innovation in software (using vendor >> specific TLV) and later on they can be converted into hardware friendly >> format using MDType. >>> >>> GRE-in-UDP >>> I am not really sure where this fits in for network virtualization. It does >>> not >> have required ecosystem support to be a viable option and does not solve >> the need for future encapsulations. >>> >>> PS: I really hope that we (nvo3 group) picks up one option out of the three >> "future" encap as the standard option to avoid unnecessary fragmentation >> and engineering overhead. >>> >>> Thanks >>> Pankaj >>> >>> >>> >>>> -----Original Message----- >>>> From: Dino Farinacci [mailto:[email protected]] >>>> Sent: Wednesday, October 28, 2015 10:11 AM >>>> To: Manish Kumar (manishkr) <[email protected]> >>>> Cc: Tom Herbert <[email protected]>; Lucy Yong >>>> <[email protected]>; Pankaj Garg <[email protected]>; >>>> [email protected] >>>> Subject: Re: [nvo3] RFC 7637 on NVGRE: Network Virtualization Using >>>> Generic Routing Encapsulation >>>> >>>> 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 >>>>>>> GRE+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%2ft >>>>>>>>> ools >>>>>>>>> .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&da >>>>>>>>>>> ta >>>>>>>>>>> =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. >>>>>>>>>>> or >>>>>>>>>>> g& >>>>>>>>>>> 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. >>>>>>>>>>> or >>>>>>>>>>> g& >>>>>>>>>>> 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%2 >>>>>>>>>>> fm >>>>>>>>>>> ail >>>>>>>>>>> archive.ietf.org%2farch%2fmsg%2fietf- >>>>>>>>> &data=01%7c01%7cpankajg%40micros >>>>>>>>>>> >>>>>>>>> >>>> >> oft.com%7cb4e8bc27b4104053ac7d08d2ca97cf9d%7c72f988bf86f141af91ab2 >>>>>>>>> d >>>>>>>>> 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. >>>>>>>>>>> or >>>>>>>>>>> g& >>>>>>>>>>> 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. >>>>>>>>>>> co >>>>>>>>>>> m& >>>>>>>>>>> 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%2f >>>>>>>>> mai >>>>>>>>>>> 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%2f >>>>>>>>> www >>>>>>>>>>> .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%2f >>>>>>>>> www >>>>>>>>>>> .ietf.org%2fmailman%2foptions%2fietf- >>>>>>>>> announce&data=01%7c01%7cpankajg% >>>>>>>>>>> >>>>>>>>> >>>> >> 40microsoft.com%7cb4e8bc27b4104053ac7d08d2ca97cf9d%7c72f988bf86f14 >>>>>>>>> 1 >>>>>>>>> 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&da >>>>>>>>>>> ta >>>>>>>>>>> =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 >>>>>>>>> &d >>>>>>>>> ata >>>>>>>>> =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 >>>>>>>>> &d >>>>>>>>> ata >>>>>>>>> =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%7c72f988bf86f141af91ab2d7cd011d >>>>>>>>> b >>>>>>>>> >>>> >> 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%7c72f988bf86f141af91ab2d7cd011db4 >>>>>>>>> 7 >>>> %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=lp >>>>>>>>> Y AfNFCgD0wGuCjHWjgvf9iJkv2Dx0EywPx6ZJL37g%3d >>>>>>>>>>> >>>>>>>>>>> >>>> https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2 >>>>>>>>>>> fm >>>>>>>>>>> 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%40micro >>>>>>>>> s >>>>>>>>> oft >>>>>>>>>> >>>>>>>>> >>>> >> .com%7cb4e8bc27b4104053ac7d08d2ca97cf9d%7c72f988bf86f141af91ab2d7c >>>>>>>>> d011 >>>>>>>>>> >>>>>>>>> >>>> >> db47%7c1&sdata=XquLeptMFXZ4doDoOE8cFJuIuPR5zWDWXK49awfESBg%3 >>>>>>>>> d >>>>>>>> _______________________________________________ >>>>>>>> nvo3 mailing list >>>>>>>> [email protected] >>>>>>>> >>>> https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fww >>>>>>>> >>>> >> w.ietf.org%2fmailman%2flistinfo%2fnvo3&data=01%7c01%7cpankajg%40mic >>>>>>>> >>>> >> rosoft.com%7cc7388153bdda4c0c55e808d2dfbab94b%7c72f988bf86f141af91a >>>>>>>> >>>> >> b2d7cd011db47%7c1&sdata=e9lIOaIf7f%2f0C4%2baNkbnjdXqptoSerbw%2fy >>>> Vxl >>>>>>>> Q%2bULD4%3d >>>>>>> >>>>>>> _______________________________________________ >>>>>>> nvo3 mailing list >>>>>>> [email protected] >>>>>>> >>>> >> https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fwww >>>>>>> >>>> >> .ietf.org%2fmailman%2flistinfo%2fnvo3&data=01%7c01%7cpankajg%40micro >>>>>>> >>>> >> soft.com%7cc7388153bdda4c0c55e808d2dfbab94b%7c72f988bf86f141af91ab >>>> 2d >>>>>>> >>>> >> 7cd011db47%7c1&sdata=e9lIOaIf7f%2f0C4%2baNkbnjdXqptoSerbw%2fyVxl >>>> Q%2b >>>>>>> ULD4%3d >>>>> >>>>> _______________________________________________ >>>>> 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%7cc7388153bdda4c0c55e808d2dfbab94b%7c72f988bf86f141af91ab2d7c >>>> d011 >>>>> >>>> >> db47%7c1&sdata=e9lIOaIf7f%2f0C4%2baNkbnjdXqptoSerbw%2fyVxlQ%2bU >>>> LD4%3d >>> >> >> _______________________________________________ >> nvo3 mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/nvo3 _______________________________________________ nvo3 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nvo3
