On Thu, Oct 29, 2015 at 5:19 PM, Lucy yong <lucy.y...@huawei.com> wrote: >> >> "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." >> >> Counter argument is that there are many GRE applications today that >> face load balancing issue. GRE-in-UDP encap addresses this issue. >> NVGRE disadvantage mentioned below is addressed by GRE-in-UDP. In >> other words, NVGRE can benefit from the gre-in-udp if it will stay long. > > [PG] What is the advantage of moving from NVGRE to GRE-in-UDP, as opposed to > moving to VXLAN? VXLAN has much better ecosystem support so one would > immediately benefit from that, no? Outside of network virtualization > GRE-in-UDP may have use cases and I have never questioned those as I am not > familiar with those. > [Lucy] VXLAN even did not allow encap of non-ethernet inner packet. -Lucy
And GRE has been around for many years, has seen considerable deployment and operational experience, and demonstrates a HW feasible mechanism of extensibility for a low level protocol. In the end, both NVGRE and VXLAN suffer from the same limitation in lack of extensibility (VXLAN more than GRE), but NVGRE over UDP seems reasonable to at least define if there is a deployed base of NVGRE that could benefit. Tom > >> >> Lucy >> >> -----Original Message----- >> From: Pankaj Garg [mailto:pank...@microsoft.com] >> Sent: Thursday, October 29, 2015 2:10 PM >> To: Dino Farinacci; Manish Kumar (manishkr) >> Cc: Tom Herbert; Lucy yong; nvo3@ietf.org >> Subject: RE: [nvo3] RFC 7637 on NVGRE: Network Virtualization Using >> Generic Routing Encapsulation >> >> 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:farina...@gmail.com] >> > Sent: Wednesday, October 28, 2015 10:11 AM >> > To: Manish Kumar (manishkr) <manis...@cisco.com> >> > Cc: Tom Herbert <t...@herbertland.com>; Lucy Yong >> > <lucy.y...@huawei.com>; Pankaj Garg <pank...@microsoft.com>; >> > nvo3@ietf.org >> > 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) >> > <manis...@cisco.com> 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" <t...@herbertland.com> wrote: >> > > >> > >> On Tue, Oct 6, 2015 at 9:31 AM, Lucy yong <lucy.y...@huawei.com> >> > 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:nvo3-boun...@ietf.org] On Behalf Of Manish >> > >>> Kumar >> > >>> (manishkr) >> > >>> Sent: Tuesday, October 06, 2015 1:02 AM >> > >>> To: Pankaj Garg; Tom Herbert >> > >>> Cc: nvo3@ietf.org >> > >>> 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 >> > >>> GRE+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" >> > >>> <nvo3-boun...@ietf.org on behalf of pank...@microsoft.com> >> 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:t...@herbertland.com] >> > >>>>> Sent: Thursday, October 1, 2015 12:38 PM >> > >>>>> To: Pankaj Garg <pank...@microsoft.com> >> > >>>>> Cc: nvo3@ietf.org >> > >>>>> 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 >> > >>>>> <pank...@microsoft.com> >> > >>>>> 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:ietf-announce-requ...@ietf.org?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:ietf-annou...@ietf.org> >> > >>>>>>> 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:ietf-announce-requ...@ietf.org?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- >> > >>>>> requ...@ietf.org?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.c >> > >>>>> om >> > >>>>> &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.c >> > >>>>> om >> > >>>>> &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 >> > >>>>>> nvo3@ietf.org >> > >>>>>> >> > >>>>> >> > >> 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 >> > >>>> nvo3@ietf.org >> > >>>> >> > 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 >> > >>> nvo3@ietf.org >> > >>> >> > 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 >> > > nvo3@ietf.org >> > > >> > >> 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 nvo3@ietf.org https://www.ietf.org/mailman/listinfo/nvo3
