Comment 7 for bug 1590908

Thomas,

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

I agree with this statement.

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

Are there constraints?
Yes.

Is the constraint to have a single VNI?
For a single bridge table in a MAC-VRF in the context of L2 EVPN overlay, for some hardware implementations, yes.
However, there are EVPN prefix advertisement use cases where there may be more than one MAC-VRF / bridge associated with a router.

We want to support L3 EVPN prefix advertisement, with the following semantics:
- VLAN Based service, where a tenant VLAN ID gets mapped to an
  EVPN instance (EVI).
  The MAC-VRF table corresponds to only a single bridge table.
  i.e. Ethernet Tag = 0
- NVEs use VNIs as globally unique identifiers
- VXLAN encapsulation (original flavor, not VXLAN GPE)
- draft-ietf-bess-evpn-prefix-advertisement-02 case 5.4 but with some aspects of case 5.1.
  Specifically:
  - In Figure 6, IP-VRF on NVEs 1 and 2 corresponds to the Neutron router
  - I am not sure why Figure 6 did not show MAC-VRF 10 in between the
    IP-VRF instances, as shown in Figure 2 for case 5.1. The IRBs facing
    VXLAN would be in between the IP-VRF instances and the MAC-VRF 10
    instances.
  - MAC-VRF 10 corresponds to the Neutron network that connects the
    Neutron routers to upstream (physical) routers
  - IRB-1 and IRB-2 correspond to the Neutron router interface to the
    Neutron network that connects to upstream (physical) routers
  - MAC-VRFs 1, 2, and 3 correspond to tenant networks behind the Neutron
    router
  - Matching a vendor implementation, regarding the many options in
    section 5.4:
    (1) GW IP = 0
        Only route type 5 is advertised, no route type 2
    (2) The DGW implementation will use the VNI and next-hop of the
        RT-5, as well as the MAC address conveyed in the Router's
        MAC extended community
    (3) The RT-5 for SN1/24 has a GW-IP=0, DGW1 does NOT refer to RT-2
    (4) NVE1 will identify the IP-VRF for an IP-lookup based on the VNI
        and the inner MAC DA

The interesting part is in Section 5.1 (3):

    Based on the MAC-VRF10 route-target in DGW1 and DGW2, the IP
    Prefix route is also imported and SN1/24 is added to the IP-
    VRF ... pointing at the local MAC-VRF10.

The route target is associated with MAC-VRF10, yet somehow the prefix route is imported to IP-VRF.
How did DGW determine which IP-VRF?

I believe the same representation and the same issue applies on the NVE side as on the DGW side.
My answer for the NVE side: This is where the router association comes into the picture.
The router association is associating the bgpvpn's MAC-VRF with the router's IP-VRF.

Now going one step further, what I would like to support eventually is a Neutron router (IP-VRF) with two different interfaces (IRB) to two different bgpvpns, each representing a different MAC-VRF (e.g. MAC-VRF10, MAC-VRF11), where each MAC-VRF has a single bridge table and a single VNI.

Based on the received IP prefixes in each bgpvpn, different routes would be populated in the Neutron router (IP-VRF), each pointing to one of the two router interfaces leading to one of the two VNIs.

If each received route type 5 contains only one RT, then under either multiple VNI proposal, this could be achieved.
If the received route type 5 contained the RTs corresponding to both MAC-VRF10 and MAC-VRF11 but only the VNI corresponding to MAC-VRF 10?
Using the algorithm in http://docs.openstack.org/developer/networking-bgpvpn/future/attributes.html#vnid-attribute, the route would not be accepted.
Using the algorithm that I proposed in #3 above, the route would be accepted.