& cplSiteName &

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

Carol Wilson
11/20/2014



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

(7)  | 
Comment  | 
Print  | 
Oldest First  |  Newest First  |  Threaded View        ADD A COMMENT
dwx
50%
50%
dwx,
User Rank: Light Sabre
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.  

http://datatracker.ietf.org/doc/draft-zhdankin-netmod-bgp-cfg/?include_text=1

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.  

 

 

 
DHagar
50%
50%
DHagar,
User Rank: Light Sabre
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.
cnwedit
50%
50%
cnwedit,
User Rank: Light Beer
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.
Sterling Perrin
50%
50%
Sterling Perrin,
User Rank: Light Sabre
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.

Sterling
dwx
50%
50%
dwx,
User Rank: Light Sabre
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. 
sam masud
50%
50%
sam masud,
User Rank: Light Sabre
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
50%
50%
dwx,
User Rank: Light Sabre
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.  
Featured Video
From The Founder
The 'gleaming city on a hill,' Steve Saunders calls it. But who is going to take us from today's NFV componentry to the grand future of a self-driving network? Here's a look at the vendors hoping to make it happen.
Flash Poll
Upcoming Live Events
September 28, 2017, Denver, CO
October 18, 2017, Colorado Convention Center - Denver, CO
November 1, 2017, The Royal Garden Hotel
November 1, 2017, The Montcalm Marble Arch
November 2, 2017, 8 Northumberland Avenue, London, UK
November 10, 2017, The Westin Times Square, New York, NY
November 30, 2017, The Westin Times Square
All Upcoming Live Events
Infographics
With the mobile ecosystem becoming increasingly vulnerable to security threats, AdaptiveMobile has laid out some of the key considerations for the wireless community.
Hot Topics
Could the Connected Car Help Prevent Terrorism?
Dan Jones, Mobile Editor, 9/15/2017
Cities Slam FCC on Broadband Proceedings
Mari Silbey, Senior Editor, Cable/Video, 9/15/2017
Apple's New iPhones: No Gigabit LTE for You!
Dan Jones, Mobile Editor, 9/14/2017
1 Million Pirate Set-Top Boxes Sold in the UK
Aditya Kishore, Practice Leader, Video Transformation, Telco Transformation, 9/20/2017
Close the Loop to Automate Service Assurance
Carol Wilson, Editor-at-large, 9/14/2017
Animals with Phones
Live Digital Audio

Understanding the full experience of women in technology requires starting at the collegiate level (or sooner) and studying the technologies women are involved with, company cultures they're part of and personal experiences of individuals.

During this WiC radio show, we will talk with Nicole Engelbert, the director of Research & Analysis for Ovum Technology and a 23-year telecom industry veteran, about her experiences and perspectives on women in tech. Engelbert covers infrastructure, applications and industries for Ovum, but she is also involved in the research firm's higher education team and has helped colleges and universities globally leverage technology as a strategy for improving recruitment, retention and graduation performance.

She will share her unique insight into the collegiate level, where women pursuing engineering and STEM-related degrees is dwindling. Engelbert will also reveal new, original Ovum research on the topics of artificial intelligence, the Internet of Things, security and augmented reality, as well as discuss what each of those technologies might mean for women in our field. As always, we'll also leave plenty of time to answer all your questions live on the air and chat board.

Like Us on Facebook
Twitter Feed