• One buzz from ONS was that a new LeanNFV broom was about to sweep away the NFV cobwebs
• However, by no means everyone agrees. Yes, it’s always easy to pick holes in the new from the standpoint of the old, but...
• LeanNFV may be on a road to nowhere

The LeanNFV white paper caused a bit of a stir when it was released at last week’s Open Networking Summit (ONS) in San Jose. That’s only natural. This was a venue to discuss open networking and the open networking supertanker, slowly but remorselessly ploughing its way through the ice flows of proprietary technology, is non-lean NFV.

Many of those present had sunk six years of time (and money) into that NFV voyage and so, depending on how they felt the trip was going, it was natural that they either cautiously welcomed the concept behind Lean NFV as a possible solution to the alleged NFV lack of progress problem; or they unwelcomed it as a distraction to a process which, while slow, was now getting there. Supertankers don’t have a ‘go faster’ button, they might say, you just have to see it through.

Premises, premises

The premise of the white paper is fairly straightforward. NFV has gone too slowly and while that might be down to a number of things, the biggy is that its software infrastructure components are too tightly bonded, it alleges. That makes it hard to innovate, increases complexity, complicates integration and drives practitioners to distraction, it’s claimed.

The white paper lists a range of problems and solutions (read it here)  but its big idea is the addition of a ‘Key Value store’ to the NFV infrastructure architecture. This provides a sort of central repository of keys and their values enabling components to ‘discover’ each other and exchange ‘state’. That, the authors claim, will make it easier to integrate components and solve much of the current problem set.

But, you guessed it, nothing can be THAT easy. Like everything in this world the Key Value Store comes with its own problems and downsides, claim LeanNFV critics.

Downsides

“I have to say that we are unimpressed with the Lean NFV concept,” says Martin Taylor, Chief Technical Officer of Metaswitch Networks, which specialises in cloud native software for service providers. “They are proposing the use of a distributed key value store as a panacea that will cure all NFV's ills, and in particular address the problems around interoperability between VNFs, cloud infrastructures like OpenStack and VNF Managers.”

Martin says that  distributed key value stores are an extremely useful tool in building and managing the configuration of cloud native VNFs - in fact Metaswitch uses key value stores extensively in its own VNFs for these purposes - but LeanNFV proposes to use KV stores for far more than config management.

“They are suggesting that VNF Managers communicate with VNFs via the KV store for initial deployment, monitoring and scaling. In a truly cloud native architecture, based on containers, Kubernetes does all of these things for you with standard APIs which are very easy to implement,” he says.

“They are also suggesting the use of KV stores for VNFs to send metrics to analytics systems.  This is not a good fit for KV stores. Instead, best practice is to use one of the emerging cloud native analytics packages such as Prometheus which has its own API for VNFs to stream metrics to.”

But he says, even if you believe that KV stores are a good solution to the above problems, they don't magically solve the interop problem.

“You would have to have all the different vendors agree on the schema for the data to be exchanged via the KV store, and we all know how easy that kind of standardization can be. In our view, truly lean NFV is based on the use of containers with Kubernetes and that will make pretty much all of the problems that LeanNFV claims to address, go away.  And it doesn't require anything new to be developed or any new standard to be agreed.”

A spur to action?

David Martin,  Associate Senior Analyst at London-based telecoms research consultants STL Partners, thinks the white paper’s approach is interesting and, if nothing else, might challenge to the industry to come up with a more agile and deployable methodology.

“ I think it should probably evaluated as a spur to agile innovation rather than a 'definitive' architecture, whatever that might mean,” he says.

“The functional separation of the 'NFV management', VNF and infrastructure layers, and integration via a common 'key value'  is certainly logical, but we need to see how the thing performs in live telco environments supporting real services.

Potential problems

“The potential problems, as I see them, include the fact that the solution proposes treating NFV workloads exactly like any other IT workload, using standard infrastructure managers. But will this be adequate for carrier-grade performance and throughput requirements?

“The white paper also claims that open-source KV frameworks have sufficiently robust access controls to meet the security requirements of telco networks.” This will also need to be tested he says.

“Can a standardised KV framework provide an adequate 'Common Information Model' to support telco service modelling, fulfilment and lifecycle management? The search for common information and data models, and the inability to agree on them, is one of the things that has held up NFV up to now, but I'm not sure using Key Values is either adequate to the task, or even necessary - TOSCA and YANG are now de facto standards for similar purposes.

“Finally, the white paper says Lean NFV isn't intended as a competitor to ONAP and OSM - the two leading open-source NFV initiatives. That may be the intention, but in practice isn't it inevitably going to become a competitor and potentially contribute to the further fragmentation of the NFV world?

“Rather than proposing a possibly simplistic, theoretically common approach to NFV, isn't it time to just accept that the only thing that will sort this out is market forces. Lean NFV will succeed if it actually helps telcos to do NFV in a leaner way; but the jury is still out. In fact it hasn't yet got any evidence to go on.”

An attempt to bridge the unbridgeable gap?

“The challenge with NFV has always been that you only get its full benefits if you design the software to be cloud native from the outset,” says Martin Taylor. “You can't just retrofit cloud nativeness to software that was architected for a physical appliance. LeanNFV looks like an attempt to bridge the gap, but we think the gap is essentially unbridgeable.”

So the obvious question is: What category of vendors or telcos would a ‘lean’ NFV along these lines favour. There’s always winners and losers in these situations - who would the winners be?

“I think the intended beneficiaries are vendors of legacy VNFs that are based on software ported from physical appliances where things like config management have traditionally been performed by command line interface.

“Using a KV store instead of a CLI is a great way to improve your ability to do operations automation.  Unfortunately, it turns out to be extremely difficult to modify such legacy software to use a KV store instead of a CLI for config management. That's one of the reasons I think LeanNFV is doomed.”