What is Intent-Based Networking?

Intent-based-networking (IBN) is the shiny new object in networking. Analysts and vendors alike are touting it as transformative to the data center and Cisco’s CEO said “Intent-Based Networking will redefine networking for the next 30 years”. Apstra pioneered Intent-Based Networking and delivered the first and only complete system which enables Cisco, Juniper, Arista, HP, and white box customers to deploy an IBN system through the Apstra Operating System (AOS^®). We are experiencing a phenomenon called “intent washing,” which Gartner predicted would happen. Vendors are rebranding existing products as “intent-based”. Some are even rebranding complete product lines. It’s confusing to discern marketing and reality — the ads, white papers, and slides — vs shipping products that deliver on the value proposition of Intent-Based Networking.

In this article, I’d like to cut through this confusion by listing and defining the foundational aspects of an IBN system. I encourage you to spend the time to internalize them and use them as criteria when considering or evaluating new products.

Motivation

The main motivation behind IBN is to allow companies to run their networks reliably and cost-effectively while offering more agility and control, both in terms of new features and vendor choices. To achieve that, the hard problem is how to compose the complex infrastructure capabilities in order to serve business needs in the presence of constant change in device capabilities and business rules?

The composition problem is a consequence of the fact that today’s data centers act as scale-out computers and there is a need to compose this infrastructure consisting of compute, network, and storage. But this is only one dimension of this composition problem. Another one is how do you incorporate complex business rules and policies? Infrastructure capabilities, as well as mechanisms to consume them, are subject to constant change. And the situation with business rules is even worse, both in terms of the frequency and the complexity of the changes. Every time a change happens, you are required to perform some composition. If you take something out, is what is left still acting as a coherent whole? If you add or modify something, is the new composite valid? With a single compute virtualization node, the problem the operating system has to deal with involves partitioning of resources as well as dealing with isolation. But with the data center acting as a scale-out computer, the distributed operating system first has to perform composition and only then again resource partitioning and isolation. But if you fail at composition due to changes in infrastructure and business rules, you will never even get to consuming your precious and expensive scale-out compute resources.

When we first spoke about our vision of Intent-Based Networking, one aspect about IBN mentioned by analysts was orchestration, but there is much more than that. Orchestration is an execution workflow and is less concerned with the state. So in that model, it is assumed that someone else creates the single source of truth about the state of infrastructure and business policies; and that this state is then fed into the orchestration workflow. In IBN, that single source of truth, originating from intent, (which we define more precisely below) is at the core of the platform and drives everything else.

Definition

So what is the intent? At the highest level, intent is a declarative specification of the desired outcome. And the desired outcome is complete automation of the whole network service lifecycle, which consists of the following phases: design, build, deploy, validate. See our videos from Networking Field Day 16 for more details about what these phases entail.

At a high level, Intent defines the “what” not the “how”. A key observation is that intent is dynamic, and a fundamental requirement of an IBN system is that it should be capable of ensuring that intent’s expectations are met in the presence of change. And changes can come from either the operator (business rule change) or the infrastructure (operational status change).

In order to enforce that intent expectations are met, the IBNS has to be the single source of truth (regarding the intended state of both your infrastructure and your business rules) that one can programmatically reason about in the presence of change.

In the absence of this, you will be spending most of your time immersed in accidental complexity developing a coordination layer that synchronizes a growing number of sources of truth that come with different formats and semantics.

One can argue that “everything can be done in software” and so can the reasoning logic described above. In a worst-case example, one could envision writing a script that consolidates a set of all sources of truth scattered across various files and databases and then reason about the resulting output. Beyond simple automation tasks, the complexity of the system will quickly become unmanageable. Add the requirement for intent to be dynamic, and this solution becomes quickly unworkable

Reasoning about intent programmatically is the key enabler for the automation of all aspects of the service lifecycle such as design, build (including resource allocation), semantic validation, configuration rendering, expectation generation, test execution, anomaly detection, troubleshooting, change request validation, and refutation.

And reasoning about intent needs to be maintainable and testable in the presence of change. In order to achieve this, the IBN solution is required to have the following capabilities:

• Ability to easily extend the schema of this single source of truth to address new business rules and infrastructure capabilities.
• Ability to programmatically decompose the single source of truth into subsets of elements of interest as it grows in size and complexity. This decomposition is the key to deal with scaling issues — i.e. an architecture that results in every piece of logic reacting to every change in intent will not scale.
• Ability to get notified reactively about the nature of a change (addition, update, deletion) in the intent. This asynchronous, reactive capability (as opposed to polling) is another key to addressing scaling issues as intent gets more complicated.
• Ability for components to communicate in reaction to a change in intent.
• Ability for network operators to insert their expertise by enabling them to insert their own logic and programmatically reason about the intent, all in the presence of change.
• Ability to add support for new innovative features offered by modern infrastructure platforms.
  Ability to add support for a collection of new telemetry data.
• Ability to launch Intent-Based Analytics to extract knowledge out of raw telemetry data.

We recommend that you use the above list as a checklist for validating IBN compliance when evaluating IBN solutions.

In summary, the intent definition language (allowing you to define that single source of truth) AND reasoning about intent has to be built into the IBN platform.

Why does “built into the IBNS platform” matter? Because it means less code (bugs) to write, review, and maintain, fewer tests to write, review, and maintain. In short, more agility and availability. In its absence, you can expect the complexity of your solution to spiral out of control in the presence of change.

Intent-Based Networking brings the best software practices into network service lifecycle management. The benefit of starting with a good foundational architecture is a measurable increase in feature velocity. Another critical advantage resides in the opportunity to become hardware vendor-independent. We encourage you to test drive a complete IBN system and explore the benefits today. We believe that you’ll be pleased by how quickly it will enable you to design, build, operate and validate your network — providing more agility and reliability than you have ever experienced before while slashing your operational costs.