Tony, Please see in-line. Thanks for your comments.
From: Antoni Przygienda <antoni.przygie...@ericsson.com<mailto:antoni.przygie...@ericsson.com>> Date: Wednesday, January 14, 2015 at 5:40 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>> Cc: "bess@ietf.org<mailto:bess@ietf.org>" <bess@ietf.org<mailto:bess@ietf.org>> Subject: RE: Tunnel question for ESI next-hop in draft evpn prefix-advert Jorge, reread the -03, don’t know how I ended up working off and commenting on -02, too many context changes here I guess. inline 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. [JORGE] that’s fair. Will clarify that after the call for adoption. [Tony said] yes, -03 clearly indicates that encapsualtion extcomm is on type-1 now as well. thanks. However, I still think that 1. we need M2 over NVE2 in the figure 2. I would prefer the router MAC extcomm on type-1 in such case since the lookup ESI23 to M2 implies new magic not present in other drafts. Adding the router MAC extcomm would make it completely analogous to the inter-subnet draft cases IMO. And if the ESI to MAC lookup is desired, the example should at least describe that NVE2 is advertising an RT-2 with the M2 MAC. [JORGE] will clarify the figure in the next rev. I’m ok to add the router’s mac ext-comm as I said in a separate thread. For the next rev, I will share a text with you and my co-authors and we can discuss it before publishing. 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. [JORGE] About the 5512 ext community, the above draft explicitly says that all the routes, including RT1 should carry the 5512 ext community with the right tunnel type. I don’t think it is required a new reference here since the evpn-overlay draft is referenced. However if you still think it is better to explicitly mention it, please suggest a text and we can add it. [Tony said] agreed, -03 is very clear now. About adding the router’s MAC ext community to the RT5 in this use-case… do we need it assuming that the NVE is sending a RT2 with the MAC associated to the ESI? [Tony said] as above, I do not think it’s beneficial to add implications of a lookup from ESI to a valid MAC just for this specific case. [JORGE] see above.
_______________________________________________ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess
