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
