Software will transform the network of tomorrow into an open, multi-vendor, programmable environment, but that...
By submitting your email address, you agree to receive emails regarding relevant topic offers from TechTarget and its partners. You can withdraw your consent at any time. Contact TechTarget at 275 Grove Street, Newton, MA.
software-defined network won't necessarily rely on a centralized OpenFlow controller architecture, said David Meyer, Brocade's CTO of the service provider business.
In fact, OpenFlow was "prematurely productized," he said during a talk this week on macro networking trends at the Techs in Paradise (TIP) 2013 conference, sponsored by Internet2, ESNet and the Asia Pacific Advanced Network in Honolulu.
"OpenFlow 1.0 was not very feature-full, there wasn't the functionality [necessary] … It was great for research, but we are struggling with all kinds of aspects of the protocol itself," Meyer said. As one example, Meyer pointed to flow table matching problems where information is lost when a controller is communicating to a switch or vice versa.
Brocade offers OpenFlow-friendly routers, which have been implemented in the Internet2 100 Gb network that connects hundreds of research and education (R&E) institutions. The average engineer at this conference would readily admit that OpenFlow is exciting for research and is even solving some isolated problems in their networks, but it is a ways off from being production-ready. Some are working to fix problems, for example, where controllers continue to send packets even when a link is down; others are looking to create controller failover.
OpenFlow 1.3, which was approved last spring, will address many of the issues these engineers have encountered. But the bottom line is, there still needs to be lots of OpenFlow testing and an environment in which engineers are free to "break" the network and then find fixes. During a conversation after his session, Meyer said he wonders if swift product releases are hampering that innovation.
"We need to try ideas … and build a culture where failure is not frowned upon," Meyer said. We won't know what the feature of the future is until we build a "technical, intellectual and cultural environment that enables agility," he said.
Are centralized controllers too radical of an approach?
But OpenFlow as a language is not the only challenge Meyer sees in software-defined networking (SDN). Generally engineers rave about OpenFlow's potential to be the underlying communication language in an environment where they can abstract and centralize the control plane of the network with direct reach into the forwarding plane. But Meyers said that's only one of many potential architectures. In fact, centralizing the control plane is one radical end of the network programmability "continuum," he said. At the other end of that spectrum is the Nicira approach, which places a software overlay on top of the physical infrastructure with its own control plane and isn't "at all concerned with the under path," he said.
Vendors push back on OpenFlow SDN
Juniper's SDN strategy: Partially centralized control
Why Nicira abandoned OpenFlow hardware control
Cisco SDN response: Programmable networks, not OpenFlow
Software-defined networking is not OpenFlow, companies proclaim
Then there is a middle-ground approach that "allows programmability in the existing control plane." For example, the IETF I2RS (Interface to the Routing System) working group is developing a framework that gives indirect access to the forwarding plane to provide programmability, Meyer said. Cisco has said it will unveil an SDN strategy that works within its existing control plane structure. Other vendors, like Brocade, have said they will support hybrid OpenFlow networks that enable engineers to run both OpenFlow and use their existing control plane architectures.
The ultimate outcome will probably be some combination of these approaches, Meyer said – and he's not concerned with which one it will be. The real magic to SDN will be in creating an environment that offers complete open APIs and allows any hardware or software vendor to plug-and-play and to create a software environment that can be integrated across network, compute and storage, for complete orchestration.
That will take a "common language" that can speak to a switch, storage array or compute element and then "use a common infrastructure to manage all of that," Meyer said. OpenFlow may not cut it as that common language, he said.
More challenging, that type of environment will also mean a "de-siloing" of IT and vendor willingness to open their hardware and software. Vendors "cringe" at both of those concepts, Meyer said.
"Vendors don't like ecosystems, they like to own end to end."