Read this draft. RFC5512 applies a case where two BGP speakers are in a BGP free core. Using encapsulation tunnel between two speakers enables one speaker to send a packet to another speaker as the next-hop.
Using this approach in nvo3 may rise a high scalability concern because any pair of NVEs in an NVO will need to maintain a state for the tunnel encapsulation. If some NVEs support VXLAN and some support NVGRE, to build mcast tree for BUM, it has to build two distinct sub-trees for each, which is more complex. "This memo specifies that an egress PE must use the sender MAC address to determine whether to send a received Broadcast or Multicast packet to a given Ethernet Segment. I.e., if the sender MAC address is associated with a given Ethernet Segment, the egress PE must not send the packet to that Ethernet Segment." Does it mean using BGP to exchange NVE MAC address that belong to an Ethernet segment first? How does this impact other evpn features? This needs to be cooked more. Cheers, Lucy -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Aldrin Isaac Sent: Monday, September 17, 2012 2:18 PM To: Stiliadis, Dimitrios (Dimitri) Cc: Thomas Nadeau; [email protected] Subject: Re: [nvo3] draft-drake-nvo3-evpn-control-plane I'm not sure that the dust has fully settled on the matter. http://tools.ietf.org/html/draft-marques-l3vpn-end-system-07 suggests the use of XMPP. The question is whether there is any sound technical reason (versus preferences) why leveraging BGP is problematic. I personally haven't heard a convincing argument. On Mon, Sep 17, 2012 at 12:11 PM, Stiliadis, Dimitrios (Dimitri) <[email protected]> wrote: > May be I missing something here .. but does this suggest running BGP-EVPN > on the NVE > that is located in the hypervisor? > > Dimitri > > On 9/17/12 8:55 AM, "Thomas Nadeau" <[email protected]> wrote: > >> >> 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
