The Pains and Problems of NFV
|
Listen to post:
Getting your Trinity Audio player ready...
|
All too many vendors like to trumpet the promise of network functions virtualization (NFV). But deploying an NFV architecture is fraught with so many problems and challenges that all too many telcos have abandoned the approach. Why and what are the problems? Read on to find out.
NFV Success Overstated
Limited operator deployments
“Another miss in 2018 is massive SDN/NFV deployment. Yes, we have some of both today, and yes, there will be more of both in 2018, but not the massive shift in infrastructure that proponents had hoped for. Operators will not get enough from either SDN or NFV to boost profit-per-bit significantly. Other market forces could help both SDN and NFV in 2019 and 2020, though. We’ll get to that at the end of next year, of course. The fact is that neither SDN nor NFV were likely to bring about massive transformational changes; the limited scope ensures that. Operators are already looking elsewhere, as I noted earlier in this blog. The success of either SDN or NFV depends on growth in the carrier cloud, and 2018 is too early to expect much in that area.”
The Driving Technologies for Network Operators in 2018,” CIMI, Corp, Tom Nolle, January, 2, 2018
CSPs Face Limited Choices
To really make this work though, the software elements need to be fully interoperable, in order to enable vendor independence and competitive pricing. The resulting network is rapidly scalable, flexible, and benefits from dynamic resource allocation. This is what NFV should be enabling – the access to a full range of interchangeable best-of-breed, trusted Virtual Network Functions (VNFs) that can be easily and cost-effectively deployed.
What is actually happening is that a lack of information and insight means that CSPs are becoming locked into full stack virtualized solutions from a limited set of vendors. Instead of having their choice of hardware constrained by lack of interoperability, they are now finding constraints in the virtual world as their choice of software is being stifled through lack of accessible, certified information.”
Cost/Benefit Rationale Unclear
Are the economies of scale an illusion?
“Most often, it’s an unrealistic assumption that applications in software on standard platforms will meet the throughput and latency demands without allocating considerable CPU resources. Operators are realizing that the cost savings of NFV are offset by the need to deploy entire racks of compute resources for a problem that a single appliance could previously solve. The CPU and server costs, rack space, and power required to meet the same performance footprint of a dedicated solution end up being as expensive as or more than custom-designed alternatives. The vision of operational simplicity and dramatically lower total cost of ownership are still a dream on the horizon.”
https://www.datacenterjournal.com/making-dream-network-functions-virtualization-reality/
Where is the business benefit?
“NFV is a huge undertaking for Network Service Providers (NSPs), involving many moving parts that are partly outside their control. The ramification of which is both the NSP and enterprise will realize only minimal cost and operational benefits. Despite the hype, NFV may not be worth deploying”
https://www.catonetworks.com/blog/why-nfv-is-long-on-hype-short-on-value/
NFV Filled With Technical Problems
NFV is too complex
“….while NFV provides an opportunity to reduce opex and improve customer experience, it introduces additional layers of operational complexity that “put more onus on the operator to integrate technologies that were traditionally integrated by a vendor.”
This chimes with the results of a survey that Amdocs recently undertook that asked CSPs about the most significant barriers to implementing open source NFV (as opposed to sourcing a turnkey solution from one supplier). Maturity/stability (35%) was the chief concern, which is no surprise given that many of the open source NFV projects are quite new.”
“The Challenges of Operationalizing NFV,” LightReading, James Crawshaw, November 29, 2017
VNF and NFV not living up to the promise
“The initial thinking was that the virtualization of physical appliances and network functions virtualization (NFV) would make carriers more agile. They could run a fully managed orchestration platform, spinning up virtual network functions (VNFs) in a generic customer premise equipment (CPE) device. Carriers would gain the efficient use of software licenses, centralized management, and upfront saving they’ve long sought and enterprises achieve the branch office operational cost reductions they’ve long wanted.
But operationally, VNFs are still multi-sourced virtual appliances. Each has to go through a complete lifecycle of sizing, deployment, configuration, and upgrades. Each must have its own redundancy scheme built per customer. Each must be run through its own management interface and policy engine. Can you imagine Amazon offering AWS where virtual machines are deployed per host, run a vendor-specific operating system, and managed by vendor-specific tools? What a headache. If that was the case, AWS would be far less compelling.”
https://www.catonetworks.com/blog/the-carrier-cloud-needs-a-new-fabric-not-a-patched-cloth/
Limited Connectivity Capabilities
“Most off-the-shelf vCPE/uCPE hardware features Ethernet ports to connect to the WAN, but little more. This is a serious impediment because most service providers operate multiple access media in their footprint, and want to deploy vCPE services across as many of these media as possible – including mobile/wireless technologies to cover more remote enterprise locations. Ideally, customer premises hardware should be able to serve all locations, regardless of available access media, without requiring additional box appliances to be deployed. Smart SFPs available in the market can be used for this purpose.
“Significant problems remain: Stitching the service chains together from different VNFs is proving to be harder than expected, and requires lengthy and costly interoperability testing. This can usually be alleviated by the vCPE solutions vendor pre-testing and integrating the VNFs from different vendors, and ensuring open APIs exist for all tested VNFs.”
https://www.cbronline.com/opinion/vcpe-challenging
VNF bloat crippling uCPEs
“….service providers are seeing their $1,500 or $2,000 uCPEs barely matching $500 to 800 NGFWs in key aspects of networking performance. In addition, service providers are sore about having to manage 60 to 80 GB of SD-WAN and other VNF images and about sacrificing two to four CPU cores just for SD-WAN/NFVI management overhead. They worry that eight x86 cores on an edge box is insufficient, yet don’t want to go to 16 cores because of the high price….”
There’s nothing universal about the universal CPE,” SDXCentral, Roy Chua, December 06, 2018
VNFs: difficult to work with
“…From a VNF perspective, things are not as automatable as we would have hoped,” said Mitchell, the director of NFV, cloud, innovation labs and support networks at Telus. “These VNFs are more of what was called a ‘lift and shift’ type of deployment. So you took a traditional piece of software that was running on vendor-provided hardware, and it came in a contained almost black-box type of solution, and that got lifted into a virtual machine and then dumped onto a pod and boom! We’ve got NFV and we got all the benefits and life is good and we’re done.
“Well, that’s not exactly true because these VNFs are very difficult to work with. They tend to be tightly coupled within themselves, and they tend to not have the openness and APIs that we would need in order to manage and configure them.”
Eliminating complexity—or increasing it?
“Problems within service chains have come to epitomize the problems with NFV. When it comes to deployments, there are significant restrictions on the number and variety of functions in a service chain. This leads to either remaining with legacy, physical network functions vendors or increasing the number of silos, which is a shame as the NFV vision was meant to break down these two barriers. Frustratingly, this can lead to increased costs as the operator transforms fixed physical infrastructure into a software-based, dynamically switched model. It turns out this is easier said than done.”
https://www.sdxcentral.com/articles/contributed/problems-with-service-chaining-stalling-nfv/2018/08/
NFV Not Achieving Key Goals
Headed in the wrong direction?
“Gumirov’s honest assessment is that Deutsche Telekom AG (NYSE: DT) is somewhere between the old physical network function and the cloud-native VNF, at an overall stage he optimistically terms the “cloud-ready VNF.” While some functions have been relatively easy to “cloudify,” such as the voice platform and telephony application server (TAS), others have not. In fact, when it comes to some of the mission- and performance-critical functions, the industry appears to be heading in the wrong direction entirely, according to Gumirov. “The trend is a bit scary,” he said.”
vCPE and uCPE are the wrong approaches
“One of the service agility benefits quickly proposed within the ISG was the creation of multi-part services by the chaining of VNFs, and this gave rise to the “service chaining” interest of the ISG. A virtual device representing a service demarcation might thus have a VPN VNF, a firewall VNF, and so forth. Recently, SD-WAN features have been proposed via an SD-WAN VNF in the chain. All of this got framed in the context of “virtual CPE” or vCPE.
“As a practical matter, though, you can’t fully virtualize a service demarcation; something has to provide the carrier-to-user connection, harmonize practical local network interfaces (like Ethernet) with a carrier service interface, and provide a point of management handoff where SLA enforcement can be monitored by both sides.
Could you deploy a service chain of functions (VNFs) into a uCPE box, as though it was an extension of carrier cloud and using the set of features and capabilities the ISG has devised (and is still working on)? Perhaps, but the better question would be “Should you?” There are in my view some compelling reasons not to do that…”
Why vCPE and uCPE are the wrong approach,” CIMI Corp, Tom Nolle, November 28, 2018
Performance and scaling
“The performance and scaling problems that operators face with generic NFV infrastructure (NFVi) will only be worsened by 5G networks. The move to 5G brings new requirements to mobile networks, creating its own version of hyperscale networking that is needed to meet the performance goals for the technology, but at the right economy scale. Numerous factors are fundamentally unique to 5G networks when compared to previous 3G/4G instantiations of mobile protocols. The shorter the distance, the higher the frequency – thus, the more bandwidth that can be driven over the wireless network.”
Bottom Line
It’s apparent that two things are true: NVF and its elements have a tremendous amount of potential and that a lot of work remains to be done. Are you aware of any other issues or have particular insight into any of those mentioned above? Let us know at press@catonetworks.com
