-----Original Message----- From: NAPIERALA, MARIA H [mailto:[email protected]] Sent: vrijdag 28 september 2012 21:05 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 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, Yes, you can. WH> How? > 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. Yes. But why would you need to transport MAC addresses? Applications do not send or receive Ethernet frames directly, they are restricted to IP services. The requirement is to provide an "IP subnet" and traffic exchange between "IP subnets". IP service is: unicast, subnet broadcast, multicast. Are you saying that the requirement for layer 2 service is to address the interaction with IEEE bridging? WH> yes you need to do IEEE bridging and this is what customers want > You could also solve this by doing both EVPN and L3VPN. Yes. And IMO, it is better to keep layer 2 and layer 3 solutions separate - cleaner, less complex, no virtualized IRB. I would rather design around the inter-subnet traffic exchange first (as it is majority of traffic), and then address intra-subnet, and whether interaction with bridging is required (because this is where complexity "lives"..) WH> you can but you need to do some interaction which can be a local implementation matter. Maria > -----Original Message----- > From: Henderickx, Wim (Wim) [mailto:[email protected]] > Sent: Friday, September 28, 2012 2:19 PM > 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
