The imported E-VPN route will determine what the next hop entry in the EVI will look like -- whether it will have encapsulation A or encapsulation B. That is determined by the sender of the E-VPN route. This is like having a PPP interface and an Ethernet interface connected to the same VRF.
Ideally the other encapsulations would have included support for multi-homing by including an additional field for a split-horizon ID for use by control-planes and NVE that support multi-homing. Maybe it's not too late to add an SH field to these encapsulations since it seems that there is some unused bits in nvGRE (maybe not enough) and in VXLAN -- just a thought. On Tue, Sep 18, 2012 at 4:18 PM, Lucy yong <[email protected]> wrote: > Hi Kreeti, > > Regarding interworking capability, Is "a given EVI can support multiple data > plane encapsulation" equivalent to say "individual NVEs need to support > multiple encapsulation schemas"? If one NVE only supports VXLAN and another > NVE only supports MPLS-in-GRE, two will not able to work in a same EVI, is > that right? Will this give more benefit than having one encapsulation in an > EVI or make more complex? > > Regards, > Lucy > > -----Original Message----- > From: Kireeti Kompella [mailto:[email protected]] > Sent: Monday, September 17, 2012 8:18 PM > To: Lucy yong > Cc: [email protected] > Subject: Re: [nvo3] draft-drake-nvo3-evpn-control-plane > > 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 _______________________________________________ nvo3 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nvo3
