On Mon, 22 Sept 2025 at 21:11, Tom Beecher via NANOG <nanog@lists.nanog.org> wrote:
- Current tooling usually gets written with current languages and frameworks. - Older tooling stays around until it's required to be replaced. - Everyone automates some things , nobody automates everything.
Coworker was looking at Ariasta AVD and it made me realise how little will any of this ever help the type of networks I work with. This higher-level provisioning addresses well the needs of DC nodes, but not DC edge or SP. And even cloudy shops don't care much about DC edge, as even hyperscalers largely write things like BGP policies by hand. Because you touch them very rarely, and for most they are very simple, there is not much to be won for a problem that is much harder to solve than bringing up interfaces. Does the community have any appetite for some type of gRPC BGP policy API? I'm thinking of a streaming API, with concerns for latency, possibly concerns for being SIMDable (otoh that may be ridiculous micro-optimization, as long as the API pipelines). The API would send pre-policy adjribin prefixes to some host over gRPC, and gRPC would respond with action that the device should take for that prefix (reject, accept, prepend, add/remove community etc). Of course we should recommend that vendors offer the ability to run the gRPC server on the local RE as well, so you can keep this entirely distributed without circular dependencies forming. I think very few would extract a lot of value from this. For us particularly almost all our config complexity is in BGP policies, and there is no work happening to reduce pain here. This would allow you to write your own policy engine in whatever language you want and then drop that server in any any-vendor RE for platform agnostic BGP policies. The alternative option, having some common policy language is far more unreasonable ask. -- ++ytti