> -----Original Message----- > From: Lucy yong [mailto:[email protected]] > Sent: Thursday, October 29, 2015 1:24 PM > To: Pankaj Garg <[email protected]>; Dino Farinacci > <[email protected]>; Manish Kumar (manishkr) <[email protected]> > Cc: Tom Herbert <[email protected]>; [email protected] > Subject: RE: [nvo3] RFC 7637 on NVGRE: Network Virtualization Using Generic > Routing Encapsulation > > "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 > > -----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 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
