The grass roots OpenConfig effort, in which large carriers and Google are applying intent-driven policy to the management of huge networks, is gearing up for prime time after just six months of work.

It's already live at Google, where it's being used to express configuration on Google-designed equipment in a part of the network, said Bikash Koley, principal network architect. His update on OpenConfig was the subject of his keynote at The New IP, an event put on by Light Reading today in San Jose.

By the end of the year, OpenConfig should also be in use in the part of Google's network built with vendor-provided gear, Koley said.

Carriers are playing with OpenConfig as well, as the code for configuring BGP routers — the first use case OpenConfig chose to tackle — is available on Github.

And major equipment vendors, which deliberately weren't included in OpenConfig's early meetings, have committed to supporting OpenConfig in their devices by the middle of this year, Koley said. (That support would be for use in carrier labs, not for live deployment.)

That's a lot of progress considering OpenConfig has only been working in earnest for about six months.

"This whole initiative had no paperwork, no lawyers involved, no papers signed — actual engineers working on actual code," Koley said. "We have waited for a long time for the network management plane, which interestingly is one of the most critical parts of the networking structure that has been neglected for years, ... to come to the model age."

OpenConfig addresses network configuration, a not-so-glamorous area that's become a bottleneck for large operators. Google convened large carriers beginning last summer and fall to see if they could find a solution. It was completely informal, organized via email list and weekly calls.

They wanted to do for network management what software-defined networking (SDN) is doing for the network, in the sense that they create an abstraction that would let them avoid having to configure individual devices on the network.

It's not a purely Google-based effort, although Google and Koley seem to be the instigators. The group also includes AT&T, BT, Comcast, Cox, Facebook, Level 3, Microsoft, and Verizon.

Add up those names, and you've got a very big percentage of the Internet backbone, Koley noted.

Every network is different, but Google had a hunch that every operator was performing a lot of the same activities. The heart of OpenConfig is the ability to build models around these everyday networking steps.

"What we found out when we started talking to each other was that our needs are very similar," Koley said. The assumption had always been that the networks were too different to make a common model possible. "We wanted to bust that myth."

OpenConfig is not meant to bypass standards bodies altogether. But it is an effort to move faster than your typical standards group. Like an open source project, OpenConfig aims to get code out quickly. Later, that fully baked code can be taken to a group like the IETF or the OpenDaylight Project as a head start toward a standard.

OpenConfig uses an intent-driven model. That is, the operator states the way the network ought to behave, without getting involved in the configuration of any specific network elements.

That's where the vendors get involved. They'll need to provide a translation layer to turn operator intention into port-by-port configuration of the router, switch, transport box, or whatever network element is involved.

As often happens, one of the least glamorous aspects of this whole process is one of the most crucial. It's telemetry, the mechanism that lets the network tell the operator what is actually happening, Koley said. Without it, you have no way of knowing whether your intent actually got implemented.

Well, there is a way; operators scrape information from routers — essentially looking up every port. That doesn't scale any more, not in huge networks with routers that have 1,000 ports each, Koley said.

What's needed instead is a form of streaming telemetry, where the operator can check if the network is behaving as expected. If it turns out something is wrong, you might have to do some exploration to figure out which port is at fault, but overall, this method would be more feasible at large scale, compared with port scraping.

So, finding ways to provide that telemetry is part of the OpenConfig charter. Telemetry is hard to do, but "at this scale, you cannot consume CPU cycles by just processing state data. That has to change," Koley said.