Preface from SDxCentral (Roy Chua): With the flurry of activity around policy and intent, there are multiple projects and proposals springing up within the standards body and open-source space, from Cisco's OpFlex proposal to Group Based Policy (GBP) in OpenDaylight (ODL) to Congress in OpenStack and even the Northbound working group in the ONF. And there's certainly no lack of commercial action as well, with quite a few jumping into the fray including companies like Cisco/Noiro, Ciena, Google, HP, Inocybe, Huawei, NEC and VMware. I'm confident there's plenty of other vendors with their own policy projects in the background that haven't been revealed yet. Given the importance of policy and intent, there's definitely value in trying to create a common language and framework that the industry can agree with. To that end, Dave Lenrow of HP (inspired by Keith Burns at Cisco and Mat Mathews at Plexxi) initiated a summit to bring together all the key players in policy for two days of discussion. Dave was kind enough to invite us to attend and I had a front-row seat at a very insightful set of presentations and discussions focused on understanding each other's approaches to solving the intent and policy problem. I'd asked Dave, who hosted, and Marc Cohn of Ciena, who attended, to provide their points of view on the event. This post and the companion post by Marc provides us with a must-read overview of the importance of Intent and where it's going.

When many people work independently and reach a similar approach, it’s a sign that the approach is somehow “right.” Over the last few years, multiple organizations have begun to experiment with a new type of application interface where applications need only specify communications requirements, independent from the underlying network details.

In the so-called “Intent” model, intelligent software (such as an SDN Controller) determines how to translate the Intent into an infrastructure-specific "prescription" that causes the network to behave in the desired manner.

When you hire somebody to cut your lawn, you don’t give them a list of all the blades of grass in your yard and the length to cut each one to (prescription), you tell them to make it look nice (intent) and they figure out the rest. Intent-based networking emphasizes the “cut my lawn” interface and is designed to move away from the “industry-standard CLI” model which is the “each blade of grass”, traditional approach. Once the description of what is needed is separated from the details of how it’s implemented, there are many benefits as described below.

Intent doesn’t change as a result of a link going down, a server crashing, changing cloud providers, changing switch vendors, upgrading firmware, or any other change to the infrastructure. This invariant description frees applications from the underlying network details, simplifying overall application development, testing, and deployment. If the expression has to change based on the state of the infrastructure, you have not yet captured the essential intent, which is infrastructure agnostic by design.

Intent (describing the applications needs) is not specific to protocols, vendors, media-types, or infrastructure providers. Because it is abstracted from changes to the infrastructure, intent-based networking eliminates the impact of such changes. Intent allows what enterprises, service providers and telecom carriers have been seeking; portability across a range of dissimilar solutions including the SDN controllers, eliminating lengthy applications integration changes and run-time complexity as a result of inevitable changes to the infrastructure.

The extensible intent interface is designed to allow disparate services, developed independently, to express their resource requirements in a common language. As a result, all of the services accessible via the intent interface share a common resource allocation and management engine.

By sharing access to this “single source of truth,” we avoid the “split brain” and “multiple writer” challenges in distributed systems design. Any combination of intent-driven services can be used concurrently. In current SDN systems, one can run a third-party QoS service or a third-party security service, but not both. Building intent-driven systems provides a way to alleviate this problem by requiring that new services be built using the intent interface. Operators will be able to choose a la carte services to offer from multiple independent software developers with minimal risk to system integrity.

Intent doesn’t change when you go from one network controller domain with a million ports to a thousand network controllers with a thousand ports each. You can take a single description of intent and hand it to all of them. This enables a scale-out approach to building, for example, SDN controller domains simultaneously supporting small failure and maintenance domains concurrent with massive overall scale. Currently, many SDN architectures assume building a scale-up system using a single, massive, clustered controller domain, which creates several operational and deployment challenges. By effectively sharding the collective intent across an arbitrary number of independent domains, we get end-to-end intent fulfillment with the superior survivability and fault handling of locally autonomous controllers.

When different SDN services push low-level (e.g. OpenFlow) rules, there is always a risk of conflicting changes to the system state. Attempts to examine these rules (of the form “match this header and perform this action”) and resolve such issues have been unsuccessful because at this low level of abstraction, it is impossible to decode the overall intent of the services pushing the rules. Because the intent-oriented description conveys the why, rather than the how, it is possible to determine actual or apparent conflicts and seek ways to fulfill the cumulative intent of the multiple-client services. Promising research in the area of intent-based conflict resolution in multi-service SDN systems is being considered in standardization activities in the ONF.

Expect to see significant progress and easier-to-use, more capable SDN systems as a result of the intent-based SDN work. Many groups working independently are now beginning to work together in standards organizations and open-source communities to create a common SDN Intent-based approach. By implementing a common intent interface across multiple controllers, vendors, and technologies this work will deliver the benefits described above and, in turn, pave the way for network operators to deploy Intent-based solutions.