CenturionStudio.it - Fotolia
Cisco is pushing its network policy abstraction language into OpenStack and hoping the community embraces it.
The Group-Based Policy (GBP) language is part of the OpenStack Juno release that was unveiled in late October in time for the OpenStack Summit going on this week in Paris.
GBP lets developers request network resources for specific applications without having to worry about underlying infrastructure details. It essentially groups network endpoints together and then applies policy to resource pools.
"The idea [behind GBP] is to capture the intent of what the application developer wanted and to let them model their application in abstract terms without worrying about performance routing," said Cisco product manager Mike Cohen, who leads the company's open source policy-based solutions.
In an OpenStack environment, there would be a policy repository and the orchestrator would push those rules to distributed controllers that manage distinct network tenants for applications.
That kind of application-centric policy enforcement is central to Cisco's ACI technology, but through OpenStack it could be applied to multivendor networks.
Once the policy abstraction layer and language are standardized, vendors could differentiate how they use that within their systems.
"Then it comes down to, do we do a better job of prioritization?" said Jeff Reed, vice president of enterprise networking at Cisco. "The way we think about it for ACI is that we've built an interesting back end [that is the] underlying infrastructure for policy."
ACG Research analyst Paul Parker-Johnson says it's "clearly a bit self-serving" for Cisco to push its policy enforcement language into OpenStack, yet "it's only one dimension of policy application in a deployment scope as large as OpenStack. Additional aspects of policies could be addressed by contributors in different ways."
There's also no denying the importance of a standardized way to apply application-aware policy to networking.
"The user and customer community at large gain the benefit via enhancement of Neutron and OpenStack with use of policies in a manner that aligns network deployments with applications … and [they're] able to express those policy objectives in a consistent way whether the 'underlay' of network infrastructure is Arista's or Brocade's or Dell's or Big Switch's.”
Are Cisco and VMware set to duke it out in OpenStack?
VMware beat Cisco to the punch in contributing policy enforcement code to OpenStack with Congress, a declarative language for governance and regulatory compliance of cloud services. Cohen says Congress and GBP have very different goals.
"We actually think the projects work well together," said Cohen. "[VMware's] system was designed for domain-independent business language. The Group Based Policy project is more about enforcing a mechanism for user intent. We have a specific language that is domain dependent."
It's hard to determine whether there is overlap in the two approaches, but it's more notable that Cisco is much further down the road of application-aware network policy than VMware, said Peter Christy, a research director at 451 Research.
"What I've heard indirectly is that Cisco's use of policy has caused VMware to accelerate its internal policy [efforts]. VMware can't wait for Congress to come together," said Christy.
Why is Group-Based Policy in both OpenDaylight and OpenStack?
Cisco has already submitted GBP code to OpenDaylight, where it has worked with a coalition of vendors to use the language through the open source controller.
But there are fundamental differences in the way GBP will be used in OpenDaylight versus OpenStack.
"The discussion in OpenDaylight is, 'How do you apply policy as a way of simplifying device management," Christy said. In OpenDaylight, GBP can be used to address groups of network devices in a common way.
Meanwhile, "policy in orchestration is a much bigger issue," said Christy. In the case of implementing NFV, for example, engineers aren't as concerned with managing specific devices as they are with looking at all of the connections and service levels committed to providing those functions. In that case, policy has to be applied across multiple elements, taking into consideration user experience.
"The policy management becomes a way to look at the commitments you're making," said Christy.
Why is Cisco suddenly so interested in open source networking?
Cisco doesn't exactly have a history as a big open source player, so why the push into OpenStack?
Certainly, Cisco is interested in "defending its position" in the cloud, said Christy, but it also has the same vested interest in the community that many have -- no one wants to see the cloud controlled by a couple of services like AWS or Azure, he said.
But Cisco is also personally invested in using OpenStack for its internal cloud, as well as for its InterCloud Fabric technology.
"They are doing this to avoid being dependent on VMware and EMC, which are not friendly [partners] at this point," said Christy.
What's more, taking nascent technology to a standards body doesn't necessarily make sense, Cohen said.
"Open source is the new place for standards for technology where there are not yet standard bodies," said Cohen. Cisco wants to see the code in action and is interested in what gets upstreamed by the community, he said.
OpenStack Neutron has issues
Can OpenStack networking scale?
Is OpenStack a real alternative to a commercial cloud stack?