Extending EVPN to MPLS environment

[ipspace]

It totally surprised me, but EVPN with MPLS works on Arista EOS with minor modifications to the EVPN configuration template -- all I had to do (apart from a few ridiculous nerd knobs) is to list VLANs in the BGP process.

To implement MPLS transport in EVPN, we'd add evpn.transport attribute that could be set to mpls (default value would be vxlan for backward compatibility). MPLS transport capability would be controlled by a device feature flag, preventing the need to update existing templates.

The transport will have to be VXLAN or MPLS but not both; I'm not brave enough to dream about implementing mixed MPLS/VXLAN EVPN environment, and trying to figure out which encapsulation to use with which BGP neighbor.

Current EVPN code generates VLAN service, bundle service, or IRB service based on vxlan.vlans attribute. We should replace that with evpn.vlans node attribute. Its default value would be vxlan.vlans attribute unless the evpn.transport is set to MPLS in which case evpn.vlans must be specified. The final evpn.vlans list in the node data would be the authoritative list of EVPN-enabled VLANs.

We could do the same for VRFs -- if the VRF has evpn.transit_vni or if the VRF is specified in evpn.vrfs then the VRF gets EVPN route targets. When missing, the evpn.vrfs list would be generated from VRFs that have evpn.transit_vni attribute.

This change should keep the existing VLAN data structures that are used to generate EVPN configuration templates intact, although I would eventually ask everyone to consider updating the templates to use evpn.vlans and evpn.vrfs lists for consistency.

Any objections or suggestion @ssasso @jbemmel?

[ssasso]

No objections on my side.

[jbemmel]

The condition for vrfs to be included in the list should be whether they have evpn: enabled, with or without transit_vni

[ipspace]

I would go for an explicit list of VRFs (evpn.vrfs) with the default value being compiled from whatever is needed for backward consistency. Right now that's evpn.transit_vni, but of course we could say "whenever evpn is mentioned in the VRF, add it to the evpn.vrfs list.

[jbemmel]

The evpn.transit_vni attribute is specific to vxlan, in mpls case each router calculates and signals its own label value.
Shall we use a different attribute to signal the use of symmetric/asymmetric irb?

Say evpn.mode = symmetric_irb / asymmetric_irb (and for vxlan evpn.transit_vni would imply symmetric_irb)

[ipspace]

Not sure symmetric/asymmetric IRB applies to MPLS-based EVPN at all, at least from the data mode point of view. If you pull all VLANs in a VRF into all nodes (plus the not-yet-existing "vlan.create_interface") you get asymmetric IRB. If you don't do that, you have symmetric IRB (assuming you're redistributing connected prefixes into RT5).

Am I missing something? Links to documentation saying otherwise would be appreciated.

[jbemmel]

See https://datatracker.ietf.org/doc/html/rfc9135#section-4.2 - symmetric/asymmetric model affects evpn signaling, and applies irrespective of the transport chosen. In case of MPLS, on SR OS one needs to choose whether to create an EVPN tunnel VPLS (for symmetric) or not. It needs an EVI and route targets for matching RT5 prefixes, but no transport_vni. Conceptually, the EVI/RT could come from the VRF (like vlan bundle case)

[jbemmel]

Default should be ‘’’symmetric_irb’’’ imho

[ipspace]

Thanks for that gem ;) and opening another can of worms ;)) It effectively describes intra-VLAN forwarding based on host routes (that would require proxy arp to work), not the inter-subnet forwarding for RT5 IP prefixes.

The way we configure EVPN at the moment, that doesn't apply, as we configure EVPN bridging for all stretched VLANs in a VRF, and symmetric IRB applies only to RT5 IP prefixes because the ARP tables on hosts point directly to egress host MAC address in case the two hosts are in the same subnet.

I'm sure we'll have great fun when we finally get there...

[jbemmel]

Reading this again, I'm guessing you mean for evpn.transport to be a global parameter, and not per VLAN (at least to start)?

[ipspace]

I would start with evpn.transport begin global/node parameter, at least I see initial configuration templates working along these lines.

I have no problem making it a VLAN parameter as well, copying the global parameter into global VLANs (likewise for individual nodes) and then let the VLAN data merge do the rest of the job. I don't know how many platforms would support this level of selectivity though, and I don't want to think about mixed scenarios where some PE-devices (of the same VLAN) support only VXLAN and others support both.

[jbemmel]

There is also the MPLS-to-VXLAN stitching use case; on SR OS this involves a VPLS service with 2 BGP instances (different RDs, same or different RTs).

We could do like we did for VRFs with transit_vni and model this as separate vlans with matching id (1 referencing the other by name). We could also leave it out of scope for now, and let users pick one or the other

[ipspace]

Let's keep things simple and ship something ;)

[ipspace]

@jbemmel: the initial code is in the evpn branch. No idea how broken it is, the CI tests look good, but then we don't have much EVPN coverage. More tomorrow (or in a few days)...