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?
Read More »
Tags: adoption challenges, APIs, Cisco, Cisco Services, consultative led, opendaylight, OpenStack, SDN, SDN controller
The London Eye
Last week I started my SDN reflections on the London Gartner Data Center Conference, and I found I had quite a lot to discuss.
Last week I covered:
- Do we need SDN?
- SDN and the Gartner Hype Cycle
- SDN Deployment Models
So here is the concluding part. This week I’ll cover:
- Overlay-Based SDN — and the questionable assumptions being made by others in this area (good for Gartner for calling these out!)
- The SDN Vendor Explosion Challenge,
- The “Unspoken Costs” of SDN Deployment, and
- The “How” of SDN is still missing.
I hope you find this useful and informative and as always, feel free to debate with me around my observations!
Read More »
Tags: architectural approach, Cisco ONE, Cisco onePK, Cisco Services, SDN controller, software defined network
In my first SDN blog, I asserted that “Services” -- that is technical support, professional and consultancy services -- are the missing “S” in the SDN debate. I’d now like to apply our Cisco Domain TenSM framework “in anger” to examine in more detail the impacts that SDN may have on your IT services and operations. While come of our competitors will only talk about the network switches and new device protocols, l’ll show how it’s not just the network switches that you should be concerned with: your SDN and Cisco ONE journey could involve impacts across multiple “domains”.
As I bogged about Cisco Domain Ten this past year, I’ve positioned it as a mechanism to help you on your data center journey. Let me now extend that use -- SDN after all is more than just a data center technology play. My experience with Cisco Domain Ten over the past year has helped me realize that it is, in fact, an excellent framework for considering impacts to more general IT services, and not just to the data center . I’ll also illustrate my case with both service provider and enterprise/business/public sector examples.
The following diagram summarizes the areas impacted -- let’s discuss each one.
SDN Impacts -- via Cisco Domain Ten
Read More »
Tags: architecture, Cisco Domain Ten, Cisco ONE, Cisco onePK, cisco_services, data center, SDN, SDN controller, software defined network
In my previous 3-part blog series I discussed the challenges in the Enterprise WAN and relevancy of SDN in overcoming these challenges and how Cisco ONE Enterprise Networks Architecture addresses these WAN challenges. In this blog post I will discuss how Cisco ONE (Open Network Environment) and ONE Enterprise Networks Architecture fit together. In a following blog, I will discuss how Cisco ONE Enterprise Networks Architecture provides six significant benefits to enterprises through programmability. ONE + ONE = 6 is the new math for Enterprise programmability!
Cisco ONE (Open Network Environment)
Cisco ONE is a comprehensive, Cisco wide solution (not just data center) approach to making networks more open, programmable, and application-aware. There are numerous blogs, and videos about Cisco ONE that can be found here. As a brief summary, Cisco ONE comprises of 3 pillars that provide a programmable approach to both physical and virtual infrastructure: Read More »
Tags: architecture, Cisco ONE, Cisco ONE Enterprise Networks Architecture, enterprise networks, open APIs, Open Networking, programmability, SDN, SDN controller
Thanks to SDN, the “Controller” word pops up in many network architecture discussions these days. In networking alone, we’re already surrounded by many “controllers” and we’re busy introducing more as we speak: For example, Session Border Controllers or Wireless LAN Controllers have been around for quite some time, and have recently announced the OpenDaylight Controller, the Cisco XNC, or the Cloupia Unified Infrastructure Controller. So what is a “Controller” in networking terms, and how many do we need in emerging network architectures?
Read More »
Tags: active network abstraction, Cisco SDN Controller, controller, network architecture, opendaylight, SDN, SDN controller