Over eight years ago, in October of 2012, at the SDN & OpenFlow World Congress in Darmstadt, Germany, 13 communication service providers (CSP) released the original NFV concept paper. AT&T, BT, CenturyLink, China Mobile, Colt, DT, KDDI, NTT, Orange, Telecom Italia, Telefonica, Telstra, and Verizon laid out a vision for the use of high-volume commodity hardware and software virtualization technologies to transform the network equipment ecosystem.

In the first section of that paper they inserted a diagram, below, that has been replicated and re-imagined time and again in numerous pitch decks for software startups, for new product initiatives within existing companies, and by strategists and analysts in the telco space.

Unfortunately, this diagram set up the incumbent network equipment providers (NEPs) as the “bad” guys on the left and a new “good” ecosystem on the right, with CSPs in control of the underlying open platform, welcoming new independent software vendor (ISV) entrants. This “NEPs are bad” mindset has had unintentional negative ramifications for all of us in the industry.

NFV — Disenfranchising the NEPs

NEPs were accused of overcharging and holding CSPs hostage. They were blamed for CSPs’ high CapEx and OpEx and slow rate to adapt and innovate. As a result, many of the NEPs felt under attack. This NFV wave followed the SDN wave that had just hit many of these providers (who also build data center networking equipment). SDN was pushing the same disaggregation, commoditization, and open-source tenets. NEPs scrambled to respond to both the NFV and SDN movements, with many publicly committing to transform themselves into software companies and embrace NFV and SDN tenets. In the meantime, strategists at NEPs worked to figure out how to continue to extract value from existing proprietary products in this new world.

Some NEPs would simultaneously invest in open source projects, while privately messaging the lack of maturity of these projects to existing customers and prospects and continuing to push their existing products. At the same time, some new ISVs entered the market, and second-tier NEPs tried to use NFV as a leapfrog strategy to unseat the incumbents. Simultaneously, CSPs tried to transform their operational platforms, designing and building out new NFV reference architectures in their labs.

However, many CSPs soon realized they were in poor shape to lead the NFV charge. Aside from a limited few, most CSPs didn’t have the software prowess or culture necessary to succeed in a software-centric world. They were missing the in-house talent and expertise needed to take advantage of open source NFV efforts and lacked cloud platform chops. Worse still, they found it hard to recruit the right type of talent to bolster their ranks — after all, if you were a full-stack cloud software developer, would you rather join an Amazon, Azure, Google, or a legacy CSP?

And those newly minted ISVs who were supposed to fill the void? Many found the venture world unsupportive. VCs favor investments in startups focused on cloud and enterprises, believing telco sales cycles to be too long and CSPs to be slow moving despite their stated NFV desires. This lack of investment meant limited new blood in the field. And so, innovation in NFV has been slow. Many NFV deployments to date are single-vendor integrated NFV stacks, not the multi-vendor plug-and-play platforms originally envisioned.

Fundamentally, the NEPs held the necessary talent to drive NFV innovation, but NEPs were not going to rush into the market to prematurely cannibalize themselves. Plus, moving to software subscription-based licensing was gnarly. Transparent and manageable NFV licensing continues to be an unsolved issue. NEP CFOs also didn’t like what this did to their revenue in the short-term, though they were open to a SaaS-type model in the longer term.

The CPE Chasm in SD-WAN

We’re seeing the same dynamics play out in the SD-WAN space. CSPs are looking to take control of edge boxes, replacing proprietary CPEs from NEPs with universal white boxes. And as part of the NFV and SD-WAN movement, edge functions would be virtualized and run as virtual network functions (VNFs) on these white boxes. CSPs want to swap in different VNFs as needed to provide flexibility to their customers and to prevent lock-in by the NEPs.

In my conversations with CSPs, early SD-WAN adopters are updating their first-generation deployments. First generation SD-WAN solutions often used SD-WAN vendor hardware since that was most expedient, but CSPs want the next generation to be based on universal CPEs that relegate SD-WAN to being just one of many VNFs. Simultaneously, CSPs are driving open orchestration and API standards so that they can swap SD-WAN vendors whenever they need to.

Again, CSPs are trying to wrest control and power from these SD-WAN NEPs. As an end goal, it makes a lot of sense — drive open white-box universal CPEs everywhere and reduce costs and increase flexibility. However, some of these initiatives are running into issues.

Many CSPs are not equipped to troubleshoot hardware platforms, nor perform software integration testing of VNFs on their universal CPEs. And many process steps in the supply chain, which NEPs used to perform — like field replacements, root cause troubleshooting of hardware platforms, OS maintenance and patching, as well as hardware optimization tuning — have yet to find new owners in this SD-WAN world with universal CPEs.

Conversations with leading white box manufacturers indicate that CSPs are pushing them to take on some of these duties, but the manufacturers aren’t quite ready. Nor do they yet believe that there’s a viable business case to do so. By prematurely pushing the NEPs out of the way, CSPs might have created a chasm in universal CPE deployments that has to be filled.

Taking a Collaborative NFV Approach in 2019

As we kick off 2019, perhaps all parties involved in the NFV ecosystem — the NEPs, including SD-WAN vendors, the white box manufacturers, CSPs, and potentially system integrators — need to come together and understand the appropriate roles they can play in this game. NEPs should be accorded the value that they bring and not be framed as the bad guys out to make a quick buck at the expense of the poor and struggling CSPs.

If the other parts of the telco ecosystem, including the CSPs, resolve to incentivize the NEPs by working collaboratively with, instead of against them, perhaps we can all move faster to a flexible, software-centric agile world. In this model, each player in the chain should be able to capture the appropriate financial value for the role that they play.