Telecom IQ
Showing results for 
Search instead for 
Did you mean: 

NFV As Viewed By Its Adopters - Part II


NFV As Viewed By Its Adopters - Part II

Quarter 3: Who's the MANO?

As we moved into the second half of 2015, the PoC efforts at leading CSPs were bearing fruit. NFV worked essentially as planned (at least, technically), VNFs could replace dedicated hardware appliances, but the concerns over orchestration were correct. Our industry partners were increasingly concerned with how to handle the management and orchestration (or MANO) of the various NFV elements.

Fortunately, HPE and a variety of other vendors were hard at work developing just these MANO solutions. CSPs now have the option of developing MANO layers in-house, or of adopting one of the commercially available solutions. The critical elements of a good orchestration solution are:

  • Scalable, can be deployed across wide networks
  • Uses Open Standards
  • Flexible / Customizable to a CSPs needs now and tomorrow

Many stakeholders are wondering of there will be just one Orchestration layer, or whether they will build hierarchical layers, with MANO masters and a higher master-of-masters.

As CSPs look to select solutions to the MANO question, they are starting to realize that this partnership choice is likely to be a very long-term relationship, not unlike the vendor relationships of the last century. While NFV offers much easier vendor switching at the VNF layer, the orchestration layer is probably a lot more central and lasting role.

Therefore it is critical for CSPs to choose a high-quality, stable partner with strong R&D resources and a commitment to invest in the NFV and SDN industry for years to come and a commitment to providing open platforms that do not lead them down the path of the past – vendor lock-ins. Of course, we believe HPE is a good fit for this role, but regardless it's important that CSPs choose any MANO partnerships wisely.

Open Solutions

Even though any orchestration layer is likely to be a long-term commitment, the right choice for a partner in the MANO layer is one that embraces Open Standards to the fullest. The orchestration layer needs to be the United Nations of a NFV/SDN architecture. The MANO needs to interoperate with all of the different VNFs from disparate vendors, those built-in house, and also legacy systems.

A big shame would be to go the route of NFV, and still not be able to choose any given VNF vendor because the MANO layer cannot interoperate. For this reason, HPE is an active participant, leader, and contributor to the most relevant communities in NFV and SDN, and regularly participates in the plugfests and PoCs. Any stakeholders in NFV should familiarize themselves with at least these bodies:

Open solutions are essential to unlock the promised benefits of NFV/SDN. It's essential that CSPs pick partners who truly are committed to openness, not just paying lip service and doing the minimum to be participate.


Quarter 4: Proofs of Concept Bearing Fruit

Driven by the Agility benefits of NFV, and the tremendous strategic pressure put on the CSPs by the OTTs, the CSPs and their vendors have launched 38 PoCs through ETSI alone. In addition, there were numerous PoCs that were conducted in more private engagement between vendors and CSPs.  These PoCs drove much of the conversation at the end of 2015

Some of the feedback coming from the PoCs is precisely what we might expect: problems. But, bear in mind, that's exactly what ETSI's PoCs are designed to uncover. The idea is to assign different specific concepts of NFV to different network operators and vendors, and to have each trial reveal what works well, and where additional solutions are needed. To summarize the PoC problems that our meeting delegates identified, they included:

  • Orchestration or MANO – the task of centrally orchestrating and managing the various VNFs is not complete. A number of vendor solutions now address the challenge, but questions still remain about whether centralized or distributed state information is most appropriate.
  • Vendor Interoperability – testing always reveals practical difficulties in connecting kit from different vendors, but this is a necessary value-proposition of NFV. What we're finding here is that the challenge is actually more manageable than thought. Interop mostly needs to work between the MANO layer and the VNFs, but not necessarily between every VNF.
  • Service Chaining – Chaining VNFs to build a complete market solution will require more interop than standalone VNFs. This provides increased challenges, but Chaining is an important part of unlocking the value of SDN.
  • The challenge of "Open" versus conventional standards – Let's be honest, neither Open solutions, nor Industry Standards are perfect. The problem with conventional Standards is that they take far too long to nail down, and even then are never fully interoperable. So the NFV industry has decided primarily to go with just Open solutions. These are not standard, but have published, shared code, and thus should hold some of the interop benefits of full standards without the big time delay. While plugfests can help ensure good levels of compatibility, perfection is never achieved. The community remains concerned about interop.

Through 2015, CSPs and vendors doing the ETSI PoCs have done a tremendous job of moving NFV off of the whiteboards and Powerpoint decks, and into real network environments. From these trials, the real challenges have emerged and can now be addressed. This method of advancing technology is by far the fastest, and it works even better in the "open" environment where many minds contribute to shared solutions, rather than being siloed within each company.


Changing Technology is Easy, But Changing Culture Is Hard

By the end of 2015, the tone of our discussions with stakeholders became much more philosophical. Results from PoCs were rolling in, and the technologies being trialed showed great results. The big new tech problems, largely around MANO and interop, seemed mostly solvable. The cloud on the horizon was not about technology, but rather about people – The problem is that technology can change overnight, but culture cannot. For CSPs making a big change towards a NFV/SDN network, cultural challenges may trump technological ones.

The virtualization transformation will inevitably demand an organizational transformation within the CSPs. Network operations will change, and will begin to overlap with other groups, somewhat following the DevOps model from IT. And with a shift towards NFV and SDN the individual skills of the CSP's engineering staff need to morph from being "task-specific-appliance people" to being more flexible "ops people". With corporate training and support, hardware people will need to become software people. Thousands of them!!

