This is part 2 of our deep dive into Open SDN and NFV blog series. To learn more about what “open SDN” really means, check out part 1. To continue with the series and note the difference between SDN/NFV projects that are truly open vs. “faux open”, go to part 3.
Openness has changed networking in ways we couldn’t even have been imagined 10 years ago, making it easy to be lured by the idea of “open SDN” for its own sake. It’s true that openness has paved the way for incredible efficiency gains and cost reductions, but openness is not the be-all and end-all. Instead, it’s important to think about when openness truly matters to the business goals you’re trying to achieve.
As part of IP-based networking, “open” historically meant standards and protocols that defined how various networking elements communicated with each other. Created out of the necessity to make different vendors’ products interoperate on the global Internet, this level of openness served networking reasonably well when networking was primarily hardware based with a limited number of vendors and products.
The advent of software-defined networking (SDN) and network functions virtualization (NFV) rendered the historical definition of “open” necessary but not sufficient. In today’s networking environment, the traditional definition doesn’t begin to touch on important considerations such as where in the stack things need to be open, and the benefits — or not — of specific open elements.
In my previous post defining open SDN, I explained openness in the context of SDN and NFV, and the various attributes to use to measure the degree of openness for an SDN or NFV project.
Here, we’ll take it a step further to explain what openness means to you, your organization, and to innovation in our industry. Where should customers and the industry look for openness? Or maybe more importantly — where should we not care, and why? This article will focus on:
- How open SDN and NFV have changed the networking landscape, and why the definition of “open” in networking must change too
- Where the industry needs openness
- What customers should look for in open solutions and open projects
Pre-SDN/NFV vs. New SDN/NFV Reality
As the world changes from a pre-SDN/NFV environment to SDN/NFV reality, how networks are automated and orchestrated (SDN), and how network functions are delivered (NFV) start to impact what needs to be open:
|Networking Pre-SDN||Networking Post-SDN|
|Networking Pre-NFV||Networking Post-NFV|
The movement to develop open protocols and standards can and needs to continue. This is more important today than ever because large cloud providers like Amazon Web Services (AWS), Google, and Microsoft (Azure) are writing their own networking software — or customizing/modifying open source software like Quagga — that then needs to interoperate with network equipment from traditional vendors deployed on service provider and enterprise networks.
Just as networking is changing in fundamental ways, there needs to be a corresponding change to what signifies “open” in networking. In my previous post, when I talked about what openness really means, I defined openness when it comes to standards, software, application interfaces (APIs)/software development kits (SDKs), and hardware. Now we’ll take a closer look at each of these four attributes and identify what is most important to be open in each.
From a packet processing perspective, I expect to see non-traditional companies become more active at leading standards bodies like Institute of Electrical and Electronics Engineers (IEEE), Internet Engineering Task Force (IETF), and Metro Ethernet Forum (MEF), which will continue to drive interoperability between new networking software and traditional networks.
For the control plane, northbound APIs and southbound APIs need to evolve into standard and open APIs and SDKs that any software developers can use to develop new networking applications. Ecosystems will be won and lost on the adoption of APIs and SDKs, so this is an area that certainly needs to be open in the sense of standards development, software code, and governance.
Open Source Software
Open source software that is central to the entire networking ecosystem needs to be foundation managed with transparent governance processes to be truly open. From an SDxCentral perspective, this means software including a) data plane software such as Open vSwitch (OVS), b) control plane software such as OpenDaylight, and c) cloud management platforms such as OpenStack should be foundation managed.
(Note: OpenDaylight and OpenStack are foundation-managed; OVS and its configuration protocol, OVSDB, are managed by VMware.)
Many open source networking projects are released under licenses like Apache 2.x, Eclipse, and GPL2, which offer free and open source software (FOSS) licensing. This is not enough protection. Many open source networking projects are controlled by a single company or entity, which poses a major risk to developers who build their own products and services off vendor-controlled open source software because controlling entities may extract a tax on the entire ecosystem that leverages their open source code.
Illustrating this concern with vendor-controlled open source software, Oracle moved MySQL to a dual license (open source/commercial) after it acquired Sun, forcing many independent software vendors to have to purchase commercial licenses to embed MySQL in their products.
Alternatively, the vendor controlling an open source project may decide to not “tax” the ecosystem. However, they may deny or slow-roll contributions from the community that are at odds with the company’s business objectives. Either situation is bad for the overall networking ecosystem.
One area where it’s not problematic to have vendor-controlled open source is the vendor-specific plug-ins to OVS or OpenStack, as such plug-ins extend the way these open technologies interface with a given vendor’s product. It makes sense to offer this software for free with licenses that allow customers to modify the software to better fit into their specific environments.
APIs and SDKs
We define “open APIs” or “open SDKs” as those that, like open software, are managed via an independent foundation and not a single vendor.
APIs are the codification of the next generation of standards that enable programmability. And as we all know, standards with code will always win against standards with no code. We also know that APIs are the interface to the developer community, which makes the stakes for defining APIs and SDKs very high. This is especially important because APIs and SDKs can be copyrighted, making it important for the industry to focus on extending the foundation-managed approach to APIs and SDKs
Unfortunately, few APIs today are foundation-managed. Aside from OpenFlow, most APIs are controlled by a single entity, such cloud provisioning by VMware for the VMware environment and Amazon for AWS. Such APIs may inadvertently stifle innovation instead of promote it because of fears about intellectual property rights.
Customers use such APIs to write applications leveraging the APIs’ functionality, but ownership questions arise when other vendors use the new API to extract their own value or take value away from the original API owner. This also means there could be risk to customers who adopt these APIs from third-party vendors who are not indemnified from the API on their own.
For the bulk of us, open hardware will have a limited effect. If you are at the level of scale of Google, AWS, Microsoft, Facebook, or maybe even AT&T, creating your own hardware can be very beneficial. But for most of the community as a whole, any benefit you may get from creating an open reference design to build your own hardware will be questionable, making open hardware a “nice to have” at best.
If you are interested in open hardware, check out the Open Compute Project founded by Facebook. Just as with any other “open” projects, I encourage you to focus on the participation model, governance, IP and licensing, and to look for the ability to fork for hardware just as we have detailed for software.
What to Look for in ‘Open SDN’ Software and Projects
The definition of “open” has changed because the nature of the problem has changed with SDN and NFV. When it comes to openness, customers should focus most on where openness creates business value or encourages innovation in our industry. (Or at least doesn’t stifle it!) Customers should consider the following with open SDN and NFV software and projects:
- Use open source software and APIs that are managed and developed by foundations, and shortlist products from vendors that build products off these standards.
- Look at the check-in logs for open software projects to see who is contributing the most. This is a good indication of the commitment from prospective vendors/partners to the ecosystem.
- Demand that suppliers (both cloud and networking vendors) participate in foundation-managed projects and open their APIs to foundations for standardization. At minimum, suppliers should promise indemnification from threat of lawsuit for writing/adopting an API — though this is a short-term fix, as you are still stuck when a “new” version with a “new” name comes out with new licensing terms.
- Encourage companies that control open source projects important to the whole community, such as VMWare, to move projects like OVS to a foundation like Linux Foundation or Apache Foundation. We also encourage organizations to use their financial support and band together with other vendors to fork projects like OVS.
Finally, be sure to look for our next and final installment in our series about openness. In “Open is the New Closed,” we’ll look at degrees of openness in specific companies, organizations, and products. I’ll talk about why you should care, and what you should do to manage risk and expectations.