Cisco has always been known for aggressive sales strategies and cynical positioning ploys. Remember the day of the “five phase plan” that was always in Phase Two when it was announced (and that never got to Phase Five)? When SDN and NFV came along, Cisco seemed to be the champion of VINO, meaning “virtualization in name only”. Certainly Cisco Live shows that the company is taking software, virtualization, the cloud, and APIs more seriously, but it doesn’t answer the question of whether Cisco’s emerging vision takes things far enough.
Cisco’s approach to networking, embodied in things like Application-Centric Infrastructure (ACI) and Digital Network Infrastructure (DNA), has been to use a combination of policy management and software control through enhanced APIs to create as many of the benefits of SDN and NFV as possible without actually mandating a transition from current switch/router technology.
ACI and DNA may seem like meaningless “five phase plan” successors, another round of cynical positioning, but they’re not. They are specific defenses of the status quo from a company who benefits more from that status quo than others. They’re also an exploitation of what Cisco knows from experience is likely to be a highly visible but largely ill-planned and ineffective initiative to change things.
Obviously, the risk of VINO is that any true benefits of infrastructure transformation are lost. However, that risk is relevant only if those kinds of benefits are demonstrably realizable. Very early in the SDN/NFV game, operators and enterprises found that capex reduction wouldn’t delivery any real infrastructure-transformation benefits. Beat the vendors up on price instead! But not much later, everyone realized that operations and agility benefits could be truly compelling. I think Cisco, at this point, started to shift their general ACI positioning from “software control” to “software automation”, emphasizing the importance of software in reducing opex and bringing services to market faster. DNA shows more of that view, for example, as the later architecture.
The truly interesting flex point came along within the last year, when it became increasingly clear that you not only could gain significant opex economy and service agility through operations automation, you probably should. My own modeling shows that you can create a bigger impact on network operator profits with operations automation than with infrastructure transformation, do it sooner, and present a better ROI along the way. Maybe I’m reading things into the Cisco event speeches, but I think Cisco may now accepting this shift, and looking to capitalize on it.
Operations automation implemented in an open way should be able to control the service lifecycle independent of the details of infrastructure. Yes, that could aid the transition to SDN or NFV or both, but it could also be used simply to improve operations on legacy infrastructure. That would play to what Cisco wanted all along—some way of improving operator profit per bit that didn’t involve shifting to a new set of network technologies that Cisco wasn’t the incumbent for.
You could also argue that it could play into the Tail-f acquisition, which gives Cisco a way of managing multi-vendor networks. Earlier this month, Cisco won a deal with SDN/NFV thought-leader Telefonica to use Cisco’s Network Services Orchestrator (NSO) for business services. This product is derived from Tail-f and the YANG modeling language. In a real sense, NSO is a kind of superset of the NFV Virtual Infrastructure Manager and NFV Orchestrator rolled into one. What it does, and what I’m sure Cisco intended it do, is let operators orchestrate/automate legacy configurations just as NFV MANO and other tools would do for NFV.
Which is the challenge Cisco now faces. In fact, the move generates several challenges to Cisco’s positioning and ultimate success.
The most obvious challenge is that a “Network Service Orchestrator” will have to orchestrate SDN and NFV as well as legacy technology. Cisco will have to let the new-infrastructure camel at least blow some sand under the tent, if not actually get the nose in. If compelling SDN/NFV business cases could be made (which so far has not happened, but could happen) then Cisco might end up facilitating the very transition it’s been trying to position against.
This challenge leads into the second challenge, which is a fast start to achieve thought and deployment leadership. Cisco has a credible NFV Orchestration product in NSO, as a recent report on NFV MANO from Current Analysis shows. The problem is that NFV orchestration isn’t a business case, it’s just a way of making NFV work. If Cisco’s goal is to fend off NFV transition it first has to make it clear that NSO opens an alternative path to benefits, then convince operators to take that path and prove out its validity.
Meeting these challenges, in my view, means making a direct connection between Cisco’s architectures (ACI, DNA) and products (NSO) and service, network, and operations automation. I think some of that came out in the announcements and talks at the Cisco event, but this isn’t something you can win by blowing kisses. NSO is delivering value below the OSS/BSS, and it’s a single-level model at a time when operators are recognizing the need for multi-layered orchestration. Other vendors have a broader, better, story in that area than Cisco.
Better-ness equates to the ability to make a compelling near-term business case for software automation of operations. NSO and YANG evolve from an initiative to fix SNMP management by creating CLI-like flexibility in a standardized way. NETCONF is the protocol that operates on YANG models, and it’s ideal for network device management, particularly in multi-vendor environments. As an operations modeling language it is, in my view, sub-optimal. I know of no operator who likes the idea of doing cloud or OSS/BSS orchestration using YANG. TOSCA, the OASIS cloud standard, is the emerging choice, in fact. Cisco has to either prove that YANG is a good choice for generalized multi-layer service orchestration or explain where those other layers and those other kinds of orchestration come from.
Ciena, Cloudify, and others have provided some good insight into how TOSCA and YANG, for example, could relate. Some operator architectures for NFV also suggest a symbiotic application of these technologies. For Cisco to get its approach going, it needs to lay out this kind of approach and make it an official Cisco policy. But it also has to tie this to benefits. Operators I’ve talked with have been continually frustrated by the lack of insight vendors have into operations efficiency and agility benefits. Vendors don’t know that the current costs are, how any specific approach would target them, and how the targets could be validated. Most of the “validations” or “use cases” so far have been inside NFV lab activities, where the specific goal isn’t operations automation at all and where most of the interesting stuff has been declared out of scope.
Cisco is making several critical bets here. First, they’re betting that SDN and NFV will not get their acts together (a fairly safe bet as I’d see it). Second, they’re betting that they can deliver meaningful operations automation at the network level, meaningful enough to drive adoption of the Cisco NSO model without much operations integration elsewhere. Third, they’re betting that nobody delivers operations automation from the top down and cuts off Cisco’s NSO layer. Neither of these last two bets are particularly good ones, and so Cisco is going to have to figure out a way of taking a lead in operations automation and service agility that sticks its nose outside the network and beyond the influence of Cisco’s typical buyers. A shift in attitude, which we may be seeing, is important to reaching that goal, but it won’t be enough. Cisco has to step up and make the business case like everyone else.