Lucy, I'm not sure we want to go down the complicated road of segmented transport tunnels. That seems to be a lot more work for the control plane and network designers. I think that might also head us in the opposite direction of the pooling principle :). Isn't it less expensive if the NVE supports different encaps versus adding complexity into the CP?
Best regards -- aldrin On Sep 19, 2012, at 10:17 AM, Lucy yong wrote: > John, > > First of all, I mean to say that the proposed solution is not proper in a > mp2mp solution in the reply to Tom. This is my mistake. > > If one egress PE supports NVGRE, one support VXLAN, and one support MPLS-GRE, > then five ingress PEs that need to have tunnels to all three egress PEs will > all need to support 3 encapsulation. > > Using a gateway interwork with different data plane is better on this. > > Lucy > > > > > > > > -----Original Message----- > From: John E Drake [mailto:[email protected]] > Sent: Wednesday, September 19, 2012 9:05 AM > To: Lucy yong; Thomas Nadeau > Cc: Kireeti Kompella; [email protected] > Subject: RE: [nvo3] draft-drake-nvo3-evpn-control-plane > > Lucy, > > What exactly do you mean by 'mp2mp' and why do you think it is needed in this > context? > > Yours irrespectively, > > John > > >> -----Original Message----- >> From: [email protected] [mailto:[email protected]] On Behalf Of >> Lucy yong >> Sent: Wednesday, September 19, 2012 6:56 AM >> To: Thomas Nadeau >> Cc: Kireeti Kompella; [email protected] >> Subject: Re: [nvo3] draft-drake-nvo3-evpn-control-plane >> >> 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. >> >> 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 _______________________________________________ nvo3 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nvo3
