Engineer wish list: SDN companies must work together, embrace openness

Network engineers tell SDN companies to pursue a common vision for networking, embrace OpenFlow and commit to openness.

In some ways, SDN is kind of like Google+. Everyone has heard of it but no one is really using it.

But that will change soon. After all, a lot of smart people are excited about SDN, and plenty of vendors are pouring resources into it. Although most network engineers remain on the sidelines waiting for the right SDN strategy to evolve, they are watching closely. With that in mind, SearchSDN asked a bunch of engineers what they want to see from SDN companies in 2014.

We need a cohesive vision and cross-platform support from SDN companies

In 2014, network engineers would like to see the market get serious about finding a common vision for SDN.

When a new wave of technology hits, vendors fight for dominance. Usually, competition sorts things out and one platform emerges supreme -- Ethernet and Blu-ray are examples of that. But with SDN, some engineers worry that the survival-of-the-fittest process may take too long.

"It's not unusual for the industry to throw out a bunch of offerings. Different vendors come out with their own solutions, and hopefully one vendor wins and everyone designs to that," said Joe Rogers, senior network engineer at the University of South Florida. "It's just that SDN is really nebulous. It can mean so many different things to many people. I think it's really hard to get the industry to stabilize on some underlying infrastructure that can support the different things that people want to do. I'm not sure with this one how long that's going to take to shake out. I hope it's sooner rather than later."

Rogers' data center networks are due for a refresh, but he's hesitant to commit to a new physical network layer due to all the flux around SDN.

"Everybody's got their own idea of what the next-generation, software-defined data center should look like, and it's just really difficult from a customer perspective to see how all these different offerings are going to interact," Rogers said. "[It's] difficult to look in the crystal ball and pick the right products. It's hard to get a consistent vision from all the vendors."

The most prominent example of all this uncertainty is the cold war that has evolved between VMware Inc. and Cisco, perhaps the two most influential vendors in the SDN world today. Cisco and VMware have been pulling away from each other ever since VMware bought network virtualization startup Nicira for $1.2 billion last year. Now, Cisco and VMware have starkly different approaches to SDN -- one that is completely software-driven, while the other is hardware-centric -- and the two are building partner ecosystems in opposite directions.

VMware and Cisco need to find a way to be "on the same page," said Teren Bryson, IT director for an industrial equipment manufacturer. "They're trying to play nice and pretend it's all fine and that they're not going in different directions. But they really are. So long as the market is fragmented and there is not any one standard, I'll keep buying the technology I'm comfortable with. I'm not going to jump into the SDN thing until there is a clear path forward."

SDN won't take off until a victor is declared in the conflict between Cisco and VMware, Bryson said. "I don't think that's going to happen in 2014, but it would be ideal. You have to have some form of tacit cooperation between those guys,” he said.

Just a few years ago, infrastructure vendors were far more cooperative, he said. A data center operator could plug Cisco networking together with HP servers, VMware hypervisors and EMC or NetApp storage. "Everything had a plug-in and parts you could mix and match. Now, that is sort of coming apart a little bit as [vendors] start stomping into [each other's] territory."

What engineers ultimately want from a common SDN vision is better cross-platform support and vendor interoperability for SDN products, said Nick Buraglio, a network engineer who works for an international research network.

"If your SDN strategy doesn't work with [other vendors], then it's probably an edge case," he said. "I'm not a fan of 'We sell the entire widget-turnkey solutions.' I like things you can put together and build whatever you want out of it."

Programmatic access to network gear is long overdue

Less enthusiastic observers of SDN claim there are very few practical use cases for the technology. Even engineers who see the technology's merits agree that much of SDN is still focused more on technological innovation than solving real business problems. But one aspect of SDN that no one can deny as being immediately useful is programmatic access to network infrastructure.

"At this point, 70% or maybe 80% of what's out there is really SDN for SDN's sake," Bryson said. "I think the biggest thing that's come out of this SDN movement -- and this applies to the entire IT world -- is programmatic access to everything."

Read what network engineers want
beyond SDN

Network engineer technology wish list

Bryson would like to see SDN push all vendors to offer more programmatic access to infrastructure so that enterprises can spin up new services quickly without having to hire expensive experts to get the job done.

Bryson recently looked at a software development kit for a NetApp storage platform and discovered that the most recent files for the kit were eight years old. "There was almost no documentation and there were a limited number of APIs [application programming interfaces] available. Everything was locked down and pre-compiled so you couldn't do certain things. I'd like to see that improved."

There is also no reason why vendors can't improve programmatic access to their installed products.

"Why do I have to upgrade my entire infrastructure to get programmatic access to [Cisco's] onePK? Why can't a software revision come out that addresses that? I know why; because if they put that capability into older switches and an older operating system, that will extend the life of those devices and people won't buy new devices," Bryson said.

Don't forget about OpenFlow

Cisco's Application Centric Infrastructure and VMware's NSX network virtualization platform may be two of the most prominent SDN technologies out there today, but neither of them has much use for OpenFlow. That's a problem, according to engineers. Vendors have to support OpenFlow more in 2014 because it's the only cross-platform protocol out there, and it's come a long way, Buraglio said.

"I think that OpenFlow 1.0 was great as a proof of concept, but I don't think it is a production-ready protocol, simply because it is limited to IPv4," he said. "Version 1.3 is OpenFlow's big-boy pants."

OpenFlow 1.3 has multitable support, IPv6 and multiprotocol label switching -- "basic networking stuff that has to be supported before anyone will take it seriously," he continued.

"Right now there might be limitations in [OpenFlow] hardware, but I think that will change over time. As far as making [SDN products] work together, I think that's where OpenFlow comes in. It's the BGP [Border Gateway Protocol] of the SDN world."

OpenDaylight needs to shine

While Cisco and VMware pull away from each other, another project that both vendors have ties to might pull them back together. The open source OpenDaylight project has an opportunity in 2014 to establish an SDN framework that multiple vendors can build products around. Cisco and many of its competitors have devoted significant resources to the project, which will release its first code in 2014.

"Vendors have actually committed to it. I'm already convinced it's going to work," Buraglio said. "I want to see a shipping version of the [OpenDaylight] controller that works with OpenFlow 1.3 and the hardware I've got out there. The last time I pulled down the code, two weeks ago, they were very close."

Dig deeper on SDN companies

Pro+

Features

Enjoy the benefits of Pro+ membership, learn more and join.

0 comments

Oldest 

Forgot Password?

No problem! Submit your e-mail address below. We'll send you an email containing your password.

Your password has been sent to:

SearchNetworking

SearchEnterpriseWAN

SearchCloudProvider

SearchUnifiedCommunications

SearchSecurity

SearchDataCenter

Close