Juniper Faces a Choice in Metro Cloud

I’m sure by now that everyone who reads this blog knows my view that the hot spot of networking is metro-cloud.  Juniper just announced a small-form-factor member of its PTX optical transport box that’s designed in large part for metro applications.  The PTX 3000 is part of the Juniper “Converged Supercore”, which is a distributed architecture for an integrated optical/electrical core transport network based on MPLS.  The company is going to be pushing this product at OFC/NFOEC, which has created a bit of a media stir because Juniper seems to be elevating its optical credentials and because it’s calling the new model a “router”.

We’re spinning a lot of useless cycles on these points, frankly.  First of all, the PTX family has been an LSR (Label Switch Router) all along; it’s an MPLS device, has an IP control plane, and runs Junos.  Second, obviously, it’s been optical all along too.  There are two differences here, both subtle, and some ongoing questions about what Juniper might do next.

The first market difference is that optical capacity is now in ascendency; it’s cheaper to create bits than to manage a lot of aggregation, and unit cost of bandwidth has to fall quickly because of retail price pressure.  So any network that’s going to be carrying a lot of traffic has to be bent toward the optical layer, thinning down the complexity of electrical-layer aggregation.  So there’s nothing wrong with shifting your push toward optics, claiming to be an optical company.  Everyone who wants to be into high-capacity transmission of bits has to be one.

The second market difference is the one I’ve been talking about—metro cloud.  Nearly all the profitable Internet traffic transits less than 40 miles, meaning it never leaves the metro area.  Smaller form factors for the PTX mean that you can run them out toward the CO to build a fiber-based virtual LSR that covers a metro area with high-capacity, low-latency routes.  That’s a good thing, a very good thing in fact.  Juniper has been fielding a better solution to IP and metro cores for a while, but the smaller PTX improves the distributability of the solution, which not only means more sites to host stuff, it means more potential sales.

There are still some kinks to work through here, though, to address the full opportunity.  One important one is the relationship between QFabric and the PTX, which is one of my ongoing issues with the positioning of the products.  In a metro-cloud, nothing would be more logical than to link cloud data centers supported by QFs directly to metro-fiber cloud cores supported by PTXs.  The problem is that the PTX is, as I’ve said, an LSR and it needs Label Edge Router (LER) functionality to get traffic onto it.  QFabric isn’t an LER, and that’s something I think Juniper needs to fix.  There are two ways to do it; add LER features somewhere or support OpenFlow on both devices.

LER features on the PTX or on QFabric seems quite feasible.  Adding “complete” LER capability to either of the two product families probably doesn’t make sense.  Truth is that you don’t need packet routing in a traditional sense in a dense core, metro or otherwise.  You’re switching routes, not packets.  All you’d really need is to have an Ethernet on-ramp to an LSP and you’re home.

By the same token, supporting OpenFlow connectivity between the two devices would be easy.  If you can do LSR MPLS switching in something you can do OpenFlow switching with not too much more than some control logic, which should be easy enough since Junos runs on both these devices and is adding full OpenFlow support over time.  Juniper people have told me several times that it was in fact possible to link PTXs and QFabric via OpenFlow.

If I were Juniper, I’d jump on the LER solution big-time.  Metro is where all the money is going, and metro-cloud is the mission that’s going to drive metro.  If Juniper were to provide good coupling between the PTX and QFabric they’d have a single-technology cloud-distributed fabric that could not only span a whole metro area (even one with an enormous population and traffic level) it could be interconnected with an OTN core and create a national or even global cloud core.  I’d hoped to see something about this in the latest announcement, but I didn’t catch any reference to LER capabilities in Juniper’s material or in reporting on the topic.

On the SDN-interconnect front, Juniper has to make a choice.  There is no question that it’s to the advantage of any incumbent router vendor to create an MPLS-dominant strategy in metro because it sells routers.  It’s likely that operators will want SDN support too, and of course you can fulfill SDN missions without OpenFlow.  So Juniper has to decide whether to buck the OpenFlow trend and create an SDN story that’s very IP-centric (as rival Cisco is doing) or to support OpenFlow and an IP/MPLS SDN story in parallel.  Smart choice?  The latter.  OpenFlow-based SDN isn’t likely to progress fast enough in the higher layers to be a threat, and having a solution based on OpenFlow would make Juniper’s position harder to assault, whether the rival is Cisco, Alcatel-Lucent, or Ericsson.  There would be no simple and obvious omissions that competitors could push against.  Watch how Juniper evolves this; it will tell us a lot about how they’ll fare in the future and how fast metro-cloud will become a market issue.

This entry was posted in Uncategorized. Bookmark the permalink.

Leave a Reply