Thank you Kireeti. That addresses my concerns.
Yours,
Joel
On 9/19/2012 8:46 PM, Kireeti Kompella wrote:
Hi Tom,
On Sep 19, 2012, at 4:17 PM, Thomas Nadeau <[email protected]> wrote:
On Sep 19, 2012:11:28 AM, 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....
That is just not how data centers are built today so that is unlikely
to happen in the wild. With that in mind, this is an interesting corner case
that we should handle just in case something is misconfigured or someone in the
future decides to build such a DC.
As I've said, I like this draft. However, "interworking" is fraught with
misinterpretations and pitfalls, and perhaps at this stage distracts from other more
pressing concerns.
Might I suggest the following reworking of Section 4:
4. Multiple Encapsulations
The Tunnel Encapsulation attribute enables a single control plane
to oversee a number of different data plane encapsulations. This can
manifest itself in several ways:
a) a data center may use a single common encapsulation for all EVIs, but
different data centers may make independent choices.
b) within a single data center, a given EVI may use a single
encapsulation, but different EVIs may choose different encapsulations.
c) a single EVI may use multiple encapsulations, one for each PE-PE pair,
and maybe even use a different encapsulation in each direction.
Going from (a) to (c ) increases generality, but also increases complexity.
The initial focus will be on (a) and (b); further details for (c ) will be
added if
there is sufficient interest.
In all cases, a PE within a given EVI knows which encapsulations other
PEs in that EVI support, and, when sending unicast traffic, it MUST choose
one of the encapsulations advertised by the egress PE.
For case (c ), an ingress PE that uses shared multicast trees for sending
Broadcast and Multicast traffic must maintain distinct trees for each
different encapsulation type. Further details will be given in a future
version.
The topic of interworking encapsulations and "gateway" functions will also
be
addressed in a future version.
Kireeti.
--Tom
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
_______________________________________________
nvo3 mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/nvo3
