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
