Intent-based networking is already here!

In this blog series about intent-based networking, I will explain that there are different ways IBN can be implemented, even without using the latest and greatest technologies.

What is intent-based networking?

As a reference, let me start with the definition of intent-based networking from Brandon Buttler, editor of Network world (see his article) and Gartner’s definition of the 4 key things you require in an intent-based system.
Brandon Buttler: “In a nutshell, intent-based networking is about giving network administrators the ability to define what they want the network to do and having an automated network management platform create the desired state and enforce policies.”. In addition, Gartner has identified the following key aspects of an IBN system:

1. Translation and Validation – The system takes a higher-level business policy (what) as input from end-users and converts it to the necessary network configuration (how). The system then generates and validates the resulting design and configuration for correctness.
2. Automated Implementation – The system can configure the appropriate network changes (how) across the existing network infrastructure. This is typically done via network automation and/or network orchestration.
3. Awareness of Network State – The system ingests real-time network status for systems under its administrative control, and is protocol- and transport-agnostic.
4. Assurance and Dynamic Optimization/Remediation – The system continuously validates (in real-time) that the original business intent of the system is being met, and can take corrective actions (such as blocking traffic, modifying network capacity or notifying) when desired intent is not met.

Intent-based networking; no-one says HOW to do it

So, what does this actually mean? When I translate this in ‘simple network engineering terms’, it means you need to be able to do the following:

1. Automatically create valid configurations based on intended policies.
2. Automate deployment of these configurations into your network.
3. Validate compliance of your intended policies in production.
4. Remediate any non-compliance issues that arise from step 3.

There is really nothing new under the sun! If you have been using network automation solutions or built your own scripts, you’ll know exactly what I mean. Any of these individual points can be addressed by using scripts or automation, but it’s lacking a system that ties everything together.
The important thing to realize is that nowhere (nor by Gartner or any other analyst) is described HOW these 4 things should be done. I believe this is where most of today’s confusion comes from. Let me explain.

New technologies are not the answer

When network vendors talk about topics like state awareness, network intent, and policy-based control, they typically throw in new technologies like API based controllers, SDN, protocols like NETCONF, modelling languages like YANG or TOSCA, and other innovative things. I am not saying these things are not relevant or important to build next-generation networks (they are!), but they were not designed specifically with IBN in mind. Their purpose and use are for specific domains and use cases and to drive standardization in the industry (although each vendor still implements their own version of these new standards!).

The reality is that the adoption of these new technologies in production networks is very slow, and I don’t think it’s realistic to expect this to change in the near future. Networks always end up being hybrid networks with a combination of legacy technology plus some of the latest products with advanced capabilities. Take for example NETCONF and YANG. They basically are ‘just’ another way for engineers to configure their network. However, the good old CLI will always be there as it remains the common denominator, even across new tech. The result is that, even though there are better and more advanced options, at best there will be a mix of methods.

Something of the future? IBN is closer than you think.

I believe it's important not to get distracted by these new innovations when talking about IBN systems. It's great if you have them but it’s not required. I’d rather state it's the other way around, meaning that any IBN system should, at a minimum, be able to address the 4 requirements by means of traditional configuration methods like CLI (SSH a.o.) and support common network automation practices.
In addition, it must integrate your processes around planning, designing, and implementing changes as that is what Gartner defines as the key for intent-based networking. Only then you can drive agility, overall standardization and control and achieve the true benefits of IBN.

In conclusion: Intent-based networking is closer than you think! A few independent software vendors, including NetYCE, already offer this today. And when you look at the open source community, which is always a good indicator for market adoption, you’ll see that all of today’s developments follow the same path. If you can address the 4 requirements, even with traditional methods, and have a way to manage them, you have an intent-based networking system.

In my next blog, I’ll go into more detail about the benefits of intent-based networking.