I honestly don't care what we call it as long as the protocol inside the
document gets the job done. *)
--Tom
On 9/19/12 7:38 AM, "Luyuan Fang (lufang)" <[email protected]> wrote:
>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-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
