Dave Lenrow shares his notes from the recent Intent-Based Summit with SDx Central readers
If you read my ONF blog post, “Intent: What. Not How.”, then you may already be familiar with the general approach of intent-driven networking. It’s a rapidly growing area of interest, and I recently hosted a summit to discuss this topic with the top influencers in the industry. Following the Intent-Based Summit, SDx Central invited Marc Cohn and me to share our thoughts on the event, and I elaborated on the approach for their readers. Below is a quick excerpt from the piece, which can be read in its entirety here.
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 is invariant
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 is portable
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.
Intent is compose-able
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.
For the rest of this article, read “Intent: Don’t Tell Me What to Do! (Tell Me What You Want)” at SDx Central.
- Dave Lenrow, Distinguished Architect, Advanced Technology Group – HP Networking
