John, Thank you very much to help elaborate on this. My question is about text in the section 4.
Regards, Lucy -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Joel M. Halpern Sent: Wednesday, September 19, 2012 8:52 AM To: John E Drake Cc: [email protected] Subject: Re: [nvo3] draft-drake-nvo3-evpn-control-plane Looking at the draft, there seems to be a very reasonable question about section 4. The text starts by noting that the presence of the Tunnel Encapsulation attribute allows for supporting a range of tunnel encapsulations. Sounds good. It then asserts that this allows interoperability across the encapsualtions. That does not seem to follow. Normally, when we allow multiple encpsulations, we specify one as mandatory to implement in order to enable interoperability of the devices. Communicating the encapsulation type does not magically enable a device that uses one encapsulation to communicate with a device that only supports some other encapsualtion. I presume that there are steps missing in section 4. Could you elaborate? Yours, Joel On 9/19/2012 4:11 AM, John E Drake wrote: > Lucy, > > Why didn't you ask your question of the authors? I had taken it as a given > that the capability to have an EVI spanning MPLS, VXLAN, and NVGRE endpoints > was a given. If the network operator does not want to deploy this > capability, that is their option. > > Yours irrespectively, > > John > > >> -----Original Message----- >> From: [email protected] [mailto:[email protected]] On Behalf Of >> Lucy yong >> Sent: Tuesday, September 18, 2012 1:19 PM >> To: Kireeti Kompella >> Cc: [email protected] >> Subject: Re: [nvo3] draft-drake-nvo3-evpn-control-plane >> >> 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- >> pl >>>>> ane-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 _______________________________________________ nvo3 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nvo3
