Calling the industry out on its stretched definitions of "open" networking, the IT heads and CIOs that make up the Open Networking User Group (ONUG) are setting their own definition of "open" in stone, in a white paper being released today. (UPDATE: It's available here; link wasn't active at press time.)

In a way, it's a manifesto demanding an end to vendor lock-in. ONUG isn't saying all products should commoditize, but the users want base standards to be set in stone to guarantee interchangeability — which is usually what users really want when they talk about "open" technologies.

ONUG has been telling these things to the vendors directly, but the white paper gives them a consistent argument to point to. It also can serve as a recruiting tool for ONUG. The group started off with high-end users — financial firms first, and now a wider demographic that includes the likes of FedEx and Pfizer — and wants to spread its membership even further.

To quote directly from the white paper, here's what ONUG expects open networking to deliver:

• In the short term, a lower operational cost model (opex) on the order of 15 to 30 percent relief; longer term, a new definition of network opex based on real vendor support cost, rather than a fixed percentage of capital cost
• Capital expense or capex cost relief on the order of 25 to 75 percent
• A thriving software ecosystem which provides rapid innovation
• Vendor-independent network design flexibility (eliminate vendor lock-in)
• Faster IT delivery and efficient business processes

ONUG also wants to see vendors share common approaches to elements such as controllers, policy management, and the communication of network state. Everyone has to talk freely with everyone else, in other words.

And what would ONUG do if vendors decided not to listen? "Collectively hold back spending, is what they can do," says Nick Lippis, the consultant who helped create ONUG. He thinks some of these users are willing to squeeze what they can out of today's networks before committing to an SDN or network virtualization vision that's insufficiently open.

It shouldn't come to that, though. ONUG has given vendors access to the IT experts within big customers — access that's not always made available. "The vendors do want to sell stuff that people want to buy, so they're very engaged," Lippis says.

The white paper also discusses ONUG's first three working groups, representing the three use cases that members most wanted to see brought to life: overlay networks, the software-defined WAN, and network services virtualization.

The writers discuss what they don't like about each area, and they don't mince words. "They're really critical about what's broken," Lippis says.

For instance, the white paper complains about the number of tunneling protocols available for overlays, including Geneve, which might alleviate the problem but is, indeed, another protocol. The white paper is specifically critical of VXLAN, the frontrunner, because of its use of multicast. "Both the user and vendor communities agree this mechanism as defined in the standard is a non-starter," the ONUG paper states.

Note that the third use case is "network services virtualization" and not network functions virtualization (NFV). The latter is being well defined, but it's intended for the service-provider realm. ONUG members, many of them large banks and pharmaceutical companies, are interested in the enterprise analogue — a way to run services purely in software without having any hardware appliance sitting in a branch office or a data center.

The working groups came about as the result of ONUG voting in May, and they kicked off this week.

Among the nine working-group candidates listed on ONUG's web site, a shared policy management framework finished last. But policy seems it would be a useful working group to create when ONUG re-convenes in October, given how much attention policy-based networking is receiving (much of it, admittedly, because Cisco based its SDN architecture around it).

A working group on policy would share space with at least three other efforts: the group-policy initiatives in OpenStack Neutron and the OpenDaylight Project, and the separate OpenStack Congress project to define policy-as-a-service.

Despite all that activity, ONUG would have something to contribute to policy, Lippis says. "Remember, [those initiatives] are all vendor-led, not IT-executive-led," he says.