Comment 3 for bug 1590908

Thomas,

Thanks for the link to
http://docs.openstack.org/developer/networking-bgpvpn/future/attributes.html#vnid-attribute

I agree with the first half. 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.

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. In our backend design, we intend to do the processing on a per VNI basis.

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

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).