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