Enabling Automation With Intent-Based Orchestration & Networking
James Crawshaw, Senior Analyst – Service Provider IT and Automation, Heavy Reading
While not a new concept, intent-based networking (IBN) is making a resurgence as a potentially promising way to advance self-configuration and closed-loop automation in the network. IBN seems to have started life in data center networking and from there it has spread into enterprise networking, at least as a marketing term.
There has been some skepticism in the telecom industry about whether there is anything really new here and indeed at the recent MPLS World conference Ali Tizghadam, principal technology architect of network softwarization in the chief technology office of Telus, admitted that vendors have a habit of providing new names for existing technologies in order to drive the sales process. Tizghadam tarred IBN with that brush, but he went to explain how Telus is using the intent approach on its journey to autonomous networking. Indeed, it is more than a buzzword.
I think of IBN as a northbound interface between an infrastructure controller (such as ODL, ONOS, or OpenStack) and a higher-level business system (such as an order management system within OSS). This northbound abstraction is similar to the MANO layering: NFV Orchestrator, VNF Manager and Virtual Infrastructure Manager. At the top layer, instructions are quite generic -- like create a new VPN. At the bottom layer, instructions are very granular and device specific. Intent isn’t concerned with the low-level APIs used to control the infrastructure but is instead focused on higher-level business needs.
What makes IBN different to abstraction layers that we usually find in software systems is that it uses a declarative language for this interface rather than an imperative one. A declarative language uses statements to express goals but doesn't specify how to accomplish those goals. In contrast, an imperative language focuses on how the goals are achieved. Imperative is a set of programmed rules while declarative uses an optimizer or planner to make decisions. The optimizer is a logic program written in a language like Prolog.
It is all well and good saying we are going to embrace intent based networking but unless there is a common language and syntax for expressing intent we are not going to deliver multi-vendor interoperable solutions to the telecom industry. Hence the need for some standards to be developed. It seems to me like the most active body that is working on this is the MEF which is planning to add "intent" to the existing APIs that form part of their Lifecycle Service Orchestration framework. The Intent Group under the MEF Application Committee will initially work on applying the intent paradigm to SD-WAN.
IBN use cases are currently more focused on automating data center operations, but this technology could be a boon to service providers' goals of simplifying their complex networks. How soon can operators realistically deploy IBN on a wider scale and will this technology live up to the marketing hype? What are the challenges to implementing intent in the management and orchestration of software-defined, virtualized networks? To find out, join us at the Big Communications Event in Austin on May 14-16 where we will be discussing intent-based orchestration and networking and how it can help with automation.
To find out more, join us in Austin May 14-16 to boost your knowledge about cloud-native software and innovation driving data center transformation, for the fifth-annual Big Communications Event May 14-16. The event is free for communications service providers. Secure your seat today!
— James Crawshaw, Senior Analyst, Heavy Reading