Comment 6 for bug 1590908

Hi Mickey,

We have to keep in mind why the possibility to specify a VNI for a BGPVPN is being added.

Let's take a step back first. We don't have a similar to define MPLS labels to use for a BGPVPN. The design of the protocols (the RFCs you quote, and before them the base specs for MPLS) leverage the idea of locally and dynamically assigned MPLS labels. All MPLS stacks have been designed to support that.

VXLAN on the contrary was designed for globally assigned VNIs, and although it can be used with a strategy where VNIs are locally and dynamically assigned, some VXLAN implementation, in particular some hardware implementations ones cannot do that (or not efficiently enough). To use E-VPN VXLAN in contexts where you need to co-exist with such hardware, you need to ensure that for a given VPN, a single VNI will be used, and hence the BGPVPN API was augmented to control the VNI. Without this constraint, the VNI to use would not need to be globally coordinated and the API would not need to control it.

With this in mind, the question of the semantic of the VNI of a BGPVPN in the presence of routes that also specify a VNI, has no elegant answer. The approach you propose would go counter to the motivation for adding the VNIs in the API (support hardware requiring a single VNI for a said VPN instance).

Now, I'm realizing that the answer I gave on advertisements is not consistent with the above: on hardware having the said limitation, advertising the prefix twice with two VNIs would not be an option.

I'm leaning toward the idea of simply saying that associating something to two BGPVPNs specifying a different VNI is disallowed. If you are in a context where no such hardware limitation is in the picture, then you would just not specify a VNI for a said BGPVPN, and the backend will be free of dynamically/locally choosing the VNI to use for a given advertisement, and honor any VNI in a received route.