Now that you understand Infrastructure as Code (IaC), it’s time to take a look into IBN. This is the penultimate step in our expedition through the evolution of network operations - after this, only one more topic remains. For now, let’s dig in to IBN…
What is IBN?
Intent Based Networking (IBN) is the abstraction of network management specifics into a common management plane (/interface). Unlike SDN, IBN doesn’t try to invent new protocols, or replace the highly effective, distributed control plane inherent in our current routing protocols. Instead, IBN provides a single, declarative management plane. One interface to manage an entire network – no matter the scope or scale. And critically, this management plane is not only protocol agnostic (you can route however you wish), it is also device agnostic – meaning that IBNs can be heterogeneous networks made up of various makes and models of network devices and functions.
But Wait, What is “Intent”
The word ‘intent’ is clearly key to the concept of IBN. The definition of intend is (a) to have in mind as a purpose or goal (plan) and (b) to design for a specified use or future. Your intent is your desired outcome or end-state. And this idea of intent and intent-based anything is tightly coupled with the idea of declarative models and declarative programming. This concept of declarative instructions is best understood by contrasting it with imperative commands/models/styles.
Declarative versus Imperative
Declarative statements describe what needs to be done while imperative statements define exactly how to do it. For example, a declarative request might be “I want a lox bagel with cream cheese on my desk Monday at 10am.” The corresponding imperative instructions would be along the lines of “Leave home 20 minutes early on Monday, and during your commute, get off the subway at the Myrtle Avenue stop, go upstairs and cross the street, enter the Good Times deli, order a bagel with lox and cream cheese, wait for the person behind the counter to make the bagel… Etc.”
The example holds for technical network operations tasks as well. We have traditionally used an imperative style approach to configuring (and troubleshooting) our networks. From executing a specific command on the CLI, to writing a script that defines the exact steps needed to implement a needed change across the network, to documenting a method of procedure (MoP) that defines exactly what needs to be done and in what order to execute a network maintenance, imperative instructions permeate legacy network management techniques.
Becoming Declarative
IBN signals a shift from imperative network management to a declarative, network as code approach. Of course those individual steps laid out in imperative instructions still need to be completed. You can’t have a lox bagel on your desk if no one buys it and puts it there. And you can’t have a peering relationship between two networks if BGP is never configured. So how do we move from an imperative model of network management to a declarative, IBN model? We need a combination of abstraction and trust.
Enter: Abstraction
Abstraction is a term we’ve already used several times in this series, and it’s worth looking at a bit deeper now. Unfortunately, for many, abstraction is an abstract idea. And formal definitions are not as straightforward a way to describe “abstraction” as they are for many other words. “Abstract” can be an adjective, a noun, and a verb - each with several meanings. Two of the most relevant are: “something that summarizes or concentrates the essentials of a larger thing or several things” and “to consider apart from application to or association with a particular instance.”
Hiding Complexity
In the context of networking, and computer science more generally, an abstraction is typically something that hides complexity from the user. Note that we said “hides” and not “eliminates.” As we mentioned earlier, someone (or something) still has to go get that lox bagel - you just don’t need to know about it. From your perspective, when you hit the “lox” button, a bagel simply appears on your desk.
Gotta Have… Trust
You can probably guess that this is where trust comes into play. In our delicious example, you need to trust that your assistant/messenger/delivery-person/whoever knows what a lox bagel is, where to find one, and how to get it onto your desk. By trusting that this person (or robot) knows how to get the task (or project) done, you remove the need to be involved in the details of every step. You free up your time to work on higher level, higher value work that is more suited to your individual skill set.
Intent Based Networking
Moving back into the world of networking, an IBN-style centralized management plane provides you with a declarative interface by abstracting the imperative details required to execute on your intent. As long as you can trust the system to carry out your orders, you need not concern yourself with those details. Of course, those detailed commands are hidden, not eliminated, and so it’s slightly more complicated than that. How complicated depends on who you are in this process. Here’s a simplified breakdown of some common roles and how they interact with an IBN:
- IBN Developer – Creates, builds, and deploys the management plane that operates your entire network as one distributed system, defined by code. They need to intimately understand the network at the component level in order to interpret declarative statements into function specific imperative commands.
- IBN Architect – Creates and builds modular configuration templates that define the operation of the network at a functional role level. They need to intimately understand the desired network architecture and the discrete functions needed to operationalize it by defining policy as code. E.g., how will edge routers operate, how will stateful firewalls operate, etc. They do not need to understand the specifics of device configuration, as that is handled by interpreters written by the IBN Developer.
- IBN Engineer – Manages network growth and change within the defined system architecture. They need to understand both the network architecture and the software systems that operate it. These engineers will ensure that the IBN works as needed through capacity planning, hardware provisioning, deploying new functions and/or functionality, handling escalations from operators and users, and escalating to architects or developers as needed for larger or more fundamental changes.
- IBN Operator – Manages the day to day operation of the network as a distributed system. They need to understand the basics of networking in general, the network architecture in use, and the functionality of the management plane. This category often includes several distinct roles or tiers depending on the type of business and the purpose of the network. Troubleshooting is a key function of these teams, however they perform this service through the management plane and should not ever need to “log in” to a specific network device or function.
- IBN User – This is a defining characteristic of IBN because a properly constructed management plane makes it possible for nearly anyone to interact with the network as an abstracted and distributed system that provides connectivity to users and applications. They only need to understand the desired business intent and the declarative model used to instantiate that intent. Users could be a provisioning team, a developer, or even an application itself. In advanced IBNs some users may be bots themselves, triggering network actions based on events as they transpire (event driven automation). They may also include executives and managers who need visibility into network operations.
NetOps Convergence
Another way to think about IBN is as the convergence of SDN, automation, orchestration, closed-loop feedback, validation, and IaC. In other words, an IBN is a network that applies everything we’ve learned so far to design, build, operate, and upgrade the network as a distributed system providing connectivity how and where needed across your business. In this context IBN is the most modern evolution of network operations methodologies, and the ultimate evolution of many of the ideas born with SDN.
Note: Some folks (Hi, Jeremy Schulman) have recently started talking about design driven automation as distinct from intent based networking. The design driven concept is essentially that the network design itself is code, which lends itself to the automatic creation of not just configurations but also tests to ensure the proper operation of the network. We’ll leave this debate for another time and will simply add here that design driven automation is both a great idea, and in our view, totally compatible with IBN methodologies.
The multi-vendor management plane provided by IBN allows for repeatable and assured operations, which ultimately leads to a more reliable network and a faster time to market for new network enabled products and services.
Beyond Intent Based Networking
In the next and final installment of our “NetDevOps Primer” series, we’ll talk about how you actually build and operate an IBN using all the concepts covered so far - stay tuned for our NetDevOps post, next month!
For those with less patience; everything in this series is available RIGHT NOW in the FullCtl whitepaper: The NetDevOps Primer.