'Lean NFV' Aims to Reignite Virtualization
SAN JOSE, Calif. -- Open Networking Summit -- A pedigree group of industry insiders is proposing a plan to jump-start network functions virtualization (NFV) by streamlining the architecture and processes involved in order to give virtualization efforts a new lease of life.
To get the ball rolling, the collective behind the "Lean NFV" proposal have issued a white paper, setting out their ideas and goals. The time is right, according to the high-level proposal on the Lean NFV website, because "the community has waited patiently for Network Function Virtualization (NFV) solutions to mature. However, the foundational NFV white paper is now over six years old, yet the promise of NFV remains largely unfulfilled, so it is time for a frank reassessment of our past efforts."
The individuals who have endorsed the white paper and put themselves forward as early supporters of the approach, are;
Lean NFV is a streamlined NFV reference architecture that aims to greatly simplify the "onboarding" of virtual network functions (VNFs), enable interoperability of NFV stack components, simplify operations and accelerate NFV adoption, according to its leading advocates.
The streamlined approach focuses on what the white paper identifies as the "three main pieces of NFV solutions," namely:
Further details and explanations can be found in the white paper.
So why do we need Lean NFV? Since NFV was outlined by the group of operator executives that founded the ETSI NFV Industry Specification Group (ISG) in 2012, progress has been slower than anticipated, Shenker said during a keynote here at the Open Networking Summit on Wednesday.
"Why has this been so hard?" Shenker asked. NFV, which involves a few simple components, is "not a trivial problem," he noted, "but it's not a six-year problem."
Integration has been the bottleneck, he noted, slowing deployment and making innovation "nearly impossible."
The solution is to simplify the focus, as noted above, and introduce a new component, a key-value store (KVS), similar to technology known as etcd that provides shared configuration and service discovery capabilities in container clusters.
The KVS allows for discovery and information exchange in lean, extensible ways, Ratnasamy noted during her ONS presentation.
"It's lean in the sense that the only thing it specifies is where you go to the discovery stage. Everything else in the system is open to integration," she said. Everything else comes from the vendor.
The NFV manager handles launching, configuration, chaining, monitoring, scaling, healing and more. Each of those capabilities is broken into components, called "microcontrollers," with each microcontroller integrated with the KVS. Each microcontroller can come from a different vendor, Ratnasamy said.
"Key value and integration allows vendors to evolve in a way that's incremental and independent of each other," she said.
Among the benefits of Lean NFV is giving networks the flexibility required for 5G, said Polychronopoulos, who also took to the stage here. "When we talk about 5G, the mind goes to [a] highly distributed network infrastructure," he said. "By design, Lean NFV is suitable to highly distributed networks and infrastructure."
But Lean NFV is in its early stages. "Nobody pretends we've solved all the problems," Polychronopoulos said. "What we have now is a concept," a starting point from which the community can develop a new approach to virtualized infrastructure. He pointed attendees to the website, leannfv.org, to find out more and get involved.
"The main technical points are simple," Shenker said. "Use the key-value store as a universal point of integration and remove a need for specialized VIMs. That's it." Lean NFV isn't a single code base; it's an open architecture designed to create a lean, extensible multivendor ecosystem for NFV.
"It's a minimal design that allows easy integration, and allows everything else open for innovation," Shenker said.
Will it work? Shenker, Ratnasamy and Polychronopoulos make a good case for it. They and their supporters have outstanding résumés. So Lean NFV is at least worth digging into and might be the new direction the NFV community needs to rid itself of its current torpor.
But might this just result in further confusion about the right approach to take -- after all, some major network operators are trying to get the operator community to double down on the efforts of two Linux Foundation Networking (LFN) working groups, Open Network Automation Platform (ONAP) and Open Platform for NFV Project Inc. (OPNFV).
It may also lead to exasperation that the virtualization community is being asked to start again after years of toil.
After all, there have been signs of progress. Since last year, we've seen significant endorsements and proofs of NFV viability from Turkcell, Intel, AWS, Colt, Equinix, AT&T and VMware. With that kind of momentum, is another approach to NFV necessary?
Lean NFV's plan to solve the current complexity by proposing a new approach and component does remind us of this classic xkcd cartoon: "How Standards Proliferate."
The Lean NFV team seems aware this move may lead to tension and exasperation: The white paper states that "this does not mean we have to throw out all our previous efforts; in fact, the Lean NFV approach should be seen as a complement to some of the existing open-source efforts."
However, the overall message is emphatic: "Current NFV efforts are drowning in a quicksand of complexity," notes the white paper. Essentially, while some progress is being made, it is too cumbersome and resource-intensive.
Light Reading will track this new development closely to see if it can deliver the simplicity so long craved in NFV circles and be a catalyst to the innovation that will be needed if the distributed telco cloud is to underpin 5G efforts: NFV is, after all, an important puzzle piece in the 5G Big Picture.
— Mitch Wagner Executive Editor, and Ray Le Maistre, Editor-in-Chief, Light Reading