Intent-driven networking reshaping network service delivery
When configuring a network, engineers often focus on individual tasks to enable network service delivery. Intent-driven networking transfers the focus to the overall network.
Certain network services require more effort by network engineers to provide a high-quality end-user experience. For services such as unified communications and distributed database architectures, engineers need to configure the infrastructure -- typically device by device -- to ensure the service's traffic is handled properly.
Ultimately, these services exist for the end user. Until recently, however, the paradigm for professionals focusing on network service delivery has centered on micro-configurations, rather than the purpose behind the service. Intent-driven networking -- telling the network, in effect, what you want, rather than telling it what to do -- provides a different paradigm that abstracts individual configurations and more closely aligns networking with the actual purpose of the service.
Micro-configuration refers to the individual tasks normally associated with configuring network devices. This includes common tasks, such as configuring quality-of-service (QoS) policies on switches, access-control lists on firewalls, jumbo frames on data center devices, route statements on routers and all the individual tasks needed to orchestrate an entire network.
This focus on individual tasks contrasts with macro-configuration, which is concerned with the overall technology and not the individual tasks. For example, a macro-configuration configures QoS throughout a network, while micro-configuration refers to individual class maps, policy maps, access-control lists, service policies and other operations to enable network service delivery.
Network engineers can get lost in the weeds of these tasks, which results in a lengthy process of design, implementation and post-mortem troubleshooting. Network service delivery becomes more about configuring individual components, rather than any sort of network orchestration. Ultimately, the intent for the network configuration can be lost in handling the minutia of individual configuration tasks.
This type of network engineering isn't really orchestration at all, and configuring intent is even more abstract than macro-configuration.
What's the intent behind intent-driven networking?
Intent is simply what the application intends to deliver to the end user. This is not the same as how it delivers it. For example, the intent of a new unified communications service may be to deliver high-quality audio and video between any two endpoints on a network. The intent, or the what, is the delivery of high-quality audio and video. The how is the part most engineers are most familiar with: configuring QoS among a variety of devices, opening up certain ports on firewalls, or configuring new virtual LANs to carry the specialized traffic.
A problem with focusing on the how is networkschange. Network resources are always in flux -- dynamic routing changes traffic patterns, network refreshes introduce new hardware and software platforms, and the turnover of network engineers affects the ability of what implementation teams are actually able to configure. Often, engineers can do little more than configure what they can, where they can and hope the network or application never changes.
This dynamic aspect is what causes applications trouble. Unless the purpose of an application itself changes, the intent doesn't change, even though the underlying network does.
Intent-driven networking solves this problem by enabling an engineer to work with a single interface -- perhaps using some sort of controller -- to tell the entire network what type of service is being deployed. The network can then automatically configure itself accordingly. There is no process of micro-configuration. That's due to the complete abstraction by the intent engine sitting in between the network and the engineer. This intent-driven method enables easy orchestration among a variety of hardware platforms and software versions, with little reliance on an engineer's skill level. This method would also allow the network to reconfigure itself when things change.
This intent-driven process is different from popular software-defined networking controllers that offer the ability to manage networks from a single interface and create some semblance of provisioning orchestration. The idea behind intent-driven controllers is they would provide an engineer with a preconfigured network application that interprets intent and translates it to the various languages, protocols and syntax necessary to configure any type of network device. An engineer doesn't click on, "Configure service-policy on interface GigabitEthernet 2/3." Instead, the network engineer clicks on the relevant intent policy -- sometimes called an intent description -- and the software intelligently applies configuration where it's needed in the infrastructure, regardless of the platform or software version.
This is a powerful method for simplifying provisioning and accommodating a dynamic network to enable efficient network service delivery. And because this also creates greater interoperability, engineers would be far less dependent on any one networking vendor.
Working toward intent-driven networking
This notion of "write once, run anywhere" is a huge part of intent-driven networking. As a software development concept, however, it isn't new. Software developers have done this for years in order to allow their programs to work on any operating system. For example, the software developers who created our favorite web browsers had to make sure their code would run on -- almost -- any operating system. Applying this type of platform-agnostic interface to networking seems amazing, but it is also the biggest challenge to making true intent-driven networking a reality.
The open source community is currently building out these systems in various projects and dealing with the complexity of writing code to accommodate any platform. But this is no easy task. Writing code that can configure any platform and also collect and interpret telemetry from the network is a tremendous undertaking. Groups such as OpenStack, the Open Networking Foundation, OpenDaylight and the Open Networking Lab are working to design methods to add this sort of intelligence to systems. But as a mature product, it's still a long way off.
Ultimately, the goal of intent-driven networking is to scale network management and add real intelligence to the infrastructure.
Writing a clever RESTful API to automate device provisioning is one thing. Writing a completely vendor-agnostic interface to configure end-to-end network service delivery with the intelligence to dynamically reconfigure a network as an application's behavior changes is very different.
Thankfully, this endeavor doesn't involve rewriting the network stack itself. Rather, it adds an overlay that can be deployed slowly and only in a part of the network at a time. For example, as the methods and products surrounding intent-driven networking mature and come to market, network engineers can use them in the data center only.
Ultimately, the goal of intent-driven networking is to scale network management and add real intelligence to the infrastructure -- all the technical pieces that make the bits go where they need to go will align with the goals of the business. We still have quite a long way to go until an engineer can declare an intent on a network and have it configure itself. But, perhaps one day, network engineers will be able to configure their networks similar to how Lt. Cmdr. Geordi La Forge gives the U.S.S. Enterprise computer commands.
