Fighting Your Way Through the Jungle of Intent

Pedro A. Aranda Gutiérrez and Diego R. López, Technology Exploration, Telefónica I+D

ABSTRACT: In this article we look at different SDN initiatives and how they are accommodating different projects exploring ways to express networking intents. We go through intent-related projects in the OpenDaylight eco-system and then look at the strategy of the ONF and OPNFV. To conclude, we provide a couple of thoughts of what intent should look like in the future.

1.1 Introduction

Intent Based Networking (IBN) is one of the current hot topics within the general trend on applying software-based techniques to networking. From its very inception, Intent has been described as “being descriptive, not prescriptive and, therefore, high-level enough to be independent of the underlying networking platform” (cf.[1] ). Other attractive properties attributed to intent include invariance and composability. But how much is hype and how much is really useful? Or, better said, is there something special to IBN? Something which can really make a difference in the way we interact with networks?

A plausible parallel to the development of IBN are programming languages. If in the beginnings, computers were programmed directly in machine code, most network appliances until recently have been programmed using a specific, low-level control channel like the current NETCONF[2] , OpenFlow [3] or vendor-specific interfaces like JunosScript [4] before. These interfaces sometimes use human-readable formats like YANG[5] . However, they are almost never easy to understand at a first glance, and by no means suitable for the laymen using networks, even when they are application programmers or system administrators.

In the early computing days, the first programming languages that appeared dubbed the structure and way of working of machine code and just provided a human-readable representation for it. It was later that programming languages that hid all the dirty details of implementing control structures, I/O and other elements of the interaction with computers to programmers started to appear. This evolution allowed programmers to write a program once and reuse it on different computers.

As with computers, a human-readable and more or less human-understandable way of representing the interaction with the network elements is desirable and we have seen a series of diverse initiatives claim the Intent flag for themselves.

1.2 A non-example

The ONF Atrium project is building an SDN-based router where users mix and match SDN controllers and Layer-2 switches to build a router with a Quagga daemon [6] implementing the required IP routing protocol suites. In order to provide a common abstraction to handle the different switches, some of which are OpenFlow-based, the project has defined an abstraction for the packet processing pipeline. This abstraction is called FlowObjectives. A question comes to mind -- whether this is Intent or not? In our opinion, this has little to do with Intent, since it just provides a common name to basic concepts of the pipeline like the next hop or a filter, and is therefore too low level. It continues to be prescriptive (e.g “do something specific for a packet in a switch”, as opposed to “do whatever is needed to provide a network service between two points”). As an analogy, it is difficult to imagine that someone would call object-oriented a macro package for an assembler.

1.3 Intent-based approaches

SDN controllers have reached the mainstream and now different Northbound Interface (NBI) developments claiming to be intent-based are popping up. ONOS has launched the ONOS Intents[7] , a framework that allows express “network control desires as policies instead of describing them through the mechanisms that implement them”. ONOS sees intent as a model that describes a request to alter network behaviour. This intent is then translated into FlowRules, which the ONOS framework again transforms into the commands for the different Southbound Interface (SBI) specific commands. ONOS Intents are purely programmatic and use the Java programming language. It’s arguable that this approach provides added value to the networking community at large, apart from providing yet another (low level) abstraction layer for SDN controller application programmers.

Another effort is the OpenSourceSDN Boulder project[8] . It defines an SDN controller independent NBIs that focuses on semantics and data models. Declarative and imperative approaches are supported.

Intent efforts in OpenStack are being pursued in different projects like Congress and Heat. OpenStack uses a so-called convergence engine as the central component that controls the infrastructure. In this effort, we also find the Group Based Policy effort. It defines collections of endpoints that underlie the same policies and provides reusable policy rule sets that can be layered based on user roles. From the point of view of readability, GBP is closer to a traditional command-line interface (CLI) than to a human language.

Last but not least, we have two projects in the Open Daylight (ODL) community that carry ‘intent’ in their names: Intent-based Network Modelling (IBNEMO)[9] and Network Intent Composition(NIC) [10] . NEMO has defined a structured, human understandable language to describe network scenarios. This language foresees a two-step process, firstly building node and link models which are then instantiated in a second step. Models are reusable, i.e. new models can be built starting from predefined models. NIC sees intent as the routing protocol for service. It defines subjects, actions, constraints and conditions, very much in the style of ONOS Intents. The NIC engine builds on a simple YANG model for Intent and receives intents as JSON files, which are human-readable but only conditionally human-understandable.

1.4 Brave new intent world?

