>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.
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: bess-evpn- prefix- advertisement- 02 case 5.4 but with some aspects of case 5.1.
- 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-
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. docs.openstack. org/developer/ networking- bgpvpn/ future/ attributes. html#vnid- attribute, the route would not be accepted.
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://
Using the algorithm that I proposed in #3 above, the route would be accepted.