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.
Had a discussion today with a SP who wants to burst/move capacity, enable disaster recovery in L2 or L3 or L2/L3/IRB constructions and support the model I highlighted below. -----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:[email protected]] > 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:[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
