Is Intent-Based Networking a "Failed" Technology?

During the mid-2010s, technology marketing mavens and analysts alike fell in love with - and extensively hyped - a technology they called Intent-Based Networking (IBN).

Now, nearly a decade later, you don't hear of IBN much anymore. But that doesn't mean it's gone.

This article details the history of IBN and its vital underpinnings to today's modern cloud infrastructure - and cloud security.

Early 2010s: Adapting to rapid changes in cloud networking

Just prior to this, at HP Networking, the CTO's office saw similar new network abstractions being invented in isolation by multiple groups trying to adapt to the new scale and rate of change in cloud networks. Much of this work was being done in open-source projects (e.g., OpenStack, Open Day Light).

HP decided to invest resources in trying to unify this work, and in 2013 hosted the "IBN Summit" at HP Labs in Palo Alto. Invitations were extended to everyone known to be working on network policy solutions for SDN and cloud projects, including folks from Cisco, HP, RedHat, IBM, Huawei, Brocade, Microsoft, NEC, VMWare, etc. The different parties presented aspects of their work in this area and agreed to try find a path towards a common API.

Mid-2010s: Defining IBN

Representatives of many of these companies then continued to work together in the North-Bound Interface (NBI) working group of the Open Networking Foundation (ONF) while I was chair. In October 2016, ONF published a document intended to present member consensus on a definition and technical overview for an IBN system.

Read the document, Intent NBI - Definition and Principles, here.

The definition from this document can be summarized by one sort of golden rule: Intent doesn't include any implementation details that would make it specific to platform or infrastructure.

Intent consists of declarative statements about desired network behaviors in business terms. Separately, there is a mapping process that knows how to implement the intent onto the current config/state/topology of the infrastructure.

Critics claimed that we were throwing away and ignoring the implementation so there was no value. We pointed out that we weren't throwing it away, but rather moving it elsewhere under the control of a mapping process. Declaring "pure" intent does not require the policy authors to be experts in the infrastructure technologies, but rather they only have to understand the business constraints for policy.

In that document, the ONF definition described an "intent active loop" within the controller:

"This element is responsible for continuously evaluating active service Intents and mappings from the repo and network information from the SBI handler; and taking actions required to instantiate new, or appropriately modify existing, service configurations as a function of detected Intent changes (repo), and/or of mapping changes (repo), and/or of Intent NBI."

The intent active loop description is consistent with a term that has become well known from Kubernetes which describes controllers that translate declarative intent to system behaviors as being built on a Continuous Reconciliation Loop (CRL) that continuously maintains an implementation of the declared intent within the infrastructure.

This article will use the term Continuous Reconciliation Loop or CRL to refer to all such technical approaches.

2017: IBN is "the next big thing"

Soon after we published the document, the industry began to talk about IBN when Gartner coined the term in 2017 and called it the "next big thing" in a blog article.

Marketers eventually made IBN meaningless, as they do, first by every vendor claiming that they have always had IBN. And then, as a result, people eventually stopped talking about it.

After all that noise, one can look back and wonder: Was IBN a failure in practical terms?

The answer is no - quite the opposite, in fact.

Today: IBN is alive and well in modern cloud infrastructure

We don't talk about IBN much, but it is ubiquitous in modern cloud infrastructure.

Three examples illustrate the breadth of usage of this approach in large production environments.

Kubernetes network policies

K8's Container Network Interface (CNI) policy controller, the Certificate Revocation List (CRL), knows the state of all pods/endpoints, virtual switches, sidecar proxies, gateways, NATs, etc. It also knows mappings for implementation (IP addresses, ports, protocols, identity, authorization, labels, namespaces, etc.) and runs a continuous reconciliation loop to keep implementation consistent with network policies.

Developers provide Kubernetes network policies (KNPs) without implementation details (intent), and the controller makes it so. KNPs do allow users to specify lower-level attributes like IP address or port, but best practice is to use label-based selectors in local policy declarations to benefit from the distributed state automation in the KNP engine.

Illumio Policy Compute Engine (PCE) and Illumio VEN (agent)

Illumio has a mature and widely deployed enterprise product that brings the intent value proposition to bare metal and virtual machines and containers by using a similar label-based abstraction. This spans multiple dynamic instances using a CRL controller to maintain policy constraints.

There is a distributed controller (PCE), pre-configured with abstracted, dynamic, label-based policies that uses the continuous reconciliation loop to implement these policies in the context of the current infrastructure state and topology.

Actual policy enforcement, in this case, is done by programming the lower-level, native tools for various on-premises and public cloud infrastructure platforms.

Juniper/Apstra

Apstra IBN also has a declarative model with automation to convert abstract policies to specific infrastructure implementations. However, the problem that it solves is slightly differently than the previous examples.

Both Kubernetes Network Policies and Illumio's platform can be categorized as "overlay" network technologies. They create and control features of a virtual network on top of a network that already has basic connectivity among physical devices.

The Juniper Apstra solution has the capability to create and control the ‚Äúunderlay‚Äù network that includes racks full of data center devices connected by cables. But, like the above examples, it maintains consistency by continuous reconciliation of declarative policies with the network.  

IBN: The backbone of cloud performance at scale

The added abstraction layer provided by an intent-based approach is necessary to achieve the scale, rate of change, and performance needed for cloud workloads.

If you have thousands or more dynamic instances of an "application" constantly changing, humans can't be in the fast path for updating policies. An intent-based interface "compresses" the rule space from the user perspective and hides all the magic of making it come true behind that interface. It allows instances with similar/identical behaviors to be treated as a group that policy can be applied to.

If your intent is "things in group A can communicate with things in group B," you create one simple rule that never needs to change. It is the correct rule and leads to the correct behavior whether there are no instances, one, two, three, or a billion instances, on a single server or millions. There is only one rule, but its implementation in a big system might require dynamic updates to a billion firewall rules in a hundred thousand firewalls.

It is the development of these huge, distributed, automated continuous reconciliation loop controllers that make it possible to implement global network policies for large-scale distributed systems which are increasingly being built on the cloud by global enterprises.

The days of an Excel spreadsheet with the rules for all your firewalls are long gone - any manual, individualized approach to "programming firewalls" for larger systems is equally obsolete.

Modern cloud security relies on IBN

IBN has quietly taken the entire ride on the hype cycle. It is so deeply woven into the foundations of modern networking that it no longer has a buzzword associated with it.

The fact that multiple parties invented conceptually similar solutions in isolation is always as strong sign that something important is happening. The people who did this work are largely unknown, but they know that they helped enable the amazing things we can do in the cloud today.

This ability is proving even more important as cyber threats increase and the protection of Zero Trust networking, in particular, becomes even more critical. The reliable, scalable nature of IBN in turn allows platforms like Illumio to offer reliable, scalable security in the cloud.

Learn more about how Illumio CloudSecure contains breaches in the hybrid cloud here.

Interested in securing your cloud network with Illumio Zero Trust Segmentation? Contact us today for a consultation and demo.