Netconf & Yang Go Mainstream

It has taken time, but Netconf and Yang are now becoming accepted as critical lynchpins of service provider IT strategies as service providers consider their virtualization strategies.

If you're not yet familiar with Netconf and Yang, you soon will be.

Or at least you should be, because they're the standards about to take the telecom sector by storm, and will be among the major topics of conversation at this week's Big Telecom Event (BTE).

There are several reasons for that.

Firstly, network operators have been looking for ways to make sense of SDN and NFV for the past few years, particular in relation to how networks with virtualized elements and separate data and control planes might be managed. In many cases, that has brought Netconf, the Network Configuration Protocol developed by the IETF for reading and writing network configurations, and Yang, the data modeling language associated with it, into full frontal view. (See NFV Group Finds Its Feet.)

Secondly, Netconf and Yang -- the Starsky and Hutch of networking, perhaps -- have already been adopted by some of the more adventurous Tier 1 telcos grappling with the migration to software-oriented networks. Undoubtedly, Deutsche Telekom AG (NYSE: DT) has led the way, adopting Netconf and Yang as part of the next-gen OSS it is adopting for its Terastream infrastructure. AT&T Inc. (NYSE: T) followed earlier this year. That's some heavyweight support. (See Deutsche Telekom: A Software-Defined Operator, Deutsche Telekom Selects Tail-F, and AT&T's Cloud Future Takes Shape.)

In both cases, it's worth noting, the technology developer/vendor engaged by DT and AT&T has been Tail-f Systems , which has been promoting Netconf and Yang as the panacea to many networking ills for many years.

Thirdly, network operators have begun to realize that Netconf and Yang are applicable right now and can help with the configuration and management of multivendor networks: These are not standards that have to wait for SDN and NFV.

And fourthly, there has been a major rush from many of the major vendors to support Netconf and Yang as part of the rush to, at least publicly, embrace "open networks." Among the supporters are Brocade Communications Systems Inc. (Nasdaq: BRCD), Cisco Systems Inc. (Nasdaq: CSCO), Juniper Networks Inc. (NYSE: JNPR), Ericsson-LG , and Nokia Networks , among others, but notably not Alcatel-Lucent (NYSE: ALU). (See Brocade Unveils Open Carrier Platform for SDN, NFV.)

That might be because a growing number of service providers are insisting their equipment vendors support these two components of a programmable network. Very soon, vendors who lack such support may find themselves excluded from major purchase deals, warns Caroline Chappell, Heavy Reading senior analyst and author of a whitepaper on Netconf and Yang, "Creating the Programmable Network: The Business Case for Netconf and Yang."

More importantly, the data protocol and data modeling language stand to replace both the costly, cumbersome manual processes that today make provisioning new services a slow and mistake-prone process, and the need to pay for proprietary approaches to automating network configuration that tie network operators to a single vendor and limit other choices.

"They must get humans out of the loop," says Geoffrey Mattson, VP of engineering and product management at Juniper Networks Inc. (NYSE: JNPR), speaking in a Light Reading radio show, Creating the Programmable Network: The Business Case for Netconf and YANG, hosted by Chappell and sponsored by Tail-f Systems . "Our research shows 60% of outages are caused by humans mistyping things or translating things wrong from print to their console."

Together, Netconf and Yang support the automation of configuration sequences across different pieces of equipment from different vendors at multiple layers of the network.

What they would replace is the variety of vendor-specific Command Line Interfaces (CLIs) which require manual configuration or expensive integration by service providers themselves or systems integrators with their own proprietary tools and equipment-specific adapters.

Netconf's development began in the IETF way back in 2003, as network operators realized that SNMP or simple network management protocol, while widely deployed, was inadequate for network configuration and that individual vendor CLIs can't easily be programmed for automation and require human interpretation, says Chappell.

Netconf and Yang also can serve to pave the way for NFV, she points out, because they support the standardization and automation required in a cloud environment and they provide the formal abstracted model of a network function that can be re-used when the function is virtualized.

(Ray Le Maistre, Light Reading Editor-in-chief, also contributed to this story).

— Carol Wilson, Editor-at-Large,