🗒Well Intended Networking (#WIN): Model-driven Config-As-Code📓

Words are the most common form of abstraction, how we call things matters and naming is hard (“naming is communication”). A recent post about Intent Based Networking (#IBN) and its relationship to marketing and business outcomes reminded me about these topics, and I figured I’d spend a few words sharing my thoughts.

At Nokia — and (Alcatel-)Lucent as it was called before that — I have been fortunate to take a front row seat during the evolution of networking over the past two decades. I have experienced first hand how there is an increasing role of software (versus hardware), open source software (versus proprietary software) and automated (versus manual) configuration and operation. Our business and the associated value proposition is moving “up the stack” — for example, while Nokia still creates and sells our own networking chips (like #FP5 and #ReefShark), we are now increasingly involved in deployments that use merchant silicon (like Broadcom Trident/Jericho)

Intent Based Model Driven Networking (#IBMDN)

“Rough consensus and running code” — this informal motto of the IETF still rings very true to me. There sure is a lot of marketing material out there, and words and slides are easy to come by — but nothing conveys technical reality like running software. So please allow me to illustrate what one might call “intent based model driven networking” through a project on GitHub:

Sample configuration of an auto-config agent (YANG model based)

In order for network devices to perform their function, they need to be configured. This configuration consists of a long list of parameters and options, depending on which features we want to enable for our design. These options often represent trade-offs — we can enable IPv6 and have a larger addressing space available, but it will take more resources. We can do L3 routing (next hop lookup) on the leaves, or somewhere else. Thousands of choices and a combinatorial explosion of possibilities.

To reduce this complexity, there are familiar abstractions we can apply. For example, in the configuration illustrated above the “leaf” role is assigned to this node. That implies that there are (typically) hosts connected to its ports (as opposed to “spine” nodes for example). By assigning a role, we can now use this abstraction in the logic that provisions the node: If this is a “leaf” node, configure this. Else, configure that. Etc.

Amongst the items to be configured are IP addresses on the interconnecting links, and things like BGP peering on top of that. Given that the structure of these networks is very regular, it makes sense to algorithmically derive these parameters. All we need to specify is a prefix range to choose from — to avoid overlap with other existing networks — and the software can take it from there.

I do realize that a lot of this is mundane, even trivial, and I am hardly the first person to come up with this stuff. However, if we talk about “intent based networking”, I believe this is essentially what it boils down to: We introduce higher levels of abstraction and specify some constraints, and then the operational configuration is automatically derived from that. It is (or should be) a repeatable, consistent process that produces materially the same result for a given set of inputs — such that we can have standardized, well tested “golden” design configurations. Rinse and repeat

EVPN asymmetric versus symmetric IRB models

The EVPN standards have many options and some vendor specific variations. This article provides a nice overview of some popular design trade-offs, and the theory behind them. But…how does that play out in practice? “Running code“ please!

Given software based configuration of network devices, we can now easily introduce these additional abstractions:

EVPN configuration options integrated in the SR Linux YANG model

And then in the generated config, add some annotations to explain what is going on:

Annotated EVPN configuration

Within the same YANG system model, we can monitor resource usage, and compare one configuration with another:

VLAN-2-VNI resource mapping resources for the ‘symmetric IRB’ option

Well Intended Networking (#WIN)

In summary, there is much to be said about networking and the technologies and approaches used to solve problems associated with that. But at the end of the day, what we need above all is — and continues to be —

rough consensus and running code

Enjoy!