One of the big attractions of NFV is that it gives operators a chance to break free of single vendor contracts and establish greater control over the future development of their networks.
Genuinely ‘open NFV’ gives operators the ability to change tack according to technical and commercial developments. It enables them to shop around for best of breed solutions and blend a mixture of, say, migration-oriented hybrid solutions with white or grey-box CPEs and connect them all to their choice of orchestrator. It also dramatically improves their negotiating power.
Yet, despite appearances, few NFV vendors practice ‘genuinely open NFV’ and instead disguise how they intend to close and lock the front door once their customer has stepped inside.
There are five common traps that vendors set for operators as they entice them toward ‘open NFV’ contracts:
#1 Charging for third-party connections
One of the world’s biggest orchestrator providers makes bold claims concerning openness, but then charges the operator prohibitively if they ask to connect third-party devices. How does $40k per device type sound? Sounds like hidden lock-in to us.
Frequently, vendors will claim openness but then quickly close down as the multi-vendor solution is being specified: ‘We have tested that combination and we’ve got to tell you that it’s very difficult to make it work. It isn’t impossible, of course, but it will take an awful lot of integration work and support from us [subtext: expensive] and frankly the other vendor has a way to go to demonstrate the maturity of their solution in your [our] environment. On the other hand, our own solution plugs right in and works straight away…’
#3 Northbound open, southbound closed
Despite marketing their openness with a REST API for northbound communications to other management applications, several vendors have opted to either deploy proprietary messaging protocols in the southbound interface of their management applications (which communicates with the device being configured) or to wrap proprietary extensions around an otherwise open protocol. Buyers beware; this means that only its product will be able to interoperate with the management layer.
#4 The performance question
If the scare-mongering doesn’t work, vendors often look to discredit the performance of a multi-vendor solution relative to its own proprietary offering: ‘Sure, we support other vendors, but our solution works far better when linked to our own VNFs and orchestrator.’ Operators would be well advised to dig further here. A review of the extent of the performance testing, the similarity between the lab setup and the proposed field environment and the performance testing data itself, should soon reveal the integrity of this claim.
#5 The grey-box trap
‘Yes, don’t worry. Our NFV solutions are based on open standards. We support NETCONF and YANG and our grey-boxes include x86 support, one of the most ubiquitous computing platforms in the world!’ So, if that’s the case, to what extent though is the proprietary hardware necessary? Perhaps it can be justified in the case of high-speed switching but the more common use case is to support routing or SD-WAN and here the performance benefit is more questionable. As well as dependence on the proprietary hardware for core network functions, there is also the question of cost where essentially the user is paying for two compute platforms in the same appliance.
These traps are mostly based on the allure of ease of integration. Yet, genuine interoperability happens by design; there is a big difference between supporting open standards and designing solutions that freely operate in an open environment. In the main, if a vendor supports NETCONF and YANG, and can demonstrate that its solution can either configure and manage third-party devices or host third-party VNFs, then its claim to openness has at least some validity.
Virtualization is a once in a generation chance for operators to take back control of their networks. To do so, however, operators must resist the siren calls of many vendors, whose appeal is based on the seductive lure of an easy life rather than on delivering the real benefits of openness.
EKINOPS (Euronext Paris - FR0011466069 – EKI), a leading supplier of telecommunications solutions for telecom operators and businesses, announces the appointment of Vincent Munière as its new Chief Technology Officer and Vice President of Research and Development (CTO and VP of R&D). He will strengthen the EKINOPS technology vision, accelerate software innovation and lead the Group’s engineering and support team.
EKINOPS (Euronext Paris - FR0011466069 – EKI), a leading provider of open, future-proof and flexible solutions for the access network, today announces the completion of a partnership agreement covering North America and Mexico between EKINOPS and Lanner Electronics, the global leader in Whitebox Solutions™ for SD-WAN, uCPE, vCPE, and MEC platforms.
EKINOPS (Euronext Paris - FR0011466069 – EKI), a leading supplier of telecommunications solutions for telecom operators and businesses, has published its first half 2020 financial statements (for the period ended June 30, 2020) as approved by the Board of Directors on July 27, 2020. The statutory auditors have conducted a limited review of the first half financial statements and will shortly issue the corresponding report.