Over a million developers have joined DZone.

Juniper’s SDN Approach Created a Rift in Engineering

DZone 's Guide to

Juniper’s SDN Approach Created a Rift in Engineering

· ·
Free Resource

juniper headquarters contrail sdn software-defined-networking opendaylight

Engineers in switching and software-defined networking (SDN) have been leaving Juniper steadily for the past year, having been deeply alienated by management after the acquisition of Contrail, sources tell SDNCentral.

At the heart of their complaints is Juniper CTO and founder Pradeep Sindhu, who sources say dismissed the significance of software-defined networking (SDN), then tried to play catch-up by acquiring Contrail, allegedly lashing out at Juniper’s engineering team in the process.

Sindhu has since fostered an us-versus-them culture, sources say; anyone who challenges Contrail reportedly gets labeled as “hostile,” as one former employee put it. (Juniper declined to comment on this article: “As a matter of policy, we don’t comment on rumor or speculation,” a Juniper spokeswoman wrote in an email.)

Exactly how many engineers have left is unclear. One source says half of the campus and data center business unit’s (CDBU) engineers are gone, along with a number of Distinguished Engineers and executives.

Much of this can be chalked up as ordinary corporate politics, sources admit. But if true, the allegations would show that SDN has caused more than a bit of turmoil at Juniper.

“I don’t think this is different from any corporation. I think this happens all the time. It just happened at this critical nexus where a company had to decide how it’s going to respond to the challenge — because SDN is a huge challenge,” one former employee says.

Welcome to the New Juniper

There’s a scene in Breaking Bad (we’ll try to avoid spoilers here) where an experienced chemist challenges young Jesse Pinkman’s skill. Pinkman acidly retorts: “I’m the guy your boss brought here to show you how it’s done.”

That, according to sources, is the way Sindhu introduced Contrail to the rest of the company, and Juniper’s then-current engineering team took it as a deep insult.

“The guy was just a complete madman on the call, muttering to himself, lashing out at engineering for ‘messing up’ Junos. He told everybody, ‘I bought this thing [Contrail] to fix the screw-ups you had done before,’” one source says — adding that Sindhu hadn’t given any previous indication of being unhappy with Juniper’s SDN progress.

In some engineers’ eyes, Contrail’s staff was then placed in a position of privilege, housed in a badged-off area of Juniper headquarters, apart from the rest of engineering.

If Sindhu was feeling under the gun to get an SDN plan rolling, it would be understandable. QFabric, a product he’d introduced with great pride in 2011, was still facing doubts in the market. (Customers love the QFX3500 top-of-rack switches, but the full-blown QFabric has a more limited market.) MobileNext, Juniper’s evolved packet core for mobile networks, was faltering and would eventually be killed off.

Those products, and Juniper’s entire strategy to become more of a software company, were launched before SDN fever consumed Silicon Valley. Juniper points out, correctly, that QFabric is SDN, but it still got upstaged by the new term.

And sources say Sindhu — like many tech executives worldwide, to be fair — dismissed the new fad. “When Google announced what it did with OpenFlow, he was incredulous,” one source says.

Sindhu did eventually come around to OpenFlow, but former engineers say there wasn’t any clear way to make money developing a controller. Juniper was putting more emphasis on Path Computation Element (PCE) as a means of WAN control, one former engineer says. “And Pradeep came out of left field and said he was going to acquire Contrail and reinvent SDN.”

An MPLS-based controller like Contrail’s was “one of many things” Juniper’s SDN team had already been working on, according to one former engineer. But once Contrail got acquired, projects involving OpenFlow and PCE seemed to lose favor. “We didn’t budget it this past year, which is why Juniper doesn’t have a PCE server,” the source says.

As a side note, Contrail’s version of BGP reportedly differs from Junos’, meaning Juniper will have to commit to supporting both versions. One source believes that could become an issue around the end of 2014, when it’s believed the Contrail team’s acquisition payoffs fully vest, increasing the chances of key people leaving.

A Question of Open-Source

There’s a partially related issue that’s bugging some former employees, and it relates to Juniper’s membership in the OpenDaylight Project: “We were under orders not to contribute anything to OpenDaylight that competed with Contrail,” one source says. “We contributed dollars, but not code.”

That source speculates that Juniper took Contrail’s code open-source in September to set up Juniper as a competitor to OpenDaylight.

Of course, the whole reason for OpenDaylight to be open-source is to avoid having any one vendor own a crucial piece of the SDN framework, particularly the controller. (The presence of Cisco still makes some skeptical, but OpenDaylight’s openness has gotten good marks so far.) OpenContrail could be a viable alternative, but it’s an open-source entity owned by a vendor. (Roy Chua highlighted the differences in his recent “Controller Wars 2.0” post.)

Where This Is All Coming From

As noted earlier, what’s allegedly happened at Juniper is probably not much different from the political battles at any large company. What’s noteworthy here is the wave of change that SDN is spurring. Like any other incumbent, Juniper wants to establish itself as a leader in the new world order and doesn’t necessarily feel comfortable letting SDN find its own direction.

“To Juniper, the answer to any question is BGP and MPLS. The SDN protocols kind of threaten Juniper’s position,” one former engineer says.

(Photo source: Wikimedia Commons.)


Published at DZone with permission of

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}