Lucy, Good question - that might fit better under the L2VPN related work section.
Thanks, --David > -----Original Message----- > From: [email protected] [mailto:[email protected]] On Behalf Of Lucy > yong > Sent: Monday, July 30, 2012 4:08 PM > To: John E Drake; Lucy yong > Cc: Thomas Narten; [email protected] > Subject: Re: [nvo3] VRF text (take 3) in draft-narten-nvo3-overlay-problem- > statement-02.txt > > Then the question is why we need to describe E-VPN in the problem draft? E-VPN > is still in developing stage and operator yet deploy it. Why we describe it as > a "traditional" solution? > > Lucy > > -----Original Message----- > From: John E Drake [mailto:[email protected]] > Sent: Saturday, July 28, 2012 6:31 PM > To: Lucy yong > Cc: Thomas Narten; [email protected] > Subject: Re: [nvo3] VRF text (take 3) in draft-narten-nvo3-overlay-problem- > statement-02.txt > > Also MAC address mobility and constant convergence time after failure > regardless of the number advertised routes. > > Sent from my iPhone > > On Jul 27, 2012, at 4:50 PM, "Lucy yong" <[email protected]> wrote: > > > Hi Tom, > > > > It is not clear what Ethernet service that E-VPN emulates for. > > MEF has E-Line, E-LAN, E-Tree, and E-access service. IETF has VPLS. IMHO E- > VPN does not emulate any of them. It emulates a bridging device connecting to > multiple sites and being configured with multiple VLANs that may have > different topologies among the sites. E-VPN is very like L3VPN [RFC4364] but > implemented in L2. Another outstanding feature E-VPN providing is multi-homing > with active-active mode. None of existing Ethernet Services support that. > Thus, E-VPN does not emulate existing Ethernet service. It seems that SP will > offer a new service by using E-VPN. > > > > Thanks, > > Lucy > > > > > > > > > > -----Original Message----- > > From: [email protected] [mailto:[email protected]] On Behalf Of > Thomas Narten > > Sent: Friday, July 27, 2012 2:57 PM > > To: John E Drake > > Cc: [email protected] > > Subject: Re: [nvo3] VRF text (take 3) in draft-narten-nvo3-overlay-problem- > statement-02.txt > > > > WG: > > > > To circle back to this thread: > > > > John E Drake <[email protected]> writes: > > > >> I would be happy to help. As the text of the two paragraphs has > >> been in flux, would you please send me what you consider to be the > >> latest text? > > > > John did provide text, and it is in > > draft-narten-nvo3-overlay-problem-statement-03.txt, which was posted > > last week. It says: > > > > For IP/MPLS networks, Ethernet Virtual Private Network (E-VPN) > > [I-D.ietf-l2vpn-evpn] provides an emulated Ethernet service in which > > each tenant has its own Ethernet network over a common IP or MPLS > > infrastructure and a BGP/MPLS control plane is used to distribute the > > tenant MAC addresses and the MPLS labels that identify the tenants > > and tenant MAC addresses. Within the BGP/MPLS control plane a thirty > > two bit Ethernet Tag is used to identify the broadcast domains > > (VLANs) associated with a given L2 VLAN service instance and these > > Ethernet tags are mapped to VLAN IDs understood by the tenant at the > > service edges. This means that the limit of 4096 VLANs is associated > > with an individual tenant service edge, enabling a much higher level > > of scalability. Interconnectivity between tenants is also allowed in > > a controlled fashion. > > > > IP/MPLS networks also provide an IP VPN service (L3 VPN) [RFC4364] in > > which each tenant has its own IP network over a common IP or MPLS > > infrastructure and a BGP/MPLS control plane is used to distribute the > > tenant IP routes and the MPLS labels that identify the tenants and > > tenant IP routes. As with E-VPNs, interconnectivity between tenants > > is also allowed in a controlled fashion. > > > > VM Mobility [I-D.raggarwa-data-center-mobility] introduces the > > concept of a combined L2/L3 VPN service in order to support the > > mobility of individual Virtual Machines (VMs) between Data Centers > > connected over a common IP or MPLS infrastructure. > > > > There are a number of VPN approaches that provide some if not all of > > the desired semantics of virtual networks. A gap analysis will be > > needed to assess how well existing approaches satisfy the > > requirements. > > > > Does that text work for folk? > > > > Thomas > > > > _______________________________________________ > > 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
