Act One of the NFV show has finished, leaving operators to sift through the hype, piece together what they have learned and knuckle down to the serious business of design, feasibility and business case development. Pravin Mirchandani, CMO and NFV Evangelist at OneAccess, recounts some sentiments and soundbites from the NFV circuit.
Operators have now moved beyond best guess, back-of-the-envelope cost estimates. At least some measured CAPEX projections are in, and with them comes a grudging realization of quite how costly NFV is going to be. Why? Because operators must build x86 server farms right across their network in order to host their NFV infrastructure (NFVi); something which is going to mean a significant investment up front. What’s more, because virtualized traffic management requires the NFVi to be distributed (to provide appropriate location of network functions and traffic management right across the geographic reaches of the network), savings can’t be made by consolidating these farms on a single location. Sitting on top of the compute infrastructure, there is of course the software infrastructure and network functions, which also needs to be funded. What this has resulted in is a marked shift in focus to citing OPEX savings, service velocity and service agility as the main justifications for NFV, away from CAPEX reductions
To date, when considering performance, the industry’s focus has been on input/output (I/O) but, given that virtualized network functions (VNFs) are sold as services to paying customers, I/O is only half of the story. To be commercial contenders, VNFs need to be associated with performance guarantees that are enshrined in service level agreements (SLAs). Further, an assessment of compute and memory footprint for each network function is required in order to assess deployment scalability. This is no great challenge where dedicated hardware is concerned, but when the network function is software-based (as with a VNF), located on a shared computing platform, the factors influencing performance are dependent on a range of resource-related variables, making guarantees harder to establish. This area needs serious attention before the NFV can move into a fully commercial phase with the major operators.
Many operators won’t open the door to a VNF vendor without full disclosure of their pricing model, especially as a couple of leading vendors have announced pricing levels that are considered by the operators as unreasonable. Pricing models also remain fragmented between vendors, making it difficult for operators to compare like for like. The software element, in particular, is a minefield. Unsurprisingly, some vendors are applying NFV pricing in accordance with the anticipated impact that NFV will have on their future hardware revenues. This is distorting the market at a very early stage, inhibiting assessment by the operator community.
A lamentable result of the current NFV market is that operators’ choices of VNF trials are being defined by availability, not strategic objectives. vCPE and virtual firewall functions have both been around for a while, but are these two functions the only ones that the operators want to do? Perhaps it’s too early to say. In any case, the real focus of today’s VNF trials is to successfully build the NFVi and nail down the orchestration and management pieces. In this sense, it doesn’t yet matter what the actual VNF is. Over time, this will change. Operators will begin to assess which VNFs are the most important for their business, and which will save them the most money? Ideally, operators should be bringing this thinking forward; if they settle on VNFs that differ from those they have trialled, it will be a struggle to understand the commercial, technical and operational implications.
Operators are seeking a steady and sensible migration path to virtualization, one that minimizes the risk of introducing VNFs by running them in parallel with their existing OSS and organizational processes. Introducing NFV gradually, in an open and operationally practical way is key here. Operators will need to leverage existing provisioning services and chain VNFs with today’s legacy services to enable a smooth transition. This step-by-step approach to service migration will help operators avoid the leap-of-faith pitfalls of alternative green-field approaches.
EKINOPS (Euronext Paris - FR0011466069 – EKI), a leading supplier of telecommunications solutions for telecom operators, today completes the acquisition of the OTN-Switch (Optical Transport Network) platform developed by Padtec, an optical communications system manufacturer based in Brazil.
EKINOPS (Euronext Paris - FR0011466069 – EKI), a leading supplier of telecommunications solutions for telecom operators, has published its revenue for the second quarter of 2019.
EKINOPS (Euronext Paris - FR0011466069 – EKI), a leading supplier of optical transport equipment and router solutions, today announces the launch of the EKINOPS Channel Partner Program (ECPP). The program has been designed to support value-added resellers (VARs) and system integrators to differentiate in the market by providing them with the opportunity to build, sell and deliver solutions tailored to their customer needs, while still benefitting from the Ekinops’ extensive knowledge, resources and expertise.