I talked in my last blog about intent modeling in NFV, and today I want to look at extending intent modeling in two directions—into SDN (which is easy) and into management (which is less than easy). I’m not going to recap the theory of intent models beyond a sentence, so if you didn’t read yesterday’s blog I suggest you do that before reading this one.
An intent model describes a “service” in terms of the characteristics it presents to its users, not by how those characteristics are created. Thus, it’s a good statement of an abstraction for a given service or at a given interface point. I’ve suggested that NFV could use intent models to describe both the “input” to NFV from the higher-layer OSS/BSS (a service model) and the “output” of MANO into the Infrastructure Manager(s) that represent resources.
Since NFV has to command connections be made, and since a NaaS abstraction is the obvious way to describe these connections, an intent model is almost surely what NaaS abstractions should look like. Since SDN is a way of creating a NaaS connection set for NFV, then an intent model can describe SDN services. In fact, better than any other approach, particularly for OpenDaylight.
OpenDaylight, with multiple southbound control options, could create a connection service using a combination of OpenFlow/SDN and legacy technologies. To make that work optimally you’d need a description of a connection service that’s technology-neutral. Which means an intent model. The ODL controller could then translate intent into commitments through the southbound APIs to the real devices or management systems. To me this is a no-brainer, to the point where you have to wonder why it’s taken us so long to get around to recognizing the value here.
The management side, as I’ve already noted, is more complex but in the end also very logical. An intent model of a network service would include the service connection points and the “SLA”, which would describe the connection behavior to be delivered. IMHO, it’s not much of a stretch to say that an intent model should define SLA variables, the usual stuff like bit rate, packet loss, delay, and so forth. We could also establish a convention that every intent model defines a “service quality gauge” that would range from green through red depending on just how good/bad the service was conforming to its SLA at a given time.
The benefit of this is that a given intent model would then be defining variables that it was the responsibility of the lower-level structure (which could be a hierarchy of models or an element that commits resources) to populate. Since an intent model would have to offer what would look like a downward policy flow to populate lower-level deployment/connection processes with SLA variables from above, there’s nothing wrong with having the flow be bidirectional.
There are implications to this approach beyond simple management variable derivations. A “service” is now a set of linked intent models, each of which is asserting an as-a-service property set to the stuff above it. Because every model is a service with policies, properties, and SLAs every model can be managed.
This addresses an important point in service-building, which is how you organize complex services. Say you have a VPN with two sites, so you have three “services” in NaaS terms—two access services and one interior VPN service. You can define this as a tree with the retail service on top and the three subordinate elements below. The “orchestration” of this combination can be visualized easily as the instantiation of the three individual subordinate services followed by the interconnection of the three. The former step is defined by the intent model for each subordinate, and the final step by the intent model for the top (retail) layer.
The end game here is simple. A service is modeled and created through a series of abstractions—“objects” in modern software terms. Each object is an intent model in its upward-facing direction and each object decomposes the fulfillment of the intent it advertises by drawing on services/intents from below.
In most cases, I think, one of these objects will have two primary service/connectivity missions. One is to activate the services below, and the other is to “connect” them into a structure that fulfills that object’s own intent model. Overall, this is a modeled, data-driven, approach to NFV.
And more. If each of these models/objects has a state/event process that describes how it responds to conditions during the service lifecycle, including how it is impacted by and impacts the state of subordinate and superior models/objects, then you can describe remediation of faults and operations/management integration simply by linking processes into that model.
To me, this could overcome what could be a serious implementation flaw in NFV, which is the use of specific logic to address service lifecycle processes. Yes, you can establish a parameter in a descriptor file to indicate whether a given VNF needs a DNS or DHCP server or a load balancer, as long as you recognize when the software is built that the parameter will be needed. It’s hard to address new requirements without changing software. But if you have a model-and-table-based approach with structured service objects, you can change things by simply changing the data model to invoke a different process.
I said yesterday that the introduction of intent modeling into NFV could be a major asset, a major revolution. Like all revolutions, it could cause significant disorder. My perception of the ISG process is that it’s proceeding in two directions at once. One direction is augmenting the original E2E model of NFV, which I believe is not suitable as an implementation guide, and the other is trying to develop functional requirements that, if accepted, would suggest a completely different approach should have been taken.
NFV is going to have to get through this at the political level and not at the technical level. Somebody, somewhere high up in the organization, is going to have to sit down with a small number of like-minded people and get this right, and then work out how to develop support for the change. That support might involve some fancy footwork to paper over the fact that a lot of detail introduced so far was introduced based on the wrong approach. It’s not necessarily going to be an easy task to change, but I think it’s essential if NFV is to be deployed optimally, and I think some operators (and even a few vendors) are seeing the light.
