Untie EVPN Bundle Services from VRF?

[ssasso]

I know I'm opening a small can of worms, but I'm just trying to understand if such kind of proposed refactoring may be worth it or not.

Currently, EVPN Bundle Services are strictly tied to VRFs. I guess that has been done to simplify implementation and user experience, to avoid creating a bundle object on the topology and reusing vrf data (including rt and rd).

Technically speaking, if I'm not wrong, that's not really true: you can have VLAN Bundles without IRB, doing just bridging.

The current implementation works fine with EOS and Aruba CX (and I guess also SR Linux), but even if I create a vlan with mode: bridge it creates a L3 VLAN interface, belonging to a VRF, with no ip addresses.

I.e.:

interface Vlan1000
 vrf tenant
 description VLAN red (1000) -> [h1,s1,h2]

That could work anyway... unless you start doing something with junos.

Actually, not because of the interfaces/vrf mapping, but because we are using the same route distinguisher for the VRF itself and the VLAN-aware bundle (RD and RT values assigned by VRF module are used to configure the VLAN bundle).

error: routing-instance vlan_aware_tenant has duplicate route-distinguisher 65000:1: as routing-instance tenant

Could it be worth the effort to untie VLAN bundles from VRF?

[ipspace]

I know I'm opening a small can of worms, but I'm just trying to understand if such kind of proposed refactoring may be worth it or not.

No?

Currently, EVPN Bundle Services are strictly tied to VRFs. I guess that has been done to simplify implementation and user experience, to avoid creating a bundle object on the topology and reusing vrf data (including rt and rd).

Exactly, particularly as there's not much demand for the EVPN bundle services (we had zero users asking for it on platform X IIRC).

Also, don't EVPN RFCs/drafts use the terminology L2 VRF?

Technically speaking, if I'm not wrong, that's not really true: you can have VLAN Bundles without IRB, doing just bridging.

Correct.

The current implementation works fine with EOS and Aruba CX (and I guess also SR Linux), but even if I create a vlan with mode: bridge it creates a L3 VLAN interface, belonging to a VRF, with no ip addresses.

You could always decide not to do that in the configuration template (or device quirk). I just wanted to have an interface in case someone decides they absolutely want to have something attached to a VLAN (like a VXLAN tunnel in Linux case), and it was better to err in the direction of one interface too many.

interface Vlan1000
 vrf tenant
 description VLAN red (1000) -> [h1,s1,h2]

In this particular case, there's no need to put the interface in the VRF as it has no IPv4/IPv6 addresses. Yet again, I think this should be a device-specific decision, in most cases we're OK with it.

That could work anyway... unless you start doing something with junos.

Yeah, I heard that many things are different on Junos 🤦‍♂️

Actually, not because of the interfaces/vrf mapping, but because we are using the same route distinguisher for the VRF itself and the VLAN-aware bundle (RD and RT values assigned by VRF module are used to configure the VLAN bundle).

In which case it would be really easy to set a flag on the VRF (for example, evpn.l2vrf) saying "this is a L2 VRF for the EVPN bundle purposes", and it would be perfectly OK to set that flag as a "service to the wider community" in the EVPN module. You could then not create a Junos VRF if it has this particular flag.

Would that approach work for you?

[jbemmel]

Would it be possible to use the existing model, in which a L2 vrf could simply be modeled as a vrf having both vrf.af.ipv4=False and vrf.af.ipv6=False?

[ssasso]

You could then not create a Junos VRF if it has this particular flag.

that could work for L2 only (mode: bridge vlans). But will be broken again when using IRB with VLAN bundles. So it won't solve the entire problem.

The alternative I was thinking was to use a JunOS quirk to allocate a different RD for the vlan-aware macvrf. But I was also thinking about the fact that this could be a "generic" problems that we may encounter again (which is the reason I opened the discussion). - In any case I can do the quirk for JunOS and postpone (or reject) any other decision.

[ipspace]

that could work for L2 only (mode: bridge vlans). But will be broken again when using IRB with VLAN bundles. So it won't solve the entire problem.

Didn't we already have an implementation of L3VRF + VLAN bundle in Junos? IIRC I had to create some crazy stuff to get away from that.

The alternative I was thinking was to use a JunOS quirk to allocate a different RD for the vlan-aware macvrf.

That might be the easiest solution for the moment. When the same problem pops up in multiple places we can try to find a more generic solution.

[ssasso]

Didn't we already have an implementation of L3VRF + VLAN bundle in Junos? IIRC I had to create some crazy stuff to get away from that

That was a bit different.

When using family ethernet-switching (Junos in "enterprise config style") by default you are (more or less, won't digress more) forced to use the default-switch instance if you want to use trunk ports (and default-switch is a vlan-aware bundle with all the vlans which are declared at "top level").

What you did was to create different mac-vrf (one for each vlan) in simple vlan mode (vlan-based), which make Junos interop with other non-bundle implementations. That has the limitation to not work in case of trunk ports, but we are ok with it for now.

What I am implementing now is the "more real" vlan-aware bundle service, with a mac-vrf for only a specific set of vlans (and different mac-vrf for different sets). This will still have limitations with trunk ports, btw.

I will create a PR with the "additional" RD quirk in the next few days.