The Linux Foundation’s Open Networking Summit Europe took place over two and a half days this week. Four main main themes emerged.
1. The threat of fragmentation. There are a lot of open source-based telco networking projects. This runs the risk of duplicating work, creating confusion for operators as to what to use, and for vendors as to what to commercialise. It also stretches limited telco developer resources as they cannot commit people to every open source effort out there.
2. Commercialisation. Will it work, and how? Specifically – how will ONAP, which is becoming a crucial open source-based framework for automated operation and orchestration of the telco cloud, be commercialised by vendors and consumed “out of the box” by operators. Operators have joined ONAP in numbers, and now seem to be realising there is still a lot of work to do.
3. NFV was next gen 2.0. We meant Cloud Native all along. VNFs are out, CNFs are in, and that requires open source. Did the industry make a mistake in making NFV its strategic goal for the past six years? Just virtualising functions hasn’t been easy and hasn’t given given operators what they wanted. Now it’s about CNFs, or Cloud Native Functions.
4. The edge, and the edge core. Open source is emerging as a key enabler for the edge – including the very edge and the virtualised Central Office. That’s because management of servers in these edge locations needs to be very light, API-based, often automated, and additionally there needs to be an environment third party developers can work to.
This article takes each of these first three in turn. The fourth – the role of open source in the edge – we will deal with in an article of its own.
Fragmentation
“We will hopefully see some announcements between some of the organisations moving forward. I wanted to make an announcement today but there’s no agreement yet.”
Deutsche Telekom’s Axel Clauberg dropped a heavy hint that different Open Source networking programmes could be about to announce something that would see them work together more closely.
In his keynote, Clauberg said that with so many open source programmes currently active there is a danger that efforts will be duplicated. He highlighted OPNFV, ONAP, O-RAN, OpenStack, MEF, ONF, LNF and so on.
As well as duplication creating possible confusion in the market, it creates problems for telcos trying to track and contribute to open source communities because they simply don’t have enough trained people to take part.
“All these organisations are extremely important for the industry but the challenge I have is how can we staff all of that to make sure things go in the right direction, and how do we avoid overlap?”
“We will hopefully see some announcements between some of the organisations moving forward. I wanted to make an announcement today but there’s no agreement yet,” he said.
Vodafone’s Fran Heeran, Group Head of Cloud & Automation, echoed some of Clauberg’s concerns in an interview with TMN at the event. “It’s a problem,” he said, “ I think it’s a challenge for the vendors. I think they are asking themselves which horse do I back, and if I am backing three or four horses it’s a pretty expensive proposition. We all have to pick a horse, at Vodafone we’ve picked ONAP; alignment is going to be key but I think ONAP has enough traction now.”
Certainly it seems some of the open source programmes themselves are aware of the potential issue. At a session on the role of open source in edge compute deployments, Nokia’s Gergely Csatari mapped the work that a host of open source communities are doing against the ETSI NFV architecture – suffice to say that many of these were addressing the NFVi layer in one way or another. Csatari said that the OpenStack Edge Computing Group had been created to give a place where those involved can discuss all the different ongoing efforts. “To make it happen we will need collaboration – it only works if we talk to each other and it’s important for OPNFV Edge and OpenStack edge to talk to each other”.
Clauberg was not the only telco executive to voice fears that there needs to be a coming together of open source telco networking developments – or at least some clear winners should emerge.
Orange’s Emmanuel Lugagne Delpon had already called for the industry to avoid an “industrial disaster” caused by fragmentation of efforts. He wanted to see the industry form more clearly around ONAP for automation and orchestration, and OPFNV for the NFVi layer.
“The way I take that,” said the Linux Networking Foundation’s VP Ecosystem & Community, Heather Kirksey, “is that is it less about a choice around specific technologies but more saying, ‘let’s all come together in the same place instead of going to different camps. Let’s listen to everyone’s problems and create software that solves everyone’s problems together. I think it’s more of a commentary on momentum around a community because you can always change code if you have the right people all there changing the code together. Then you can put out the features that people need instead of putting it in in multiple places.”
One obvious alternative place to come together and do that is within the Standards Developments Organisations (SDOs). The problem there is that standards tend to be document-based and monolithic, and don’t support the continuous development and integration methodology of the Cloud. In essence it’s the difference between writing specifications and writing code. But those SDOs themselves seem to be leaning more towards (at least) a quicker iterative process. MEF’s Daniel Bar-Lev said that MEF has been working hard to reduce the time it takes to get a spec out – moving more to a minimum viable standard. Klaus Martiny, a colleague of Clauberg’s at DT said that standards and open source should somehow work together to ensure interoperability – “I don’t think open source alone can give this kind of guarantee,” he said. Could we see standards bodies hardening off some of the open source work, yet how could that square with the continuous interation mode of working telcos are looking for in cloud ops?
Commercialising ONAP
“With current stability and availability it is hard to introduce new use cases. We need to improve and make it more modularised, flexible and use case driven.”
The fragmentation issue, and the desire to achieve some level of stability whilst still retaining flexibility, is directly related to the second big issue – achieving stability, maturity and commercialisation of, especially, ONAP.
ONAP, still only a year old, seems to have the traction of many big global operators, save Telefonica. Famously it claims supporting operators account for 70% of global subs under their management. That said, those running the project are aware that there are still only three operators with an ONAP deployment, and there were plenty of discussions as to how will it be commercialised. AT&T’s Catherine Lefevre said that the goal is to move beyond ONAP being a China Mobile and AT&T thing, to produce code that can be adopted and then provided by vendors in some sort of consumable way. But operators, even those on board, have expressed concerns around documentation, automated testing, and modularity of the framework.
Vodafone’s Heeran said, after presenting an ONAP based proof of concept to provision and deliver an enterprise VPN across Vodafone and China Mobile’s cloud infrastructures, that he was looking for vendors to take ONAP code, ingest it and deliver back to operators as deployable solutions.
“We’ve no published plans yet because I want to make sure what we are getting is a solid stable product, and we are not going to deploy this ourselves. We will look to the vendor community and say, ‘Bring me your ONAP-compliant orchestrator or inventory manager or analytics module’. And we are seeing the vendors beginning to step up. In the last few months I see a notable change in vendor strategies, they are getting in behind these open source projects and making it a key part of their portfolio strategy, coming back to us with an updated plan.”
He did caution, however, that there is still work to do on making ONAP more modular, with modules hardened against specific use cases.
“ONAP could do a better job there,” he said. “On paper it looks great, but there’s definitely work to do to improve modularity. That’s really important because not everyone’s interests apply equally across all the modules.”
DT’s Clauberg said that more than 80% of deployments will require commercial support for ONAP. So it’s a “great initiative, but it’s also fairly big. We don’t see any vendors supporting the full beauty of ONAP at this point in time. The way forward of classical agile, Minimum Viable Product, makes sense for a lot of operators. To position this as a commercial product in the market, that’s the way forward for vendors to support the deployment models we are seeing.”
Orange Programme Director Jehanne Savi said that the operator could require an ONAP distributor similar to the role RedHat has in OpenStack. ”Probably we would need to rely on an “editor” as for example we do with Red Hat for the OpenStack distribution. I think the ecosystem misses actors that want to be ONAP editors,” she told TMN in an interview.
Certainly these issues of getting ONAP from its current code base to something that can be commercialised by vendors, and consumed by operators, is an issue within ONAP and the Linux Foundation itself.
The LF’s Kirksey said, “Within ONAP right now a big focus right now is on modularising the platform, with the knowledge that there is a core subset that makes sense for most operators, and then different operators have some needs on top of that. But as long as it is being modularly developed then that helps you get best of both worlds”.
In a panel session, Helen Chen, of Huawei and an ONAP Project Technical Lead for Integration, was willing to admit there’s a way to go on integration. She recalled a prior description of ONAP as a fat baby – as in it’s large and immature. “There is work on to create use cases and then modularise around those use cases,” she added.
Junglan Fen, of China Mobile, said, “We struggle, same as the community, when we deployed ONAP in the business. The challenges we have is that it is a massive code base, and with current stability and availability it is hard to introduce new use cases. We need to improve and make it more modularised, flexible and use case driven.”
If this doesn’t happen, it opens up the doors to the systems integrators to come in and make sense of ONAP in a deployable manner, and this is what the telcos are trying to avoid – a further integration tax.
Going Cloud Native
We’re dropping the use of the term VNF or NFV, it’s really all about cloud.
One driver for telco adoption of and support for open source is the realisation that just virtualising functions is not enough. What is really needed is full cloud native operations – something that operators have been saying for a good 18 months. That’s because the virtualisation process to date has been more lengthy and expensive than operators had thought.
The conference heard about a new collaboration between the Cloud Native Computing Foundation (CNCF) and LF Networking (LFN),with the aim of migrating Virtual Network Function (VNFs) to Cloud-native Network Functions (CNFs).
Dan Kohn, Executive Director, CNCF, said that if the current network architecture 2.0 evolution sees VNFs run on VMWare or OpenStack, then the next stage evolves to lightweight CNFs running on Kubernetes containers on any cloud.
Orange’s Savi said that integrating just one VNF onto NFVi in Spain had taken the operator 9 months, with the underlying IaaS sucking up $6 million of investment.
What Orange wants is for VNFs to be genuinely cloud ready and fully automated. But Savi said that there is much lacking in current VNF certification. “Agility is still low, and VNFs are not truly agnostic to the NFVi.”
“What we have targeted is that we could have VNFs available in an app store or marketplace model, and at this stage they are not fully operational, and certification is not ambitious enough.”
Vodafone’s Heeran said that the operator had stopped using the term virtualisation and NFV – “we’re dropping the use of the term VNF or NFV, it’s really all about cloud and that’s the narrative internally as well as external.”
Vodafone’s focus is on viewing virtualised network functions just as a part of its overall cloud infrastructure, which includes public and private deployments. It has retired the Ocean name, and subsumed the network virtualisation projection into its cloud platform initiative, Heeran said. This would align network virtualisation a lot closer to IT cloud instances.
“The real savings come when you push the notion of completely re-architected software, cloud native software that understands this notion of a horizontal platform and is more efficient in how it uses resources. That’s very different from taking software that was written ten years ago and virtualising it.”
DT’s Clauberg, for his part, said he had argued for the adoption of Networks Function Cloudification as terminology all along, rather than NFV. But he cautioned that the move to cloud native is not going to be easy. Providers cannot wait for telcos to get everything sorted out and then move into CNFs. It won’t work like that.
“Anyone who is not getting experience in today’s heavy virtualisation, virtual machine-based world, will find it difficult. There are topics we have to master in today’s world as well. Orchestration we have to master now – we cannot say we are waiting for cloud native. We do have a great initiative with ONAP and that is taking the right steps to microservices and containerisation, but it will require a focus on bringing in AI to orchestrate in this microservice world with distribution to the edge.”
That mention of the edge takes us onto the fourth major theme of the event, one that deserves its own separate article.
