Intent-Based Networking Seeks Network Effect (David Lenrow, SDxCentral)

Posted · Add Comment

Source: SDxCentral

I have written previously about Intent-Based Networking (IBN) (“Intent: Don’t Tell Me What to Do! (Tell Me What You Want)“, “The Most Important Work in SDN: Have We Got It Backward?“) and the potential it offers to change the way we operate and employ networking infrastructure. Part of my day job is working in open communities to try and create a common interface to an Intent-based network infrastructure controller, which we seek to proliferate widely across diverse controller systems, network devices, and protocols.

I am pleased to report that there are diverse, and sometimes overlapping, groups of people actively engaged in building Intent-based systems solutions across the Open Networking Foundation, OpenDayLight, ON.Lab,OpenStack, and various NFV projects. We still need plenty of help from smart, dedicated people, but we are on our way to providing fungible components from which network solutions can easily be built.

We are poised to offer true choice and head-to-head “bake-offs” between system components and architectural choices without onerous integration costs. The much sought-after and rarely seen “second source” option will actually be made available to network operators, and vendor-specific lock-in and high-friction changes will be largely eliminated by agreeing to this critical inter-system interface. To insure success we are rapidly making multiple implementations available in order to appeal to diverse stake-holders and reduce barriers to entry for innovators.

The Network Effect

In order to succeed, it will be necessary to create a “network effect.” This concept is based on the idea that in an ecosystem, there is a non-linear growth pattern that develops from a virtuous cycle. Facebook, for example, saw explosive growth due to the fact that the value of the service is a function of how many people use it.

In software platform terms, the forces acting are operators and vendors. For a given API/SDK/ecosystem, if more vendors support it, more customers will seek it, which will lead more vendors to support it, a winner-take-all network effect that can establish a dominant platform. We hope to create a network effect of adoption of IBN, by proliferating a common, community-developed North-Bound Interface (NBI) with compelling value for both operators and vendors.

Intent-Based Networking is gathering strong support from diverse stakeholders in the cloud, data center, and enterprise sectors. Evangelism and education by true believers has spread the word to the point where IBN can go mainstream. Highly regarded industry analyst and SDN/NFV expert Tom Nolle has sung the praises of this approach (multiple blogs: “Could Intent Modeling Save the NFV Business Case?“, “Intent Models in NFV: More than “Useful”, “Diving Deeper into Intent Models for NFV“). Below, we’ll outline multiple projects, indicative of the broad interest in IBN.

Thinking Different

In an Intent-based system, we model the interface between network service consuming systems and network infrastructure (e.g., the SDN controller NBI) based on what the connected workloads need from the network (their communications intent). Because we are not specifically describing any aspect of the network implementation (protocols, ports, channels, addresses, packet headers), we get portability benefits allowing the “Intent description” for a given set of workloads to be utilized, unchanged, across different vendors, protocols, media, operating systems, etc.

In addition, the operator who understands the distributed applications and their communication needs doesn’t need to know anything about protocols, vendors, or media to create an Intent description that supports the targeted workloads. Because the Intent description provides rich context describing the what (rather than the how), it is possible to create an integrated system where multiple, discrete SDN services are offered, while resolving and avoiding potential conflicts over shared resources such as forwarding tables. (This property is formally known as “composability” of the offered services, and is not offered by existing SDN systems.)

An intent-based system is more secure than a less abstracted interface to network controller resources. The primary vulnerabilities identified in traditional SDN interfaces (raw flow-table manipulation, etc.) are not possible in a system where the only NBI exposed is Intent-based.

JVM Analogy

To understand the conceptual approach represented by an Intent-based network system, it is helpful to consider the Java Virtual Machine as analogous.

Creating code to deliver features in multiple browsers and operating systems was complex and expensive with lots of duplication of effort. As a result, Java, a more abstract language, was developed and proliferated based on a “write once, run anywhere” value proposition. This innovation was based on the observation that removing platform- and infrastructure-specific aspects from the language allowed the language interpreter run-time (JVM) to be ported once to each of the diverse platforms. Java became ubiquitous by enabling and riding the network effect around write-once, run-anywhere.

Operation of network solutions is largely done at the level of individual devices and is based on what is essentially custom code for each of the different vendor/protocol/ASIC combinations available. The Intent NBI turns the SDN controller into a black box that accepts a write-once, run-anywhere description of some set of network-attached entities. We refer to this description as a set of “Intent expressions.”

