Automation & Programmability
Showing results for 
Search instead for 
Do you mean 

Towards the path to Network Innovation (part 2 of the YANG blog series)

by Juniper Employee ‎09-03-2015 03:09 AM - edited ‎09-03-2015 05:07 AM

In my earlier blog post, where I introduced Netconf and YANG, I used a classroom analogy that compared communicating knowledge to a diverse group of students with communicating configurations to a diverse group of networking devices. The analogy showed the same common sense approach to communicating information in a classroom can, and in fact needs to, be applied to the networking world too.


Vendor specific logic and differences have historically been a pain for the Network Management Entity to resolve (and endure). From different protocols to talk to a vendor’s device, to different ways of specifying network configuration – it has been the Network Management Entity’s responsibility to implement logic for every vendor.


YANG provides a data modeling language, with which network configuration schemas can be defined. If each of the devices understands the relevant network service YANG data model, then for managing that network service, the Network Management Entity needs to talk to all the devices in ONLY one way.


Lets look at how this works using a minimal configuration for a single BGP neighbor on two different vendor’s routers.



The Openconfig WG has defined a common YANG data model for specifying BGP configuration. The relevant portion of Openconfig’s BGP YANG data model is:



Assuming both vendors support YANG and Openconfig’s BGP YANG data model, the Network Management Entity can now configure both the vendor’s devices by communicating the same XML configuration snippet over NETCONF:



Just as the Junos CLI allows the native Junos XML configuration data to be entered, the Juniper implementation of YANG also allows configuration data defined by YANG data models to be entered with CLI commands. Here’s an example of how the Openconfig BGP configuration on a Junos router looks:




So falling back to my earlier analogy:

  • Everybody in the class speaking Queen’s English is akin to all devices using the OpenConfig YANG model.
  • Just as Queen’s English has a certain grammar and syntax, YANG models defined by OpenConfig specify the grammar and syntax of communicating configuration. (For example, a BGP OpenConfig YANG model specifies grammar and syntax for BGP configuration)
  • In the classroom, now that everybody understands the same language (Queen’s English), I as a teacher can communicate with my students using simple sentences. This is akin to programming a BGP neighbor on all devices using the OpenConfig YANG model.


This is all goodness. However, I firmly believe this goodness should be delivered with our customer’s networks in mind and how this should lead us to the path of Network Innovation. This perspective focuses us on two very important elements:

  • Agility
  • Customization


Agility: IETF and the OpenConfig WG are defining YANG models for configuration of various network hierarchies. The ability to support these YANG models as soon as they become standardized is a key element.

  1. Customers should not have to wait for months, or even years, for a new software release which supports a new YANG data model.
  2. In addition, supporting a new YANG model should not require a software upgrade of the device or even a system reboot of the device.


Customization: Some network configuration YANG models are being standardized in the IETF and OpenConfig WG. Juniper strongly believes in supporting these standard YANG models, however we also believe we should provide complete flexibility to our customers by also allowing them to define their own custom YANG models.

  1. If a network service has no standard YANG model defined, customers have the choice to define their own models
  2. Customers do not have to wait for the models to become standard, and can start having their Network Management Entity talk to all boxes the same way, even today (This also focuses on the agility element)
  3. Customers can define YANG models that best abstract their particular business workflow
  4. Customers can extend existing YANG models by using extensions that YANG provides via the ‘augment’ statement

Some of the subsequent blogs will have more information on this aspect.


Rewinding this whole blog… You see that by adding these very obvious features to Junos, we’ve now enabled customers to take most of the device specific knowledge out of their Network Management Entity. This reduces entry barriers and complexities, and is what I call the path to Network Innovation.


There is still more to do, in order to truly achieve the path to Network Innovation. Watch out for the next blog in this series.

by Juniper Employee
on ‎04-08-2016 03:59 AM

Hi Pallavi,

Nice blog! Just wondering, if multiple customers start defining their own models for numerous network services (non standard YANG), wouldn't it be a herculian task for providers like Juniper to support all of these?

Thanks, Mithun.

by Juniper Employee
on ‎04-10-2016 04:52 AM

Hi Mithun,


Fair point. Junos has been architected in a way that these datamodels - be it custom YANG models, IETF, OpenConfig - are add-ons, i.e., they do not need native code changes in Junos for support.




Juniper Networks Technical Books
About the Author
  • Ben has been working with service providers around the world for the last 15 years developing business cases for a variety of product concepts and new ventures. Ben holds an MBA from MIT and a BS & MS in Mechanical Engineering from Johns Hopkins University.
  • Part of Juniper PS EMEA since 2005 Primarily interested in making technology do the boring repetitive work so I can do fun new work.
  • Donyel Jones-Williams is the Director of Service Provider Product Marketing Management overseeing all of Juniper's Service Provider Products for Juniper Networks. In this role, he leads all of the internal and external marketing activities for Juniper with respect to routing, automation, SDN and NFV. Prior to joining Juniper Networks in January 2014, Donyel was a Senior Product Line Manager for Cisco Systems with in the High End Optical Routing Group managing product lifecycle for multiple products lines helping telecom providers operate efficiently and effectively including; ONS 155xx Product Family, ONS 15216, ONS 15454 MSTP, Carrier Packet Transport Product Family, ME 2600x, & ASR 9000v. He also negotiated favorable agreements with 3rd-party vendors furnishing components and parts and conducted both outbound and inbound marketing (webinars, case study-development, developed and delivered both business & technical at Cisco Live 2005-2012). Donyel graduated from California Polytechnic State University-San Luis Obispo with a Bachelor of Science in Computer Science. While attending Cal Poly SLO he was a collegiate student athlete playing football as a wide receiver and a key member of the National Society of Black Engineers. Donyel is now an active volunteer for V Foundation.
  • Dwayne loves everything related to automation and enjoys talking about it: Automation benefits outweigh any associated disruption.
  • Ebben Aries is a Principal Engineer for Junos Manageability in the Juniper Development and Innovation Division.
  • Michael Pergament, JNCIE-SP #510, JNCIE-ENT #23, JNCIE-DC #3
  • Marcel Wiget is a member of the Routing TME team. His career within Juniper started back in 2009 as a Senior Systems Engineer driving one of the first MX based Broadband Edge deployment to success. Prior to Juniper, Marcel held various positions in pre-sales, professional services and development at Chantry Networks, Spring Tide, Nortel Networks and Wellfleet.
  • Surya Nimmagadda is a Distinguished Engineer working on packet forwarding software for Juniper Networks routing and switching platforms.
  • Pallavi Mahajan is Vice President Engineering, Junos Engineering, and leads the Junos Programmability & Automation teams
  • Product Manager, JUNOS Automation