Maria,
Even if all of the traffic in a Data Center is IP traffic, this IP
traffic may use a
specific layer 2 technology for at least part of the deployment. This may
happen, for
example, if a company that uses data-center bridging to provide a SAN (or cloud)
storage solution merges with a company that uses some (as yet to be defined?)
strictly L3 overlay solution.
Or it may happen in cases where a combination of L2 and L3
virtualizations
are used in a common deployment (e.g. - to provide further scaling advantages).
In a way, we (the IETF) have cooked our own goose and may have to stew
in
the juices of the result.
We have defined mechanisms for transport of (various types of) Layer 2
over
IP. The result is that the mechanisms we've defined mimic Layer 2 constructs
(e.g. - a
link or a virtual bridged network) in ways that may be less than perfect.
"Pseudo-wires" for example are not actual wires (or even fibers).
Layer 2
VPNs are not exactly the same thing as VLANs, either.
And it matters.
Since we have done this, we need to make sure that we deal with any mess
that arises out of these potential imperfections - particularly for the
potential "killer
applications" that we see (or have pointed out to us) on the horizon.
We defined them in the IETF, therefore it is (potentially) our mess to
clean up.
For this reason, we need to consider at least the possibility that a
strictly L3
overlay solution may not be enough.
However, if we want to avoid making things worse, then we need to
restrict
our efforts to the bare-minimum "clean-up" required. For this reason, we need
to
avoid thinking of the work we are doing as explicitly including support for any
non-IP
traffic.
In some cases, I suspect that the "bare minimum" will comprise use of
the
expression "just say no." The trick will be getting agreement as to when this
applies.
:-)
--
Eric
-----Original Message-----
From: NAPIERALA, MARIA H [mailto:[email protected]]
Sent: Thursday, September 27, 2012 11:39 AM
To: Eric Gray
Cc: [email protected]
Subject: RE: [nvo3] draft-drake-nvo3-evpn-control-plane
Importance: High
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