The common Intent NBI being developed in the ONF NBI Working Group under the leadership of Ciena VP Chris Janz, is defining operating principles and information models for an Intent NBI (analogous to the Java language definition) that will be implemented on as many network controller platforms as possible to encourage a network effect. The Intent “engine” is the JVM equivalent that networked application designers can use to create a write-once description of their network infrastructure needs.

An Improved Ecosystem

Intent-based networking offers many benefits to the ecosystem of distributed application developers, network equipment suppliers, network software developers, and network operators.

In general, the existence of a common NBI across multiple diverse infrastructure controllers (ODL, ONOS,OpenStack, OPNFV) creates new opportunities for choice, competition, and differentiation for both free, open-source solutions and for commercial, value-added solutions. The clean layering established between theorchestration platforms and the network infrastructure controller allows vertical specialization by a set of folks who don’t care at all how the infrastructure gets implemented, and allows customization and differentiation in terms of implementation and resulting properties such as scale, performance, robustness, and ease of use.

A network effect initiated by high-profile adopters could drive both the infrastructure and the business solutions creators to build a large, complementary set of choices.

Intent Discussion Widespread

One can credibly argue that Intent-based networking is gaining wide support. IBN projects have been initiated in the Open Networking Foundation (Project Boulder), Open DayLight Project (NIC project link), ONOS (ONOS Intents), OpenStack (OSSFC), and OPNFV (VNFFG).


The Open Networking Foundation is defining common Intent NBI principles and an information model. In the ONF North Bound Interface Working Group, Ciena’s Janz is Vice Chairman running the Intent networking activities currently being consolidated under the OSSDN Boulder Project. The primary work items in progress currently are:

  • A “Principles of Operation” document that describes at a high level how an Intent-based network system operates and how the operating requirements get split between completely portable “Intent Expressions” and “Intent Mapping” descriptions capturing non-portable (implementation dependent) descriptions of how to realize a given intent on a given system. This designs the system in which the intent NBI exists.
  • A group of Information Models that describe the Intent and Intent Mapping interfaces. These software artifacts are provided to “downstream” network infrastructure controller projects for inclusion in Intent-based system implementations.

OSSDN Boulder Project

The OSSDN Boulder Project is publishing multi-controller software artifacts to open-source controller projects. The Boulder Project consists of tools, documents, and information model and data model translation tools to provide authoritative interface components for building dissimilar controller system implementations.

Within the OSSDN repository there will be simultaneously “approved” IM fragments that have been discussed and have achieved broad consensus by the community, and “proposed” fragments where anyone can customize and experiment in the root of the Intent IM tree.

Downstream projects entirely control the selection of IM fragments to include in building any controller instance. As of this writing, there are no approved fragments, and the process of getting to some is being developed in the community.

Initial work on the Boulder project provided a demonstration of end-to-end service function chaining, using OSSDN Boulder artifacts, across both an Open DayLight domain and an ONOS domain using the common Boulder Intent interface. Inocybe Technologies did this work, partially sponsored by the ONF.

ODL NIC Project

The OpenDayLight Network Intent Composition (NIC) project has been established as a place to build one of the reference implementations for Intent-based networking based on the ONF Intent NBI artifacts. The OpenDayLight Helium Release includes demo/experimental features supporting a demo of service function chaining using the NIC interface based on ONF artifacts from Boulder.


The ON.Lab ONOS SDN controller also supports an Intent interface and can be expected to support ONF Intent NBI artifacts in the future. In June 2015, ONOS was demonstrated with initial support for implementing service function chaining based on Boulder artifacts.


Some work has been done on defining Intent-based interfaces for service function chaining. In addition, there are conversations taking place among major stakeholders from Neutron and from controller projects to understand how to offer additional benefits of Intent-based systems to OpenStack workloads and developers.


There are multiple projects within OPNFV that can be supported by network infrastructure using the Intent interface. Community discussions are ongoing about consolidating the diverse Intent needs for OPNFV projects and providing this as a requirements-input for the ONF NBI Info Modeling work.


Intent-based networking approaches are being discussed and will be contributed to ETSI documents from NFV, EVE, and IF working groups.

Leave a Reply