Maria, Keep in mind the DC environment has and interacts with a lot of legacy L2 environment that does not have a control plane: i.e. VLANs, VPLS, IEEE new protocols or proprietary. So there is a lot of flooded traffic coming towards the new Cloud environment (NVO3/VPN4DC based). As you probably know it takes a really long time to get rid of the legacy stuff, unfortunately. :(
Even for the new cloud environment I always wondered whether a cloud provider can actually impose/guarantee that the Application running in the user space does not send any flooded traffic (Broadcast/multicast)? This is on top of the ARP broadcast that we can eliminate using EVPN/SDN controllers. Florin > -----Original Message----- > From: [email protected] [mailto:[email protected]] On Behalf Of > Henderickx, Wim (Wim) > Sent: Friday, September 28, 2012 11:19 AM > To: NAPIERALA, MARIA H; Luyuan Fang (lufang); Bitar, Nabil N; Fedyk, > Donald (Don); [email protected] > Subject: Re: [nvo3] draft-drake-nvo3-evpn-control-plane > > Maria, there is since a customer/enterprise will demand a L2 > communication or L3 communication for certain Apps/VMs. As such the > cloud provider needs to accommodate it. You cannot transport a > broadcast packet via L3, neither can you route a packet in the same > subnet as you would change the TTL and if it is 1 it will be dropped. > As such they care since apps break. > > EVPN allows to provide a L2/L3 communication. > L3VPN does not since you do not transport the MAC address. > You could also solve this by doing both EVPN and L3VPN. > > These are the options you have so far. > WIm > > -----Original Message----- > From: NAPIERALA, MARIA H [mailto:[email protected]] > Sent: vrijdag 28 september 2012 20:12 > To: Henderickx, Wim (Wim); Luyuan Fang (lufang); Bitar, Nabil N; Fedyk, > Donald (Don); [email protected] > Subject: RE: [nvo3] draft-drake-nvo3-evpn-control-plane > > Wim, > > > Maria, there are applications in enterprise that require L2 > > communication between hosts, same IP subnet, etc. As such the > solution > > needs to accommodate this. Don't get me wrong I also want to make it > > as simple as possible, but this is what people are looking to do and > I > > believe we cannot ignore it. Enterprise customers will demand to > > enable this in the Public Cloud. > > Why would a customer care how a *Public* Cloud delivers IP traffic > between VMs/appliances, as long as the traffic is delivered > successfully? If this is just IP-subnet issue then this no issue since > the traffic is handled the same way by a VM whether one implements EVPN > or L3VPN. There is no visible difference. > > Maria > > > > > -----Original Message----- > > From: NAPIERALA, MARIA H [mailto:[email protected]] > > Sent: vrijdag 28 september 2012 18:54 > > To: Henderickx, Wim (Wim); Luyuan Fang (lufang); Bitar, Nabil N; > > Fedyk, Donald (Don); [email protected] > > Subject: RE: [nvo3] draft-drake-nvo3-evpn-control-plane > > > > Since layer 3 can address both intra-subnet and inter-subnet IP > > communication by a uniform forwarding (i.e., there is no difference > in > > forwarding between those two), the question is why to introduce a > > complication of mixing L2 and L3 forwarding in the *same* solution. > > As Kireeti wrote, with which I agree: "mixing L2 and L3 for a tenant > > (either as VNs or between DC and WAN) is fraught with complications > > (basically, IRB in a virtualized setting)." > > IRB was always intended to be used to solve specific and narrowly > > defined problems, not to build the entire network on IRB. > > > > Maria > > > > > > > -----Original Message----- > > > From: Henderickx, Wim (Wim) [mailto:wim.henderickx@alcatel- > > lucent.com] > > > Sent: Friday, September 28, 2012 12:58 AM > > > To: Luyuan Fang (lufang); Bitar, Nabil N; NAPIERALA, MARIA H; > Fedyk, > > > Donald (Don); [email protected] > > > Subject: RE: [nvo3] draft-drake-nvo3-evpn-control-plane > > > > > > Luyuan, mixing L2 and L3 is very common for IAAS. > > > People will have different groups of networking: > > > - L2 domains connected via L3 > > > - Something like this: > > > > > > VM11 ---+ +-- VM21 > > > | | > > > L2 CUG1 + -- L3 -- + L2 CUG2 > > > | | > > > VM12 ---+ +-- VM22 > > > > > > L2 CUG1 is a web tier > > > And L3 CUG2 is the business tier > > > > > > A very common use case which I have seen so far. > > > > > > -----Original Message----- > > > From: Luyuan Fang (lufang) [mailto:[email protected]] > > > Sent: vrijdag 28 september 2012 0:26 > > > To: Bitar, Nabil N; Henderickx, Wim (Wim); NAPIERALA, MARIA H; > > > Fedyk, Donald (Don); [email protected] > > > Subject: RE: [nvo3] draft-drake-nvo3-evpn-control-plane > > > > > > Nabil, > > > > > > We talked this earlier this week while your mail was sent but > > "napping" > > > in the system somewhere. :-). > > > > > > I did not mean that interworking a Layer 2 service having access to > > an > > > IP routing service, that is done today... > > > I meant to say, e.g., today we don't establish a single VPN with > > > some sites being l3vpn and others being vpls. > > > > > > I think we are generally in agreement. > > > > > > - both L2 and L3 support are needed > > > - both L2 and L3 can be supported in the same network and on the > > > same device (it is done today) > > > - What we need to be more careful is wither we should mix different > > > sites with l2 and l3 into the same vpn. It could create > complication > > > than its worth. Study/work need to be done if reality really calls > > for > > > the case. > > > > > > Luyuan > > > > > > > -----Original Message----- > > > > From: Bitar, Nabil N [mailto:[email protected]] > > > > Sent: Thursday, September 27, 2012 7:58 AM > > > > To: Luyuan Fang (lufang); Henderickx, Wim (Wim); Bitar, Nabil N; > > > > NAPIERALA, MARIA H; Fedyk, Donald (Don); [email protected] > > > > Subject: Re: [nvo3] draft-drake-nvo3-evpn-control-plane > > > > > > > > Do you mean by interworking a Layer2 service having access to an > > > > IP routing service as commonly done today? I wouldn't compare > > > > that to FR/ATM interworking. > > > > > > > > There are applications that require operation over Ethernet and > > have > > > > MAC > > > > awareness. There are also dependencies on the other end of the > > > > communication operations and capabilities. > > > > > > > > There are other applications, legacy or not, that are not IP > aware > > > and > > > > will require Layer2 connectivity. Storage, depending on the > > > > storage networking technology, is an example and I think there > was > > > > an email from Dave Black about that some time back. There are > > > > probably other > > apps, > > > > proprietary or commercial that rely on Ethernet only. I am > raising > > > that > > > > not because of E-VPN or not but the general notion being debated > > > > by some that we need to take a hard-line saying only IP service > > > > needs to be supported, as much as I would like that to be the > > > > case. > > > > > > > > While one can argue that if an application is not IP-based, it > can > > be > > > > migrated to one that is or you can tunnel to the application > > > depending > > > > on > > > > the application or ..,, it seems to me it is a hardline to say > > > > that > > > an > > > > L2 > > > > service is not > > > > needed in the DC at the functional level of NVE and gateways as > it > > > can > > > > be > > > > disruptive in certain cases or create hurdles. > > > > > > > > The net is that the DC fabric (underlay) can be IP only although > > for > > > > some > > > > Ethernet can still be a choice. The service overlaid on that can > > > > be > > > IP > > > > or > > > > bridged Ethernet and that is a choice for people to do based on > > > several > > > > constraints including applications they want to support. Today > > > Ethernet > > > > and IP services are realities and need to be addressed. IP will > be > > > > always needed, no doubt. If one can live with IP only they would > > > > have the tool, if they need a mix of IP of Ethernet bridge > > > > services, they should > > > also > > > > have the tools. Id people are only interested in IP services, > they > > > can > > > > only work on that, and if people have the need for the mix or > want > > to > > > > work > > > > on the mix or or one or the other, they can also do that. > > > > > > > > Thanks, > > > > Nabil > > > > > > > > > > > > > > > > On 9/24/12 5:40 PM, "Luyuan Fang (lufang)" <[email protected]> > > wrote: > > > > > > > > >Wim, > > > > > > > > > >Agree. > > > > >I tried not to go into the mix case :-). Need to better > > > > >understand > > > the > > > > >real needs, its implication, and various (prefer simplified) > > > potential > > > > >solutions. > > > > > > > > > >Mix could mean people deploy L2 and L3 separately in the shared > > > > >infrastructure, or it could mean inter-working if you are > > > > >thinking > > > > some > > > > >sites are L2, some are L3 within one VPN, or inter-connecting LX > > DC > > > > with > > > > >LY VPN network... > > > > > > > > > >Technically, these can all be done. Practically, we need to ask > > > > operators > > > > >what are the objectives, how much complication they are willing > > > > >to > > > get > > > > >into, and the benefits, trade-offs. > > > > > > > > > >Do we see a lot of mixed case for L2/L3 VPNs in today's network > > VPN > > > > >deployment after all these years? If not so, why do DC operators > > > want > > > > to > > > > >make it more complex? > > > > > > > > > >In my past experience on the operator side, inter-working (e.g. > > > > FR/ATM, > > > > >ATM/Ethernet, MPLS/Ethernet...) were good on papers, but always > > too > > > > >complicated for operation, never that successful. > > > > > > > > > >I can see sometimes we are dealing with some existing and the > new > > > > >environment, the mix may or may not be avoidable. > > > > >But I want to see if many operators really want to mix things, > > > > >and > > > to > > > > >what level. > > > > > > > > > >Thanks, > > > > >Luyuan > > > > > > > > > >> -----Original Message----- > > > > >> From: Henderickx, Wim (Wim) [mailto:wim.henderickx@alcatel- > > > > lucent.com] > > > > >> Sent: Monday, September 24, 2012 11:09 PM > > > > >> To: Luyuan Fang (lufang); Bitar, Nabil N; NAPIERALA, MARIA H; > > > Fedyk, > > > > >> Donald (Don); [email protected] > > > > >> Subject: RE: [nvo3] draft-drake-nvo3-evpn-control-plane > > > > >> > > > > >> Luyuan, > > > > >> > > > > >> While I understand there are customers for L3, there are > > > > >> equally customers for L2 as you said, but also for a mix when > > application > > > > >> tiering is required. > > > > >> We need to address all 3 use cases. > > > > >> > > > > >> Cheers, > > > > >> Wim > > > > >> > > > > >> -----Original Message----- > > > > >> From: [email protected] [mailto:[email protected]] On > > > Behalf > > > > Of > > > > >> Luyuan Fang (lufang) > > > > >> Sent: maandag 24 september 2012 22:57 > > > > >> To: Bitar, Nabil N; NAPIERALA, MARIA H; Fedyk, Donald (Don); > > > > >> [email protected] > > > > >> Subject: Re: [nvo3] draft-drake-nvo3-evpn-control-plane > > > > >> > > > > >> Nabil, > > > > >> > > > > >> See in-line. > > > > >> > > > > >> > -----Original Message----- > > > > >> > From: Bitar, Nabil N [mailto:[email protected]] > > > > >> > Sent: Monday, September 24, 2012 9:45 PM > > > > >> > To: Luyuan Fang (lufang); NAPIERALA, MARIA H; Fedyk, Donald > > > (Don); > > > > >> > [email protected] > > > > >> > Subject: Re: [nvo3] draft-drake-nvo3-evpn-control-plane > > > > >> > > > > > >> > Luyuan, > > > > >> > Well put. > > > > >> > > > > >> Thx. > > > > >> > > > > >> I am presuming that you are also saying that both need to > > > > >> > co-exist (E-VPN and RFC4364) and get interconnected in > > > > environments > > > > >> > that > > > > >> > need that. > > > > >> > > > > >> Yes. Interconnected with the matching environment is a good > > > > >> description. > > > > >> > > > > >> Personally, I see L3 (in general sense) is becoming the trend > > for > > > > >> scaling, the move from L2 to L3 happened already in some > > > > >> largest > > > DCs > > > > >> deployed today. > > > > >> On the other hand, there are networks must support certain > > legacy > > > L2 > > > > >> services, and some DC operators may be more familiar with L2 > > > > >> environment so prefer l2 solutions, or there is need to inter- > > > > connect > > > > >> to the matching environment as you mentioned. Besides, not > > > everyone > > > > >> needs the scale like FB, MS, Amazon... > > > > >> So both L2 and L3 need to be supported. > > > > >> > > > > >> >Is that so? Interconnection may happen in different ways to > > > > >> >allow bridging when traffic is among endpoints on on same > > subnet > > > > and > > > > >> > routing when crossing subnets in the same vpn. > > > > >> > > > > >> Yes, particularly true as with today's typical l2 solutions. > > > > >> In all L3 case, there would be no bridging. > > > > >> > > > > >> > > > > > >> > Thanks, > > > > >> > Nabil > > > > >> > > > > > >> Thanks, > > > > >> Luyuan > > > > >> > > > > >> > > > > >> > On 9/24/12 3:12 PM, "Luyuan Fang (lufang)" > <[email protected]> > > > > wrote: > > > > >> > > > > > >> > >Don, > > > > >> > > > > > > >> > >I'm ok with what you said people need both L2 and L3 > > > > capabilities... > > > > >> > but > > > > >> > >have trouble with > > > > >> > >> IP VPNs and EVPNs are well suited as one solution for > > > extending > > > > >> the > > > > >> > L2 > > > > >> > >>and L3 connectivity for large and physically disperse data > > > > centers. > > > > >> > > > > > > >> > >What do you mean by "one solution"? They are two solutions > > > > >> > >to > > > me. > > > > I > > > > >> > want > > > > >> > >to make sure that we are not redefining BGP L3VPN (RFC > 4364, > > > aka > > > > >> > 2547). > > > > >> > > > > > > >> > >Though E-VPN is leveraging many fundamental building blocks > > of > > > > BGP > > > > >> L3 > > > > >> > >VPN, it is essentially developed for people who must > support > > > > certain > > > > >> > >existing L2 services and prefer L2 solutions with E-VPN. If > > one > > > > >> wants > > > > >> > to > > > > >> > >have BGP L3 VPN solution only in the DC and inter- > connecting > > DC > > > > to > > > > >> the > > > > >> > >existing network l3vpn, or inter-connecting DCs, they can > > > > >> > >use > > > BGP > > > > >> > L3VPN > > > > >> > >as its original form (if practical), or extend it to make > > more > > > DC > > > > >> > >friendly (e.g. draft-marques-l3vpn-end-system, as many > > pointed > > > to > > > > in > > > > >> > >their mails). > > > > >> > > > > > > >> > >L3 VPN has huge deployment base, mostly in SP network space > > > over > > > > the > > > > >> > last > > > > >> > >14 years or so, and some recent development in DC space. I > > > don't > > > > >> > assume > > > > >> > >you are implying to ask operators to change their L3VPN > from > > > 4364 > > > > >> > format > > > > >> > >into this so called "IP VPNs and EVPNs... as one solution", > > or > > > > ask > > > > >> > them > > > > >> > >to inter-work between existing L3VPN with this new "IP VPN > > and > > > > EVPN > > > > >> > ... > > > > >> > >as one solution" in DC, which would introduce complexity > for > > > > nothing > > > > >> > if > > > > >> > >they simply need the L3VPN from network to DC. I hope this > > > > >> > >is > > > not > > > > >> the > > > > >> > >case. > > > > >> > > > > > > >> > >My point is, leave BGP L3VPN and EVPN as two separate > > solutions > > > > as > > > > >> > they > > > > >> > >are. > > > > >> > > > > > > >> > >Thanks, > > > > >> > >Luyuan > > > > >> > > > > > > >> > >> -----Original Message----- > > > > >> > >> From: [email protected] [mailto:nvo3- > [email protected]] > > On > > > > >> Behalf > > > > >> > Of > > > > >> > >> NAPIERALA, MARIA H > > > > >> > >> Sent: Monday, September 24, 2012 8:01 PM > > > > >> > >> To: Fedyk, Donald (Don); [email protected] > > > > >> > >> Subject: Re: [nvo3] draft-drake-nvo3-evpn-control-plane > > > > >> > >> > > > > >> > >> Don, > > > > >> > >> > > > > >> > >> > The complexity comes from the date center environment, > > but > > > > >> > >> > is seems better to provide both L2 and L3 capabilities > > and > > > > let > > > > >> > >> > deployments choose the mix. > > > > >> > >> > > > > >> > >> I am afraid that once you mix those capabilities in one > > > > >> > implementation > > > > >> > >> there is no choice. As a result, inter-subnet IP > > > > >> > >> forwarding > > > > which > > > > >> is > > > > >> > >> trivial in L3VPN (as is intra-subnet forwarding, btw) > > becomes > > > > all > > > > >> of > > > > >> > a > > > > >> > >> sudden complex under such construct. > > > > >> > >> > > > > >> > >> Maria > > > > >> > >> > > > > >> > >> > The nice property of BGP based IPVPN and EVPN is the > > > ability > > > > to > > > > >> > >> > partition the information such that the both L2 and L3 > > VPNs > > > > can > > > > >> > scale > > > > >> > >> > independently, each in context (for example VLANs, IP > > > VPNs). > > > > In > > > > >> > that > > > > >> > >> > sense IP VPNs and EVPNs are well suited as one solution > > for > > > > >> > extending > > > > >> > >> > the L2 and L3 connectivity for large and physically > > > disperse > > > > >> data > > > > >> > >> > centers. > > > > >> > >> > > > > > >> > >> > Don > > > > >> > >> > > > > > >> > >> > > > > > >> > >> > > > > > >> > >> > -----Original Message----- > > > > >> > >> > From: NAPIERALA, MARIA H [mailto:[email protected]] > > > > >> > >> > Sent: Monday, September 24, 2012 12:49 PM > > > > >> > >> > To: Fedyk, Donald (Don); [email protected] > > > > >> > >> > Subject: RE: [nvo3] draft-drake-nvo3-evpn-control-plane > > > > >> > >> > > > > > >> > >> > Don, > > > > >> > >> > > > > > >> > >> > > Perhaps I'm missing something but I thought EVPN was > > > built > > > > >> using > > > > >> > >> many > > > > >> > >> > > of the same building blocks as RFC4364 so that it > > > > >> > >> > > could > > > be > > > > >> used > > > > >> > in > > > > >> > >> > > combination with EVPN. In other words IP VPN + EVPN. > > > > >> > >> > > > > > >> > >> > It needs to be explained why/what are the requirements > > that > > > > you > > > > >> > need > > > > >> > >> > both (IPVPN and EVPN) in the same solution because this > > is > > > > not a > > > > >> > >> > trivial complication. > > > > >> > >> > The complexity of the solution depends on the > > requirements. > > > > If > > > > >> > >> > majority of traffic in a (significant class of) data > > center > > > > is > > > > >> > inter- > > > > >> > >> > subnet, a solution should be optimized for such traffic > > > and, > > > > >> > hence, > > > > >> > >> > solving the forwarding of such traffic should be the > > > starting > > > > >> > point. > > > > >> > >> > > > > > >> > >> > Maria > > > > >> > >> > > > > > >> > >> > > -----Original Message----- > > > > >> > >> > > From: [email protected] [mailto:nvo3- > > > [email protected]] > > > > On > > > > >> > >> Behalf > > > > >> > >> > Of > > > > >> > >> > > NAPIERALA, MARIA H > > > > >> > >> > > Sent: Monday, September 24, 2012 10:09 AM > > > > >> > >> > > To: [email protected] > > > > >> > >> > > Subject: Re: [nvo3] > > > > >> > >> > > draft-drake-nvo3-evpn-control-plane > > > > >> > >> > > > > > > >> > >> > > I think we should try to clarify what problems or > what > > > type > > > > of > > > > >> > data > > > > >> > >> > > centers specific solutions are addressing. > > > > >> > >> > > Specifically, EVPN can only address traffic bridged > in > > > the > > > > >> same > > > > >> > >> VLAN. > > > > >> > >> > > In data centers where most traffic is inter-VLAN, > > > > >> > >> > > i.e., > > > > >> packets > > > > >> > are > > > > >> > >> > > routed, the EVPN doesn't achieve much as an overall > > > > solution. > > > > >> > >> > > I tried to make this point on the webex during the > > > > >> > >> > > nvo3 > > > > >> interim > > > > >> > >> > session > > > > >> > >> > > when draft-drake-nvo3-evpn-control-plane was > discussed > > > but > > > > I > > > > >> am > > > > >> > not > > > > >> > >> > > sure if my message went through. > > > > >> > >> > > > > > > >> > >> > > Maria > > > > >> > >> > > > > > > >> > >> > > > -----Original Message----- > > > > >> > >> > > > From: [email protected] [mailto:nvo3- > > > > [email protected]] > > > > >> On > > > > >> > >> > Behalf > > > > >> > >> > > Of > > > > >> > >> > > > Thomas Nadeau > > > > >> > >> > > > Sent: Monday, September 17, 2012 11:55 AM > > > > >> > >> > > > To: [email protected] > > > > >> > >> > > > Subject: [nvo3] draft-drake-nvo3-evpn-control-plane > > > > >> > >> > > > > > > > >> > >> > > > > > > > >> > >> > > > A number of us just published this draft and > > wanted > > > to > > > > >> > >> bring it > > > > >> > >> > > > to the NVO3 WG's attention. We will be > > > > >> presenting/discussing > > > > >> > >> this > > > > >> > >> > > > draft at the interim meeting this week as well, but > > > > please > > > > >> > >> discuss > > > > >> > >> > > here > > > > >> > >> > > > on the list as well. > > > > >> > >> > > > > > > > >> > >> > > > Thanks, > > > > >> > >> > > > > > > > >> > >> > > > Tom, John, et al > > > > >> > >> > > > > > > > >> > >> > > > > > > > >> > >> > > > A new version of I-D, draft-drake-nvo3-evpn- > control- > > > > plane- > > > > >> > 00.txt > > > > >> > >> > > > has been successfully submitted by Thomas D. Nadeau > > and > > > > >> posted > > > > >> > to > > > > >> > >> > the > > > > >> > >> > > > IETF repository. > > > > >> > >> > > > > > > > >> > >> > > > Filename: draft-drake-nvo3-evpn-control-plane > > > > >> > >> > > > Revision: 00 > > > > >> > >> > > > Title: A Control Plane for Network > > > > Virtualized > > > > >> > >> Overlays > > > > >> > >> > > > Creation date: 2012-09-16 > > > > >> > >> > > > WG ID: Individual Submission > > > > >> > >> > > > Number of pages: 12 > > > > >> > >> > > > URL: http://www.ietf.org/internet- > > > > drafts/draft- > > > > >> > drake- > > > > >> > >> > > nvo3- > > > > >> > >> > > > evpn-control-plane-00.txt > > > > >> > >> > > > Status: > > http://datatracker.ietf.org/doc/draft- > > > > >> drake- > > > > >> > >> nvo3- > > > > >> > >> > > evpn- > > > > >> > >> > > > control-plane > > > > >> > >> > > > Htmlized: http://tools.ietf.org/html/draft- > > > drake- > > > > >> nvo3- > > > > >> > >> evpn- > > > > >> > >> > > > control-plane-00 > > > > >> > >> > > > > > > > >> > >> > > > > > > > >> > >> > > > Abstract: > > > > >> > >> > > > The purpose of this document is to describe > > how > > > > >> > Ethernet > > > > >> > >> > > Virtual > > > > >> > >> > > > Private Network (E-VPN) can be used as the > > > control > > > > >> > plane > > > > >> > >> for > > > > >> > >> > > > Network Virtual Overlays. Currently this > > > protocol > > > > is > > > > >> > >> > defined > > > > >> > >> > > to > > > > >> > >> > > > act as the control plane for Virtual > > Extensible > > > > Local > > > > >> > Area > > > > >> > >> > > > Network (VXLAN), Network Virtualization > using > > > > Generic > > > > >> > >> > Routing > > > > >> > >> > > > Encapsulation (NVGRE), MPLS or VLANs while > > > > >> maintaining > > > > >> > >> their > > > > >> > >> > > > existing data plane encapsulations. The > > > > >> > >> > > > intent > > > is > > > > >> that > > > > >> > >> this > > > > >> > >> > > > protocol will be capable of extensions in > the > > > > future > > > > >> to > > > > >> > >> > handle > > > > >> > >> > > > additinal data plane encapsulations and > > > functions > > > > as > > > > >> > >> needed. > > > > >> > >> > > > > > > > >> > >> > > > > > > > >> > >> > > > _______________________________________________ > > > > >> > >> > > > nvo3 mailing list > > > > >> > >> > > > [email protected] > > > > >> > >> > > > https://www.ietf.org/mailman/listinfo/nvo3 > > > > >> > >> > > _______________________________________________ > > > > >> > >> > > nvo3 mailing list > > > > >> > >> > > [email protected] > > > > >> > >> > > https://www.ietf.org/mailman/listinfo/nvo3 > > > > >> > >> _______________________________________________ > > > > >> > >> nvo3 mailing list > > > > >> > >> [email protected] > > > > >> > >> https://www.ietf.org/mailman/listinfo/nvo3 > > > > >> > >_______________________________________________ > > > > >> > >nvo3 mailing list > > > > >> > >[email protected] > > > > >> > >https://www.ietf.org/mailman/listinfo/nvo3 > > > > >> > > > > >> _______________________________________________ > > > > >> nvo3 mailing list > > > > >> [email protected] > > > > >> https://www.ietf.org/mailman/listinfo/nvo3 > > _______________________________________________ > nvo3 mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/nvo3 _______________________________________________ nvo3 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nvo3
