EVPN Using EBGP without an Additional IGP - introduce evpn.as for use in default RTs

[jbemmel]

Looking at https://www.ipspace.net/Data_Center_BGP/BGP_in_EVPN-Based_Data_Center_Fabrics

The way things are currently modeled, we can only realize that topology using bgp.local_as tricks and custom allow-own-as knobs. The reason is that EVPN route targets default to <bgp.as>:<vlan.id>, and hence won't match in an EBGP topology

If we were to introduce an evpn.as parameter and configure evpn.rt as \<evpn.as or bgp.as\>:\<vlan.id\> we could instead assign every node its own bgp.as value and simplify the configuration.

Any thoughts or objections?

[ipspace]

What you're describing is pure EBGP case, and the handling of RTs is a well-understood problem. Cumulus deals with it by ignoring the AS number in the RT, Nexus OS has a nerd knob... It has nothing to do with bgp.local_as -- that's caused by the crazy desire to run IBGP over EBGP because vendors can't get their shit together and implement EVPN properly -- or allow-own-as -- that's caused by another desire to use the same AS number on all spines while ignoring the realities of what that implies. All these things are also well-understood by the few people who want to know the details, and glossed over in vendor designs.

It somewhat surprises me that most EVPN platforms (apart from the ones I implemented ;) claim to handle EBGP-only design, and yet we're still having this discussion.

Ranting aside, what you're proposing would break the moment you'd get another idea to build a non-trivial topology (hub-and-spoke VLANs emulating private VLANs come to mind), but we already have the behavior you want -- the AS part of RT/RD values for global VRFs is built from global bgp.as or vrf.as (when there's no global bgp.as). We just have to extend that behavior to VLANs instead of building VLAN RD/RT values on-the-fly in node_post_transform hook. It probably makes sense to use evpn.as as the fallback value, as you might build an EVPN network without VRFs.

[jbemmel]

vrf module does this: https://github.com/ipspace/netlab/blob/dev/netsim/modules/vrf.py#L44

def get_rd_as_number(obj: Box, topology: Box) -> typing.Optional[typing.Any]:
  return \
    get_from_box(obj,'bgp.as') or \
    get_from_box(obj,'vrf.as') or \
    get_from_box(topology,'bgp.as') or \
    get_from_box(topology,'vrf.as')

SR Linux has no knobs to ignore the AS part in RTs, they have to match in order to be considered part of the same service.
The *:VNI approach by Cumulus/FRR is not supported (for reasons I am not privy to, but could imagine having to do with scalability and/or breaking existing deployments)

Since RTs are based on each node's bgp.as value, what I meant to say is that currently for srlinux I can only make EBGP work using bgp.local_as hacks.

In my mental model, the service lives in the "overlay" whereas the EBGP AS values are part of the "underlay". Different vrfs (e.g. representing different tenants) would each have different overlay AS values.

The behavior we currently have for vrfs does not get me what I'm looking for, because it still uses the node specific underlay bgp.as value first. A global single evpn.as value, optionally extended with a per-vrf generated vrf.evpn.as value (e.g. based of vrf.id) could work

[jbemmel]

Note that I thought it would be possible to implement *:VNI matching using custom import policies like:

community-set VNI1234 {
        member [
            .*:1234
        ]
    }

but it turns out that is not currently an option.

[ipspace]

Nah, that's too complex. We'll create consistent RD/RT in the data model. As for

The *:VNI approach by Cumulus/FRR is not supported (for reasons I am not privy to)

... it might have to do with doing sane things instead of misusing a technology in ways it was never designed to be used.

FYI: I am not a great fan of all the shortcuts Cumulus took to get things to work.