[IBN] Modeling Intent: The Data Models That Don’t Collapse at Scale

If the first article of this series was the “you need a closed loop” argument, this second article is the part everyone asks for next, usually with a skeptical squint:

“Okay. Show me the intent.”

Not a PowerPoint abstraction, a vendor demo, or a set interface xe-0/0/0 unit 0 family inet address… wrapped in a Jinja template.

Show me what intent looks like when:

That’s what we’re doing here.

We’re going to build an intent model the way you build a software interface at scale: stable contracts, strict types, explicit invariants, and testable expectations.

And we’ll do it while keeping one promise:

When teams first “model intent,” they end up accidentally building a vendor-neutral CLI.

They create YAML like this:

It feels structured, right? It’s in Git, it has indentation… it must be modern. Right?

And it collapses, fast. Because that’s not an intent, that’s just a configuration expressed in a different syntax.

It doesn’t answer the fundamental questions the business actually cares about:

Intent modeling starts by refusing to model “how to configure devices” and instead modeling “what the network is meant to provide.”

The easiest way to do that is to think in domain objects.

IBN models fail when they either:

The sweet spot is a small number of domain objects that map to how networks are actually operated and reasoned about.

At scale, “tenant” is the unit of ownership, isolation, and blast radius.

A tenant isn’t just a VRF name. It has:

If your model doesn’t put tenants first, you’ll end up putting “meaning” into device tags and spreadsheets. That is how drift is born, so it is time for you to avoid this approach if you want to adopt intent-based networking.

These are deceptively simple and incredibly powerful.

“Prefix P must be reachable from region X” sounds trivial until you operationalize it:

Reachability intent is about stopping the argument over configs and starting to assert outcomes.

This is where real networks go to die if you don’t model it.

Routing policy isn’t “route-map 10 permit.” Routing policy is a contract:

At hyperscale/service-provider scale, routing policy intent is often more important than IP addressing.

Not everyone needs SR policies on day one, but everyone needs constraints:

The key is not to model “RSVP vs SR vs static.” The key is to model the constraint and let compilers map to mechanisms.

Security intent must be expressed in business terms:

And then, critically, security intent must tie to evidence:

This is the “guardrails” layer for engineering quality:

Reliability intent prevents your design from slowly degrading as exceptions accumulate.

This is the part most teams bolt on after incidents. Instead, it should be modeled up front.

Observability intent is not “we have dashboards.” It’s:

If you don’t model observability intent, you end up with:

Let’s build a starter schema set that could credibly live in a production repo.

Two design principles before we write any YAML:

We’ll say “Customer C may export only these prefixes and only to these parties.”
We will not say “apply route-policy CUSTOMER-C-OUT on neighbor x.x.x.x.”

This is the software-engineering trick that changes everything.

If “a prefix list may be either IPv4 or IPv6” is encoded as a string, you will ship bugs.

If it’s a typed object validated by a schema, the bad PR never merges.

This is not a “toy,” because it expresses:

And it still doesn’t mention “Junos vs XR vs EOS.” And that’s intentional!

You can implement validation in many ways. The core is the same: the shape and semantics are enforced before deployment.

A pragmatic and popular pattern:

Why this matters: the failure mode at scale isn’t that engineers don’t know networking. The failure mode is that a slight formatting ambiguity becomes a major deployment issue.

IBN prevents ambiguity from existing.

Now we get to the part that transforms “intent modeling” into “intent operations.”

Most teams stop after compiling the config.

IBN doesn’t stop there. It outputs expectations: a machine-readable statement of what the network should look like if the intent is being met.

Think of expectations as the “unit tests” of your network’s runtime behavior.

Because it forces you to answer:

And because it unlocks automation that isn’t dumb:

The compiler might generate an expectations file like:

Notice what this does:

This is where your earlier protocol list matters in the real world:

The validator doesn’t need to be omniscient. It needs to be consistent, scoped, and continuously improving.

At scale, you’ll often encode ranges and invariants, not exact values:

Likewise for ACL counters: you often encode “plausible bounds” rather than precise rates.

That’s how you avoid the “monitoring that cries wolf” problem, another common cause of model collapse.

Multi-vendor isn’t a complication to hide. It’s a forcing function that proves whether your model is actually intent or just an abstraction of one vendor.

Here’s the fundamental rule:

When you do this right, your system evolves like a compiler toolchain:

A classic failure mode is adding vendor knobs into the intent model:

The moment you do that, you’ve abandoned intent and built a multi-vendor config repository.

Instead, you encode:

Example: your SoT says:

The intent stays the same. The renderer output differs. This separation is what makes IBN survivable.

If you want a minimal schema set that doesn’t collapse, start with these files (conceptually):

And one more that people forget:

If you adopt that as a design law, your model will remain coherent even as:

Because you aren’t modeling knobs. Instead, you’re modeling what you actually mean.

In the following article, we will take this exact schema approach and show a real repo layout, including how we can separate intent/, schemas/, sot/, compiler/, validator/, and simulations/, plus how PR validation gates work, so invalid intent never ships.

See you then!

Leonardo Furtado