“Should we expect enthusiasm from telecom staff for who may worry that a shift to NFV/SDN also may mean a shift from employed to unemployed, out-of-date, and obsolete? These reasonable concerns must be addressed.”

This cultural and very human hurdle is the hardest one to overcome. And the only solution is one of timing: The answer is not "So don't do NFV", but rather the opposite: “Do it NOW”. Start slowly, and do it steadily. This allows the longest ramp for re-training, and reduces anxiety and resistance among valuable enginering employees.

Currently there are two kinds of CSPs: Those aggressive ones that are doing PoCs, and those that are using a "wait and see" approach to NFV.

The former group of CSPs tend to learn about technologies involved in NFV and hire additional staff to support these initiatives.  They see the need for software and ops engineers over box engineers early. They begin hiring with this knowledge, and retraining existing resources. HR partners with the effort. These CSPs can compete with OTT using agile principles, and use DevOps to bring marketing, planning, and ops work together. 

The latter group of CSPs that might end up waiting 3-5 years to begin their NFV journey might have the advantage of more open, mature technologies, but unfortunately, their engineers are not familiar with the new technology and the new ways of operations.

The lesson is that, while you can quickly purchase the new technology, you just can't change the culture that quickly.

There are many business situations where being a "Fast follower" is a smart strategy. But because culture takes time to change, NFV at telcos is absolutely NOT one of those cases. Fast Follower successes require a quick response when the market is proven. An agile response…but agility is just the thing that is lost when the established culture rejects a change. And while technology can be agile, culture simply never is.

Because of the above, NFV is an HR issue just as surely as it’s a technology issue. CSPs should bring HR up to speed on the changes that will likely impact the company, and better sooner than later.


What Does 2016 Hold for NFV?

Software Will Eat Telecom

Looking forward to 2016, the pace of NFV is only going to accelerate. Really, there is no better way of backing this assertion than to quote from AT&T's Senior EVP for Tech and Ops, John Donovan, who spoke at an investor’s conference in early 2016. Donovan kicked off the year by announcing that AT&T is on track to have the network 75% Software Controlled by 2020. Donovan said 50% of currently planned software will be built using Open Source software. He asked his vendors to focus on supporting OpenStack, and said AT&T was getting serious about shifting from standards-based software to an open one. Donovan expects that by 2020, we'll think of AT&T as a software company.

In 2011, Marc Andreesen famously said that software would eat everything, and it looks like telecom is next.

A Strong Market

The market for NFV solutions is predicted to grow over 4x for 2016. IHS forecasts a TAM of $2.3 Billion in 2015, but $11.6 Billion in 2016. Meanwhile, Heavy Reading forecasts for CapEx spending in NFV rocket from $485 Million in 2014 to $12.7 Billion in 2019. Growth in the sector is as close to a certainty as you can get.

Evolution of NFV as a Technology

In 2016, expect us to start to cloudify NFV. The PoC trials were generally standalone efforts to flesh out the benefits and challenges of various VNFs. In the PoCs, the participants Virtualized what was formerly dedicated hardware. The next step in the progression, as show below, is to Cloudify.

What does Cloudify mean? It means abstracting geographic location from network function. It means that a firewall in Los Angeles is being run in a Datacenter in Arizona, because the LA datacenter had higher power rates, and it was cheaper to spin up a virtual firewall server in Arizona than to run the workload in LA. It means that compute power will be elastic, virtual, efficient, low-cost, and unbounded by geography.




In 2016, we should also expect another IT trend to cross over into telecom, and that's DevOps. This is part of the great culture shift that will be challenging, but which comes with the NFV/SDN revolution.

DevOps tears down functional walls within a company, such that CSP product development might work integrally with Network Operations staff to develop and launch a new service.

If CSPs wish to offer service innovation at any kind of faster pace, regardless of whether they employ NFV, they will still need to tear down the functional walls between network, IT, and product development teams. CSPs need to get their best minds working together on competitive service offerings, NOT in separate silos. Otherwise, OTT vendors will dominate the market for services, and will own the customer.

Match OTT Coopetition With CSP Service Agility

OTT services are increasingly grabbing market opportunity that could have gone to the CSPs, if they had been more agile. Things like group messaging, voice search, photo or video messaging come to mind. But now, OTTs cut even deeper, because they are moving into the telcos' very core services – communications services like text messaging and voice calling. What the OTTs bring, and the telcos can't yet match, is an ability to quickly invent and trial new ideas. They put engineers, developers, product, and marketing people on a single team to build a service, then iterate rapidly. The fact that they do this over the telcos' pipes is doubly frustrating for the network operators.

So, the competitive response must be increased agility at the CSPs. NFV and SDN are the tools for that job. Leveraging an agile platform and diversifying into digital services, CSPs can both compete against, and partner with OTT providers:

  • Agile network services can be offered directly to customers, built rapidly by the CSP and deployed as VNFs or service chains.
  • CSPs can offer VNFs as a valuable platform that unleashes the best solutions of OTT partners, and participate in the rewards.

In either case, partnership or competition, it is far better for the CSP to be on the field as players, rather than watching the game happen from the sidelines.


Want to read more? Catch Part I of this blog peice here and learn about the "Relationship between NFV and SDN" (Chapter 1) and "The First VNFs" (Chapter 2).

Learn more at our HPE OpenNFV website, and follow us on Twitter at @HPE_NFV and @HPE_CSP.


0 Kudos
About the Author


Read for dates
HPE Webinars - 2019
Find out about this year's live broadcasts and on-demand webinars.
Read more
Read for dates
HPE at 2019 Technology Events
Learn about the technology events where Hewlett Packard Enterprise will have a presence in 2019.
Read more
View all