I am looking into TMF921 Intent Management. I am quite familiar with the concept of intent, but from a different perspective, having worked with one of the intent pioneers, Dave Lenrow. Intent is federated, so once intents have been created, they can be decomposed and passed down to autonomous subsystems.
That all makes sense, although I am not convinced that local optimization by subsystems would guarantee a globally optimized solution. Sometimes, for sure, that will be the case; but in my experience there are also cases where local optimizations lead to a globally suboptimal solution.
Anyway, I am trying to understand how TMF921 fits into, complements, or disrupts a classical TMF SID based approach.
As explained in TR290, an intent is an expression of requirements on a set of Target resources needed to fulfill the intent. This implies that at the time of expressing the intent, the resources that the intent is about must be somehow already known to the person/system expressing the intent. This, for me, contradicts the expressed purpose of intent - to relieve the person/system expressing the intent from knowing details about the technical realization and resource behind the intent.
Example:
- "I need a firewall with these rules configured" - that is not intent based, because "a firewall" implies an up-front decision of how the intent should be realized
- "I need firewalling, to ensure that web-pages with gambling are not accessible" - this is intent based. Decisions on how the intent is realized are left to the systems - perhaps one or more firewalls are required? Perhaps the firewalls are physical and shared, perhaps dedicated and virtual? Perhaps the technology is not even classified as a "firewall"? The policies to be applied depends on the type and make of technology.
I have found that the "-ing" form of expression is typical for the distinction between resource-centric and intent-based approaches. Compare "accessing versus a fiber access box", "load-balancing versus a load-balancer"
But the way TR290 defines intent, it appear that the resource - firewall - needs to be known up front, and I find that confusing.
Now, comparing this with classical TMF Service Specification approach. The Service specifications, grouped in a TMF633 catalog, define a meta-model for CFS instances (TMF638) that can be requested. This can be made as abstract as required. I could define a Service Specification for "Firewalling", and the RFS decomposition would identify resources for which TMF921 intent makes sense.
The objection to "classical" service fulfillment that I see in the Catalyst information about TMF921, is that the classical approach requires low-level, technology specific characteristics to be specified, but for me, if that is the case, then it just means that the classical CFS specifications were badly designed.
Now, If we want TMF921 to be relevant at the CFS level, allowing the expression of intent without having to know about the resources, I would have imagined that a Service Specification could include something like "intent specifications", defining the intent expressions that users could want - where the expressible properties would depend completely of the category of service in question (bandwidth for connectivity, rules for firewalling, etc). In other words - I am looking for the meta-information of Intents relative to intent-expression-instances that would be the counterpart of Service Specifications relative to Service instances.
The problem with the classical approach is that as new resource types are added, they may support new types of intents, and you may want those new intent options to be presented to the users - say, the old firewall could only protect against gambling, but the new one could also protect against pages with firearms. This is where intent negotiation could make sense, I just don't see how the current TMF921 and associated TRs support this up to and integrated with the CFS level.
In other words, for me the old Service Specification approach might be too closed and restrictive, but the new TMF921 approach appears to be too open-ended and unbounded. I am looking for a unified middle ground.
As mentioned, I am coming from a somewhat different angle, so I am probably just confused.
- Is there material somewhere that explains the above?
- Should I be joining some TMF921 specific groups for discussion and clarification?
------------------------------
Peter Bruun
Hewlett Packard Enterprise
------------------------------