It’s the first working day of 2016, and I guess I have a kind of obligation to talk about what to expect the rest of this year on the biggest issue facing telecom—operator return on infrastructure. We stand a year from the time when operators said that falling revenue per bit and insufficient progress in cost reduction would put their revenue/cost line in crossover territory. The question is whether there will be progress in 2016, or whether we’ll enter 2017 with the real risk that investment in broadband services will slow.
Most of the pressure for performance is going to fall on Network Functions Virtualization (NFV) because it was really NFV that was tasked to solve the problem of crossover in the first place. While in fact SDN has just as good a chance of reducing costs (capex and opex), nobody really seemed to expect that to happen. SDN was promoted more for the impact it might have on the network vendor establishment, as a kind of rising up of the masses to smite the mighty. We’ll see as I go along whether SDN might end up doing a bit more.
For now, though, let’s see where NFV is. We have a specification set from the NFV ISG that was never broad enough to address the credible set of benefits needed to address the operators’ revenue/cost challenge. That was known by operators even in the fall of 2013 when the second white paper on NFV was published. The problem was that operators themselves could not “collude” (as the anti-trust lawyers would have called it) and that left only the option of participating in industry groups along with the vendors—the very vendors whose revenues would necessarily fall if cost control was successful. Guess how that went?
Nothing is going to wrestle control back to the operators, not in the ISG and not in any current or yet-to-come open-source group. We are left in 2016 with four possible paths:
- NFV could be adopted as a service-specific strategy in a very limited number of areas, like business services. The total impact of that would be by my calculation less than 2% of total operator capex/opex. You’d have to be able to grow this early success into something bigger.
- Operators could accept that the lower-level ISG standards won’t cut it, and look to OSS/BSS systems to build a business case umbrella over the basic deployment mechanisms the ISG worked out. But the TMF hasn’t moved any faster or more credibly than the ISG, and it’s also primarily a body of vendors.
- The non-network vendors, whether involved in NFV currently or not, could step in. These are the IT vendors like Canonical, Dell, HP, IBM, Red Hat, and Oracle. They have everything to gain from NFV success and absolutely nothing to lose. Support of software/hardware players could create an open community that would crack the current NFV deadlock, or simply provide a proprietary solution knowing that there’s no credible open alternative coming. But only two of these IT giants (HP and Oracle) have substantial NFV capability, and neither has been effective in promoting systemic change.
- Operators could, through integration projects and their evolution to deployment, create de facto solutions that would become standards by acclimation if they work. But these operators have failed to create consensus, or even to bring out all the critical issues, in current standards and open projects. Could they do better?
The question, obviously, is whether any of these things could move the ball with respect to NFV progress. To do that, they’d have to produce a business case not at the service level alone, but for broad deployment. That’s true because of two factors. First, only broad deployment would change costs much. Second, only broad deployment can deliver operations benefits. Capex can be saved on a narrow front, but not opex; you have to modernize whole operator-wide practices. Any of these paths to NFV success could work, but at least one has to develop significantly this year or NFV could lose steam.
Another question is whether operators, now down to the wire on their revenue/cost convergence, will start to look at other options. This is where SDN comes in.
What we’ve proved so far with SDN is also a bit disappointing, perhaps even more so given that it came along first and has broader applicability. We can already use SDN in cloud data centers, and we can also use it inside IP core networks. For operators that’s not enormously helpful because they don’t have that many cloud data centers and they don’t spend much of their capex and opex on core IP networks. Is there no more to it than this?
There is, of course, and we’ve made an industry out of ignoring what’s there. SDN can do new things, build truly new services and not just create another way of doing the services we’ve had all along. SDN can also build new networks, meaning define a whole new model for WAN infrastructure.
The OSI model defines a model of networking that builds from what we know we have to what we think we need. We have wires, so there’s a physical layer, and that’s a good unequivocal place to start. What grew above Level One was based on less solid evidence. Remember that this came about in 1974, and we presumed the need for data-link error recovery because data links were unreliable. That gave us Level 2 (later adapted to LANs as well). We needed services and that gave us Level 3, and so forth. Each layer built on the ones below, using the capabilities that were designed there. Evolutionary networking, feature-wise.
Evolution doesn’t always produce logical things, only workable ones. Look at Emperor Penguin reproduction. What SDN could do is take us to a place where the features of networking were redistributed, where what we thought was happening below changed so radically that what was needed above would be revolutionized too. Example: If I have wires that are error-free, that redirect themselves to provide capacity as needed, how many Level 2 and 3 features can I then render obsolete? I don’t need to invent perfect transmission to do this, only invent virtual-layer agility at Level One, which I can do with SDN.
There’s more. Look at operations cost and service agility. We hear a lot about how NFV could revolutionize costs and time-to-deploy, but where exactly do we find the realization of these benefits, assuming we realize them? Most of what we need is service automation that ends up being exercised above the infrastructure. If we assume that intent models can define NFV deployments, SDN connectivity, and legacy service elements, why couldn’t we reap the benefits of service automation without any of that other stuff? Why not modernize services and let infrastructure go as it must, shifting in technology direction as convenient under our new umbrella of intent models and service virtualization? SDN and NFV might not be needed to drive change at all.
We have a three-legged race here with the legs on different racers. None of these things is really running; you can see that from the truly pathetic progress we’ve made. Hopping is about it. But the thing is, if there’s a finish line and a prize to be won, even hopping will get somebody across it eventually. That’s is my forecast for 2016—the Year of the Hop.
Operators don’t really know how to do any of this stuff, even the best of them. That shouldn’t be surprising given that they are buyers of technology not producers of it. But somebody has to tell the story of next-gen networking for us to get it, and the most logical players (the network equipment vendors) are probably far more likely to want to suppress that story than to support it. What makes NFV more likely to drive change is not that it’s a technically better option (it is not) but that there are powerful players who can sponsor NFV for the good business reason that they would win big in an NFV transition. In the SDN or service automation area, though, we could have a second-tier player step up. Brocade and Ciena have good SDN positions, and there are many second-tier OSS/BSS players too.
I think that what we’re going to see is one of these three developments—maturity of the NFV business case, realization of SDN’s potential, or service automation reframing of service management—will come along and be decisive enough to drive change in 2017. Maybe more than one. Which one(s) might happen is beyond making predictions because there are too many forces (many totally illogical) involved. We’ll just wait and see. Meanwhile, Happy Year to you all!