SR Linux: Changes to support release 25.3.1

[jbemmel]

• Fixes extended community filtering

Note: not backwards compatible...

Fix: #2058

[ipspace]

Thank you!

On a tangential note: do we want to push people to 25.3.1? IIRC @hellt told me that 24.10 is a LTS release, so it might be better to stay there.

I will also try to stay diplomatic and not mention what I think about companies that change their APIs with every other release and haven't discovered versioned APIs yet (something that Cisco figured out around IOS release 10.0 in 1990s).

[jbemmel]

I agree we should stay with 24.10 for now, I just wanted to record what changes would be needed. Someone who needs 25.3 could pick up this branch and run with it

I wanted to test 25.3 to see if it fixes the bgp prefix filter issue - it doesn’t

[ipspace]

Another crazy idea:

I agree we should stay with 24.10 for now, I just wanted to record what changes would be needed.

What if we implement our own API versioning for the beautiful versionless™ SR Linux API? We could use the srl_api_version (wanted to proposed srl_api_**** but I guess we have to stay SFW ;), set it based on image version, and use it for weird stuff like "I need prefix in front of the prefix-set"

[jbemmel]

Another crazy idea:

I agree we should stay with 24.10 for now, I just wanted to record what changes would be needed.

What if we implement our own API versioning for the beautiful versionless™ SR Linux API? We could use the srl_api_version (wanted to proposed srl_api_**** but I guess we have to stay SFW ;), set it based on image version, and use it for weird stuff like "I need prefix in front of the prefix-set"

The SR Linux API has YANG if-feature statements sprinkled throughout. I was thinking that we might be able to use that as a kind of "versioning" mechanism; however, it appears they did not apply this to the match prefix prefix-list change

We could collect 'facts' from the running container, such as its version

 A:admin@r# info from state /system information version
    version v25.3.1-149-g5f74f68b94

and conditionally insert prefix: as needed

[hellt]

v25.y.z vs v24.y.z is a pretty clear versioning scheme

At this yearly boundary we introduce braking API changes.

In the early days breaking changes crept in to the in-year releases, but this has been improved to a more rigorous versioning scheme wrt NBC changes.

So versionless is not a correct statement

[jbemmel]

So versionless is not a correct statement

As far as I know, there is no way to address the 25.3.1 SRL container using a versioned 24.10.3 API. In that sense, it is versionless - only a single (implied) version of the API is available, the latest one available at the time of release

We are not talking about "having a version number" - all software has that

If SRLinux were to have a versioned API, there there would be no such thing as "breaking" changes. Older clients using previous API versions would continue to work. Alas, SRL does not offer that

[hellt]

---

[hellt]

Yes, there is no such thing in SR Linux like a management server supporting both v24 and v25 APIs at the same time.

What vendors offer this multi version API support?

[ipspace]

What vendors offer this multi version API support?

Microsoft Azure ;) I'm pretty sure AWS does as well.

Do remember that API is a long-term contract with your users who (you hope) are investing significant resources into tools using it.

[hellt]

Yup
We we also have multiple versioned apis implemented by our controller system with transformation plugins that enable this.

And as azure doesn't let you configure network devices and switches directly, you are free to use a controller for it. The complexity of this belongs to a controller in all of these cases.

It is just here we were talking about network apis implemented by the devices and then somehow suddenly dropped into cloud apis that have very little common ground with a NOS

[ipspace]

Great job. No changes in integration test results for 24.10.3 and improvements in 25.3.1.

Thank you!