Attached comments I started on the prefix advertisement draft in eVPN to get
e'one a chance to jump in
thanks
--- tony
I shall never be ashamed of citing a bad author if the line is
good.<http://www.quotationspage.com/quote/26861.html>
~~ Seneca
--- Begin Message ---
inline
From: Rabadan, Jorge (Jorge) [mailto:jorge.raba...@alcatel-lucent.com]
Sent: Tuesday, January 13, 2015 9:04 AM
To: Antoni Przygienda; Henderickx, Wim (Wim); flo...@nuagenetworks.net; Ali
Sajassi (sajassi) (saja...@cisco.com)
Subject: Re: Tunnel question for ESI next-hop in draft evpn prefix-advert
Hi Tony,
Please see in-line.
From: Antoni Przygienda
<antoni.przygie...@ericsson.com<mailto:antoni.przygie...@ericsson.com>>
Date: Monday, January 12, 2015 at 11:33 PM
To: Jorge Rabadan
<jorge.raba...@alcatel-lucent.com<mailto:jorge.raba...@alcatel-lucent.com>>,
"Henderickx, Wim (Wim)"
<wim.henderi...@alcatel-lucent.com<mailto:wim.henderi...@alcatel-lucent.com>>,
"flo...@nuagenetworks.net<mailto:flo...@nuagenetworks.net>"
<flo...@nuagenetworks.net<mailto:flo...@nuagenetworks.net>>, "Ali Sajassi
(sajassi) (saja...@cisco.com<mailto:saja...@cisco.com>)"
<saja...@cisco.com<mailto:saja...@cisco.com>>
Subject: Tunnel question for ESI next-hop in draft evpn prefix-advert
Gentlemen,
specific question for section 5.4 (2) in the evpn prefix advertisement draft
since the language is difficult to parse
Do you mean 5.3, ESI next-hop ("Bump in the wire") use-case?
[Tony said] yepp, bump-in-the-wire, it’s section 5.4 in revision -02
What do you mean by “and the corresponding tunnel information” for ESI
next-hop for type-5 in the vxLAN case?
a) I don’t see how vxLAN will work with that since at least a Router
MAC’s extended comm is needed in such a case, section 5.4 (4) describing how to
derive the inner MAC is fuzzy, we cannot look-up the VRF ARP table since NVE2
has no overlay IP address and ‘EVI-10 FDB table’ is something I don’t
understand and I don’t think has been defined. The alleged M2 to be used does
not exist in the figure at all.
We can clarify that section for sure. The idea is that the RT5 in this case
requires a recursive lookup resolution to the information given by the RT1. The
tunnel information (destination VTEP, VNI) comes from the RT1. In this use-case
we want to direct the encapsulated frames to the owner of the active ESI.
EVI-10 FDB should be replaced by MAC-VRF10 FDB in DCW1/2, we can fix that. In
the MAC-VRF you could find M2 since it is associated to the ESI23 (NVE2/3
advertise TS2/3 MACs with ESI23).
[Tony said] the idea is completely clear to me (and commendable). I got
what you say but Figure 5 is missing M2 and M3 in it and maybe a sentence
saying to be perfectly clear that NVE2 announces M2 type-2 (without IP address
obviously). The text still implies an impossible lookup to me. ARP table needs
IP addresses for NVE2/NVE3, there is no such thing as ESI23<->M2 entry so it’s
some kind of a completely new beast which I need to think through. I think
calling it ‘ARP lookup or EVI-10 MACVRF’ is implying magic in this case.
b) the “tunnel information” provided by A-D route seems to imply
ext-comm RFC5512 carried on A-D routes as well (original eVPN draft does not
provision for carrying those ext-comms on type-1 unless I missed some other
draft). How can we differentiate otherwise between MPLS and vxLAN tunneling? If
that’s the intention, I think it has to be spelled out.
Definitively RFC5512 bgp encap ext community as per
http://tools.ietf.org/html/draft-ietf-bess-evpn-overlay-00
[Tony said] ok, yes, but carrying 5512 on type-1 routes is a completely new
concept I didn’t see in any other draft and I think that should be pointed out
explicitly. Honestly, the resolve the problem above we may want to carry the
Gateway MAC ExtComm as other VxLAN cases do. That would make things symmetric
and resolve the ‘magic lookup’ I see here.
Merits couple clarifying sentences would merit addition?
Yes, we’ll do that.
As well, the last paragraph is hard to parse with the ‘same BGP next-hop for
type-5 and type-1’ being ‘valid’? I also think it is superfluous to imply a
condition of ‘validity’. There is no check necessary.
L3VRF will hold two type-5 routes with NH ESI23 but the resolution is
happening over type-1 of which there is only one so there will the L3
load-balancing ending however on exactly the same underlying tunnel. Nothing
wrong with that. It’s basically BGP advertising third-party next-hop which is
not often seen but perfectly valid.
Yes, I agree. Will modify that in the next rev.
[Tony said] ok, cool.
--- tony
--- End Message ---
_______________________________________________
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess
