News Stay informed about the latest enterprise technology news and product updates.

ONUG: IT users want to shape vendor SDN, network programmability strategy

At the Open Networking User Group meeting next week, IT execs will tell vendors what they want from SDN and network programmability; will they listen?

Next week, a group of IT executives from mega companies like Bank of America and CitiGroup will gather in New York City to shape the way network vendors develop and sell SDN and network programmability.

The executives are members of the Open Networking Users Group (ONUG), an organization that provides a forum for networking superusers to brainstorm how they might use SDN and programmable networks. Next week, these members will discuss a wide array of use cases and even vote to prioritize the SDN applications they need most. A host of vendors, including Cisco, Hewlett-Packard, IBM, Juniper, Nuage, Arista and Big Switch, will also attend the meeting to discover what these heavy hitters are actually willing to pay for.

Essentially, ONUG members will tell the likes of Cisco how they want to design networks, instead of being told how proprietary hardware and software will shape their network architectures. For many years, network engineers have been limited by proprietary network operating systems in how they could design -- and even manage -- their infrastructure. As a result, for example, the network cannot be as flexible as the virtual environments it serves and it can take days, if not weeks, to make minor changes.  "It has been 25 years since we've actually designed a network; it's an odd thing," said ONUG co-founder Nick Lippis, who also produces the Lippis Report. Open networks should provide users with a choice in how they design their networks and program [their] infrastructure, he said.

Lippis defined open networking as a technology "that delivers a separation of hardware and software" and uses "open interfaces" that let users closely program and customize their networks.

Open networks could involve an OpenFlow-based SDN architecture that decouples the control plane from switches and routers and places it in a central controller. It could also refer to network virtualization and overlays that are managed by network hypervisors, lying on top of a physical network of white box switches. For that matter, it might involve vendors providing hybrid switches that use both merchant silicon and proprietary ASICs.

"What the market wants is choice," Lippis said. "It's not about knocking one vendor down for another. They want innovation and they don't care where it comes from. If Cisco can innovate faster than a startup or Juniper, so be it."

Currently vendors are in "an arms race for innovation" and it behooves them to listen to what users actually need, he explained.

What do superusers want from SDN and network programmability?

The ONUG board, made up of execs from Bank of America, CitiGroup, Gap Inc., UBS, Fidelity Investments and JP Morgan, prepared for next week's ONUG summit by meeting with the Open Networking Foundation, OpenDaylight and OpenStack, all organizations that are involved with planning SDN standards and models.

Then board members spent the afternoon taking an initial stab at prioritizing SDN and programmable network use cases. It became swiftly apparent, according to Lippis, that ONUG members are looking to use SDN and programmability beyond the data center where most of the market has so far been focused.

More on the new network programmability

What Facebook's open source switch will mean to SDN

Open APIs are great, but vendors should take more responsibility

In the programmable WAN, applications are boss

How are Path Computational Element and SDN connected?

"The bottom line is that the market wants a much broader approach to open networking," Lippis said. "Open networking needs to be deployed in the data center, the wide area network, the campus environment."

Board members talked about the need for a "declarative language" that they could be used to express application dependencies on network topology. With this language, enterprises could automate workloads by more easily linking them to underlying storage, compute and network needs.

"Since we are moving into a model of automated workload creation, enterprises want to do what you can do in Amazon [Web Services] -- put up a workload and configure storage and network [and] the whole cloud infrastructure. But they can't because … they need a way in which a dependency map gets created automatically," Lippis said.

The ideal answer would be to have a language like JSON or XMPP that can be shared across IT siloes so that when a problem arises, there can be a "cross-domain response" to troubleshooting, he explained.

But that's only one example of a lack of the right software written for programmable networks.

"What's missing in this marketplace is a software ecosystem," Lippis said. "There is all this middleware that's not there yet and needs to be put in place." This middleware could let applications call upon the network for resources, and allow DevOps and NetOps apps to better see what's occurring in the network.

Next week ONUG will further detail the prioritized SDN and network programmability use cases.

Dig Deeper on Software-defined networking

Join the conversation

1 comment

Send me notifications when other members comment.

Please create a username to comment.

Nick is right that we need to be able to orchestrate workloads across multiple IT silos. The question becomes one of state management (where configuration is just one aspect).

What is the common data model to use to describe application workloads? How is that description translated into device-specific behavior? Who acts as the source of truth?

The role of the controller will be important here. But if workloads are truly orchestrated, which controller are we talking about? Most of the SDN controllers have a uniquely networking slant. How does a network controller talk to a storage controller in this world?

It's great to see users raising the right sets of questions. It will be interesting to see how this plays out over the next few years.

-Mike Bushong (@mbushong)