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
