This article is more than 1 year old

People don't want big OpenFlow deployments, so let's do small ones

Eating an elephant slice by slice is much easier than eating the whole thing

OpenFlow looks like it has all the hallmarks of inevitable success: it fits into a broad stack of open networking protocols, it has lots of vendor support, it's backed by the Linux Foundation, and it's been under development since 2009.

All that remains is users, which are rather hard to find. Might that change if the project considered smaller deployments? In an interview with The Register's networking desk, Brocade's global solutions architect, Pete Moyer suggested smaller users are the way to get the train moving again.

“OpenFlow has been around three to five years, so it's fair to ask where are all the deployments?” Moyer said from New Zealand, where he attended the APRICOT 2016 chatfest.

The community needs to expand OpenFlow's use-cases, he argued. “We need to look at specific operational problems,” he explained.

“Rather than thinking of it as a next generation networking protocol, think of it as a networking tool – a collection of ways to solve specific problems.”

That works against how most “software defined X” protocols are pitched, but he reckons it's worth demonstrating to businesses they can get value out of OpenFlow without upending their entire network.

“Take DDoS mitigation, for example”, he said. “You can push a rule from a controller into a network switch, and it can say: 'if you NTP see flows over a certain capacity, assume it's an NTP DDoS attack, and discard it.'”

That relieves the load from firewalls, because it's a happening in the switch – “all in the hardware, and at line rate”.

“If you throw away those packets at the ingress of the network, then you don't have to ask the appliance to do it,” he continued. “You're no longer bothering the firewall with packets that are going to be thrown away anyway.”

That, he argued, offers a payback that's fairly easy to demonstrate to the business, because there's less money spent on firewall horsepower.

Another example Moyer cited is using OpenFlow – instead of mirror-ports on a switch – to copy a flow for analytics capture.

“For example, send VoIP flows for application analysis and storage analysis.

“If you're trying to pick out particular flows, it can get very complex and manual,” he explained. “A “span-port” inside a device will capture everything, and then you have to filter it.

“If the switch only knows how to switch everything then you need to do a lot of work. But OpenFlow can automate this in real time.”

Both examples fit in what the protocol calls a “normal action”, and Moyer pointed out that OpenFlow rules are familiar to sysadmins, because they look very much like access control lists – “if it matches this, do this”.

In both cases, he argues, the ability to apply specific actions very simply in OpenFlow makes the case for the protocol to be deployed to specific use-cases rather than as a “big bang” upgrade.

There's also an opportunity for vendors, he said, to create OpenFlow-based offerings that look more like point solutions (something Brocade has done with its Flow Optimiser).

“You can provide solutions where you can say 'match on this flow, copy on this flow, and forward it based on IP routing'. That action doesn't interrupt the flow forwarding.

“The 'normal action' has been in OpenFlow for many years, but there aren't many people exposing what it's capable of,” he said.

Now that the industry is learning the attraction to a more incremental deployment, Moyer said, the next step is teaching customers they can avoid the “big bang”. ®

More about

More about

More about


Send us news

Other stories you might like