Configurable default BGP address families

[ipspace]

We never implemented a full-blown data model that would cover all possible nooks and crannies of RFC 8950 (#181), which is probably a good thing. Most of the combinations allowed by that RFC only get implemented together with a very specific feature (example: 6PE, IBGP-over-EBGP EVPN, IPv4-over-SRv6...) and should thus be implemented in the corresponding feature module.

The core BGP configuration module got the capability to disable individual transport sessions (for example, IPv4 transport session in IPv4-over-SRv6 scenario or IPv6 IBGP session in 6PE scenario) in #365. That functionality could be used by feature modules instead of manipulating the neighbor list directly. The bgp.sessions could be used, for example, by MPLS module instead of tweaking neighbors list when enabling 6PE.

We need another tweak to support designs like IBGP-over-EBGP EVPN: the ability to enable (or disable) the default address family on a transport session. For the EVPN use case, we need to disable IPv4 AF on the IPv4 IBGP transport session. I would suggest to add another BGP nerd knob called enable_default_af (or something similar) that would list session types on which a particular default AF should be enabled. The default value would obviously be:

bgp.enable_default_af:
  ipv4: [ ibgp, ebgp, localas_ibgp ]
  ipv6: [ ibgp, ebgp, localas_ibgp ]

In the EVPN use case, we'd enable IPv4 default AF only on EBGP sessions:

bgp.enable_default_af:
  ipv4: [ ebgp ]

This parameter would then be translated into enable attribute on the BGP neighbor; we could then use that attribute to add the neighbor activate (or similar) command to the configuration template (which does mean that this functionality would have to be added to configuration templates).

There's a nice side effect of implementing this: IBGP-over-EBGP design can be specified within the BGP configuration module features, alleviating the need for any EVPN-specific nerd knobs or custom plugins.

Any thoughts @jbemmel @ssasso?

[ipspace]

I decided to call the attribute bgp.activate because that's how it's called on multiple platforms using industry-standard CLI 😜. Test scenario is in tests/integration/bgp/local-as/leaf-spine.yml.

It should be relatively easy to modify the configuration templates, see changes to ios.j2 and eos.j2 in fd5849c

Next on the list: create an EVPN IBGP-over-EBGP test case using the new BGP attributes. Yeah, I have too much time today...

[ipspace]

Also, @jbemmel, if you don't like how the attribute is called, please chime in ASAP, it's still pretty easy to rename it.

[jbemmel]

I would prefer an ‘bgp.address_families’ attribute for each bgp peer, to iterate over in the template.

On SR Linux we “enable” or “disable” each address family, “activate” is vendor specific

Note that platforms can have limitations on the address families they support in the default vrf versus other vrfs (e.g. SR Linux supports evpn on default, but not inside other ip vrfs)

Like I did for SR Linux:

srlinux:
    ...
    bgp:
      address_families:
        ibgp: [ ipv4, ipv6 ]
        ebgp: [ ipv4, ipv6 ]

'localas_ibgp' could be added here too. For an IBGP-over-EBGP evpn design, this could become

    bgp:
      address_families:
        ibgp: [ evpn ]
        ebgp: [ ipv4-over-ipv6 ] ( i.e. ipv4 prefixes with ipv6 extended next hops )

[ipspace]

I would prefer an ‘bgp.address_families’ attribute for each bgp peer, to iterate over in the template.

We had this discussion a few times. There are a gazillion of combinations as everyone is using BGP as the kitchen sink control-plane protocol.

The BGP configuration module should (IMO) support only the creation of IPv4 and IPv6 transport sessions, and IPv4-AF-over-IPv4-session and IPv6-AF-over-IPv6-session. Everything else should be enabled/activated/whatever-you-want-to-call-it within the corresponding configuration template (example: EVPN).

The exiting bgp.address_families do not specify how you want to run IPv4 or IPv6 AF (example: IPv4-over-IPv6 transport) and what next hop you use (example: IPv6 next hop for IPv4-over-SRv6). I also don't want to expand that; I closed #181 for a reason).

Long story short: because some people insist on implementing designs that should never have been attempted (EVPN IBGP-over-EBGP) we need an attribute that controls the activation of default IPv4/IPv6 unicast sessions, and that's all I want to see in the BGP configuration module. Everything else belongs somewhere else.

On SR Linux we “enable” or “disable” each address family, “activate” is vendor specific

I don't care how it's called. We can go with "enable" if you wish.

Note that platforms can have limitations on the address families they support in the default vrf versus other vrfs (e.g. SR Linux supports evpn on default, but not inside other ip vrfs)

EVPN AF handling belongs to the EVPN configuration module.

[ipspace]

Like I did for SR Linux:

srlinux:
    ...
    bgp:
      address_families:
        ibgp: [ ipv4, ipv6 ]
        ebgp: [ ipv4, ipv6 ]

That was a hack that supported a very particular use case you had (IPv4-over-SRv6 IIRC).

For an IBGP-over-EBGP evpn design, this could become

    bgp:
      address_families:
        ibgp: [ evpn ]
        ebgp: [ ipv4-over-ipv6 ] ( i.e. ipv4 prefixes with ipv6 extended next hops )

And that's precisely what I don't want to see. These things belong to the technology-specific configuration modules, and should be configured there, and not in the BGP configuration module.

The only difference we could be discussing (if we were in the bikeshedding mood) is whether to set feature flags in the neighbor data structure (example evpn: True) or whether to store those feature flags as keywords in bgp.address_families dictionary. Guess which one is easier to handle in Jinja2 ;)

[jbemmel]

There is a reason for doing it like that: SR Linux insists on having at least 1 address family enabled per peer group. For a design like the above, it wouldn't work to have the generic bgp module create an "empty" peer group, and then have the evpn module enable the 'evpn' family in that group

It would be possible to define a bgp-peer-group macro that takes module-specific additions, and reference that from the evpn template. However, that would imply some restructuring - my current (easier) solution was to enable evpn within the generic bgp template: https://github.com/ipspace/netlab/blob/dev/netsim/ansible/templates/bgp/srlinux.macro.j2#L84

[ipspace]

There is a reason for doing it like that: SR Linux insists on having at least 1 address family enabled per peer group. For a design like the above, it wouldn't work to have the generic bgp module create an "empty" peer group, and then have the evpn module enable the 'evpn' family in that group

Ah, it's amazing how creative vendors are ;)

It would be possible to define a bgp-peer-group macro that takes module-specific additions, and reference that from the evpn template. However, that would imply some restructuring - my current (easier) solution was to enable evpn within the generic bgp template: https://github.com/ipspace/netlab/blob/dev/netsim/ansible/templates/bgp/srlinux.macro.j2#L84

I have absolutely no problem with that, I just don't want to push everyone in that same direction. I'm trying to keep different technologies as separate as possible, and conceptually I consider EVPN a different technology than BGP. Of course that always fails on individual platforms -- see for example the mess I had to make in VRF interface code, or VLAN definitions before we can create VLAN interfaces.

[ipspace]

Going from interesting theoretical discussions to a hands-on issue: should we use bgp.enable or bgp.activate? Would love to get that settled before adding any other stuff.

[jbemmel]

If that's the choice, then I would say keep what you have (bgp.activate)