Don, Thanks for the quick clarification! Luyuan
> -----Original Message----- > From: Fedyk, Donald (Don) [mailto:[email protected]] > Sent: Monday, September 24, 2012 9:28 PM > To: Luyuan Fang (lufang); NAPIERALA, MARIA H; [email protected] > Subject: RE: [nvo3] draft-drake-nvo3-evpn-control-plane > > Hi Luyuan > > Yes in that sense "one solution" is a poor choice of words. (I meant > One option for control plane using BGP. NVO3 is discussing other > control plane options.) I agree with your wording two solutions with > common building blocks. > > Thanks, > Don > > > > > -----Original Message----- > From: Luyuan Fang (lufang) [mailto:[email protected]] > Sent: Monday, September 24, 2012 3:12 PM > To: NAPIERALA, MARIA H; Fedyk, Donald (Don); [email protected] > Subject: RE: [nvo3] draft-drake-nvo3-evpn-control-plane > > 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
