Juniper has followed the lead of competitors Brocade and Cisco in launching a virtual router product. Their press release on this was refreshingly entertaining, offering the announcement in the context of an example of what it might do. The only problem is that Juniper hasn’t really done anything more than either Cisco or Brocade in explaining the benefits of virtual routers. That raises the question “Why not?”
Under the covers, every virtual router has a common goal—allow what used to be a router device to become a software-hosted equivalent. The most obvious benefit you’d achieve from this sort of substitution is the capex benefit, the assertion that the combination of the router license cost and the cost of the server that hosts it would be less than the cost of the “real” router device. It’s a kind of NFV argument, although routers were not specific targets of NFV.
The issue this creates from the vendor side is pretty clear. If a real router device costs x dollars, and the sum of the costs of software and server have to be no more than perhaps 0.75x, then the cost of the software has to be a lot less. That means that by promoting virtual routing, vendors are undermining their revenue stream.
Cisco and Juniper have deep issues here, obviously, because they’re in the router business. They either have to try to align the mission of their virtual products to minimize their impact on current router sales (which seems to be Cisco’s approach) or suggest there are benefits to virtual routers that go beyond capex—which is what Juniper’s press release implies.
Brocade can dodge this issue because its Vyatta line aims at a routing market where Brocade doesn’t field traditional devices at all. Arguably, Brocade is in the position to be the disruptor in this whole space because they have little or nothing to lose. Buy Vyatta and a server and save (for example) 25% of your budget off the top.
In the end, though, a vendor likes a market that’s getting bigger rather than getting smaller. Declining network budgets reduces the perceived importance of networks and the influence of network personnel. This, at a time when revolutions like SDN and NFV demand new concepts be explored and deployed. Cost reduction as a goal effectively drains the pool while you’re trying to learn to swim.
Juniper’s approach to evading a pure-capex-reduction value proposition, as it outlines in its release, is postulating a future of services where the network operator can turn on cloud-based features and applications from a simple portal, responding to business needs the way an OTT player could respond. It’s the most creative way Juniper has presented its offerings, and there’s an element of truth in what they propose. Also, three issues.
The first issue is that service agility at the network level and service agility at the application level aren’t necessarily strongly related. If an enterprise wants to augment basic Internet with cloud-based UC/UCC and other applications (as the Juniper release proposes), most of that augmenting has to be done above the network. In fact, if the OTTs are really the preferred providers for these services as the release suggests, there can be no network tie at all since the OTTs can’t manipulate the network underneath.
The second issue is that whatever is agile and whoever provides it, you have a service management and operations problem first and a technology problem second. Building the kind of service described is an exercise in combined network/cloud orchestration and management, and so it’s really an example of what NFV should provide. Most of what vendors want to claim for operations efficiency and service agility can be claimed only if you change to a more comprehensive implementation of NFV-like MANO.
And issue three is critical. Servers are not as reliable as hardened devices, and while you can manage availability through resiliency and performance through load-balancing and scaling, this adds complexity to the operations side. It does you no good to postulate benefits that can be attained only at a cost that’s greater. Traditional network ops can’t manage virtual devices effectively.
The sum of these points is that you need a really flexible operations-management framework to provide agility and efficiency, over top of whatever network-layer accommodations to those goals you might make. But even with one, there’s still no specific link between agility/efficiency and virtual routing. What Juniper, and Cisco and Brocade as well, need to do is to tie virtual routers explicitly to services in some way. So let us, in the way of an exercise, look at how that might be done.
What’s the difference between a software router and a physical device, in an agility sense? The answer is that a physical device is put somewhere physically, and a software router can be put somewhere virtually. If you assume a server pool that’s reasonably distributed through an operator domain, you can put virtual routers anywhere. When you build a private network for a user, you can put routers where they should logically be based on traffic patterns. When you build service networks designed for multi-tenant operation you can do the same thing. If you used physical devices, you’d have to move current boxes and install new boxes, or pre-position boxes that could be used effectively in a multi-tenant mission.
This means that the value of virtual routing is greatest where the distinction between virtual and physical placement is most valuable. Where a virtual router is really helpful is where you create separate Level-3 service topologies ad hoc. Traffic patterns are created by the juxtaposition of process points and information sources/sinks. Effective topologies match traffic patterns. If we build VPNs or any other business service by assembling lower-layer (agile optics, Carrier Ethernet) pipes and connecting them with routers, we can do it better and faster and cheaper with virtual routers. That’s because we can put those virtual routers where traffic dictates. If we build partitioned networks at Level 3 for services like IMS or cloud computing, we can do that better/faster/cheaper too. The move toward agile optics, toward contained and service- or customer-specific subnets, could boost virtual router value considerably.
You could make a strong case for virtual routing of this type even if you were an OTT, presuming that you were networking virtual routers together with tunnels. That means cloud computing could use them, and content delivery and more. But to get back to my early point, all this agility is useless if you have a two-week-long manual process associated with just taking the order, or you squander human capital just keeping your network connected. We have to wrap something that can be agile in a framework that exploits the property of agility to secure provable business benefits.
The moral here is simple. We are starting to jump on the opex-reduction and service-agility bandwagons now because capex reduction is 1) already done, so it’s no longer news, and 2) it’s eating the vendors’ own young. Getting PR is a good thing. Creating a strategy that’s not self-cannibalizing is also a good thing, but you have to go beyond the slogans to get the benefits. That means redoing operations. Nobody—not Juniper, Cisco, or Brocade, has that in their message or offers what I’d consider a clear path to it. And no, OpenStack integration isn’t the solution either; not by itself. You can’t solve a problem by handing it off to something else, unless that something solves it. OpenStack and OpenDaylight aren’t full management and orchestration, and that’s what the virtual world needs, whatever your product strategy might be.
Juniper’s heading on their release is The New “Virtual” Reality, and that’s a fair characterization of where we are. We’re discovering that agility is the cure for inertia, and virtualization is the path to agility. We now need to discover that this virtualization thing has to envelop operations first, or we can’t take it anywhere else and be effective. None of the virtual-router players so far, including Juniper most recently, have done that. But it can be done, and eventually somebody is going to get this right.