There’s a lot of hype around intent based networking. Some vendors seem happy to slap the term on anything that moves. But intent based networking, apart from the marketing hype, is a very compelling shift in network operations that I truly believe network engineers, architects, IT managers, and CIOs must pay attention to.
You see, especially in large environments, network operations is difficult to do well because of inconsistent practices, a lack of visibility, inefficient device-by-device configuration, and limited vendor tools. It’s a real problem that needs to be solved.
Using a closed loop CI/CD network operations workflow provides a framework to solve this problem and make NetOps more efficient, consistent, and aligned with the business’s intent. A true intent-based networking solution is about a workflow that compares the known network state with the intended state, and it’s about taking real action autonomously when there’s some sort of discrepancy between the two.
This is what Apstra calls the “self-operating network”, and this is what sets them apart from the hype.
Levels of Intent Based Networking
Mansour Karam, CEO and Founder at Apstra, explained in a presentation at Networking Field Day 19, that IBN can be seen as having varying levels of maturity. I read this once in a Network World article written by Sasha Ratkovic, and I found that it made a lot of sense.
According to Sasha, there are 4 basic levels of IBN:
Level 0: Basic Automation
Level 1: Single Source of Truth
Level 2: Real-time Change Validation
Level 3: Self-Operation
In the NFD presentation, Mansour explained that many vendors making an IBN claim actually function at level 0 or level 1. This means that most vendors that use the term “intent based networking” are doing only some sort of network automation and providing some sort of sophisticated network visibility.
Though these are certainly valuable advancements in network operations, Mansour argues that it really isn’t intent based networking. The true goal is to get to level 3, or achieving the dream of a self-operating network.
So How Do We Get There?
Apstra makes it very plain that to get to a self-operating network, we need to get away from proprietary network fabrics, we need to use loosely coupled architectures, and we need to avoid management systems provided by the networking vendor. These are no easy tasks, but that’s basically what Apstra is trying to do.
But how is that actually done?
First, Apstra starts by abstracting everything in the network as lines of code, and I mean everything. Every device, every interface, every IP address, every BGP configuration. Now the network can be looked at whollistically in a programmatic manner. What that means is that since the network and all its components exist as lines of code, scripts can be run against them to gather real-time information and make changes.
This isn’t just basic network automation and visibility, though (levels 0 and 1 according to Sasha). Since everything exists as lines of code, the real-time network state including individual device configurations can be compared to a reference architecture, or what Apstra calls a blueprint, which represents the intent.
Put into a CI/CD workflow, we can say that brings us to level 2, continuously monitoring and validating the network. But how do we make the jump to a level 3 self-operating network?
Apstra uses something called “interface maps” as the actual glue between the abstracted network device and the actual physical device. Interface maps exist in the raw as JSON payload which is just structured data representing the mapping. Think of it like a driver we use for software to interoperate with a physical computer or device. There are also pre-defined pools of resources, such as ASNs, IP addresses etc, that the intent based networking system, or IBNS, can pull from.
In this way the network abstractions, or logical representations of network devices and configurations, get mapped to actual hardware, called device profiles.
These components all work together in a complete and closed loop workflow allowing Apstra to look at the entire network as a whole, compare known state to a reference architecture (intended state), and kick off automated actions to fix discrepancies.
What Sets Apstra Apart
The goal of intent based networking isn’t only telemetry and network validation. For a mature IBNS, those are components of an entire system that then uses that information to take appropriate action, without human intervention, to fix deviations.
This is why I believe a true intent based networking solution is so much more than orchestration, and why I agree with Mansour that so many vendors using the term “intent based networking” aren’t actually doing much more than advanced orchestration.
Pay attention to what the vendors say when they mention their intent based networking solution. If there isn’t an element of continual validation and some sort of autonomous activity to bring known state in line with intended state, I might suspect that they’re using the term incorrectly.
Apstra is clearly different from most other vendors that use the term “intent based networking.” The difference between level 2 and level 3 intent based networking is not a small step, but indeed a huge leap in the NetOps paradigm.