IP protocols/software

Google, AT&T, BT Unite on Network Data Models

An initial informal collaboration of two web giants, Google and Microsoft, along with major telecom players AT&T and BT, has produced a key network data model for next-generation packet networks, starting with a specifications for BGP (border gateway protocol), which plays an essential role in routing traffic across IP networks.

The companies have produced a vendor-neutral Yang model called BGP Configuration Model for Service Provider Networks, which focuses initially on BGP base protocol configuration and policy configuration. Now the group is ready to tackle MPLS with a wider base of participants.

The new model was presented in draft form to the Internet Engineering Task Force (IETF) at its meeting in Honolulu last week, and could see implementations commercially next year, according to Bikash Koley, principal architect and manager of network architecture at Google (Nasdaq: GOOG), which is already implementing the new model internally.

Working informally as a group through a GitHub-based open source process -- the code is here, but available on an invite-only basis -- the quartet started with a Google working draft to which all four participants contributed significantly during the past several months. Their goal was enabling a vendor-neutral approach for network operators to manage BGP configuration in multi-vendor networks, something that would allow network operators to mix and match routing hardware and software systems from multiple sources without enduring lengthy integration efforts.

That's something that will become increasingly important as operators look to build networks using SDN and NFV capabilities. One of the main reasons network operators are keen on SDN and NFV adoption is that it should enable them to break free of vendor lock-in, but the full benefits of such freedom can only be realized if it is easy to plan and deploy networks using hardware and software from multiple best-of-breed suppliers.

The OpenConfig workgroup -- an invitation-only group found here -- deliberately chose BGP as a starting point because "we thought it would be hardest and most complex to pull off," says Koley. But the group was able to create results in a matter of months, speeding the process of standardization and getting to an implementation point quite quickly even ahead of a standards process, he notes.

A snapshot of the current OpenConfig data models is also publicly available in the YangModels Github repository here.

AT&T Inc. (NYSE: T), BT Group plc (NYSE: BT; London: BTA) and Microsoft Corp. (Nasdaq: MSFT) were equal contributors, he notes, and he credits those efforts with enabling this early success. Moving forward, other companies including Comcast Corp. (Nasdaq: CMCSA, CMCSK), Verizon Communications Inc. (NYSE: VZ) and Yahoo Inc. (Nasdaq: YHOO) are joining the efforts to address MPLS in a multi-vendor protocol fashion.

This industry-wide initiative is something Koley had publicly sought when he delivered a keynote address last summer at Light Reading's Big Telecom Event, admitting that Google needed help in advancing what it sees as key network data models. (See Google to Open Key Network Models for Industry Comment, Standardization.)

Light Reading's Ethernet/IP section always has the latest new on developments in routing, IP protocols, Ethernet standards and more.

"The momentum has been very impressive. Starting from essentially nothing, just a Google model, to build on top of, to having an IETF draft with four major carriers contributing to the model actively, is impressive," Koley says. "The key here is that all of them actually contributed as much as Google."

The ultimate goal is to have this new data model natively supported in routing gear so network operators can choose their equipment based on its functionality and not be locked into one vendor because of the lack of compatibility among BGP deployments. By building the model from the operator perspective, the OpenConfig workgroup was able to focus on implementation and the real-world issues around that, Koley says.

BGP was considered the toughest technical challenge because of the wide diversity of use cases among operators and the concern that "you can't do something that is generic enough" to cover all operators, especially since the use cases are so different and are described and implemented in specific ways, he notes.

"What we are really proving here is that it is completely do-able -- the model we have come out with is actually quite elegant," Koley says. "The base model is quite concrete and comprehensive and covers all these use cases. It proves there is real value in doing this and you can come out with something that is very much multi-user and covers a wide swath of use cases."

Waiting for the standards process to accomplish this same goal would take much more time, which makes industry agreement on what becomes a de facto standard a better approach, according to the Google exec. He does credit the IETF and its committee chairs with supporting this process and expects to see even more widespread support going forward with the next focus on MPLS.

Vendor support is also ultimately important, as the vendors have to implement the data models being developed by the open source group. "We want them as part of this process," he says, but the standards themselves need to be operator-driven.

