Open source networking will be the hottest open source trend in 2016. Projects such as OpenDaylight and ONOS are gaining adoption, structure, and a strong development community. On the Linux kernel side, projects like DPDK , with leadership from Intel, plus 100 GigE chipsets from companies like Broadcom are enabling Linux to match the performance of core routers, while providing the increased flexibility of a full Linux OS for a new class of applications.
I’ve identified six opportunities for the open source networking community to address in 2016. I invite everyone to join our community to work together to solve these problems.
Tighten OpenFlow & Other Key Standards
Standards like OpenFlow are loose. The standards body had the goal of making OpenFlow easy to adopt, but there are currently gaps that need to be filled. Three companies can implement the standard in three different ways. Open source networking standards are like Swiss cheese, full of holes. With adoption on the rise, it’s the perfect time to work with developers, users, and vendors to define tighter standards.
In 2016, there could be more development of OpenFlow flavors for switches and hardware, so that standards for SDN protocols become more widespread. For example, in the OpenFlow protocol, Common Structures are not well defined. More activity and ideas here would be welcome.
Share Architecture Templates With Specs
We need better methods to detail the feature and functionality of open source network equipment. Enterprises know their own requirements, but they have a difficult time choosing equipment. For example, if they need 20,000 flows, what type of hardware and software system do they need?
To illustrate what our industry needs, let’s look at the established industry of automobiles where there are standard parameters to evaluate a vehicle. In this industry there is curb weight, engine displacement, horsepower, gas mileage, top speed, and specific types of acceleration.
In the open source networking industry, we need things like number of flows, size of buffer, throughput, MPLS labels, and amount of memory.
Currently few architecture templates exist because only a few people are showing off what they have developed to this point. Any vendor-neutral site can serve this function. If people can’t find a better place to share templates, it can be hosted on the cloudrouter.org site to further stimulate education and collaboration. It can certainly be hosted on your own site, but if you need help sharing your templates and don’t know where to turn to, that community can help.
Creating Experts That Can Build White Boxes
This is a sea change. In the past, people were more focused on developing hardware or software expertise, not necessarily both. Your internal team may be experts in networking technology, hardware from major vendors such as Cisco or Juniper, and the OS specific to each vendor. Or they may be experts at building great software to use the network.
A move to white box and open source will require expertise in both hardware and software. It will involve retraining your existing staff. Although your current staff may not have extensive experience with white box and open source networking, the basics are the same and they can be retrained for the new architecture. To prepare for the change, businesses need to begin pilot deployments and use the information from those pilot deployments to identify skills gaps. Using this information, they can start programs to train their staffs in 2016.
It is important to contribute to open source community discussions, via mailing lists primarily. This is the best way to form some level of relationships with the key people in the community, so that answers can be asked quickly and easily. In 2016, get your team involved in pilot deployments. And ask questions! And if you find out useful information on training curriculum, for example, consider sharing it, so you start to build a knowledge base.
Evolving From Research Projects to Stable, Supported Releases
You can’t sit on a version of code and be happy with it for 18 months. One of the big lessons I learned in 2015 is that we are in the middle of a time of rapid innovation in open source networking. Many open source projects started off as research projects to test technical assumptions and ways to collaborate. Prior to deployment as critical infrastructure, companies want to feel comfortable with the plans for security fixes, bug fixes, and upgrade schedules for the next few years.
Currently, we often see that both the infrastructure software and the network application software are integrated into an ongoing development process, creating maintenance and potential security challenges. The open source community is addressing this with structured engineering releases for both production and development versions. As the number of mission-critical deployments increases, we’ll need to work closely with the community to ensure that businesses and developers have processes in place to deal with the rate of change.
It is imperative that enterprises work with open source communities to help them understand requirements for a release schedule as well as features. In the open source world, stable releases often happen too frequently for network infrastructure. You can not just deploy and forget. Organizations like the Linux Foundation , ONOS, OpenDaylight, and CloudRouter have enterprise-friendly stable release cycles. This follows closely the example of Red Hat Enterprise Linux, with two distinct development schedules: development and stable. Open source communities take on the responsibility for building stable versions and handle tests for compatibility, security, updating, and more. This directly benefits enterprise users.
Develop Certification for Systems Integrators
Businesses need help in deploying open source and white box networking architecture. They need experts that can recommend equipment, software, and build the applications that enterprises need to manage and automatically configure their network. It’s a huge opportunity, and I know many companies are evaluating offering professional services in this area.
To address this, in 2016 certifications for systems integrators (SIs) and white-box vendors should be developed and promoted so that the path to implementation is clear. Companies could more easily judge expertise level and make informed decisions. A key component is also training.
Create an Organized Marketplace
The big question businesses face is whether they are better off making a new application internally or going to a specialized SI. In both cases, a compatibility matrix of applications would help with the decision. Due to the lack of internal knowledge of application, usage, and hardware, businesses need to turn to specialists today. Starting a centralized marketplace will help both businesses and systems integrators and make the decision to deploy open source on white-box hardware easier.
A compatibility matrix obviously needs to be vendor neutral, but in 2016 it could start off on a smaller scale as just a listing of applications. Why don’t you start it? If you are an SI, it makes good business sense. Eventually it can evolve into a larger marketplace.
Conclusion: Join the Revolution
As an open source developer, I’m excited by challenges. As a community, we’re capable of solving all of them. The big opportunities for open source developers, both in personal growth as well as sense of accomplishment, are often at the beginning of a big time of change. Open source networking is going big in 2016. Start learning today. It’s the first step in joining the revolution in network architecture.