Intent-driven networking is reshaping network service delivery

When configuring a network, engineers typically focus on individual tasks that enable network service delivery. Intent-driven networking shifts their focus to the entire network.

Certain network services require network engineers to devote greater attention to achieving a high-quality end-user experience. For services such as unified communications and distributed database architectures, engineers need to configure the infrastructure—often on a device-by-device basis—to ensure that service traffic is handled correctly.

Ultimately, these services are delivered to end users. However, until recently, the professional model for network service delivery has focused on micro-configuration rather than the intent behind the service. Intent-driven networking is really about telling the network what you want, rather than telling it what to do. It has a different model that abstracts away configuration while aligning the network more closely with the true intent of the service.

Micro-configuration refers to the individual tasks typically associated with configuring network devices. This includes common tasks such as configuring Quality of Service (QoS) policies on switches, configuring access control lists on firewalls, configuring jumbo frames on data center equipment, configuring routing statements on routers, and all the tasks required to orchestrate an entire network.

This model focuses on tasks that are completely opposite to macro configuration, which focuses on overall technology rather than individual tasks. For example, a macro configuration configures the QoS of the entire network, while micro configuration refers to individual class maps, policy maps, access control lists, service policies, and other operations that enable network service delivery.

Network engineers may be overwhelmed by these tasks, resulting in significantly longer design, implementation, and post-deployment troubleshooting times. Network service delivery becomes more and more focused on the configuration of individual components rather than any network orchestration. Ultimately, the intent of network configuration may get lost in handling a variety of trivial configuration tasks.

This type of network engineering is actually not compilation at all, and the configuration intent is even more abstract than macro configuration.

What is the intention behind intent-driven networking?

In simple terms, intent refers to what the application is going to deliver to the end user (the service). This is different from how it will deliver the service (the means). For example, the intent of a new unified communications service might be to deliver high-quality voice and video between two endpoints on the network. The intent (the what) is to deliver high-quality voice and video. The means is the part that most engineers are most familiar with: configuring QoS between various devices, opening specific ports on a firewall, or configuring a new virtual LAN for transmitting specific traffic.

The problem with focusing on how services are delivered is that networks change. Network resources are constantly changing - dynamic routing changes traffic patterns, network updates introduce new hardware and software platforms, and changes in network engineers impact the actual ability of implementation teams to configure the network. Often, engineers are limited in what they can do, and they always hope that the network or applications will never change.

This dynamic nature is exactly what causes problems for applications. Unless the purpose of an application itself changes, its intent does not change, even if the underlying network changes.

Intent-driven networking solves this problem by having an engineer operate just one interface - or use some kind of controller, which tells the entire network which service should be deployed. The network can then automatically configure itself accordingly. There is no micro-configuration in this process. This is due to the complete abstraction achieved by the intent engine between the network and the engineer. This intent-driven approach allows easy orchestration across a wide variety of hardware platforms and software versions, completely independent of the engineer's own skill level. In addition, this approach allows the network to reconfigure itself when the environment changes.

This intent-driven process is different from mainstream software-defined network controllers, which can manage the network through an interface while creating some functions to implement the orchestration. The concept behind intent-driven controllers is that they can provide engineers with a pre-configured network application that can interpret the intent and convert it into various languages, protocols and syntax as needed to configure any type of network device. Engineers don't need to click a button that says "Configure service policy on Gigabit Ethernet 2/3." Instead, network engineers only need to click the relevant intent policy - also known as the intent description, and then the software will intelligently apply the configuration to where the infrastructure needs it, regardless of the platform or software version.

This is a powerful approach that simplifies dynamic network allocation and adjustment for efficient network service delivery, and because it allows for greater interoperability, engineers do not need to be tied to any one network vendor.

Implementing intent-driven network connectivity

"Write once, run everywhere" is the main concept of intent-driven networking. However, it is a concept that comes from software development and is not new. Software developers have been doing this for many years to make their programs run on any operating system. For example, web browser developers must ensure that their code can run on any operating system. Applying this platform-independent interface to the web may seem surprising, but it is also the biggest challenge to ensure that intent-driven networking becomes a reality.

The open source community is currently building this type of system in various projects while dealing with the complexity of writing cross-platform code. However, this is not an easy task. Writing code that can configure any platform while also collecting and parsing data from the network is a huge task. OpenStack, the Open Networking Foundation, OpenDaylight, and Open Networking Labs are all working on designing ways to add this kind of processing power to the system. However, it will take a long time before it becomes a mature product.

Writing a clever RESTful API that enables automatic provisioning of devices is one kind of task. Writing a completely vendor-neutral interface for configuring end-to-end network service delivery, while being able to intelligently and dynamically reconfigure the network as application behavior changes, is an entirely different task.

Fortunately, this work does not require rewriting the entire network stack. Instead, it is just adding a layer of software that can be deployed slowly and only affects a part of the network at a time. For example, as the methods and products related to intent-driven networking become more mature and abundant, network engineers only need to use them in the data center.

Ultimately, the goal of intent-driven networking is to extend network management and add true intelligence to the infrastructure - all technologies are designed to get packets to where they should go, while aligning with business goals. We are still a long way from being able to declare an intent on a network and have it configure itself. However, maybe one day network engineers will be able to enter a command like in the movies and have the network configured.