The high cost of joining the Open Networking Foundation has prohibited many engineers at startups and research organizations from joining the community, which is responsible for developing the OpenFlow protocol.
This lack of diversity and narrowed input at the Open Networking Foundation (ONF) has resulted in premature commercialization of OpenFlow, and could lead to additional problems for software-defined networking (SDN) in the future, some engineers claim.
The ONF: An exclusive club
Anyone can join the ONF and contribute to OpenFlow protocol development, but only if they can afford the foundation's $30,000 annual membership fee.
You can't take beta code and sell it and say you're behind moving the standard forward -- that's not a real OpenFlow implementation.
CEO, Adara Networks
The ONF develops the OpenFlow protocol through its members, who sit on the foundation's board of directors and a number of working groups. The foundation's board is dominated by large network operators and major enterprises that are OpenFlow users, including Google, Goldman Sachs, Facebook, NTT, Verizon, Yahoo and Deutsche Telekom. But every leading enterprise infrastructure and technology vendor, from Cisco, HP and Brocade to VMware and IBM, has joined the ONF and fuelled its growth.
Unlike these large players, engineers at research and education (R&E) institutions and some SDN startups said the annual membership fee is too steep and limits their input into the development of the OpenFlow standard. The fee could also restrict access to important information that helps guide their investment in the technology. Other standards-making bodies, such as the Internet Engineering Task Force (IETF), are free for membership.
"In the open source community, your value is what you contribute," said one engineer at a large university who asked to remain anonymous. "This leaves us at a choke point."
OpenFlow protocol productized too early and without enough contribution?
Engineers who are concerned by a lack of diverse participation in the ONF are worried about the foundation's push for swift productization and commercialization of OpenFlow. A number of the vendors who have joined the ONF have released OpenFlow-friendly switches and other related technologies.
"OpenFlow was productized too fast," said an engineer at a large university lab who requested anonymity. The release of commercial products based on OpenFlow version1.1, which didn't yet support IPv6 and had a number of other security and Quality of Service problems, is evidence of premature products, the engineer said.
Releasing a commercial product based upon a "sub-optimal API that is not production-ready" could hamper OpenFlow SDN adoption, said Eric Johnson, CEO of San Jose, Calif.-based SDN firm Adara Networks. A wider range of input from across the community in the ONF might have stopped this from occurring, he added.
"You can't take beta code and sell it and say you're behind moving the standard forward -- that's not a real OpenFlow implementation," Johnson said. "In that case, the standard will suffer and the market will gravitate to APIs that Cisco and Alcatel-Lucent (for example) are creating."
The ONF fee is not as prohibitive to a company like Adara, which makes other enterprise infrastructure and security technology, but it is for those with limited resources. Yet, SDN startups and academic research institutions have gone the furthest in testing OpenFlow interoperability and tackling severe technical problems that still exist in the protocol, Johnson said. Their contribution is crucial for development of the specification. "These are the companies and organizations that you want embracing OpenFlow," he added.
ONF: High fee ensures serious commitment by community
Dan Pitt, ONF executive director, said the fees pay the bills at the foundation, but just as importantly, they limit participation to only those who are "seriously committed" to commercially productizing OpenFlow and seeing it implemented in enterprise and operator networks.
"There are those who want to say this is only a research exercise and not commercially real -- and that's why we are de-emphasizing the research origins,"Pitt said. The standard is "written by people who need to build this stuff and implement it," he said.
More on OpenFlow development
Can OpenFlow research be truly open when it's vendor-funded?
OpenFlow and SDN for the campus LAN?
FlowVisor offers path toward network virtualization
OpenFlow emerged from research at Stanford University that was led by Nicira founder Martin Casado and a team of now-renown engineers, including Nick McKeown, who has been heavily involved in the ONF and the underpinnings of the OpenFlow standard. At first, OpenFlow was published on an open website called OpenFlow.org, but the ONF took over development when it was in version 1.1 and has since published OpenFlow version 1.2 and approved OpenFlow 1.3.
The ONF's membership is now consistently growing and includes many SDN startups, but several engineers interviewed for this story speculated that a few key vendors are injecting their own agendas into much of the work done by the foundation. One engineer pointed to VMware, Cisco and Big Switch as the driving forces.
"What the community needs is a consortium of people in control of a transparent protocol where vendors have input, but they don't control it," said a university network engineer, who asked to remain anonymous.
Adara's Johnson, on the other hand, pointed directly to VMware as pushing the ONF agenda.
"A lot of what the ONF is focused on is driven by VMware as a result of the Nicira acquisition," he said. Johnson is also troubled by the idea that many companies with proprietary SDN and network virtualization platforms, including VMware and Cisco, are so heavily involved in the development of an open source protocol.
Pitt, however, has long maintained that the ONF's mission is to avoid allowing vendors -- namely Cisco -- from calling the shots. Vendor dominance can hamper innovation or push proprietary strategies, he has said. In previous interviews, Pitt has even quipped about the ONF not becoming the next IETF. Many say the IETF's agenda has been driven by Cisco over the years.
Research engineers run huge OpenFlow networks, but have second-hand ONF input
Vendors that are heavily involved with the ONF have worked closely with engineers at R&E labs on both product development and interoperability testing. As a result, these universities are sometimes the first to put the technology into their production campus and data center networks.
Research engineers have been able to contribute to the ONF's work through these vendor partnerships by sending recommendations through their corporate liaisons. But recently at the TIP 2013 conference in Honolulu, a number of R&E engineers expressed frustration with what one engineer called "filtered" participation.
There are those who want to say this is only a research exercise and not commercially real -- and that's why we are de-emphasizing the research origins.
executive director, Open Networking Foundation
"This is sort of a ghetto way" of participating, said a university engineer, who asked to remain anonymous.
This type of participation really falls apart if the vendor doesn't agree with the findings of the research engineers -- or, worse, if they believe those recommendations could limit their own commercial product plans.
"These guys may not like what we want, so they don't propose it," the engineer said.
Outside of these corporate partnerships, research institutions have implemented wide-scale OpenFlow projects. Internet2, for example, has built a global 100 GbE OpenFlow network that connects R&E institutions and will enable them to do massive big data transfers for scientific research and collaboration.
Internet2 didn't comment on the ONF fees, but sent an email saying, "We have a great relationship with the ONF and understand that they are doing a lot of things to expand their support for Academic and Research organizations, which we support."
The ONF has a program for academic associates who don't pay dues but do have full participation rights, Pitt said. The membership is given to individual researchers (not their institutions), and four members from Stanford, Princeton, Indiana University and University of Maryland have joined. The program will expand to allow independent research laboratories to be part of the mix with universities, but Pitt did not say how many spots the ONF would add.
Lack of access to information to OpenFlow protocol development just as troubling
Beyond contributing to the standard, engineers want more information about OpenFlow protocol development. They are reluctant to invest in the technology without this information.
"I am looking at buying hardware and there is all this information, yet I can't get access to any of it," said one university engineer, who is currently researching the technology for his production environment. "If I am spending a million dollars, but there are engineers sitting on this information, that's not good."
Pitt pointed out that the ONF has been very forthcoming with publishing information from its working groups and board. The foundation's key mission, he said, is circulating updated OpenFlow information to those who are developing and implementing the technology.
Yet, the engineer who is researching technology for his production environment said there is a severe lack of documentation and implementation blue prints available at this time.
The ONF will hold its annual summit this April in Santa Clara, Calif.