Or interconnection when needed, as you have L2 access to L3 as Wim's example depicts.
Thanks, Nabil On 9/27/12 6:58 PM, "John E Drake" <[email protected]> wrote: >Luyuan, > >I think the correct model is to keep separate L2 & L3 VPNs but allow >selective leaking of info between them. > >Yours irrespectively, > >John > > >> -----Original Message----- >> From: [email protected] [mailto:[email protected]] On Behalf Of >> Luyuan Fang (lufang) >> Sent: Thursday, September 27, 2012 3:26 PM >> 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:[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 _______________________________________________ nvo3 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nvo3
