What is an Intent Driven Network?
An Intent is a persistent object that represents the desired properties of the network. Desired properties are high-level descriptions of the end functionalities we want the network to offer. In other words, they describe the “goal of the configuration” of the network. For example, an intent would specify that a tunnel is needed from POP A to POP B, which traffic then goes into that tunnel and the desired properties of the tunnel. But it would not specify how this is implemented: if a single device is used for the tunnel or multiple ones, how the BGP advertisements are made or which specific hardware tables or software features are used.
Persistent objects are used to maintain the set of desired properties for a network. Any change is applied by creating, modifying or deleting persistent objects (intent objects) via well-defined system APIs. Modifying intent objects is the only way to change the desired state (intended-state) of the network. Manipulating individual elements of the network is not permitted. [1]
An intent-driven network is a system that ensures a network remains in the intended state as described by the intent object automatically, utilizing a closed-loop system.
Is Intent Driven Networking New?
Intent driven networking is not a new concept. More generally, intent-driven systems have been around for a long time. Kubernetes is a well-known and widely deployed intent-driven system. Hyperscale cloud companies have deployed [3] intent-driven networking systems for years. The advent of modern network orchestration systems such as Juniper Contrail Networking, Contrail Service Orchestrator, Mist and many other Kubernetes CNI implementations have made commercial intent-driven network systems for mission critical and scaled deployment fully viable.
What is the difference between Declarative and Imperative Operation?
Intent-driven networking is a declarative paradigm of network operation where the desired state of the network is described, while an orchestration system takes care of getting and maintaining a configuration of the network that meets those goals. A great parallel to an intent-driven system is a self-driving car or most modern jets. You punch in the destination coordinates and the car/plane figures out how to get there. The system will not only take you there, but based on various parameters and how good the implementation is, it will try to pick the best route, react to traffic or optimize fuel consumption.
Traditional networking however has been imperative, where highly trained network engineers have described the sequence of actions needed on individual network elements to get the network to the desired state, typically through a combination of CLI, EMS and automation scripts. This is essentially how a human driver drives a car today!
Why is Intent Driven Networking the right answer?
Declarative intent-driven networking requires a sophisticated network orchestration system that can make complex decisions by itself. Contrail and Mist are two such systems that leverage AI for IT to achieve this. But there are great benefits to this approach.
Many studies have established that the vast majority of network outages result from unintended human errors during imperative operation on the network [4]. Intent-driven networking significantly reduces network risk while enabling operational efficiency by enabling:
- Validation of the intent object before it is ever applied to the network. Such validation is not just syntactic, but includes semantic checks against the context of the whole network (e.g. validation of a network wide policy)
- Instantaneous roll back or roll forward by applying the appropriate versioned intent object to get back to a known, good state if something goes wrong during network wide roll-outs
- Blast-radius containment during new intent rollout through well-defined policy
- Intent based fallback. As the system knows what the desired outcome for a specific configuration is, it can ensure that the desired goal is achieved, even in the face of outages or device errors, by re-configuring other elements in the network or by using different mechanisms to achieve the same results.
All of the above ultimately enables more frequent AND safe changes to the network while making the network more reliable. The net result is significantly better operational efficiency.
What does it mean in practice to have an intent-based system?
An intent-driven network today is built around a set of microservices and APIs to build what this document describes. Going from top to bottom of an implementation, you generally have:
- A data model – describing high level objects and their detailed semantics. This data model is generally layered: as an intent is actuated through different layers of the stack, high-level intents will trigger lower and lower level intents to be programmed. For example, a high-level intent may be “create a virtual network between those machines,” which results in lower level intents like “create a tunnel between physical network A and B,” and so on.
- Customers of this data model – that through web interfaces, command line tools or SDKs define which intents need to be programmed in the network
- API endpoints – that process the requests to apply and modify the intents. In a layered system, most of those API endpoints can be stateless: only the high-level intents need to be stored as the authoritative source of truth of the desired configuration, used by the reconciliation system to derive all the rest. Further, how a high-level intent is translated in lower and lower level intents should be considered an internal implementation detail: it will change over time and may even change at run-time based on different parameters as the controllers get smarter. For example, the “create a virtual network between machines” example may or may not require a tunnel. A smart controller may decide to use a kind of tunnel in some cases and a different kind in others. Or even dynamically change how traffic is routed based on networking conditions. Having any other system rely on the presence or creation of a tunnel will break the model.
- Some storage mechanisms – used by one or more of the API endpoints to store the desired intents. Note that the storage mechanism is an implementation detail.
- Mechanisms for an API endpoint to program intents in other API endpoints.
While much of the networking industry is still driven by manual, CLI-driven operations, the continued emergence of cloud and multicloud architectures managed through cloud-delivered controllers can drive the industry toward an intent-driven approach. This allows network teams to elevate above the infrastructure, allowing them to spend less time among the semantics of making everything work and more time focusing on things that are meaningful to business growth and success.
[1] In practice, however, intent systems need to be designed to a) tolerate individual elements or specific parts of the config being manipulated outside of the intent system b) provide the ability to perform manual overrides and tweaks in emergency scenarios, and c) be able to reconcile the system even in the face of manual tweaks.
[2] https://kubernetes.io/docs/concepts/overview/working-with-objects/kubernetes-objects
[3] https://static.googleusercontent.com/media/research.google.com/en//pubs/archive/45687.pdf
