The OpenFlow protocol for software-defined networking has been around for several years and despite vendor adoption and some deployments, has yet to become the pervasive SDN standard many in the industry expected.
OpenFlow's challenges and its future were a topic of discussion during a panel keynote at the OpenDaylight Summit, held this week in Santa Clara, Calif. OpenDaylight Executive Director Neela Jacques raised the issue, telling the panel of SDN experts that he gets a lot of questions about OpenFlow and hears talk of other protocols used for SDN, such as BGP.
Justin Pettit, a lead developer on the Open vSwitch (OVS) project who was involved in the creation of OpenFlow at Stanford University, said OVS is a big OpenFlow user. "The reason why people are asking questions is because the specification itself has some difficulties," he said.
OpenFlow tries to program both software and hardware switches, but ran into problems in programming hardware, said Pettit, a VMware engineer. OVS plans to continue to use OpenFlow, he added.
Dan Pitt, executive director of the Open Networking Foundation, which manages OpenFlow, said with version 1.1 of the protocol, it became harder to implement OpenFlow in merchant silicon for hardware switches. But a demonstration of the ONF's Atrium software distribution, which was released in June, included white-box switches running OpenFlow 1.3, he noted.
He said OpenFlow presents interoperability challenges because it has so many features. ONF has worked to address the problem by mining work from the Ryu open source SDN framework in order to test switches for compatibility. Still, while there are a lot of OpenFlow deployments, they're typically not multi-vendor, Pitt said.
While some have criticized OpenFlow for a lack of scalability, Pitt said he doesn't understand that in light of large OpenFlow deployments such as Google's.
Guru Parulkar, executive director of the Open Networking Lab (ON.lab) and the Open Networking Research Center, said while OpenFlow may not be perfect, he hopes the industry doesn't return to a world of proprietary boxes. Calling that "a dangerous path," he said the industry should remain focused on separating network control and forwarding functions.
After the panel, I asked additional networking experts about their thoughts on OpenFlow. Tom Hollingsworth, a network engineer and blogger, said in an email, "It really feels like OpenFlow is headed down the same path as TRILL."
"Vendors bake in certain 'enhancements' that don't port between each other. That causes lock-in," he added. "Lock-in prevents widespread interoperability when you can't pick up OF-compatible gear cheap."
Dan Conde, an analyst at Enterprise Strategy Group, said he believes many OpenFlow-based controllers work best with a single family of switches.
Vendors like HP support OpenFlow, but "use it for specific exceptions or policy decisions, and classic packet forwarding is handled with a traditional method, not OpenFlow," he said in an email. "So what this means is that 'being OpenFlow compatible' [varies] from vendor to vendor."
Hollingsworth said OpenFlow still might succeed if ONF and OpenFlow proponents are willing to create a reference software switch platform and force hardware vendors to keep on top of enhancements.
Subsea cable alternatives can provide a level of comfort for those concerned about disruptions. Realistically, they will continue to play a small, but critical role in the short term.
Maintaining existing network infrastructures often incurs huge technical debt before newer technologies are adopted over time.
Amid ongoing regional uncertainties, telecom infrastructure in the Middle East has expand to include terrestrial low-latency network infrastructure, which offers resilience and agility in navigating political complexities without relying solely on undersea networks.
