-----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-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
