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:[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
