Interoperable Intent

Tom Nolle wrote a very nice follow-up to my earlier post providing a more in-depth analysis of how (TOSCA) service models can be used as the foundation for Intent NBIs. Tom further explores the fundamental concept that high-level abstract service models can be orchestrated by decomposing them recursively into increasingly more detailed substructures until they can be realized onto resources that are owned and controlled by the service provider (a concept Tom has described in many of his earlier posts).

As Tom points out, this process begs for answers to the following two fundamental questions:

• What are the right service models? While TOSCA provides the framework for describing and composing service models, successful adoption of this framework will depend on designing the “right” service models. Tom writes: “A great program for drawing organization charts won’t organize your business, and so with TOSCA or any other service model you still have to decide what exactly your model should look like”.
• How do we provide interoperable implementations of service models? Tom points out that unless two service models expose the same external interfaces, one cannot interchangeably substitute one model for the other and expect the same behavior. 

Fortunately, the second issue can be dealt with relatively easily by leveraging TOSCA’s built-in support for interoperability. Components in Tosca Service Templates (Node Templates, in TOSCA parlance) all have Types that define the externally visible characteristics of those components. These characteristics include not only properties, but also requirements (that declare relationships to be established to other Node Templates), capabilities (that declare the ability to act as the target of such relationships), and interfaces (that define the lifecycle operations supported by the node template). As long as different components or different subcomponents advertise the same type, they can be readily and interchangeably substituted in higher level TOSCA service topologies.

Answering the first question is a bit more challenging. TOSCA Simple Profile in YAML introduces a normative type system, but Version 1.0 includes only a relatively small number of (mostly cloud-focused) types. Many more domain-specific types are needed. This begs the question of who will drive the creation of those types.

• ETSI NFV’s newly formed Solutions Workgroup is investigating the use of TOSCA for defining network service descriptors and VNF descriptors. As this work will get further along, this will create an opportunity to define standard TOSCA types for various network functions but it’s unclear how soon this will happen.
• The ONF is doing great work (in the context of their Project Eagle) to define a common information model for the networking industry. It would seem only natural that this information model could be used as the foundation of network-specific service models. However, I haven’t seen evidence so far that this is actually happening. Much of the Project Eagle focus seems to be on translating the common information model into YANG, which is a data modeling language for network element configuration and not really suitable for service modeling.
• The ONF’s own Intent NBI work (Project Boulder) is only now getting started in earnest, but it doesn’t appear that Boulder is currently focusing on service models as the context within which to describe intent. This makes it unlikely that Boulder will drive the definition of standard models anytime soon. 
• It appears that the MEF’s LSO work is leveraging the ONF’s information models for their APIs (at least for their Legato interface) but again it’s not clear at this point whether these APIs are based on a service model paradigm.

It would be great to see coordination across these various initiatives so we can all work towards a truly open and interoperable intent ecosystem.