We continue to have a lot of discussion around the use of open-source technology by network operators in NFV and SDN applications. Obviously, the majority of the SDN spectrum is already covered by open source (OpenDaylight for example) and there’s no shortage of open source in NFV either, with OpenStack, Linux, and so forth. Why is there a need for a formal group, under the Linux Foundation, then? If there is a need, is the process likely to meet it?
If you looked at either SDN or NFV holistically you’d find that there are three basic pieces to each. There’s underlying infrastructure (in SDN, white-box switches and in NFV server pools), there’s applications that control behavior (VNFs in NFV and those “northbound apps” in SDN) and there’s some central binding/control logic—orchestration in NFV and the Controller in SDN. We have some open-source contribution to all of these areas already.
The problem, as operators report it to me, is that their business case for SDN or NFV demands a fairly comprehensive implementation of a whole service and operations ecosystem that can accommodate these new technology options. You hear all the time about how we have to integrate SDN with network management or NFV with OSS/BSS, but it’s more complicated than that. The management tools and practices of a pre-virtual world don’t map optimally to the new cloud-SDN-NFV tools. That lack of optimality means that you can’t make as good a business case, which means less gets deployed.
In my early spring survey of operators, the consensus of C-level executives was that their trials for SDN and NFV were proving technology choices but not proving the business case. That means that all this work is at risk for being rendered useless, because nobody cares if something works technically if it can’t create enough value to deploy. I think that one big driver to the open-source movement is the frustration of operators with the fact that they don’t have a clear set of SDN or NFV ecosystem options in place, that they can’t do a useful trial for lack of functional scope.
For the last decade, operator have faced business transformation pressures, and they clearly face them even more starkly these days. Normally they’d have expected a competitive equipment market to come to their rescue, producing new gear to take them in new directions. Since 1999, though, the vendor community has been induced by Wall Street to focus on selling the next quarter’s quota, and has simply not been interested in rolling the dice on some transformed future. So, say the operators, we have nothing from them that builds the ecosystem up to the top, where the benefits collect. Vendors all hope somebody else will do it—and operators think that if vendors won’t, then open-source is likely the only choice. They can’t band together in any other forum without generating anti-trust complaints.
OK, so we do have a problem. The question then is whether the project under the Linux Foundation can solve it. Some of that is beyond our ken right now because we don’t know what they’re going to do, but there are some disquieting signs in my view.
Sign number one is that the activities we already have in open-source networking, and the proposal for the NFV one, are based on what I’ll call the “ONF model”, meaning that they’re a group with “membership levels”, the top levels of which will require a significant annual investment and the bottom levels of which may not even admit smaller tech companies who can’t pay ten to fifty grand per year to play. So who funds these “Platinum” levels? Vendors, big ones, the same ones who haven’t been delivering commercial solutions to the transformation dilemma their customers face. Why do it now, then? Wouldn’t these people just hunker down as they’ve always done to protect their current revenue model?
Sign number two is that the early target areas for open-source NFV are in the areas of NFVI, the infrastructure. Did we learn nothing from SDN? What good is a protocol to drive switch behavior in the absence of any way to model target behaviors and present them to users? We’ve proved we can build IP network areas and Ethernet data centers using SDN, but we’ve had those things long before SDN came along, so the benefit is hardly revolutionary.
A realistic target for NFV open-source has to start with a set of goals, and here are my candidates:
- First, you require that the architecture admit all current open-source network functions running on a cloud-capable platform, without changes to the functions. That lets open-source into the VNF opportunity space.
- Second, you require that there be a boundary between infrastructure and services that is abstracted so that it can support both legacy technology (devices or collective services presented through a provisioning interface like that of an NMS).
- Third, you focus on finding open-source tools that can be enhanced to get you where you need to be, not on developing something from scratch. We’ve spent nearly two years now on NFV standards. Do the operators want to spend two more on open-source NFV development?
But we’ve still not targeted the problem, the benefits. So here’s a stark truth for you. Every single document I’ve seen that presents a credible survey of operator interest ranks service agility as the top goal for both SDN and NFV, and ranks operations efficiency as either goal two or three (capital savings is ranked higher in some). What generates agile services? It’s not just agile components, it’s an agile component assembly process. That means an orchestration or service-building model that can quickly define complex services, services that initially and maybe forever will be a mixture of legacy stuff and new SDN/NFV stuff. Where is that structure? Everyone who talks “orchestration” and “management” is taking all of the new virtual things and sticking them into the old operations model, a model that everyone agrees is too monolithic even now.
We’re supposed to be talking about these issues next week. So my challenge to the operators, to the Linux Foundation, is show that something can be done to drive NFV and SDN deployment, not just prove that deployment is possible. There are a lot of things that can be done that won’t be, because nobody can make the case. Prove that SDN and NFV don’t have to be among that group of losers.