Hi Joel, Yes, existing implementations use VNI 0 for BFD over VXLAN. Here are a couple of references: https://www.juniper.net/documentation/en_US/junos/topics/concept/sdn-ovsdb-bfd-nsx.html
https://www.cisco.com/c/en/us/products/collateral/switches/nexus-9000-series-switches/white-paper-c11-740091.html#_Toc18013665 I guess this document has been evolving and I have not kept up with it. The version I had reviewed and commented on originally allowed for VNI 0. The -04 version of the draft has this: https://tools.ietf.org/html/draft-ietf-bfd-vxlan-04#section-7 What version are you referring to? Thanks, Anoop On Mon, Oct 28, 2019 at 12:55 PM Joel M. Halpern <[email protected]> wrote: > You are saying that there are existing implementations using VNI 0 for > this? Given that previous versions of the spec explicitly disallowed > VNI 0, I am having trouble with your objecting that a spec for how to > run over VNI 0 breask existing implementations. > > Note that when there is a good technical reason, the IETF does change > Internet Drafts in ways that break early implementations. That is the > price of standardization. > > Yours, > Joel > > On 10/28/2019 2:30 PM, Anoop Ghanwani wrote: > > Hi Joel, > > > > Writing the spec in that way would make the current, inter-operable > > implementation of multiple vendors non-compliant with the spec. > > > > Thanks, > > Anoop > > > > On Mon, Oct 28, 2019 at 11:07 AM Joel M. Halpern <[email protected] > > <mailto:[email protected]>> wrote: > > > > I assumed this was only for the case where a tenant VNI was being > used. > > > > For the 0 VNI (which is what I prefer), always (MUST) use the > loopback > > address. There are no addresses assigned to the VTEP in that space. > > There is no IRB in that space. > > > > Yours, > > Joel > > > > On 10/28/2019 1:58 PM, Anoop Ghanwani wrote: > > > Joel, > > > > > > Are we going to qualify this by VNI? There's a bunch of > > implementations > > > out there that don't use a tenant IP or a loopback with VNI > 0--they > > > simply repeat the underlay IP in the inner IPDA. > > > > > > Thanks, > > > Anoop > > > > > > On Mon, Oct 28, 2019 at 10:46 AM Joel M. Halpern > > <[email protected] <mailto:[email protected]> > > > <mailto:[email protected] <mailto:[email protected]>>> wrote: > > > > > > I can live with saying that you SHOULD use loopback, and MAY > > instead > > > use > > > an IP address in the customer space known to be owned by the > VTEP > > > device > > > when such exists. > > > > > > Yours, > > > Joel > > > > > > On 10/28/2019 1:32 PM, Anoop Ghanwani wrote: > > > > Hi Joel, > > > > > > > > Perhaps we need to say use of an address owned by the > device > > > containing > > > > the VTEP. > > > > > > > > Or are you suggesting that the use of the loopback address > > space > > > is a MUST? > > > > > > > > Anoop > > > > > > > > On Mon, Oct 28, 2019 at 10:22 AM Joel M. Halpern > > > <[email protected] <mailto:[email protected]> > > <mailto:[email protected] <mailto:[email protected]>> > > > > <mailto:[email protected] <mailto:[email protected]> > > <mailto:[email protected] <mailto:[email protected]>>>> wrote: > > > > > > > > There is something I am missing in your assumption > > about IRB. > > > > > > > > As I understand VxLAN, the VTEP is under the control > > of the > > > operator. > > > > As such, it is a pure bridge. If you run IRB behind > > it, that > > > is fine. > > > > Yes, an operator may offer IRB. But as I understand > it, > > > conceptually, > > > > in terms of the VxLAN architecture the IRB is an entity > > > behind the > > > > VTEP, > > > > not part of the VTEP. > > > > > > > > Yours, > > > > Joel > > > > > > > > On 10/28/2019 12:23 PM, Anoop Ghanwani wrote: > > > > > Santosh, > > > > > > > > > > Does it have to be a MUST? What if I am running > > IRB and there > > > > are IP > > > > > addresses per VNI assigned to the VTEPs? Why can > the > > > operator not > > > > > choose to use those? > > > > > > > > > > Anoop > > > > > > > > > > On Mon, Oct 28, 2019 at 7:51 AM Santosh P K > > > > > <[email protected] > > <mailto:[email protected]> > > > <mailto:[email protected] > > <mailto:[email protected]>> > > > > <mailto:[email protected] > > <mailto:[email protected]> > > > <mailto:[email protected] > > <mailto:[email protected]>>> > > > > <mailto:[email protected] > > <mailto:[email protected]> > > > <mailto:[email protected] > > <mailto:[email protected]>> > > > > <mailto:[email protected] > > <mailto:[email protected]> > > > <mailto:[email protected] > > <mailto:[email protected]>>>>> wrote: > > > > > > > > > > Dinesh, Anoop et all, > > > > > Lets us know if this text works for 127/8 > > > address range? > > > > > > > > > > [proposed text for firewall] > > > > > > > > > > "As per section 4 inner destination IP address > > MUST be > > > set to > > > > 127/8 > > > > > address. There may be firewall configured on > > VTEP to > > > block 127/8 > > > > > address range if set as destination IP in inner > IP > > > header. It is > > > > > recommended to allow 127/8 range address through > > > firewall only if > > > > > 127/8 IP address is set as destination address > > in inner IP > > > > header." > > > > > > > > > > > > > > > In section 4 we are talking about using 127/8 > > and not > > > really > > > > giving > > > > > reason why. I think we should have text as RFC > 5884 > > > has mentioned > > > > > with below text. > > > > > > > > > > [From RFC 5884] > > > > > "The motivation for using the address range > > 127/8 is > > > the same as > > > > > specified in Section 2.1 of [RFC4379] > > > > > < > https://tools.ietf.org/html/rfc4379#section-2.1>. > > > This is an > > > > > exception to the behavior defined in [RFC1122 > > > > > <https://tools.ietf.org/html/rfc1122>]." > > > > > > > > > > > > > > > > > > > > Thanks > > > > > Santosh P K > > > > > > > > > > > > > > > > > > > > On Thu, Oct 24, 2019 at 1:24 AM Dinesh Dutt > > > <[email protected] <mailto:[email protected]> > > <mailto:[email protected] <mailto:[email protected]>> > > > > <mailto:[email protected] <mailto:[email protected]> > > <mailto:[email protected] <mailto:[email protected]>>> > > > > > <mailto:[email protected] > > <mailto:[email protected]> <mailto:[email protected] > > <mailto:[email protected]>> > > > <mailto:[email protected] <mailto:[email protected]> > > <mailto:[email protected] <mailto:[email protected]>>>>> wrote: > > > > > > > > > > Looks good to me Greg. I see that the text > > around > > > the use > > > > of the > > > > > inner IP address as also quite acceptable. > Will > > > you add any > > > > > words about the firewall? > > > > > > > > > > Dinesh > > > > > > > > > > On Wed, Oct 23, 2019 at 8:36 PM, Greg Mirsky > > > > > <[email protected] > > <mailto:[email protected]> > > > <mailto:[email protected] <mailto:[email protected]>> > > <mailto:[email protected] <mailto:[email protected]> > > > <mailto:[email protected] <mailto:[email protected] > >>> > > > > <mailto:[email protected] > > <mailto:[email protected]> <mailto:[email protected] > > <mailto:[email protected]>> > > > <mailto:[email protected] <mailto:[email protected]> > > <mailto:[email protected] <mailto:[email protected]>>>>> > wrote: > > > > >> Hi Dinesh, et al., > > > > >> please check the updated version that > > removed the > > > > reference to > > > > >> Hypervisor in the text and Figure 1. > > > > >> > > > > >> Regards, > > > > >> Greg > > > > >> > > > > >> On Wed, Oct 23, 2019 at 10:47 AM Santosh P > K > > > > >> <[email protected] > > <mailto:[email protected]> > > > <mailto:[email protected] > > <mailto:[email protected]>> > > > > <mailto:[email protected] > > <mailto:[email protected]> > > > <mailto:[email protected] > > <mailto:[email protected]>>> > > > > >> <mailto:[email protected] > > <mailto:[email protected]> > > > <mailto:[email protected] > > <mailto:[email protected]>> > > > > <mailto:[email protected] > > <mailto:[email protected]> > > > <mailto:[email protected] > > <mailto:[email protected]>>>>> wrote: > > > > >> > > > > >> Dinesh, > > > > >> Please see my inline comments > [SPK] > > > > >> > > > > >> > > > > >> - In section 3, there's a sentence > > that > > > is: "BFD > > > > >> packets intended for a Hypervisor > > VTEP MUST > > > > NOT..". I > > > > >> recommend getting rid of the word > > > "Hypervisor" ashe > > > > >> logic applies to any VTEP. > > > > >> > > > > >> [SPK] Thanks for comments. We will > > change this. > > > > >> > > > > >> - You already explained the > > precedence of > > > the use of > > > > >> 127/8 address in the inner header > in > > > MPLS. I have no > > > > >> specific comments in that area. I > have > > > only two > > > > >> questions: > > > > >> - Has anybody verified that the > > use of > > > 127/8 > > > > >> address (and the right MAC) works > with > > > existing > > > > >> implementations, including the > silicon > > > ones? If this > > > > >> doesn't work there, is it worth > > adding the > > > > possibilit > > > > >> y of another address, one that is > > owned > > > by the > > > > VTEP node? > > > > >> > > > > >> - Do we know if Firewalls stop > > such VXLAN > > > > packets? > > > > >> I ask this because VXLAN has an IP > > header > > > and I > > > > don't > > > > >> know if firewalls stop packets > > with 127/8 > > > in the > > > > inner > > > > >> header. If not, is it worth adding > a > > > sentence to say > > > > >> that firewalls allow such > > packets? The > > > use of a > > > > >> non-127/8 address may alleviate > > this case > > > as well. > > > > >> > > > > >> [SPK] I think we may need to add the > text > > > about firewall > > > > >> as some checks in firewall will be > > there if > > > they are not > > > > >> already using MPLS OAM which has inner > IP > > > header with > > > > >> 127/8 address range. > > > > >> > > > > >> > > > > >> The rest of the draft looks good > > to me, > > > > >> > > > > >> Dinesh > > > > >> > > > > >> On Wed, Oct 23, 2019 at 7:58 AM, > > Greg Mirsky > > > > >> <[email protected] > > <mailto:[email protected]> > > > <mailto:[email protected] <mailto:[email protected]>> > > > > <mailto:[email protected] > > <mailto:[email protected]> <mailto:[email protected] > > <mailto:[email protected]>>> > > > <mailto:[email protected] <mailto:[email protected]> > > <mailto:[email protected] <mailto:[email protected]>> > > > > <mailto:[email protected] > > <mailto:[email protected]> <mailto:[email protected] > > <mailto:[email protected]>>>>> > > > > >> wrote: > > > > >>> Hi Dinesh, > > > > >>> I greatly appreciate your > comments. > > > Please heave a > > > > >>> look at the attached copy of the > > working > > > > version and > > > > >>> its diff to -07 (latest in the > > datatracker). > > > > >>> > > > > >>> Regards, > > > > >>> Greg > > > > >>> > > > > >>> On Tue, Oct 22, 2019 at 9:52 PM > > Dinesh Dutt > > > > >>> <[email protected] > > <mailto:[email protected]> > > > <mailto:[email protected] <mailto:[email protected]>> > > <mailto:[email protected] <mailto:[email protected]> > > > <mailto:[email protected] <mailto:[email protected]>>> > > > > <mailto:[email protected] <mailto:[email protected]> > > <mailto:[email protected] <mailto:[email protected]>> > > > <mailto:[email protected] <mailto:[email protected]> > > <mailto:[email protected] <mailto:[email protected]>>>>> wrote: > > > > >>> > > > > >>> I have the same feeling as > Anoop. > > > Greg, can you > > > > >>> please point me to the latest > > draft > > > so that > > > > I can > > > > >>> quickly glance through it to > be > > > doubly sure, > > > > >>> > > > > >>> Dinesh > > > > >>> > > > > >>> On Wed, Oct 23, 2019 at 4:35 > AM, > > > Anoop Ghanwani > > > > >>> <[email protected] > > <mailto:[email protected]> > > > <mailto:[email protected] <mailto:[email protected]>> > > > > <mailto:[email protected] > > <mailto:[email protected]> <mailto:[email protected] > > <mailto:[email protected]>>> > > > > >>> <mailto:[email protected] > > <mailto:[email protected]> > > > <mailto:[email protected] <mailto:[email protected]>> > > > > <mailto:[email protected] > > <mailto:[email protected]> > > > <mailto:[email protected] > > <mailto:[email protected]>>>>> wrote: > > > > >>>> Greg, > > > > >>>> > > > > >>>> I think the draft is fine as > is. > > > > >>>> > > > > >>>> I discussion with Xiao Min > was > > > about #3 and I > > > > >>>> see that as unnecessary > until we > > > have a draft > > > > >>>> that explains why that is > > needed in the > > > > context > > > > >>>> of the NVO3 architecture. > > > > >>>> > > > > >>>> Anoop > > > > >>>> > > > > >>>> On Tue, Oct 22, 2019 at > 11:17 AM > > > Greg Mirsky > > > > >>>> <[email protected] > > <mailto:[email protected]> > > > <mailto:[email protected] <mailto:[email protected]>> > > > > <mailto:[email protected] > > <mailto:[email protected]> <mailto:[email protected] > > <mailto:[email protected]>>> > > > > >>>> > > <mailto:[email protected] <mailto:[email protected]> > > > <mailto:[email protected] <mailto:[email protected]>> > > > > <mailto:[email protected] > > <mailto:[email protected]> > > > <mailto:[email protected] > > <mailto:[email protected]>>>>> wrote: > > > > >>>> > > > > >>>> Hi Anoop, et al., > > > > >>>> I agree with your > > understanding > > > of what is > > > > >>>> being defined in the > current > > > version > > > > of the > > > > >>>> BFD over VxLAN > > specification. > > > But, as I > > > > >>>> understand, the WG is > > > discussing the scope > > > > >>>> before the WGLC is > closed. I > > > believe there > > > > >>>> are three options: > > > > >>>> > > > > >>>> 1. single BFD session > > between > > > two VTEPs > > > > >>>> 2. single BFD session > > per VNI > > > between > > > > two VTEPs > > > > >>>> 3. multiple BFD > > sessions per > > > VNI between > > > > >>>> two VTEPs > > > > >>>> > > > > >>>> The current text > > reflects #2. Is WG > > > > accepts > > > > >>>> this scope? If not, which > > > option WG would > > > > >>>> accept? > > > > >>>> > > > > >>>> Regards, > > > > >>>> Greg > > > > >>>> > > > > >>>> On Tue, Oct 22, 2019 at > > 2:09 PM > > > Anoop > > > > >>>> Ghanwani > > <[email protected] <mailto:[email protected]> > > > <mailto:[email protected] <mailto:[email protected]>> > > > > <mailto:[email protected] > > <mailto:[email protected]> <mailto:[email protected] > > <mailto:[email protected]>>> > > > > >>>> > > <mailto:[email protected] <mailto:[email protected]> > > > <mailto:[email protected] <mailto:[email protected]>> > > > > <mailto:[email protected] > > <mailto:[email protected]> > > > <mailto:[email protected] > > <mailto:[email protected]>>>>> wrote: > > > > >>>> > > > > >>>> I concur with Joel's > > assessment > > > > with the > > > > >>>> following > > clarifications. > > > > >>>> > > > > >>>> The current document > > is already > > > > capable > > > > >>>> of monitoring > > multiple VNIs > > > > between VTEPs. > > > > >>>> > > > > >>>> The issue under > > discussion > > > was how > > > > do we > > > > >>>> use BFD to monitor > > multiple > > > VAPs that > > > > >>>> use the same VNI > > between a > > > pair of > > > > >>>> VTEPs. The use case > for > > > this is not > > > > >>>> clear to me, as from > my > > > understanding, > > > > >>>> we cannot have a > > situation with > > > > multiple > > > > >>>> VAPs using the same > > > VNI--there is 1:1 > > > > >>>> mapping between VAP > > and VNI. > > > > >>>> > > > > >>>> Anoop > > > > >>>> > > > > >>>> On Tue, Oct 22, 2019 > > at 6:06 AM > > > > Joel M. > > > > >>>> Halpern > > > <[email protected] <mailto:[email protected]> > > <mailto:[email protected] <mailto:[email protected]>> > > > > <mailto:[email protected] > > <mailto:[email protected]> <mailto:[email protected] > > <mailto:[email protected]>>> > > > > >>>> > > <mailto:[email protected] <mailto:[email protected]> > > > <mailto:[email protected] <mailto:[email protected]>> > > > > <mailto:[email protected] > > <mailto:[email protected]> <mailto:[email protected] > > <mailto:[email protected]>>>>> > > > wrote: > > > > >>>> > > > > >>>> From what I can > > tell, > > > there > > > > are two > > > > >>>> separate > problems. > > > > >>>> The document we > > have is a > > > > VTEP-VTEP > > > > >>>> monitoring > > document. > > > There is no > > > > >>>> need for that > > document to > > > > handle the > > > > >>>> multiple VNI > case. > > > > >>>> If folks want a > > > protocol for doing > > > > >>>> BFD monitoring > > of things > > > > behind the > > > > >>>> VTEPs (multiple > > VNIs), > > > then do > > > > that > > > > >>>> as a separate > > > document. The > > > > >>>> encoding will be > > a tenant > > > > encoding, > > > > >>>> and thus > > sesparate from > > > what is > > > > >>>> defined in this > > document. > > > > >>>> > > > > >>>> Yours, > > > > >>>> Joel > > > > >>>> > > > > >>>> On 10/21/2019 > > 5:07 PM, > > > Jeffrey > > > > Haas > > > > >>>> wrote: > > > > >>>> > Santosh and > > others, > > > > >>>> > > > > > >>>> > On Thu, Oct > > 03, 2019 at > > > > 07:50:20PM > > > > >>>> +0530, Santosh P > > K wrote: > > > > >>>> >> Thanks > > for your > > > > explanation. > > > > >>>> This helps a > lot. I > > > would wait > > > > for more > > > > >>>> >> comments from > > others > > > to see if > > > > >>>> this what we > > need in this > > > > draft to be > > > > >>>> >> supported > > based on > > > that we can > > > > >>>> provide > appropriate > > > sections > > > > in the > > > > >>>> draft. > > > > >>>> > > > > > >>>> > The threads on > the > > > list have > > > > >>>> spidered to the > > point > > > where it is > > > > >>>> challenging > > > > >>>> > to follow what > the > > > current > > > > status > > > > >>>> of the draft is, > > or should > > > > be. :-) > > > > >>>> > > > > > >>>> > However, if > I've > > > followed things > > > > >>>> properly, the > > question > > > below is > > > > >>>> really the > > > > >>>> > hinge point on > > what our > > > > >>>> encapsulation > > for BFD > > > over vxlan > > > > >>>> should look like. > > > > >>>> > Correct? > > > > >>>> > > > > > >>>> > Essentially, > > do we or > > > do we not > > > > >>>> require the > > ability to > > > permit > > > > >>>> multiple BFD > > > > >>>> > sessions > between > > > distinct VAPs? > > > > >>>> > > > > > >>>> > If this is so, > > do we > > > have a > > > > sense > > > > >>>> as to how we > should > > > proceed? > > > > >>>> > > > > > >>>> > -- Jeff > > > > >>>> > > > > > >>>> > [context > preserved > > > below...] > > > > >>>> > > > > > >>>> >> Santosh P K > > > > >>>> >> > > > > >>>> >> On Wed, Sep > > 25, 2019 > > > at 8:10 AM > > > > >>>> > > <[email protected] <mailto:[email protected]> > > > <mailto:[email protected] <mailto:[email protected]>> > > > > <mailto:[email protected] > > <mailto:[email protected]> <mailto:[email protected] > > <mailto:[email protected]>>> > > > > >>>> > > > <mailto:[email protected] <mailto:[email protected]> > > <mailto:[email protected] <mailto:[email protected]>> > > > > <mailto:[email protected] > > <mailto:[email protected]> <mailto:[email protected] > > <mailto:[email protected]>>>>> > > > wrote: > > > > >>>> >> > > > > >>>> >>> Hi Santosh, > > > > >>>> >>> > > > > >>>> >>> > > > > >>>> >>> With regard > > to the > > > question > > > > >>>> whether we > > should allow > > > > multiple BFD > > > > >>>> sessions > > > > >>>> >>> for the same > > VNI or > > > not, > > > > IMHO we > > > > >>>> should allow it, > > more > > > > explanation as > > > > >>>> >>> follows. > > > > >>>> >>> > > > > >>>> >>> Below is a > > figure > > > derived from > > > > >>>> figure 2 of > > RFC8014 (An > > > > Architecture for > > > > >>>> >>> Data-Center > > Network > > > > >>>> Virtualization > > over Layer 3 > > > > (NVO3)). > > > > >>>> >>> > > > > >>>> >>> > > | > > > > >>>> Data Center > Network > > > (IP) | > > > > >>>> >>> > > | > > > > >>>> > > > | > > > > >>>> >>> > > > > >>>> > > > > +-----------------------------------------+ > > > > >>>> >>> > > > | > > > > >>>> > > | > > > > >>>> >>> > > > | > > > > >>>> Tunnel Overlay > > | > > > > >>>> >>> > > > > >>>> > > +------------+---------+ > > > > >>>> > > +---------+------------+ > > > > >>>> >>> > | > > > > >>>> > > +----------+-------+ | > > > | > > > > >>>> > > +-------+----------+ | > > > > >>>> >>> > > | | > > > Overlay > > > > >>>> Module | | > > | | > > > Overlay > > > > >>>> Module | | > > > > >>>> >>> > | > > > > >>>> > > +---------+--------+ | > > > | > > > > >>>> > > +---------+--------+ | > > > > >>>> >>> > | > > > | > > > > >>>> | | > > | > > > > | > > > > >>>> >>> NVE1 > | > > > | > > > > >>>> | | > > | > > > > | > > > > >>>> NVE2 > > > > >>>> >>> > | > > > > >>>> > > +--------+-------+ | > > > | > > > > >>>> > > +--------+-------+ | > > > > >>>> >>> > > | |VNI1 > > > > VNI2 VNI1 > > > > >>>> | | | | > VNI1 > > > VNI2 VNI1 > > > > | | > > > > >>>> >>> > | > > > > >>>> > > +-+-----+----+---+ | > > > | > > > > >>>> > > +-+-----+-----+--+ | > > > > >>>> >>> > > |VAP1| > > > VAP2| | > > > > >>>> VAP3 | > > |VAP1| VAP2| > > > > | VAP3| > > > > >>>> >>> > > > > >>>> > > +----+-----+----+------+ > > > > >>>> > > +----+-----+-----+-----+ > > > > >>>> >>> > > > | | > > > > | > > > > >>>> > | > > > | | > > > > >>>> >>> > > > | | > > > > | > > > > >>>> > | > > > | | > > > > >>>> >>> > > > | | > > > > | > > > > >>>> > | > > > | | > > > > >>>> >>> > > > > >>>> > > > > > > -------+-----+----+-------------------+-----+-----+------- > > > > >>>> >>> > > > | | > > > > | > > > > >>>> Tenant > | > > > | | > > > > >>>> >>> > > TSI1 | > > > TSI2| | > > > > >>>> TSI3 > > TSI1| TSI2| > > > > |TSI3 > > > > >>>> >>> > > > +---+ +---+ > > > > >>>> +---+ > > +---+ > > > +---+ > > > > +---+ > > > > >>>> >>> > > > |TS1| |TS2| > > > > >>>> |TS3| > > |TS4| > > > |TS5| > > > > |TS6| > > > > >>>> >>> > > > +---+ +---+ > > > > >>>> +---+ > > +---+ > > > +---+ > > > > +---+ > > > > >>>> >>> > > > > >>>> >>> To my > > > understanding, the BFD > > > > >>>> sessions between > > NVE1 > > > and NVE2 are > > > > >>>> actually > > > > >>>> >>> initiated and > > > terminated > > > > at VAP > > > > >>>> of NVE. > > > > >>>> >>> > > > > >>>> >>> If the > > network operator > > > > want to > > > > >>>> set up one BFD > > session > > > between > > > > VAP1 of > > > > >>>> >>> NVE1 and > VAP1of > > > NVE2, at the > > > > >>>> same time > > another BFD > > > session > > > > >>>> between VAP3 of > > > > >>>> >>> NVE1 and > > VAP3 of NVE2, > > > > although > > > > >>>> the two BFD > sessions > > > are for > > > > the same > > > > >>>> >>> VNI1, I > > believe it's > > > > reasonable, > > > > >>>> so that's why I > > think we > > > > should allow it > > > > >>>> > > > > >>>> > > > > _______________________________________________ > > > > >>>> nvo3 mailing list > > > > >>>> [email protected] <mailto:[email protected]> > > <mailto:[email protected] <mailto:[email protected]>> > > > <mailto:[email protected] <mailto:[email protected]> > > <mailto:[email protected] <mailto:[email protected]>>> <mailto:[email protected] > > <mailto:[email protected]> > > > <mailto:[email protected] <mailto:[email protected]>> > > > > <mailto:[email protected] <mailto:[email protected]> > > <mailto:[email protected] <mailto:[email protected]>>>> > > > > >>>> https://www.ietf.org/mailman/listinfo/nvo3 > > > > >>>> > > > > > > > > > > >
