-----Original Message----- From: NAPIERALA, MARIA H [mailto:[email protected]] Sent: vrijdag 28 september 2012 21:24 To: Henderickx, Wim (Wim); 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, > > Yes, you can. > > WH> How? RFC 6513 - "Announcing the Presence of Unsolicited Flooded Data". WH2> this would not work for the use case I mentioned: broadcast flooding, TTL 1 apps > > 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 Are you referring to your customers? WH2> yes > > 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:wim.henderickx@alcatel- > lucent.com] > > 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
