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

Network Programmability with OpenConfig and Junos

by Juniper Employee ‎03-07-2016 08:29 PM - edited ‎03-07-2016 08:33 PM

Building upon the previous post in the YANG blog series, we take a further look into third-party data models and Junos; specifically those defined by the OpenConfig operator group. 




For years, network operators have been faced with developing a number of techniques to manage multi-vendor environments. Today, these network elements are often configured via vendor-specific CLIs (command-line interface) or through well structured programmatic standard (e.g. NETCONF/XML) or proprietary interfaces each colored with their own vendor-specific hue. Outside of the configuration aspects of these network elements, the extraction of telemetry and operational state information has also been fragmented and inconsistently available forcing operators to rely on a combination of techniques such as SNMP polling, syslog parsing and periodic screen-scraping of show commands to glean the operational state of their network.


Throughout the past year, the OpenConfig initiative and operator group has been in full force developing a collection of vendor independent data-models which lay the foundation and provide the building blocks of a next-generation configuration, operational and streaming telemetry framework. Juniper Networks has been actively engaged in the OpenConfig initiative from the inception, enabling support for the configuration of core internet routing protocols and the delivery of key network element information via OpenConfig defined models and scalable modern RPC frameworks.


OpenConfig Objectives


Consistent Vendor-Neutral Models


One of the key objectives of the OpenConfig initiative is to develop vendor-neutral data models for the configuration and management of network elements. Today there are at least as many different configuration schemas for routing protocols as there are vendors. Even within each vendor there may be multiple mechanisms for configuring identical functionality across different platforms and network operating systems. This diversity significantly increases the cost for operators when developing back-end systems that interact with these network elements.


By defining a set of vendor-neutral data models for commonly used features and protocols, the configuration process can be dramatically simplified across platforms and vendors. With these models in hand, an operator can build offline schemas and serialize configuration data into the preferred format for consumption by a vendor/platform in a consistent manner without having to worry about generating the appropriate vendor-specific syntax to effect a particular configuration.


Declarative Configuration


One of the core tenets of OpenConfig operations is the use of declarative configuration. This enables operators to specify their configuration intent and have the network element determine how to implement that intent. The burden of having to define the specific actions to achieve that objective is removed from the network operator and placed back on to the network element.


From its inception, Junos OS has enabled declarative device configuration. Operators who adopt the OpenConfig models and deploy them on Junos can be assured that they will be able to apply the models in a declarative manner while the Junos translation engine performs the implementation specific actions.


Model Only Commonly Deployed Features


The models and the functionality being defined within the OpenConfig group do not attempt to be all things to everyone. Instead, the intent is to model only commonly deployed features within operator’s networks. By definition, this leaves some functionality out-of-scope for OpenConfig models. Due to the flexible nature of the Junos implementation and packaging of OpenConfig support, Juniper Networks (and customers themselves) are able to extend the capabilities of the baseline OpenConfig models and augment these models and the corresponding mapping capabilities to enable the use of Junos-specific features while retaining the vendor-independent baseline models.


In supporting the OpenConfig models, Junos has taken care to provide clear deviations where there may be differences between the baseline definition (in terms of units, application hierarchy, etc.) and where there may be gaps in coverage. Customers may choose to extend the baseline models themselves, or Juniper Networks may opt to provide augmentations to the baseline models for commonly utilized Junos functionality which isn't in the baseline models in order to streamline deployments for customers.


We will illustrate the methodology for augmentations and deviations in a future blog in this series.


Relationship to Other Models


Over the past couple of years, there has been an explosion of YANG-based modeling activities within the IETF. While it is very encouraging to see the energy behind the application of a common model-based approach to IETF technologies, there are a number of challenges associated with the proliferation of models, their relationship to each other, and the consistency of structure across multiple disparate models.


We will detail these challenges and Juniper's approach to resolving them in a future blog in this series.


Modular Delivery


In keeping with the objectives of the OpenConfig group to rapidly iterate, Juniper is decoupling the delivery of OpenConfig model support from the base Junos OS release process. This means that as existing models mature and new ones become available, Juniper can ship OpenConfig bundles separately and independently from Junos releases. As a result, an operator can qualify a release for deployment in their network and later on incrementally adopt the use of OpenConfig models by installing independent OpenConfig bundle from Juniper as the corresponding models are developed.


For more information on OpenConfig and Junos, visit us at MPLS/SDN World Congress March 8-11th, 2016 in Paris, France.




by ramas
on ‎03-08-2016 12:48 AM

Very nice article

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