The headlines say that Telefonica has picked a new integrator for its Unica network program—Ericsson—and that’s true but only sort of. It’s true that Telefonica rebid the integration deal that HPE won originally, and it’s true that Ericsson won the new deal. Ericsson was one of the three choices all along, and the one I’d been hearing would be the final pick. What doesn’t appear to be true is that the deal Ericsson won is much like the original deal that was rebid, and what has changed is a lot more important than who won the changed bid.
If you look at the Telefonica press release, which is quite short, it says that they closed “a new phase in the selection process for UNICA”, which hardly sounds like a big integrator award. They don’t get to Ericsson or the award to the fourth paragraph, when they say “Ericsson has been awarded as a key partner of this program to provide the infrastructure and software required to launch the UNICA architecture in Telefónica Germany in 2016.” The press release doesn’t say what Ericsson is doing in “infrastructure” but Light Reading reported it included “Hyperscale Datacenter System 8000, Ericsson Cloud Manager, OpenStack based Cloud Execution Environment, Cloud SDN” and automation tools.
What the press release does say is that HPE and Huawei, the other two finalists in the integrator bid, will “continue to participate in this program as strategic partners for NFV.” Some insiders tell me that these two firms may even have enough latitude to develop the integrated frameworks they’d proposed to Telefonica, though apparently without receiving integrator payments.
What this looks like to me is a bit of a shift of focus. I’d heard that Telefonica was learning that the integration task for NFV was profoundly different and more difficult than they’d expected it to be. I’d heard that they were unwilling to pay for the kind of work they now knew would be needed. Most importantly, I heard that they were rethinking their approach to control the costs.
The most important point in the integration story isn’t who was selected but that Telefonica is apparently now relying on open source contributions to not only supply components to their network, but also to shift the focus of “integration” to something broader and more suitable to making an NFV business case. They’re showcasing their Open Source MANO initiative at MWC and they’ve now released the white paper referenced on the OSM site. I agree with most of the points they make there, and because Telefonica is a big power behind OSM and it’s thus likely to frame the cooperation among vendors and products that they expect Ericsson to integrate, I want to summarize what it says.
OSM is a superset of NFV, designed that way because of what limited the ISG work. “This initiative did a fine job of focusing on the additional components (to a conventional network) required to enable NFV service. There was a great effort in defining information models, which can in turn drive a lifecycle management function enabling resource orchestration through the NFVO and VIM. The challenge was initially so vast that some aspects were left outside of scope for further study. These included the higher-level issue of end-to-end service orchestration and also the current state of play in the open-source community with respect to cultivating possible management and end to end service orchestration solutions.”
Nobody will be surprised that I agree with this point; the scope limits in the ISG work were something I fought from the first. What the OSM material is saying is that you need “service orchestration” beyond the narrow problem of orchestrating virtual functions, and that’s clearly true. What’s critically important here is that a major Tier One and one of the ISG founding members is supporting a broader model of “service orchestration”. This is what’s been missing all along in making the business case.
The OSM model the white paper presents has some interesting technical principles. The paper cites them as layering, abstraction, modularity, and simplicity and it’s hard to disagree with any of them. The implementation that’s described in the paper adds some color to these principles; the deployment process is orchestrated by JuJu, which is an application-modeling-and-deployment tool that comes from the cloud (Canonical). JuJu is probably the best of the current cloud DevOps tools, so it seems an inspired choice.
So far, the paper describes a useful and even insightful model of service management, but there are still a couple of issues the white paper doesn’t completely address, IMHO. One is the VNF Manager (VNFM) concept, which is the ETSI way of addressing the problem of lifecycle management beyond the initial deployment. The other is exactly what a service orchestrator does, and in particular how services are modeled.
It appears that the OSM approach still supports, if not mandates, a VNF-integrated VNFM component to handle things beyond the general tasks handled by JuJu. I’m uncomfortable with this approach, as I’ve been all along, because it seems to me that it will both complicate VNF integration and also raise risks of diluting the boundary between services/tenants. I hope further experimentation within OSM will address these issues. I’ve got nothing against the notion of having a VNF component do parameterization, but you need to insure that it doesn’t have to address real resources or you’ve created a security/stability risk.
On the service orchestration side, the logic is contributed by Rift.io. I’ve had some discussions with this company and reviewed a slide deck, but their deck and website material don’t offer any detail on the service modeling, and in fact imply that they have what’s essentially an open-source implementation of MANO, which OSM agrees doesn’t include service orchestration. The website, in fact, seems to suggest the company’s focus is on a VNF-PaaS approach, and the diagrams show orchestration as being a contribution from the NFV ISG side, presumably Open MANO from Telefonica. I’d like to see their service model and details made available, because the material that’s currently distributed doesn’t validate the service-orchestration positioning of the paper or the demo.
I’ve focused on open VNFs so far, but Telefonica isn’t ignoring open resources. The press release on Telefonica’s site notes in passing a very important advance—the support for multiple VIMs. The notion that a single VIM would manage all virtual infrastructure created what to my mind was a completely intolerable risk of lock-in, since a major vendor would likely support their own stuff with a VIM and then use some of their killer apps to pull through a VIM solution that wouldn’t work with anyone else. So we have a big step toward openness at the NFV Infrastructure level.
What all this adds up to in my view is that Telefonica is now looking to OSM to create a new framework for VNF deployment, and because OSM isn’t quite ready to do that and the integration tasks associated with it can’t be defined precisely, they’re holding off on the “integration bid”. What Ericsson won wasn’t what HPE lost. Nobody has won that yet, and nobody will likely win it ever, in its original form. We’re going to see a new NFV model, defined by OSM, at Telefonica.
This doesn’t mean that Ericsson didn’t win anything or HPE lose anything. Ericsson will have a big NFVI deal in Germany, and Intel will have a bigger one. Remember my comment in a prior blog that Intel was trying to make sure that we got enough NFV data centers to boost their chip sales? Well, the Ericsson system based on is Intel’s disaggregated cloud-scale-and-hyperscale architecture. HPE is losing what might have been a nice early deal, though some people tell me that HPE actually still has a shot to provide servers based on that same Intel architecture (which HPE offers) to Telefonica in Germany.
All the vendors lose one common thing, which is the opportunity to frame NFV at the high level. The OSM project is the big competitor and the big winner, providing that it can actually deliver something. I’ve noted the issues I have with the architecture as announced; I think these will have to be resolved quickly because both HPE and Huawei have functional NFV implementations that cover all the space OSM proposes to cover, and more.
In summary and at the highest level, Telefonica is going to step beyond ETSI NFV to attempt to establish an open model for NFV that can make a broad business case. There is no value in integration for any piece of NFV if it can’t make the business case overall, and thus won’t deploy except in specialized applications. There’s also no way, in my view, to integrate even within a strong business case unless you adopt a service-model approach like the one I described in my blog yesterday. OSM would be bigger news if I could be confident that they’re taking all the steps needed and that progress will be timely, but I can’t say that will be the case based on what’s released. There are still questions, ones I’ve raised in recent blogs on service models and service orchestration.
We have other open-source activities associated with NFV, from OpenNFV (which I think is still stuck in the early stages of defining the software project and hasn’t gotten around to much at the functional level) to OPEN-O, which sort-of-competes with Telefonica’s OSM. The media has made a lot of the competition here, but the real competition—between a strict ISG model of NFV and a broader model that can make much more of a business case—hasn’t gotten much attention. I think now that it will.