+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
