Moderator Moderator , Moderator Moderator Moderator
What is open good for?
Mar 10, 2014

Last week in a conversation with a customer I was asked about the differences between ODL and OpenContrail and if NorthStar was going open source as well. That discussion seemed interesting for a blog on approaching “open” networking, especially given we’ve just come thru the Open Networking Summit earlier this month.


Open can manifest in a lot of ways. In my mind, chiefly, as open source, open standards, and open interfaces. Personally “open interfaces (APIs)” seems like a misnomer to me, but it seems too late to change.


Open standards have always been the underpinning of network component interoperability. The degree to which networks are interoperable is the degree to which they can peer and grow into larger networks, so this is vital for networks in a world with explosive desire for connectedness of people and things all the time and everywhere.


In developing OpenContrail and NorthStar, you’ll notice the implementation bias toward using proven and existing open standard protocols like MBGP and others, rather than employing new protocols like OpenFlow for example. This is important because we’re building platforms AND products. Customers buying the product care about investment protection and an evolution from where they are to the future they will realize as they roll out the product more and more. Notice how this is at odds with pure technologists’ desire to optimize the technology, regardless of whether reinvention is necessary or not in their view. When building products, we simply must incorporate a bias to evolution over revolution.


Open source is another topic with its virtues and its own problems. The ecosystem and community built around a cause is wonderful for innovation. Projects like Linux and OpenStack offer customers greater options of which vendor they want to use for the commercial support, and with some flexibility to change between them and leverage innovations across them easier than wholly closed-source vendor solutions.  On the side of open source challenges, these ecosystems can tend to be driven by technologists and they don’t necessarily rally around specific customer business problems. It takes vendors to best focus on the customer, and with that does come some lock-in. Open source doesn’t necessarily mitigate all vendor lock-in as some would tout, but open (common) interfaces, a frequent byproduct of open source projects, does help in this regard.


Open interfaces help to create isolation in layers of the software stack; thus, we get the option to switch out and recompose the layers and that option truly lowers vendor lock-in. Interfaces effectively decouple. Decoupling can also be built into systems by choice. For example, Juniper designed OpenContrail to not rely at all on the physical network except IP reachability. That creates true freedom for the customer, breaking an area where lock-in may otherwise set in.


Are all these axes of openness needed or best applied universally? Probably not. When you look at cloud infrastructure, open source is trending strongly. The ETSI NFV ISG is even creating its reference architectures on open source infrastructure, and in genernal, trying to keep IT up-to-speed with the public clouds, Web 2.0s, and hyperscale enterprises demands keeping up to the speed of innovation that an open source ecosystem provides. OpenContrail fills this demand perfectly, coming to the open source cloud infrastructure party with a lot to offer because it was incubated to maturity before launching. When it comes to applying SDN paradigms in the WAN (also read backbone/core), this open source party simply doesn’t exist. Therefore, I don’t see a need to open source Juniper’s NorthStar controller. Incubating it in-house until its later release, we will ensure we align all of our internal technologists (Juniper is known for wickedly smart and passionate engineers) in the direction of customer needs.


I know I still haven’t answered with respect to OpenDaylight (ODL) vs. OpenContrail and NorthStar. There are a bunch of things to say like how Juniper Contrail used OpenContrail code exactly (not just a a basis to hack into a product), but my favorite part is my car analogy. OpenDayight is positioned as platform for SDN and innovation, but these are very broad goals. SDN and innovation are an umbrella across networking domains, but for totally separate solution areas like high-IQ WAN networks and cloud infrastructure for virtualized data centers and the service-enabled SP edge, we are best served by separate but complementary products. As I said to our customer, “If you had an F1 race on the track and also an off-road race on a course with obstacles, then you would take separate cars, that is, if you want to win.”

Apr 1, 2014
Steve Adams


Hi James-

Your dissection of different flavors of "open" is interesting, and makes good sense in general. Can you comment on how you might measure the value of open source projects? You mention Juniper Contrail used OpenContrail code "exactly".

Is the benefit of open source best seen when multiple vendors offer commercial support? Or when significant contributions to the source from a wide variety of contributors are integrated? Until then, are the end user benefits of open source realized? Your thoughts?


Apr 1, 2014
Moderator Moderator

Thanks for your comment and questions Steve.


There are several ways I suppose we could measure the value of open source projects.


First of all is how well it aligns with solving a problem/opportunity and how important that opportunity is. What I pointed to herein was how OpenContrail aligns well with networking for cloud infrastructure: a well-defined, popular, and important opportunity.


Another metric of success could be the participation in the project. Greater participation in open source projects leads the community to collect the efforts of many into one place.


Yet another metric would be how many people benefit from the project. Vendors benefit first by leveraging the project (this aligns well with a good engineering principle of solving hard problems once... not reinventing the wheel). From that the end user also benefits too because they reap more innovation at a lower price because the vendors' leveraged R&D results in a lower cost.


The point I made wrt "exactly" is that Juniper and OpenStack/CloudStack vendors leverage all of OpenContrail and don't change it, and it gets us very close to a whole solution for cloud networking. ODL is less solution specific (its mission is a platform). Using it doesn't get one near as close to the same solution. A lot needs to be added, and I've heard there is also a lot of changes to it as well.


Of course there are implementation differences between OC and ODL, so perhaps another metric comes down to implementation choices that impact the final use of the technology. The open standards and open interfaces used for example in OC and ODL are not the same.


To answer your final questions, I think it is best when multiple vendors can offer commercial support and when contributions to the source are integrated toward improving the above metrics. I believe the end user benefits are progressive and happen indirectly (more innovation at a lower price & drives open interfaces reducing lock in).

Aug 13, 2014
Moderator Moderator

Just wanted to add pointers to a few good articles that I have read lately:


Open source and open interfaces/APIs for devops and app portability on cloud infrastructure: and


Open source and the devops culture: