While the N.V.O. ordering is apropos of the WG, it would be cleaner if it was called "E-VPN Control Plane for Virtualized Network Overlays."
On Sep 19, 2012, at 10:42 AM, John E Drake <[email protected]> wrote: > Fine with me. I will add it to the list of updates for the next version. > > Yours irrespectively, > > John > > >> -----Original Message----- >> From: Luyuan Fang (lufang) [mailto:[email protected]] >> Sent: Wednesday, September 19, 2012 7:39 AM >> To: NAPIERALA, MARIA H; Kireeti Kompella; John E Drake; Thomas Nadeau >> Cc: [email protected]; Lucy yong >> Subject: RE: [nvo3] draft-drake-nvo3-evpn-control-plane >> >> John and Tom, >> >> Regarding the title, may be more accurate to use something like "E-VPN >> Control Plane for Layer 2 Network Virtualized Overlays"? >> Thx, >> Luyuan >> >>> -----Original Message----- >>> From: [email protected] [mailto:[email protected]] On Behalf >>> Of NAPIERALA, MARIA H >>> Sent: Tuesday, September 18, 2012 7:35 PM >>> To: Kireeti Kompella >>> Cc: [email protected]; Lucy yong >>> Subject: Re: [nvo3] draft-drake-nvo3-evpn-control-plane >>> >>> Kireeti > [...] I would change is the draft name: I prefer "...-nvo3- >>> l2- >>> Kireeti > in-l3-control-plane". >>> >>> I have the same comment. The document describes control plane for >>> layer >>> 2 overlays (i.e., for transporting MAC/ethernet headers for IP >>> packets). Throughout the document when "network virtualization >> overlay" >>> is used it should be clarified that it is a layer 2 overlay. >>> >>> Maria >>> >>> >>>> -----Original Message----- >>>> From: [email protected] [mailto:[email protected]] On >> Behalf >>> Of >>>> Kireeti Kompella >>>> Sent: Monday, September 17, 2012 9: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- >> 0 >>>>>>> 0 >>>>>>> >>>>>>> >>>>>>> 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
