An article in Light Reading yesterday caught my eye, because it said that a survey of operators showed a lower level of confidence in their meeting virtualization goals. This isn’t a surprise to me, given that my own contact with operators has been saying they had little confidence all along. It does offer some insights into what’s going on with NFV and the broader and more important topic of “transformation”.
One obvious question raised by what I just said is “Why did I say that operators never showed much confidence in NFV and LR shows a decline?” It’s probably a matter of who you survey and how. NFV has been driven largely by the CTO organization (what was once called “Science and Technology”), since it’s this body that contributes people to the standards process that’s been the most visible NFV initiative. This group is notoriously fixated on “does it work?” rather than on “does it help?”. Most surveys grab the standards people for subjects, so there’s no surprise that they’d be looking at NFV through rose-colored glasses.
Nothing succeeds just because you can get it into a lab (unless it’s lab equipment). As NFV or anything else progresses, it has to pass from the technical domain to the financial domain. That transition exposes a bunch of issues that were accidentally left out, deliberately declared out of scope, or were never part of the CTO mission to start off with. In particular, with NFV, the maturation of the testing process has made it clear that there weren’t enough software types involved in the ETSI ISG, and that as a result critical software issues were never addressed.
The biggest problem in that sense is the management, which is flat unworkable and has always been. This manifests itself with the connection between VNFs and the rest of the NFV world. This connection is the place where “integration” at the software level is required; the data-plane connectivity of a VNF is managed largely the way it would be managed for any piece of software. What was always needed for NFV was a set of firm APIs that provided the linkage, and a management-network model that described how you connected with those APIs while staying secure. Neither was provided.
There were also financial issues, but they related to one critical point that I tried to make myself in the summer of 2013. It should have been clear from the first that VNF providers were going to try to protect and expand their own revenue streams in the transition to virtual functions. The only reasonable way to reduce this opportunism was to focus on open-source VNFs. These, because they were open-source could have been easily modified to support those standard APIs.
Open-source orchestration to support proprietary VNFs isn’t the most logical approach in the first place, and priority should have been given to open VNFs. I think the ISG was trying too hard to get broad engagement from potential VNF sources, in part because they’d perhaps outnumber network vendors or operators. It’s possible this point is also why the process ended up with such a kludgy management concept; the VNF vendors don’t want to have to create something that conforms to a standard API because it would make plug-and-play substitution too easy.
That’s also why there’s such a blowback against VNF licensing terms. If operators wanted them to be reasonable, they had to be able to use competitive pressure against the VNF vendors. Absent an open framework, and open-source VNF competition, how likely was that? So where we are on the technical points has weakened operator leverage on the commercial terms.
The thing is, reasonable commercial terms is what operators want. They also want open-source software and plug-and-play, and yet it’s clear that the steps needed to realize these needs and maximize their benefits weren’t taken. I think the big eye-opener for NFV survey targets has been coming up against these points as the process of trials advances. It’s not that these problems haven’t been there from the first (they have), but that people successfully ignored them. Now, the time has passed where that’s possible, so everyone is in agonizing reappraisal mode.
The CFOs that I’ve talked with, and even the COOs and CIOs, have never been all that convinced that the NFV pie (or the SDN pie) was fully baked. Remember that almost none of the CFOs believed that the current tests would advance the business case, and they didn’t see any initiatives underway that would. But just as the CTO people are facing the NFV march to the sea, the CFOs are starting to see progress. Over the last two months, they’ve been warming to the idea that AT&T’s ECOMP project just might expose all the critical issues in making a business case, and move to address them.
The question is whether we’re asking too much from ECOMP at this point. Yes, AT&T has done a much better job of framing everything needed for transformation of the carrier business model than ETSI did. But as I pointed out in my exploration of ECOMP, there are still issues in management orchestration and connection that aren’t fully described in the ECOMP documents. The code isn’t available yet for review, so I can’t be sure that AT&T has gone far enough.
Then there’s the future. What we’re trying to do with SDN and NFV and carrier cloud at this point is play catch-up. We don’t have an architecture that covers current requirements well enough to make a convincing business case, and that’s the first lesson of the slip in operator confidence that LR is reporting. But the second lesson is that you can’t ignore what’s happening if you want to address it, and there’s more happening in the cloud today than there was in 2012 when the Call for Action paper launched NFV.
The cloud is a new platform for software development, a platform that includes distributability, elasticity, agility, and more. There are common web services already offered by competing cloud providers, services that should be incorporated in any NFV or SDN architecture, and yet they have not been incorporated or (as far as I know) even considered. Even today, we could be shooting way behind the duck, especially considering how long it would likely take to deploy something that met even minimal requirements. We should be looking at the cloud in 2021 as a lesson for NFV development in 2017. I propose to do that, and I hope we can have some interesting discussions on the points!