> > I am curious, however, about the suggestion that we need "to > > address *non-IP* traffic" > > in the context of an IETF working group. Why is that? > > This is a good question. As I stated, if you assume that all traffic in a DC > is IP then layer 3 overlay solution seems to be obvious one to me.
In addition, there is IP traffic that requires L2 adjacency based on needing IP subnet multicast for traffic that does not use IP multicast. Thanks, --David > -----Original Message----- > From: [email protected] [mailto:[email protected]] On Behalf Of > NAPIERALA, MARIA H > Sent: Thursday, September 27, 2012 11:39 AM > To: Eric Gray > Cc: [email protected] > Subject: Re: [nvo3] draft-drake-nvo3-evpn-control-plane > > Eric, > > > > > Maria, > > > > Thanks for the explanation. > > > > Since there are already existing solutions for virtualized data > > centers, I think it is only too > > obvious that we're conceding that a "one-size fits all" solution is > > pretty much out of the question. > > > > So, it seems possible (at least) that a solution built around > > EVPN may be applicable to at > > least a subset of use cases. > > > > I am curious, however, about the suggestion that we need "to > > address *non-IP* traffic" > > in the context of an IETF working group. Why is that? > > This is a good question. As I stated, if you assume that all traffic in a DC > is IP then layer 3 overlay solution seems to be obvious one to me. > > Maria > > > -- > > Eric > > > > -----Original Message----- > > From: NAPIERALA, MARIA H [mailto:[email protected]] > > Sent: Thursday, September 27, 2012 12:02 AM > > To: Eric Gray; [email protected] > > Subject: RE: [nvo3] draft-drake-nvo3-evpn-control-plane > > Importance: High > > > > Eric, > > > > (BTW, there was a follow up to this e-mail which you might want to > > check out also). > > > > A data center where all traffic (intra- and inter-subnet) is *IP* then > > a routing solution such as L3VPN is the most optimal for such data > > center. I would think everybody would agree with this assertion. > > > > The question is how to address *non-IP* traffic, in those DCs that care > > about such traffic. The best way to answer that question would be to > > measure such traffic. If a data center has a lot of *non-IP* traffic > > then it would make sense to use EVPN for intra-subnet forwarding. If > > non-IP traffic is localized to a small subset of VLANs perhaps it makes > > more sense to have a solution where EVPN is only used when necessary, > > rather than to design the entire solution around EVPN. > > > > Maria > > > > > -----Original Message----- > > > From: Eric Gray [mailto:[email protected]] > > > Sent: Wednesday, September 26, 2012 3:49 PM > > > To: NAPIERALA, MARIA H; [email protected] > > > Subject: RE: [nvo3] draft-drake-nvo3-evpn-control-plane > > > > > > Maria, > > > > > > Given that we already have routing, I am not clear on what else > > it is > > > that you're saying needs to be done to produce an "overall solution." > > > If we use EVPN as one way to address traffic "bridged in the same > > > VLAN" and we use routing to handle traffic that "is inter-VLAN, i.e., > > > packets [that] are routed" do we have less than an overall solution? > > > > > > I am personally convinced that this is just one over-all > > solution, of > > > possibly many > > > - but it certainly seems like a good candidate to consider for work > > > here in the IETF. > > > > > > -- > > > Eric > > > > > > -----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
