Where Does the MEF’s LSO Model Fit in Lifecycle Automation?

One of my favorite authors on networking in the last century (it sure feels odd writing that!) was Tannenbaum, and I loved his quote in “Computer Networks”; where he said “The wonderful thing about standards is that there are so many to choose from.” We could say that about standards bodies these days, and one such body is the MEF. Like all organizations, the MEF has evolved to stay alive, and its current iteration offers some guidance on service orchestration.

Originally, the MEF was the “Metro Ethernet Forum” but today it may be best known for its Lifecycle Service Orchestration (LSO) work. LSO is one of those sprawling standards initiatives that, like those of the TMF, are difficult to absorb for any who haven’t lived with them from the first. The current publicity on the work focuses on the LSO Sonata APIs, so let’s start our exploration there.

APIs are ways of exposing functionality as a generalized interface rather than as a human-driven portal or GUI. Obviously, an API set is only as useful as the functionality it exposes, and APIs inherit any limitations in functionality that exist in the underlying software. If there are issues with how a given function works within a given piece of software or software system, the APIs will inherit those issues. Like any implementation, APIs can also create their own unique issues if they’re designed wrong.

This “functionality” stuff is both the strength and the limitation of LSO Sonata. The APIs it defines are clearly linked to important business functions associated with network operator/service provider operations. That fact means first that there’s a strong incentive to use them, and second that the broad importance of the functionality almost assures that most operations software will be able to map functionality to those APIs. However, the limitation of the exposed functionality derives from its association with high-level OSS/BSS functions. What happens below, particularly at the network level with FCAPS, is out of scope.

Operators seem to like LSO Sonata for the same reason as enterprises like APIs exposed by their core applications; they facilitate the use of cloud front-end technology to broaden the categories of users that can be supported and tune the user experience to each. You need something like LSO Sonata to create OSS/BSS cloud front-ends of the kind that already drive enterprise use of the cloud. For this mission, there’s not much doubt that LSO Sonata is a good fit.

This API mission also fits in the pattern of opex optimization that the operators have pursued for the last decade. A network, like any cooperative system, can be operationally inefficient for two broad reasons. First, the means whereby operations teams exercise service lifecycle management can be sub-optimal. Second, the underlying network technology may itself be operationally deficient; the stuff is just hard to manage. Since capital equipment inertia limits the rate at which technology changes can be introduced, operators have focused on the first reason for inefficiency.

The problem is that the benefits that can be accrued by optimizing the exercise of management rather than optimizing the manageability of the network have largely been wrung out at this point. In addition, operators are finding that not all operations processes can be turned over to users by creating a portal. Some are too complex, too risky to network stability overall. Not only that, things like function hosting and even white-box switching have introduced new levels of technical complexity. All of this is becoming critical for operators, and none of it is within the scope of LSO Sonata.

The MEF does address some lower-level standards, though. One notable example is their “Lean NFV” model, and it’s notable for a positive contribution and also for a negative connotation. We’ll look at both, but start with the latter for reasons soon to be obvious.

NFV, or Network Function(s) Virtualization, is an initiative launched to replace physical devices with virtual functions hosted on commercial off-the-shelf servers. I’ve blogged about NFV many times, so I won’t go into all the issues I believe came up in association with it. The specific issue here relating to Lean NFV is that much of the focus of the NFV ISG within ETSI was on something other than what drove its launch, the “universal CPE” or uCPE model. This proposed an on-premises device that would host edge functionality by loading it with various edge-related features (like firewall).

To me, that concept was weak from the first. NFV is a high-complexity software structure, and it’s hard to justify using it to support software feature control in an edge device. The other problem is that the uCPE approach puts the whole NFV notion into direct competition with the vendors who would have to provide the virtual-function software in the first place. If you’re a firewall vendor who offers an appliance, why would you want to decompose functionality to let it run in a white box? Given this, I’d argue that focusing a standard on uCPE was a bad idea.

The positive contribution Lean NFV makes is the decomposition of the NFV management elements (specifically the VNFM, VIM, and NFVO) into “microcontrollers” which I take to be microservices, and the centralization of parameters in a key-value store (KVS) repository. If you are in fact going to do uCPE virtual functions, then you need a standard way of managing them, including their parameters. I also think that all those NFV functions should have been microservices all along, and that I think is what the “microcontroller” concepts introduced in Lean NFV mean.

The problem in Lean NFV is that while it creates a single API to manage a uCPE deployment (MEF Presto), that API is again a very high-level element, and almost everything in detail below it, including how the microcontrollers are structured, is out of scope. The effect is to harmonize the approach with LSO Sonata, to make uCPE visible almost to the service level, but to do so by abstracting away all the details.

You can’t hide complexity within an abstraction, you can only transfer responsibility for it away to another party, one who may be even less capable of resolving it. In this case, as in other cases we’re seeing in the whole service modeling and orchestration debate, there are just too many of these other parties who’d have to cooperate to make things whole. Even then, we’d be faced with perhaps a dozen different implementations of the same thing, and new layers of orchestration that add complexity.

Bottom-up strategies are always appealing for developers and standards-writers because they start with what we know. That’s not the question; we should be thinking about where they end up and not where they start. All too many times, we never get to the top of the matter, or we get there by skipping over the middle. I’m afraid that’s what the MEF has done.