Three light beams that emanated from OpenDaylight Summit

Earlier this month, I attended the first ever summit on OpenDaylight (ODL) project in Santa Clara, CA. This near sold out event was largely successful by many standards. It brought together a large number of great minds to the table to solve some of the toughest challenges the networking industry is facing around Software-defined Networking (SDN) and Network Function Virtualization (NFV). The group announced a first major step forward with the first open source software release called Hydrogen.  The bulk of the credit goes to 154 contributors from Cisco, IBM, Ericsson, Red Hat, Citrix and others who wrote over a million lines of code in past ten months to make this happen.

The two-day summit was packed with a variety of sessions that were geared towards a diverse set of audience. The sessions varied from general topics to specific topics such as relevance of Open source software, NFV, LISP, standards, discussions on North and South bound APIs, developer tutorials for building applications & tool chain, using OpenStack with ODL, analytics, test automation, and a true story of SDN in production environment.

Of all these topics, here are the three important themes that stood out to me –

    1.      The importance of an Open Source, community initiative for SDN

The concept of Open Source software has been around since decades. It is fast catching up in the non-traditional realms of computer networking. For some, the concept of open source equates to free software. While this is partially true, I strongly believe that open=free is a misnomer. I have started to realize that open source and further, the collaborative initiatives like ODL is far beyond the notion of freeness. In my view, the most important thing that such an initiative does is to gather right minds to bring out bright ideas. The collective wisdom that emanates from such a collaborative initiative helps vendors develop a cohesive set of products that speaks a common language, and perhaps share certain fundamental design constructs to aid interoperability. At the same time, I believe that this collaboration helps to compress the infinite ways vendors can built products to a bounded, agreed upon set of behaviors and interfaces. Customers are real beneficiaries of such an open initiative due to this standardization and better product interoperability. As Vijay Pandey from IBM aptly said in one of his presentations, open source initiatives like ODL “promote innovation and raise the value bar.”

Cisco firmly believes in and supports such open source initiatives. Cisco is a platinum member of ODL project, as well as a Gold member of OpenStack Foundation. You can find more information about OpenStack at Cisco , and a rich set of Cisco Services to help you exploit and adopt OpenStack.

 

    2.      What and how much to Standardize (North and South bound APIs)

In the summit, there were several interesting debates on what to standardize and how much. With regards to how much, I am with Guru Parulkar’s mantra to “standardize as little as possible.”

One of the core capabilities that SDN brings to the table is the notion around exposing interfaces from control plane to the infrastructure layer (South Bound APIs or SBI) and to the application/business layer (North bound APIs or NBI).  We talked about using common approach for design constructs above, and the APIs are central to the constructs. However, if we (are somehow able to) standardize every hook into the system, we are forcing the industry to take a “single” approach to solve the underlying problems. Additionally, I believe that such an approach will not only go against the very notion of openness, but will also hinder innovation and ability to provide unique experiences.

If we talk about SBI, we rightly need some standardized ways to abstract some of the infrastructure complexities. I learnt that ODL will include support for SDN open standards such as OpenFlow, VxLAN, PCEP etc. Similar to SBI, can we standardize the NBI’s as well?

One of the consensuses that emanated from multiple discussions in the summit was that since NBI’s are tied to business layer, the APIs may inadvertently need to be unique from one implementation to next. Therefore, instead of focusing on interfaces themselves, we should care about the outcomes that this business layer intends to achieve. Additionally, this north bound layer is where innovation could flourish by way of new protocols or applications. Instead of fixating on standards, we should rather establish a framework or process that vendors could leverage for developing NBI’s. I found this to be a very convincing argument.

A top down sandwich approach that creates an abstraction layer could be one way to solve the problem. But this could potentially create dependencies and bottlenecks. Mike Dvorkin, co-founder of Insieme, proposed a better way to define this abstraction using information models. These models can be standardized rather than APIs itself, and can be used to exchange information across different applications in a standardized fashion.  It brings the needed abstraction between the application and the infrastructure layer. At the end of the day, it not only allow us to rightly standardize only certain aspects of the system, but at the same time empowers us to build an open system so we can iteratively solve complex problems with respect to SDN. I found Mike’s proposal to be very fascinating as it provides a balanced approach to standardization.

 

3.     Adoption challenges, and a consultative-led solution

When it comes to adopting SDN in your organization, you have to consider your “current state” infrastructure in association with your business and technology goals. And often times, there may be not be a single magic pill when it comes to adopting SDN. From a technology perspective, the “end state” may consist of a mix of ODL and vendor specific controllers, a mix of open source and proprietary tools/capabilities, and perhaps a mix of standardized and proprietary APIs as well. These are inherent adoption challenges that the industry as a whole is facing. My colleague, Stephen Speirs, has blogged a few times on the topic of SDN adoption challenges. The inherent adoption barriers demand that we do introspection of these challenges using a “Why-What-How” framework. One of the best ways to address these barriers is by using a consultative approach.

Take the case of the top four adoption hurdles that emerged from a panel discussion at this summit:  Organizational inertia, Skill gaps, Interoperability, and Standardization or common approach to things. Dan Pitt from ONF rightly said that a use case driven approach and training are some of the ways to ease the adoption resistance. A consultative approach, like how Cisco Services has taken, helps to uncover as well as solve the business, technology and organizational barriers to overcome these adoption challenges and help realize the SDN benefits.

Dr. Jun Park from EIG/ Bluehost, in his keynote, shared a very interesting (and a true) story of a SDN implementation in their production environment using elements of ODL and OpenStack. And we could hear his adoption challenges loud and clear.  Dr. Park explained high level entry criteria they had set out with respect to their SDN implementation.  On their road to SDN, one of the first things they realized was that the entire data center will be at a mercy of controllers – something that can potentially pose a huge risk to their infrastructure environment. On top of that, using an open source element demanded investigation into the failover procedures as well as understanding the overall limitations of a community driven solution.

Unless we make dedicated attempt at solving these adoption barriers, the organization or the industry in general cannot move past the adoption resistance and fully realize the potential benefits of SDN. And I firmly believe that a consultative-led approach can be a catalyst in bringing about this change.

That said, I would like to hear more about the challenges that your organization is facing when it comes to adopting SDN. Please reply to this blog with your comments…