Analyst Nolle: Fundamental Errors Plague NFV

It isn't hard to find folks who'll say telecom's adoption of NFV isn't going all that well, but few speak with the authority -- and specificity -- of veteran industry analyst Tom Nolle.

Nolle, a software architect and head of his own consultancy, CIMI Group, was closely engaged with operators and vendors in the early days of Network Functions Virtualization, and as the leader of a consortium called CloudNFV, had the first proof-of-concept to be approved by ETSI's NFV Industry Standards Group.

What Nolle now says, however, is that the industry made a fundamental mistake in adopting what was intended to be ETSI NFV ISG's initial functional model as its actual software implementation for NFV. In doing so, it sent NFV development off in the wrong direction -- an error from which the industry hasn't recovered.

"People constantly assured me it was only a functional diagram and wasn't intended to show how the software would really be structured," he says in an interview. "I told them from the very beginning that if you did structure the software that way, you would produce something that isn't going to work and that's exactly what happened: We produced something that isn't going to work on a large scale."

"The fundamental issue here is we should have known that this has to be a data model-mediated, stateless process-implemented framework for the cloud, or it is not going to scale," Nolle states. "And that is the reality of this."

Spelling it out
In a blog posted earlier this week, Nolle lays out how the original CloudNFV approach addressed critical issues still being raised today around NFV, and he is confident in saying he believes it would have worked.

"If we could have done what the architecture was intended to do, I believe that by the early part of 2014, we could have had a global multi-operator testbed for full orchestration of management and operations process and onboarding of VNFs in a way that would have been standardizable, repeatable and everything," Nolle says. "I believe that because I sat down with six operators and showed them through the process how it worked and they agreed it would work."

Get real-world answers to virtualization challenges from industry leaders. Join us for the NFV & Carrier SDN event in Denver. Register now for this exclusive opportunity to learn from and network with industry experts -- communications service providers get in free!

For those who don't remember CloudNFV, it was a small pack of vendors, led by Nolle, that argued NFV would require a cloud-based implementation. The group set about developing a prototype as quickly as possible, which became the ETSI proof-of-concept, sponsored by Telefonica and Sprint. The intent was to move quickly to productize, but the six vendors involved never took that final step. Nolle stepped away from the project in early 2014, having spent more than a year of his own time on the effort. (See CloudNFV: Dell's Lost Opportunity?)

"It ended because ultimately it was a small consortium activity that never had the kind of funding it needed to have, and where the goals of the individual companies to make a profit from their efforts eventually made it impossible to move forward collectively," Nolle says now.

But he is frustrated looking back, because NFV has pretty much evolved as he feared it might. Nolle is known for his candor -- and his amazing safari vacations -- and isn't pulling any punches now. Five years into its evolution, NFV hasn't been the transformational technology the industry sought.

"I'm frustrated because I'm saying to these guys right from the start, hey, this is a cloud development process, where is the discussion of the cloud architecture?" he comments. "Where are the issues being raised that define how this would be made to be scalable and resilient and so forth? These are all things that a software architect would say are part and parcel of the value proposition, that you need at the start because you can't retrofit a new programming architecture onto an old set of interfaces, but we never did it."

There has been an evolution in the cloud realm, but it's being led by Amazon, Google and Microsoft, he notes. They are now producing programming languages and software architectures that deliver on the promise of cloud, supporting event-driven applications.

"That is what NFV would look like if you generalized it. It's an event-driven application where events are service conditions," Nolle says. "All event-driven applications are going to end up being written this way. It's the only way you can write them if they are going to work properly."

Is it too late to start over?
The veteran analyst says it's not impossible for the right approach to NFV to still be adopted, but he sees that as unlikely for a couple of reasons. First, it would mean companies basically throw away a ton of work they've already done and that's going against their internal politics in a big way. Secondly, Nolle sees some operators embracing a different strategy: buying legacy stuff more cheaply.

"The biggest problem is tempis fugit," he comments. "There was a compelling value proposition for NFV in 2013 -- that value proposition is rapidly diminishing because the more operators invest in another model of network transformation, a model that says, screw virtualization and all the other things, let's just buy really cheap stuff. And the more you invest in really cheap legacy technology models, the less incremental value there is to the original NFV concept."

Nolle believes much of what is called NFV today is basically replacing a physical appliance with a general-purpose computer and some software instances.

"The result is still a box -- it has none of the dynamism or resilience is baked into the process," he says. "I've just taken logic that used to run in a box and run it in a different box, or done it a cloud-hosted services."

For a look back at CloudNFV:

— Carol Wilson, Editor-at-Large, Light Reading

VPMarket13134 8/18/2017 | 3:48:52 AM
Cato Networks does "NFV" for the cloud If you sum up the 2 main factors Nolle (and other commentators below) cite for the architectural challenges of NFV they are: sticking to appliance form factors vs built for the cloud service software and waiting for incumbents to build VNFs that conform to the new services architecture and eliminate their telco lock in the process. We decided to achieve all the goals of NFV but without falling into all these traps. We built a converged network and security platform from scratch in software as a multi-tenant cloud service. No appliances, no 3rd party components that need separate management or scaling. It is basically a new carrier operating system and we using it to compete with incumbents. Take a look at https://www.sdxcentral.com/articles/contributed/the-carrier-cloud-needs-new-fabric-not-patched-cloth/2017/04/
Carol Wilson 8/17/2017 | 1:41:10 PM
Re: NFV is Deployed, Stop the Negativity clarkede, 

I understand your frustration but here's mine: I write a lot of articles about NFV deployment, so in the broad scheme of things, there is balance on the Light Reading site. I've probably written more positive articles in the last year than negative. And invariably, someone complains that we're sugar-coating things. 

We are, at the moment, in a period where some are reflecting on how far NFV and virutalization has come, compared to where it could be, and I don't think that's a bad thing overall. it has the potential to inform deployments going forward.


clarkede 8/17/2017 | 1:38:06 PM
NFV is Deployed, Stop the Negativity It is getting very tiresome to see such repetitive and unjustified negative commentary about NFV. Leading operators are deploying, for example BT: https://www.globalservices.bt.com/uk/en/news/bt-accelerates-cloud-with-hosted-riverbed-service. Lets have some balance please.
Kevin Mitchell 8/14/2017 | 9:21:58 AM
Choose Your Own Virtualization Adventure

NFV hasn't been the transformational technology the industry sought.

Where NFV is applied to VoIP, I've been saying this for years on my blog and this LR message board (see Danger of Decomposition as an example). NFV is overly complex, too costly to build, and won't deliver on the promise of feature/market agility. Plus traditional vendors aren't motivated to bring about the desired business outcomes and service providers need a next-gen solution today, not 2025.

For each service or application, service providers should define the desired business outcomes of any network change and examine all the technology paths.

At Alianza, we've argued that for most service providers the best approach for VoIP/UC is to use a turnkey, integrated virtualized software solution delivered via the cloud (vs building your own NFV-based IMS cloud).  

A Heavy Reading study (link to it below) supports a growing inclination to cloud source vs build: 83% of CSP respondents said that it was somewhat or very likely that they'd use a XaaS option for replacing or augmenting network infrastructure.

Read more in my blog posts:

And white papers:
TomNolle 8/14/2017 | 8:57:59 AM
Re: CloudNFV I agree, but the problem that CloudNFV demonstrated is that the network opertors want to have big firms with deep pockets to back them in any new technology initiative.  Network equipment vendors were understandably slow in backing a venture that was designed at the first to reduce capex, which of course meant their own revenues.  The server players were the ones that operators in 2013 were looking to, at least for backing.  They believed for a time that Dell would indeed step up and become the de facto champion of the CloudNFV effort, rather than just being a supplier of servers.  Since they didn't do that, it left the project with no big-company champion.

FYI, there was another company involved in CloudNFV but who declined to make their participation public.  They were another big player, but I think they believed that the risk of alienating some of their customers would be excessive.
Gabriel Brown 8/14/2017 | 4:44:15 AM
Re: CloudNFV "Could the current projects be retroed to take a cloud view?"

Redesiging what exists and then attempting to displace the incumbent network is expensive, and given the revenue and margin opportunity in telco networking, possibly not the most astute business decision. This is a problem for NFV. A lot of work, for not an enormous amount of gain, even if it goes well.

The better investment is in newer systems, new architectures, and new deployments.
Gabriel Brown 8/14/2017 | 4:34:38 AM
Re: CloudNFV Dell wasn't and isn't a telco networking company so didn't / doesn't have chance of driving an NFV vision to reality. It's best bet is to excel in its role as a hardware/server vendor. For the same reason, for the majority of networking vendors, there's no sense in attempting to become server vendors.
TomNolle 8/12/2017 | 10:41:46 AM
Re: CloudNFV Originally, when I was Chief Architect of CloudNFV, it WAS an open project and it at least allowed open-source implementation, though the initial vendor software was not open-source.  Dell provided the test cloud and hosting, but they didn't contribute software functionality to the project at that point.  I don't know what happened beyond early 2014 when my involvement ended.  The open framework did not develop as I had expected/hoped it would.

My concern with the current open projects you cite is less the time/momentum issue than that they followed the ETSI functional model fairly literally rather than taking the cloud-centric view CloudNFV took.  I truly, firmly, believe that a literal functional-model implementation will not scale or perform as operators want.  Could the current projects be retroed to take a cloud view?  Probably, but it would be difficult to turn something around like that at this point.  I think if anyone gets this right, they'll likely start from scratch and follow the cloud-and-intent-model approach CloudNFV took.
James_B_Crawshaw 8/12/2017 | 3:32:32 AM
CloudNFV I understand CloudNFV had a lot of carrier interest and the components and interfaces were generally considered to be good. For some reason Dell, the main vendor behind the PoC, decided not to follow through. Seems like a missed opportunity because they are still active in this space. However, CloudNFV would have been a small ecosystem dominated by one vendor. The open source alternatives that we have today (ONAP and OSM) are arguably more likely to succeed in the long term though they take longer to build momentum. 
Gabriel Brown 8/11/2017 | 10:39:52 AM
NFV Progress Tom's point is well made that if you create a functional diagram, people will build to that. The same risk is there now in 5G standardization (more on that another time).

And we've known for a while that operators are benefiting from lower cost equipment due to the implicit threat of virtualization. You could argue that NFV has achieved one of its goals without without actually being deployed at scale.

And yes, NFV could have made better technical progress, etc. At the same time, you can see progress in many operators. It's not as gloomy as the piece indicates, in my view.

One (the?) fundamental issue is investment cycles. I've argued for years that the big opportunity will not come until big operators are making major refreshes that are architecturally signifcant, or are investing next-gen deployments. If you already have an IMS, or an EPC, or whatever, the motivation to rip and replace is low. You may use a virtual solution for add-on use-cases, but in effect, your cake is baked already.

SDN WAN seems like good example of where there's enough new stuff, and enough operational change, that new solutions are worth pursuing. I don't actually cover SD-WAN, so feel free to correct me on that.

In mobile, 5G is the next obvious upgrade cycle. This is the time operators need to be strategic and make the move to cloud (where it makes sense, etc. etc.). It will be tempting not too, especially with the agressive timescales and technical challenges in a 5G launch. But this is a once-a-decade opportunity
Sign In