4 Byte BGP ASNs

[sdktr]

BGP ASN is typechecked to be a 2Byte value at the moment:
https://github.com/ipspace/netlab/blob/9cadf7cda2e2033b98b16c328655d90d61d100d5/netsim/data/types.py#L519C33-L519C33

Given the supported platforms for this module, is the a realistic limit? Can we simple relax the type check or do we need additional controls per platform we're serving, to indicate whether the 4B asn will work before finding out the hard way?

[sdktr]

The set of supported BGP features are already set per platform. So my proposal is to allow 4B ASN in the generic datamodel and implement a BGP 4b support boolean per platform. We need to analyse the used ASN and if it's a 4B and the new boolean is not True, this should error.

Example feature gate in a device:

netlab/netsim/devices/sros.yml

Line 34 in 9cadf7c

bgp:

Example check in the module logic that we could replicate:
https://github.com/ipspace/netlab/blob/9cadf7cda2e2033b98b16c328655d90d61d100d5/netsim/modules/bgp.py#L243C1-L252C19

[ipspace]

In principle: yeah, let's do it. However:

• Adding what you described is easy (and you got it exactly right), particularly as most devices support 4-byte ASN these days (Cisco IOSv might be the only exception).
• We also use BGP ASN in RD/RT for VRFs, MPLS/VPN and EVPN, and having a 4-byte ASN there opens a whole set of challenges

We would probably have to:

• Add similar capabilities check for VRFs, MPLS/VPN and EVPN (never checked how widespread support for 4-byte RD/RT is)
• Tweak the "what communities you want to advertise" knobs. Does "standard" mean "RFC 1997 and RFC 8092" or does it mean "only communities according to RFC 1997"

Any thoughts @ssasso @jbemmel

[ipspace]

Looks like even IOSv supports 4-byte ASN for RD/RT (at least it doesn't complain). I'll relax the ASN validation check, and we ever run into problems we'll either add a documentation warning saying "check what your devices can do" or implement feature checks.

[ipspace]

Implemented in 9942edd and 92c1263