Comment 5 for bug 1590908

Thomas,

Thanks for the clarification of intent.

I do not get why you think of an association between a network or router and a BGPVPN as something exclusive, where connectivity between that network or router and everything else is limited to the definitions of that BGPVPN.

I think of an association between a network or router and a BGPVPN as allowing connectivity between that network or router and other things in that BGPVPN. That does not mean that the same network or router cannot connect to other things, outside the context of that BGPVPN.

The specific use case that I always have in mind for this is an application running in a multi-tenant data center, that requires connectivity both to the public internet for the front end, and back to an on premises customer site on the back end. By using BGPVPN for both aspects of connectivity, a router can learn which addresses are reachable over the BGPVPN leading to the on premises customer site, and which addresses are reachable over the BGPVPN leading to the internet.

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

I do not agree that the route is 'imported based on a BGPVPN association saying "VNI2"'. The route is imported based on BGPVPN1, not based on BGPVPN2.

Look at RT processing. From RFC 4364: "Note that a particular VPN-IPv4 route is only eligible for installation in a particular VRF if there is some Route Target that is both one of the route's Route Targets and one of the VRF's Import Targets". As long as there is an intersection in the route's RTs and the import RTs, the route is eligible. The presence of additional import RTs does not affect route eligibility.

It is true that typically for the use case that I described above, routes will have either RT 1 or RT 2, but not both (in which case either proposal would work). However, I still contend that RT should be used as a filter to determine whether a route is eligible. Once a route is eligible, you use the VNI specified in the route. Just because there is an additional RT in the route, that should not preclude the route from being used.