Comment 4 for bug 1590908

Mickey,

> I find the text for a network or router associated with multiple
> BGPVPNs confusing. The only way I can make sense of it is to change the second bullet to read:
> - the route is used to establish connectivity to the destination in the forwarding plane only if the
> received VNID is contained in the set of retained VNIDs in the previous step.

The current formulation may need to be improved, but your reformulation does not match our initial intent.

The intent was to say that a route can be used only if the VNI in the route matches the VNI of all the BGPVPNs that import it (if there is one BGPVPN that imports the route and has a VNI different from the one of the route, the route can't be used, because using it would result in choosing a VNI that would violate whether the VNI specified in the route or the VNI specified by that BGPVPN).

> For received routes, I guess the question is whether to filter the received VNI within each BGPVPN
> independently, or filter the received VNI across the set of BGPVPNs associated with the network or router.
> For example, if BGPVPN 1 has import RT 1 and VNI 1, and BGPVPN 2 has import RT 2 and VNI 2, should a
> received route with RT 1 and VNI 2 be accepted?
> I think the answer should be no.

I agree with you.

> My proposed alternative:
>
> when a route is imported, for each BGPVPN associated to the Network or Router and having a VNID defined:
> the set of Route Targets of the route is intersected with the import_rts of the BGPVPN
> if this intersection is non-empty, and the ‘VNID’ of the BGPVPN is equal to the VNID defined for that
> BGPVPN, then the route is used to establish connectivity to the destination in the forwarding plane

Let's apply this algorithm to the a scenario where a Network is associated to both BGPVPN1 and BGPVPN2, BGPVPN1 has import RT 1 and VNI 1, BGPVPN2 has import RT 2 and VNI 2, for a route carrying both RT1 and RT2 and has VNI 1. The algorithm would accept the route based on the check applied for BGPVPN1. The fact that the check fails for BGPVPN2 will not prevent the route from being used and VNI1 will be used for a route imported based on a BGPVPN association saying "VNI2".

> Regarding advertisement, if the VNIs vary over the multiple BGPVPNs, then the prefix(es) will have to be
> advertised separately for each VNI. I guess a similar issue exists with respect to RDs, requiring
> separate advertisements if the RDs are different. The RTs for each prefix advertisement will be the union
> of the export RTs for all associated BGPVPNs with that VNI value (and RD value).

Yes, I agree.
This is something the specs currently don't capture properly (for both RDs and VNIs).
(Note that for RDs, things would be slightly different since we allow lists: a same route can be used to
advertise to two different VPNs as long as the BGPVPN don't specify non-intersecting lists of RDs.)