Hi Maria

I see the problem as data centers need both L2 and L3 connectivity. I think 
that the Requirements Documents do spell this out. Perhaps they need more. 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. 

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

Reply via email to