Juniper founder Pradeep Sindhu says Cisco’s many operating systems make things hard on customers, but that his focus is on making Juniper’s switches and routers more scalable.
It’s perhaps no small coincidence that Cisco makes a major announcement just days before Juniper does or hosts an important event. The day before Juniper unveiled its EX line of Ethernet enterprise switches last month, Cisco introduced its new data center switch, the Nexus 7000. This week was no different, as Cisco unveiled its next-generation ASR1000 edge routers just as Juniper held its annual analyst conference in Southern California. Network World Managing Editor Jim Duffy stole some of Juniper CTO and founder Pradeep Sindhu’s time at the conference to gauge his thoughts on Cisco’s new router as well as a range of other topics.
What is your impression of Cisco’s ASR 1000 router?
Let me just make one broad characterization. In sharp contrast to what Juniper tries to do -- which is to have a single operating system, consistent architecture – our competition seems to specialize in producing a new operating system with each product line. And this doesn’t serve the customer well. We try to have a consistent single operating system and a single unified architecture for two reasons: internally [at Juniper], it is tremendously efficient because we get to solve difficult problems once rather than solving them over and over again; from a customer’s standpoint products appear to be consistent and are consistent, so they are a lot easier to use. When we add functionality to the operating system, we integrate it in. We don’t sort of patch it on the side. But I’m much more comfortable talking about what Juniper does rather than what our competitors do.
OK, but how can your competitors remain successful if they keep coming out with multiple operating systems that increase complexity and inconsistency?
[A single operating system] is a need that our customers are telling us they have. They do not like the fact that they have to read manuals this thick to figure out what release of the operating system works with which particular product and products, and what the combination of limitations are that are imposed by particular subsets of the products that they are using. That becomes very complicated. Much of this is reflected in operational cost increasing for the customer.
Where does Juniper have to go with its product line, operating system, ASICs to address next-generation data center and infrastructure opportunities?
The primary place we have to go to is larger scale. [Also, the] interaction between computing and storage and the network is going to become very important.
The [Juniper Control System] 1200 is a very important product. It begins to address the scaling aspects of the control plane. One of the issues we had seen is that if you try to put the control plane into the router – and traditionally we’ve done that, our competition has done that – one of the issues you end up with is that as computing power has increased trying to fit it into a predetermined form factor becomes challenging over time. So the ability to go to a standards-based platform and be able to have both the latest microprocessor technology, be able to iterate it as fast as the technology is changing in the market, and to be able to have storage inside the same platform is of tremendous benefit to the scaling of the control plane.
The other thing to recognize is, along with the announcement of the JCS 1200, is the announcement of the [software developer’s kit]. The SDK is designed to open JUNOS so that partners and customers can add value themselves rather than rely on every line of code being written by Juniper.
Does Juniper plan to support or integrate Provider Backbone Transport (PBT) in its MX960 Carrier Ethernet switches? [Editor’s note: PBT is a Nortel-developed derivative of the Ethernet standard intended to bring connection-oriented characteristics and deterministic behavior to Ethernet.]
PBT is actually a replication of much of the functionality that is inherent in MPLS. But we will listen to our customers. If our customers truly believe that this is the capability that they want, we will implement it.
Do you see certain applications – say, in the metro area -- where PBT is more beneficial than MPLS?
I personally don’t. PBT is essentially a different implementation of all of the MPLS concepts, with the exception that it is done over Ethernet encapsulation as opposed to over MPLS encapsulation. So that is not a substantive difference. What is painful to see is that if we do actually have to do this we will be replicating functionality, which is unnecessary.
In the enterprise market with your new EX switching line, what specifically is Juniper doing differently than all of Cisco’s other competitors that haven’t been able to gain more than 5% market share?
The Ethernet market is now going on 25 years, maybe 30 years. Ethernet has evolved a lot. Many of the companies that have been in the market for a long time, the operating systems that they have, the code and the implementation that they have reflect the total history of Ethernet along the way. And the same thing that happened in the IP world where, when Juniper came in routers were already a decade old. But we did not have to pay attention to the multiprotocol world that routers had traveled to. The same way when we entered the switching market we don’t have to care so much about every detail of the place where Ethernet had been. So our implementation will be a lot cleaner, they can be a lot meaner, and by having the feature set match the current needs as opposed to what the needs were along the way, I think our implementation is going to be advantaged. They can be much more reliable, much more scalable, secure and they can be high performance.
Will the NetScreen VPN and firewall products eventually go the way of the Kagoor session border controllers and Redline DX application accelerators you acquired, and be integrated into Juniper routers?
All the functionality of firewalls and deep packet inspection is actually being rewritten on top of JUNOS. That effort, which is now going on two-and-a-half years, is well along on its way. Of course we will support the NetScreen products for a long time. But all of the new development will be on JUNOS. We’re going to replace ScreenOS with JUNOS. This, we believe, is absolutely the right way to do it. I don’t want to give any time frames, but our effort is well along on its way.