![[IBN] What “Intent-Based Networking” Actually Means](https://media.beehiiv.com/cdn-cgi/image/fit=scale-down,quality=80,format=auto,width=720,onerror=redirect/uploads/asset/file/4f0b72d7-3c75-4bda-aab7-0b4b80a55543/ibn1.jpeg)
I recall creating a survey for new newsletter subscribers, asking eight key questions about their content preferences and frequency. I also added an open-ended question for free feedback. One question stood out, inspiring me to craft a series of posts addressing this subscriber's inquiry:
“Go deeper and more specific about what it actually looks like to build an intent-based network. What are the system components, and what do they do? Where do they run? How are they maintained? How do you introduce them into existing infrastructure? Even more specific: what does the repo layout, pipelines, and deployment look like for this system?”
Ready to begin?
A few years ago, I watched a network team do something that looked perfectly reasonable… until it wasn’t.
They had a widespread incident triggered by a “simple” routing policy change. One engineer adjusted a BGP export filter for a single customer. Another engineer, somewhere else, fixed a related reachability issue by “just patching it on the box” because the customer was screaming and the maintenance window was closing. A third engineer later pushed an automation job that reapplied what Git said was true, overwriting the emergency patch, because Git was “the source of truth.”
The funny part of this mess was that everyone involved did what they believed was the right thing!
The config in Git was stale, but “approved.”
The CLI patch was correct, but “invisible.”
The automation was consistent, but “blind.”
So, the network oscillated between two realities: the reality people thought they were operating in, and the reality packets were actually living in.
If you’ve ever lived through that kind of drift, where your tooling is working, your engineers are competent, and your outcomes are still chaotic, you already understand why intent-based networking (IBN) exists.
But there's always a catch, there isn't? The problem is that most IBN explanations stop at philosophy, and that is a fact.
This article is the opposite. It’s the “concrete” blueprint: what “intent” really is, what it is not, and the system components you must have if you want to claim you’re building an intent-based network; whether you’re operating a data center fabric, a service provider core, or a global edge.