Inline > -----Original Message----- > From: Tom Herbert [mailto:[email protected]] > Sent: Thursday, October 29, 2015 6:07 PM > To: Lucy yong <[email protected]> > Cc: Pankaj Garg <[email protected]>; Dino Farinacci > <[email protected]>; Manish Kumar (manishkr) <[email protected]>; > [email protected] > Subject: Re: [nvo3] RFC 7637 on NVGRE: Network Virtualization Using > Generic Routing Encapsulation > > On Thu, Oct 29, 2015 at 5:19 PM, Lucy yong <[email protected]> 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. > [PG] From my NVGRE experience in large datacenters and enterprise market, I am not sure of any benefits from GRE-in-UDP. If we need better entropy, we would go with VXLAN and if we need a future encap, we would go with either VXLAN-GPE+NSH or Geneve. There is no point in picking GRE-in-UDP and then waiting for NIC and switch ecosystem around it to turn up, only to then realize that it doesn't offer required extensibility. So not really, I don't see value in GRE-in-UDP for network virtualization.
> Tom > > > > >> > >> Lucy > >> > >> -----Original Message----- > >> From: Pankaj Garg [mailto:[email protected]] > >> Sent: Thursday, October 29, 2015 2:10 PM > >> To: Dino Farinacci; Manish Kumar (manishkr) > >> Cc: Tom Herbert; Lucy yong; [email protected] > >> 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:[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 > >> > >>> 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" > >> > >>> <[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. > >> > >>>>> 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 > >> > >>>>>> [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%2fww > >> > w > >> > >>> > >> > > >> > .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
