Comment 9 for bug 1590908

Revision history for this message
Thomas Morin (tmmorin-orange) wrote :

Thanks for your inputs.

After giving some thought to this, I'm thinking we should keep the rule as-is for imported routes but *only* for L2 BGPVPNs (and hence only for Network associations), because the hardware limitation which lead us to add this restriction applies to a single bridge domain but not anymore if a bridge is in between.

This is consistent and I think does resolve the obstacle wrt. the use in BGP DR project.

For l3, the VNI specified would apply to advertised routes, and for received routes we could whether (a) apply something like the rule you suggest (use a route compatible with the VNI-specification of any BGPVPN, considering that a BGPVPN with no VNI specified would mean "accepting any VNI"), or (b) do not do any filtering at all (use any route received, and honor whatever VNI it specifies). Any reason to not choose the simplest (ie. (b)) ?

Thoughts ?

Side comments/answers to some of your questions below:
- section 5.1 of evpn-prefixes draft indeed lacks a bit of details on RT; my interpretation of the sentence you quote is that it means that the IP-VRF is importing from/to the RT used for the MACVRF10 (nothing prevents a same RT to be imported by multiple entities).
- you say "The DGW implementation will use the VNI and next-hop of the RT-5 [route]" ; I read this as "the DGW implementation can honor any VNI used, and is not limited to using a VNI associated to its MAC-VRF", which lead me to ask: why then do you need/want to use globally assigned VNIs ? everything is sooo simpler when dataplane ids are just locally assigned...