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:[email protected]] >> 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:[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:[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
