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
