On Sep 19, 2012, at 7:55 AM, Lucy yong <[email protected]> wrote:
> Tom, > > I am not auguring if NVO3 should support different data encapsulations. I > question that the proposed solution is proper in a mp2mp situation. Using a > gateway for this case is much simpler, which can still be done in a single > control plane. Actually, I strongly disagree with the assertion that "using a gateway for this case is much simpler". We (operators) build networks to scale by pushing as much functionality to the EDGE of the network, as possible. If you mandate a GW be used as a converter that becomes a capacity planning headache, you have to worry about it's resiliency (fail-over), etc. Do not go there. -shane > However, in NVO3, encapsulation is done at NVE not end system, right? I don't > know the intention of your second sentence. > > Lucy > > -----Original Message----- > From: Thomas Nadeau [mailto:[email protected]] > Sent: Tuesday, September 18, 2012 6:10 PM > To: Lucy yong > Cc: Kireeti Kompella; [email protected] > Subject: Re: [nvo3] draft-drake-nvo3-evpn-control-plane > > > There is definitely a requirement to do different encapsulations > simultaneously. There is even support coming from NIC vendors to support > multiple VMs with different encapsulations at the same time. > > --Tom > > On Sep 18, 2012:1:18 PM, at 1: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 > _______________________________________________ nvo3 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nvo3
