Implement bgp bandwidth auto for SR OS

[jbemmel]

• Enable extended communities for EBGP inside the plugin, for all platforms
• Also adds MED and localpref

[ipspace]

The 'add communities to EBGP' code does nothing as you modify a local variable but not store it. Anyway, we need to enable extended communities for EBGP only if the device is able to set Link Bandwidth in outgoing EBGP updates (for the moment, only EOS and FRR/CL).

Also, it looks like the changes to SR Linux / SR OS templates are not included in this pull request.

[jbemmel]

The 'add communities to EBGP' code does nothing as you modify a local variable but not store it.

'get' returns a reference, I verified that the topology output contains the 'extended' community for EBGP. You are correct that the code assumes bgp.communities is already defined; if it is not, it would be modifying a local variable

Anyway, we need to enable extended communities for EBGP only if the device is able to set Link Bandwidth in outgoing EBGP updates (for the moment, only EOS and FRR/CL).

Updated, SR OS does support outgoing updates. There is a missing 3rd type: Locally add a community to incoming routes

Also, it looks like the changes to SR Linux / SR OS templates are not included in this pull request.

Added now

[ipspace]

Updated, SR OS does support outgoing updates. There is a missing 3rd type: Locally add a community to incoming routes

That's what bgp.bandwidth.in: auto (or just bgp.bandwidth: auto) is supposed to be doing, or did you have something else in mind?

Added now

Thank you, merging.

[jbemmel]

Updated, SR OS does support outgoing updates. There is a missing 3rd type: Locally add a community to incoming routes

That's what bgp.bandwidth.in: auto (or just bgp.bandwidth: auto) is supposed to be doing, or did you have something else in mind?

There are 3 knobs:

1. Add bandwidth extended community to incoming EBGP routes
2. Accept (trust) extended community on incoming routes
3. Send extended community on advertised routes

#1 is currently being called "in", and #3 is "out". I didn't add #2 yet, because there is no flag for it

[ipspace]

There are 3 knobs:

On SR OS ;)

2. Accept (trust) extended community on incoming routes

I could add bgp.bandwidth.in: accept keyword, but we're back to adding nerd knobs for one particular platform. Not sure anyone else has that same nerd knob; if you want to scrub communities, you do it with a route-map.

[jbemmel]

There are 3 knobs:

On SR OS ;)

2. Accept (trust) extended community on incoming routes

I could add bgp.bandwidth.in: accept keyword, but we're back to adding nerd knobs for one particular platform. Not sure anyone else has that same nerd knob; if you want to scrub communities, you do it with a route-map.

I'm perfectly happy with leaving things the way they are for now, merely pointing out that there is some asymmetry in the semantics around "in" versus "out" that could be confusing to some people