[IBN] What “Intent-Based Networking” Actually Means

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!

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.

Traditional network automation is often built on the belief that:

That belief holds right up until it doesn’t; usually at scale, under pressure, and when failure modes emerge because the network is not a set of text files.

A network is:

Configuration is merely one lever in that system, and it’s the least honest one, because it can be “correct” while the network is objectively broken.

IBN begins when you admit this:

And that, my friend, changes everything.

Intent is a declaration of outcomes, constraints, and safety rules expressed in a form that’s:

Intent lives above vendor syntax and below hand-wavy prose. It’s not “we should have reliable routing.” It’s closer to:

These are operational truths you actually care about. IBN also forces a second step that most “automation” never gets to:

That’s the missing layer, because “desired state” without “proof of compliance” is just wishful thinking with better formatting.

If you remember nothing else, remember this:

An intent-based network is a closed-loop system.

It has three realities:

And then it has the loop:

Everything else, including UI, “AI,” and dashboards, is pretty much secondary.

If your system cannot continuously compare observed reality to intent and respond, you do not have IBN. You have config generation, and that's a totally different story altogether.

Teams name these things differently. Vendors package them differently. Some companies buy half of them and build the rest.

But every serious IBN implementation converges on the same functional components. I call them “the seven boxes” because once you see them, you’ll start recognizing them everywhere.

This is where intent becomes a product, not an idea.

If intent is free-form YAML, it will devolve into tribal knowledge. If it’s strongly typed and validated, it becomes a stable interface.

A proper intent layer includes:

This is the difference between “we store configs in Git” and “we operate a network as a software product.”

Anecdote from the trenches: the first time you enforce schema validation, people complain that you’re “slowing them down.” The second time it prevents a production leak (because a prefix-list would have matched more than intended), it becomes your most popular feature.

No intent system survives contact with reality unless it can answer a simple question reliably:

Inventory, topology, roles, allocations, underlay addressing, BGP sessions, tenants, VRFs, link capacity, optics, device capabilities, OS versions, and operational constraints.

In practice, “source of truth” is rarely one database. It’s usually a federation. Some examples:

IBN reads from this truth. Humans should not “just know” it.

This is where intent becomes actionable.

The compiler takes:

…and produces:

A compiler is not only a templating engine. It’s a translation layer from “what we mean” to “what the network must do,” including ordering and constraints.

And the moment you support more than one vendor, you realize why “intent” exists: it’s the only way to keep your higher-level logic stable while renderers vary.

This component answers questions that engineers ask implicitly, but automation often ignores:

A planner is where your operational maturity lives.

Example: You want to rotate BGP authentication or change the route policy on the edges. The planner knows:

Without a planner, “automation” becomes a way to do unsafe things faster.

The deployer executes the plan.

This is where the real world bites: device locks, commit semantics, transient failures, partial success, and concurrency.

A deployer in an IBN system must be:

It must also speak the protocols you actually operate with:

This is where IBN stops being a philosophy and becomes a control system. You cannot verify intent with “show run” screenshots.

You need continuous, machine-readable reality:

The telemetry layer must deal with backpressure, ingestion lag, and retention. It’s not “monitoring.” It’s the feedback signal of your control system.

This is the brain of IBN. It compares observed state to intent-derived expectations and then decides what to do.

And it must be opinionated, because “drift” isn’t a single category:

Reconciliation actions are similarly graded:

This is where IBN gets its reputation. If this layer is weak, you end up with expensive dashboards. If it’s strong, you get fewer incidents.

Let’s be specific, because my subscriber asked a fair question: where do these components run?

In real hyperscale/service-provider environments, you typically see a split:

Most commonly, Kubernetes; sometimes VMs; rarely bare metal, unless requirements demand it.

This is frequently overlooked, and it matters.

Collectors near the network reduce latency and improve survivability during core incidents. They also support scaling patterns such as sharded gNMI collectors.

You may run:

IBN does not remove humans. It removes invisible human impact.

You still allow CLI access because of reality. But you make it:

If “break glass” changes can persist silently, your IBN system will eventually become fiction.

Let’s ground this in a scenario nearly everyone recognizes.

You run an internet edge. You have multiple transits, peering, customers, DDoS constraints, and region-based preferences. Someone fat-fingers a community, and suddenly you export what you didn’t mean to export.

In a config-centric world:

In an intent-based world, you start earlier, and you end calmer.

Your intent says something like:

Now the system:

And importantly, the incident response becomes structured.

Instead of “something is wrong,” you get:

That’s the shift I've been saying here, on my posts: from heroics to systems.

It’s worth naming the traps, because teams repeatedly fall into them.

No. That’s configuration management.

If you cannot express outcomes and verify them continuously, you don’t have intent. You have version control.

Git is a record of what you think you deployed. It is not evidence of what the network is doing.

Useful, but insufficient.

Many catastrophic failures occur while configs look “fine.” BGP can be up and still wrong. Forwarding can blackhole with correct configs. A route reflector can diverge while everything “looks consistent.”

IBN treats control-plane and data-plane evidence as first-class reality.

No. Mature IBN means CLI cannot create an invisible truth.

Here’s a litmus test you can use on your own stack:

If you make a change to intent and merge it, can the system answer these questions without humans?

If the answer is “yes,” you’re doing IBN.

If the answer is “we can push config,” you’re doing automation.

Both are valuable, but only one is intent-based.

This article gave you the system and the minimum components.

The next pieces get even more concrete:

Because that’s where the real work and the real payoff live.

See you then!

Leonardo Furtado