Subject: [bess] Tunnel question for ESI next-hop in draft evpn prefix-advert

From: Antoni Przygienda <[email-masked]>
Date: Wed, 14 Jan 2015 18:35:03 +0000

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

Subject: RE: Tunnel question for ESI next-hop in draft evpn prefix-advert
From: Antoni Przygienda <[email-masked]>
To: "Rabadan, Jorge (Jorge)" <[email-masked]>, "Henderickx, Wim (Wim)" <[email-masked]>, "[email-masked]" <[email-masked]>, "Ali Sajassi (sajassi) ([email-masked])" <[email-masked]>
Date: Wed, 14 Jan 2015 01:18:02 +0000

inline

From: Rabadan, Jorge (Jorge) [mailto:[email-masked]]
Sent: Tuesday, January 13, 2015 9:04 AM
To: Antoni Przygienda; Henderickx, Wim (Wim); [email-masked]; Ali Sajassi (sajassi) ([email-masked])
Subject: Re: Tunnel question for ESI next-hop in draft evpn prefix-advert

Hi Tony,

Please see in-line.

From: Antoni Przygienda <[email-masked]<mailto:[email-masked]>>
Date: Monday, January 12, 2015 at 11:33 PM
To: Jorge Rabadan <[email-masked]<mailto:[email-masked]>>, "Henderickx, Wim (Wim)" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "Ali Sajassi (sajassi) ([email-masked]<mailto:[email-masked]>)" <[email-masked]<mailto:[email-masked]>>
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