Hi Florin, I agree with the concerns you raise.
In my view in a DC there would be one or 2 encapsulations in the worst case (Server-to-server and server to others) used at any point of time. This could be as a parallel to how we have different networks in HPC. Thanks, Vishwas On Wed, Sep 19, 2012 at 11:28 AM, Balus, Florin Stelian (Florin) < [email protected]> wrote: > John, > I think more details need to be added here. What happens if one PE > advertises nvgre encap while the other advertises only vxlan? Do you allow > asymmetric encapsulations? > What if one NVE supports all 3 which one is chosen, advertised? Just a few > examples.... > Thanks, > Florin > > On Sep 19, 2012, at 9:04 AM, John E Drake <[email protected]> wrote: > > > Joel, > > > > From section 4, the section you referenced in your note below: > > > > "Note that an ingress PE must use the data plane encapsulation specified > by a given egress PE in the subject MAC Advertisement or Per EVI Ethernet > AD route when sending a packet to that PE. Further, an ingress node that > uses shared multicast trees for sending Broadcast and Multicast traffic > must maintain distinct trees for each different encapsulation type." > > > > Aldrin also recast this into English in his reply to Lucy: > > > > "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." > > > > Yours irrespectively, > > > > John > > > >> -----Original Message----- > >> From: Joel M. Halpern [mailto:[email protected]] > >> Sent: Wednesday, September 19, 2012 6: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- > >> plan > >>>>>>> e > >>>>>>> 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 >
_______________________________________________ nvo3 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nvo3
