Intent Based Networking certainly became a popular term over the last couple years. I don’t hear about it much anymore in terms of new and upcoming tech, though. I hear the term being used almost as a side comment when vendors say things like, “oh yeah we do intent based networking – it’s built right into our GUI.”
So after all the marketing hype, the buzzword bingo, and as much digital transformation as we can stomach, where are we with intent based networking in 2021?
At one point I really thought IBN was quickly headed for the panacea of autonomous networking. Closed loop validation and remediation – a network engineer’s dream. That’s definitely still out there, and I know a couple companies that haven’t lost sight of that. But for most IBN companies, I’m not sure that’s the focus anymore, at least not right now and at least not publicly.
IBN is all about abstracting the network as much as possible and treating it as a collection of inter-related objects. Treated as objects, physical and logical components of the network can be more easily organized into relationships, automated, orchestrated, and validated within a closed loop system. That’s the idea, at least.
At some point that workflow becomes a fully closed loop including autonomous remediation. In other words, the IBN platform knows what the network should look like or be doing, it notices a problem, and then it fixes it (and then checks it again). Today, that’s not really happening en masse among vendors, though I absolutely believe they can if they focused on it. So if that’s not the focus, what is?
In the process of building a system to [eventually] autonomously operate a network, an intent based networking system, or IBNS, needs to have its grimy little hands in every single part of the network down to each interface and each logical configuration on every switch, router, and firewall. Then it abstracts it all so that each component becomes a few lines of code in a database.
Possibly without meaning to, an IBNS has actually become a very powerful network visibility tool beyond just collecting flows and SNMP traps. The whole idea is that it can create relationships among network objects and their activity, which is how an IBNS can orchestrate a complex system using only a network operator’s intent.
Visibility is huge right now. Networks are more complex than they’ve ever been. Hybrid multi-cloud networks, SD-WAN overlays, data center fabrics, multiple protocols running everywhere one on top of the other. And network engineers in the trenches are doing all they can to troubleshoot one urgent network problem while another one comes into the ticket queue.
IBN vendors are catching on to this. I see it every day in their marketing. Instead of touting autonomous remediation and intent based orchestration, these same vendors are re-positioning their solutions as visibility tools the likes of which the world has never scene. Instead of intent based networking, you have intent based visibility, replete with exhaustive, granular, searchable information pulled directly from the single source of truth and stored in a relational database.
That’s where I think IBN is 2021. At least for now, it seems to be all about visibility and the ability to see relationships among network objects and their activity. Nevermind that correlation doesn’t mean causation. We’re networking professionals, and in our world, if the network blipped while you were tying your shoelaces, it was probably the firewall.
Thanks,
Phil
{networkphil} 
A well-explained article on intent-based networking. Thanks for writing this amazing post. It really clear all the doubts I have.
LikeLike
Hi Phil – good to read your thoughts and important to highlight this!
IBN has recently suffered from “intent-washing” of products but there is a serious side to it, including IETF activities to at least standardise descriptions and definitions: https://datatracker.ietf.org/doc/draft-irtf-nmrg-ibn-concepts-definitions/
The important thing for me is to realise that it isn’t a product, but an *approach* to designing, building and operating networks. The designer translates business intent to technical requirements; the network engineer then takes this “intent” and renders or fulfills it using automation and/or orchestration techniques; then she/he uses Assurance systems (in conjunction with other operational tooling) to verify that network is performing as expected. And if not, the config is modified to suit.
This has to happen across the *whole* network and not just one domain or the other, because then you’re just introducing more complexity and tech debt, but in order to do that you need a consistent and complete view.
I think we are starting to realise the shortcomings in our current approaches to network automation: in reality we need this kind of framework around it in order to deliver holistic service improvements and to guarantee that what we build faster, at greater scale and with more consistency really meets the need of the businesses we work for!
Thanks, Daren.
LikeLike