Despite intent being in its beginnings, some interesting applications can be foreseen. One that is gaining interest is machine-learning applied to networking. A network using machine learning would extract information from the network to assess its state using systems previously trained by a human expert and autonomously take decisions to optimise itself. This approach implies the human expert would train the system by providing an initial set of human understandable statements, further refine the learning process by means of additional feedback, and possibly assess system behaviour by interpreting its autonomous decisions. In all these tasks, a declarative, high-level language to achieve human-machine communication would lower the entry barrier for this process.

As with any hype, intent can be a very empty buzzword to position a project in the SDN community and caution should be exercised when yet another project pops up and starts claiming ‘intent’. However, SDN is evolving very rapidly and, eventually, the most useful results from different initiatives will converge in well consolidated concepts and architectures. So, what could we expect from an all-embracing intent framework?

The interface to operators should be human-understandable. With computing power increasing, parsing should not be a problem and facilitating a ‘human-in-the-loop’ approach will increase trust in the platform/solution/architecture.
Intent should support composition. We have not gone all the way in introducing software development techniques in the network (e.g. agile programming techniques have translated in DevOps-style service development) to ignore the benefits of reusing of previously defined services to build new ones, in terms of reduced time-to-market, etc.
Intent should not try to build the (networking) world from scratch. There are a lot of efforts to model network equipment and network services (e.g. using YANG). Any serious intent effort should build on what is available and not try to redefine everything from scratch.

References

[1] Intent: Don’t Tell Me What to Do! (Tell Me What You Want) https://www.sdxcentral.com/articles/contributed/network-intent-summit-perspective-david-lenrow/2015/02/

[2] http://www.rfc-editor.org/rfc/rfc4741.txt

[3] OpenFlow: Enabling Innovation in Campus Networks: http://doi.acm.org/10.1145/1355734.1355746

[4] https://www.juniper.net/documentation/en_US/junos12.3/topics/concept/junos-script-automation-junos-xml-protocol-and-api-overview.html

[5] YANG - A Data Modeling Language for the Network Configuration Protocol https://www.ietf.org/rfc/rfc6020.txt

[6] Quagga Routing Suite http://www.nongnu.org/quagga

[7] ONOS Intents https://wiki.onosproject.org/display/ONOS/Intent+Framework

[8] OpenSourceSDN: Project Boulder http://opensourcesdn.org/projects/project-boulder-intent-northbound-interface-nbi/

[9] Network Modeling Language: https://datatracker.ietf.org/doc/draft-xia-sdnrg-nemo-language/

[10] Network Intent Composition in ODL: http://es.slideshare.net/opendaylight/whats-the-intent

Dr. Pedro A. Aranda Gutiérrez obtained his PhD at Universität Paderborn in 2013. He has been working in different positions in Telefónica I+D for the last 26 years, where he has participated in collaborative research projects both at national and European level. His past research topics include IP infrastructures and the BGP-4 protocol. Currently, he focuses on SDN and NFV research topics and is the Technical Coordinator of the FP7 NetIDE project, which is producing a multi-controller SDN development and runtime environment, which supports a controller-independent approach to SDN. His main interests currently include conflict resolution in SDN platforms and Intent-based Networking. In his free time, he likes to read, to enjoy music and to swim.

Dr. Diego R. López joined Telefonica I+D in 2011 as a Senior Technology Expert on network middleware and services. He is currently in charge of the Technology Exploration activities within the GCTO Unit of Telefónica I+D. Before joining Telefónica he spent some years in the academic sector, dedicated to research on network service abstractions and the development of APIs based on them. During this period, he was appointed as member of the High Level Expert Group on Scientific Data Infrastructures by the European Commission. His current interests are related to network virtualization, infrastructural services, network management, new network architectures, and network security. Diego is currently chairing the ETSI ISG on Network Function Virtualization, and acting as co-chair of the NFVRG within the IRTF. Apart from this, Diego is a more than acceptable Iberian ham carver, and extremely fond of seeking and enjoying comics, wines, and cheeses.

Editor:

Neil Davies is an expert in resolving the practical and theoretical challenges of large scale distributed and high-performance computing. He is a computer scientist, mathematician and hands-on software developer who builds both rigorously engineered working systems and scalable demonstrators of new computing and networking concepts. His interests center around scalability effects in large distributed systems, their operational quality, and how to manage their degradation gracefully under saturation and in adverse operational conditions. This has lead to recent work with Ofcom on scalability and traffic management in national infrastructures.

Throughout his 20-year career at the University of Bristol he was involved with early developments in networking, its protocols and their implementations. During this time he collaborated with organizations such as NATS, Nuclear Electric, HSE, ST Microelectronics and CERN on issues relating to scalable performance and operational safety. He was also technical lead on several large EU Framework collaborations relating to high performance switching. Mentoring PhD candidates is a particular interest; Neil has worked with CERN students on the performance aspects of data acquisition for the ATLAS experiment, and has ongoing collaborative relationships with other institutions.