Hi Lucy, On Sep 17, 2012, at 3:36 PM, Lucy yong <[email protected]> wrote:
> 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. They would have to in any case. The tunnel encap is a couple of bits; the "tenant id" is also needed. > 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? Yes to the first question; not at all (imo) to the second. > This needs to be cooked more. I think it's pretty well cooked, although I must confess a predilection for sushi. In effect, these very capable authors saved me the trouble of writing pretty much the same draft :-) The only thing I would change is the draft name: I prefer "…-nvo3-l2-in-l3-control-plane". Oh, and add a code point for STT :-) Kireeti > 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 _______________________________________________ nvo3 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nvo3
