While some would argue that NFV doesn't deserve a third, fourth or fifth chance, MEF has thrown its support behind Lean NFV.
MEF agreed to take on Lean NFV as a standards project in July of this year. Lean NFV created a stir at last year's Open Networking Summit North America by billing itself as an open solution for the management and orchestration of network function virtualization (NFV) environments.
RELATED: 'Lean NFV' takes center stage at Open Networking Summit
Nefeli Networks CEO Eugenia Corrales, who is one of the lead "editors" of MEF's Lean NFV project, said her goal was to have the draft Lean NFV standards completed by year's end. MEF CTO Pascal Menezes said that the Lean NFV standard would then need to go through a final phase of MEF membership and Board approval before a standard is published in 2021.
Assuming it passes the letter ballot stage, the Lean NFV standards would be passed over to MEF's board of directors, where there's a waiting period prior to their vote. Menezes said once Lean NFV reaches the letter ballot stage, the working team would start on the second version right away.
NFV MANO traces its origins back to a whitepaper by ETSI seven years ago, but for the most part, NFV has fallen far short of some its original goals due to its complexities. In short, Lean NFV is a simplified and elastic form of NFV that makes it easier to onboard virtual network functions (VNFs) and containerized network functions (CNFs) by using a key-value store as the universal point of integration.
"If I'm using one firewall and I decide I want to use a different firewall, as long as both firewalls can talk to the key-value store from a management controller perspective, I need to make no changes," Corrales said. "So it's very powerful."
While the MEF working team is starting out with a lean version of Lean NFV, Corrales said the eventual goal is for network function vendors to integrate their commercial VNFs directly with the key-value store. Those VNFs could be utilized today by doing a small wrapper around them to use their existing APIs to integrate with the key-value store.
"Juniper is one of the companies that has been involved from the very beginning," Corrales said. "They estimate that it will be relatively simple for them to integrate with the key-value store."
Corrales said while using a key-value store to manage NFV is a new approach, etcd, Google, Kubernetes, IBM and Salesforce use them.
"There's a lot of maturity around the usage of a key-value store," she said. "It's not something that we're inventing."
In Lean NFV's latest white paper, it identifies three key areas or goals to its approach. The NFV Manager would be implemented as a distributed set of interacting sub-components, each of which specializes in handling one or more specific task, instead of as monolithic solution.
According to the white paper, the Computational Infrastructure comprises compute resources (bare metal or virtualized) and the connectivity between them, provided by a physical or virtual fabric. The former is managed by a compute controller, such as Openstack, and the latter by an SDN controller.
VNFs can include both data plane and control plane components. The VNFs can optionally have an elemental management system (EMS), but only to handle VNF-specific configuration, which leaves all of the other lifecycle management tasks to the NFV Manager.
In addition to those three recognized NFV components, Lean NFV includes the key-value store, which is central to its approach for reducing integration complexity between the first three components.
RELATED: Colt Technology Services takes 'Lean NFV' on a test drive
There's also a commercial side of Lean NFV under the auspices of Nefeli. To date, Colt Technology Services, Sparkle/Telecom Italia and one other service providers are in different stages of deploying Lean NFV, according to Corrales.
Colt Technology Services' Mirko Voltolini, global head of network on demand, declined to discuss his company's use of Lean NFV after previously speaking to FierceTelecom, but Sparkle's Daniele Mancuso, chief of marketing solutions, followed up via email after this story was first published.
"As of today, what we have achieved after seven years is just the dematerialization of physical boxes that were responsible for a specific network function," he said. " But, in reality, we have just transferred that specific network function from one kind of box, engineered for that specific purpose, to another type of box that is a physical server. Nothing from the monolithic approach has changed so far and the process of certification, onboard, management and orchestration is really complex and requires lots of effort from the service provider perspective.
"What we really would like to achieve is the decomposition of a monolithic physical and virtual network function into several atomic components, each of them streamlined to absolve one specific task, consuming the minimum amount of resources. These atomic components could be then instantiated where it is more reasonable to do it—such as customer premises, point of presence, central office and data center) with the overall usage of resources resulting fully optimized."
Mancuso said in order to solve this "extremely challenging scenario, lots of simplification has to be sought and we believe Lean NFV can be the first step towards this direction."
Corrales said software management companies and network function providers are also participating in the Lean NFV standards work.
Lumen Technologies (formerly CenturyLink), NTT, Sparkle and Colt are among the service providers who are working within MEF on the Lean NFV standards. As of early last year, Lumen/CenturyLink was on its fourth version of NFV.
"It's really around creating a common set of interfaces that anyone can use to manage virtualized network functions," Corrales said. "We see it as another tool in the toolbox that's available to certainly the service providers, but also to a broader set of providers that we want to include such as MSPs, SaaS providers and cloud providers. It's another way for them to be able to integrate virtualized network functions.
"Lean NFV is a very flexible architecture. It could be used for a lot of things, but where we believe it's really standing out, the first very important use case, is the network edge."
MEF's to-do list for Lean NFV this year includes defining the integration points of Lean NFV into the MEF 55 LSO (Lifecycle Service Orchestration) framework; defining the internal Lean NFV interfaces and conducting a proof of concept trial (PoC) for a secure access service edge (SASE) use case.
"Apart of being involved in the running of the MEF project, we are actively working with Nefeli and other players on a MEF PoC dealing with a SASE VNF on a Lean NFV deployment," said Sparkle's Mancuso, who also noted it was too early to discuss a production phase.
"MEF has been climbing up the stack," Menezes said. "We went from physical connectivity with Ethernet to standardizing SD-WAN. And now we've gone up the stack further with the SASE story and security."
Menezes said there's a need within the industry for the ability to orchestrate virtual resources in a much more efficient way across various environments.
"It's really important that we be able to have this experience where a managed offering like SASE or SD-WAN is available to the subscriber," Menezes said. "When they pick what they want from their managed service, it's going to be able to instantiate through virtual resources. Those virtual resources will live at the CPE. They'll live at the emerging network edge and even in data centers."
RELATED: OPNFV evolves and hitches its wagon to Common NFVi Telco Taskforce
As it happens, the Common NFVi Telco Taskforce (CNTT), which is jointly under the auspices of the Linux Foundation's LF Networking and GSMA, is also targeting the onboarding of VNFs and the edge. Corrales said she looked at both ETSI and CNTT before deciding that MEF was the best avenue for Lean NFV's development, but she also said Lean NFV will work with both of them.
Lean NFV can work with or without a virtualized infrastructure manager (VIM), as well as with various VIMs, and it uses a virtual switch for monitoring, reporting and troubleshooting. Instead of deploying a monolithic stack that makes the service provider beholden to a vendor, Lean NFV can enable a tailored best of breed environment for managing virtualized resources, according to Menezes.
Lean NFV would also support MEF 3.0, which includes SASE, SD-WAN and the WAN edge. For MEF’s LSO Reference Architecture, Menezes said Lean NFV could come into play by going up the stack to the BSS level using the LSO Legato APIs or down with LSO Presto APIs for underlying technologies, but using either would be down the road a bit. MEF already has work underway for LSO Legato across SD-WAN, SASE, and Carrier Ethernet.
Digging into Lean NFV
While MEF is putting its resources and members behind the Lean NFV effort, Tom Nolle, president of CIMI Corp. has long argued in his blogs that NFV has been flawed since its inception, and that more time spent developing NFV is a wasted effort. While he's not all the way sold on Lean NFV, Nolle does see some promise and one problem.
"My conclusion, based on my examination of the latest whitepaper is that 1) they recognize the issues that created the NFV problems, 2) they’ve set three goals (computational, management, VNFs) that actually could help if they were achieved, 3) it would be possible to infer an implementation of those three goals that would likely work, but 4) a key-value store isn’t the right way to approach the implementation," Nolle said in an email to FierceTelecom.