— Carol Wilson, Editor-at-Large, Light Reading

dwx 11/21/2014 | 2:53:59 PM
Re: Vendor buy-in? This is just a total guess on my part, but with the introduction of things like the vMX, CSR1000v, XRv, ALU vSR they have made their network operating systems run on commodity server hardware, sometimes in a very optimized way.

Why couldn't that be a commodity switch as well?  Juniper, Cisco, Arista, etc. both sell switches based off the same Broadcom chipsets as the white label vendors.   There is no reason why they couldn't make their OS available to run on those devices if they really wanted to.  The reality is the feature support and maturity of what Cisco and Juniper have is leagues above the open source options today or something like Cumulus.  

BTW Linux is the base operating system today for many of their platforms including their versions of the commodity switches.   Cisco even supports running Linux Containers on their Nexus 3K switches.  
sam masud 11/21/2014 | 2:34:14 PM
Re: Vendor buy-in? When you say Cisco/Juniper will "write the code controlling things like bare metal switches," were you also referring to the operating system? If so, would they then not have to fully get behind Linux?
dwx 11/21/2014 | 12:11:43 PM
Re: Vendor buy-in? I think in the end what you'll see is some of this work be merged with existing work from the vendors.  No one is really working on standard YANG models which do not interoperate across multiple vendors, that's the whole point.  

I did somewhat mispeak because the YANG model definition documents aren't standards, they are published as Informational RFCs meaning it's up to vendors which model they want to use and it's up to vendors which parts of the YANG models they actually implement.  

I do think naming the draft "BGP config model for service provider networks" is probably the wrong approach.  For instance Juniper and Cisco have thousands of customers using BGP who aren't service providers.   There should just be a BGP configuration model.  

Cisco and Juniper will be the ones to drive the code for their own hardware, and I think in the future they may be the ones who write the code controlling things like bare metal switches. 
Sterling Perrin 11/21/2014 | 9:32:53 AM
Re: Vendor buy-in? Dwx,

I'm very interested in these open source/standards developments as I believe this type of activity is key to success of SDN in carrier networks. Based on your posts, you seem to have quite a bit of technical knowledge. I'm curious about your statement:

In the end I don't see this having much traction as an actual standards document, but maybe it will get things moving a bit in the right direction.

Can you elaborate on your view? Is it because you feel Cisco and Juniper need to be the ones who drive the code that controls their equipment? Is it because there are technical problems with what these operators are creating? Something else?

These are extremely influential service providers so my initial thought is that their impact on vendors would be huge.

cnwedit 11/21/2014 | 7:14:31 AM
Re: Vendor buy-in? I think Google, et al., know well they need vendor buy-in. As Koley says, the vendors have to do the implementation. But it's hard to imagine vendors, even those as big as Cisco and Juniper, standing up to four of their largest customers and saying, no, thanks. 

Light Reading will certainly be following up this story with their reaction.
DHagar 11/20/2014 | 9:46:14 PM
Re: Vendor buy-in dwx, interesting.  I am thinking though that if even the big gorillas collaborate and create their own models separately, they may find themselves backed into a corner.  I think that model has been tried before.

This BGP model sounds well thought out and sustainable to attracting multiple vendors and systems that can carry them all the way.
dwx 11/20/2014 | 7:18:54 PM
Vendor buy-in? Cisco introduced a BGP YANG model draft last year that was already adopted by the NETMOD working group and has seen a revision in October.  


Now it contains lots of extensible options which are Cisco specific and not found on other platforms but it also defines base configuration the same on any platform.  There are some glaring omissions from this new effort including RPKI.  

Juniper's 14.2+ router configuration is stored as YANG so I'm interested to see how they define their standard BGP configuration internally.

In the end I don't see this having much traction as an actual standards document, but maybe it will get things moving a bit in the right direction.   The reality is Cisco and Juniper are the 1000lb gorillas and have defined a lot of what is being defined by YANG already, so BGP/MPLS/etc. is going to follow suit.  They are the ones developing new standards for those protocols, doing development and implementation, etc.   The YANG models need to be extensible to support new feature development by those vendors.  



Sign In