Industry Solutions and Trends
Technology is more than just networking and Juniper experts share their views on all the trends affecting IT
Juniper Employee , Juniper Employee Juniper Employee
Industry Solutions and Trends
Juniper’s Model driven Heritage
Jun 30, 2016

In her earlier blog posts, Pallavi explained Netconf & YANG and took us through the path of network innovation using these technologies.  In this and subsequent blog posts, I would like to talk about Juniper’s contribution to these technologies and how we’re implementing them which makes Juniper a distinct player in this game.


We take pride in saying that Junos has been model driven from day one and its User Interface (UI) is much more than CLI. The CLI is just one of the many clients of UI infrastructure. A model driven UI infrastructure provides well defined set of APIs (xml-api). Furthermore, Junos emits config and operational command output data in XML for API clients. Since CLI is also one of the clients, it receives data in XML and renders that XML into text output using the rules defined by the developer in using a specification called ODL (Output Definition Language).


From its inception, Junos was designed with a model-driven approach, using data models as constraints to determine valid input for both users and API clients.  This has given us an unmatched advantage for network automation and programmability.


We announced our API back in Junos release 4.2 in the year 2001, calling it the JUNOScript API, and we called our modeling language DDL (Data Definition Language).  Developers wrote DDL files that told the UI what valid input looked like and Junos use that information to parse command line, file-based, and API input, as well as other internal uses.


To help customers, Juniper took its inventions like JUNOScript API and DDL to IETF and these are now industry standards. NETCONF is the IETF standard protocol for managing devices and is derived from JUNOScript API. YANG is the data modeling language and is based of Juniper’s Data Definition Language (DDL).  


Please refer to Pallavi’s first blog if you want to understand more about NETCONF and YANG in layman...


The look and feel of DDL & YANG


Let’s use an example to explore both DDL and YANG. The following definition of some of the nodes under ‘/protocols/bgp’ hierarchy, presented in both DDL and YANG, allowing a side-by-side comparison.



                       Model in DDL        

                      Model in YANG

object protocols {

  object bgp {

    help "BGP options"


    object group {

      help "Define a peer group";

      flag setof list;

      attribute group_name {

        help "Group name";

        type string;

        flag nokeyword identifier;


      attribute "description" {

        help "Text description";

        type ranged string 1 .. 255;



      attribute "type" {

        help "Type of peer group";

        type enum uint {

          choice internal {

            help "IBGP group";


          choice external {

            help "EBGP group";







container protocols {

  container bgp {

    description "BGP options"


    list group {

      description "Define a peer group";

      key group_name;

      leaf group_name {

        description "Group name";

        type string;



      leaf "description" {

        help "Text description";

        type string { length 1 .. 255; }



      leaf "type" {

        description "Type of peer group";

        type enumeration {

          enum internal {

            description "IBGP group";


          enum external {

            description "EBGP group";









As you can see, these two languages are almost identical from both syntax and semantics perspective. YANG can be thought of as an IETF standard version of DDL. Juniper has been using DDL for quite some time and through heavy usage of the language, we have come across many improvements of the language.


The creator of DDL Phil Shafer has provided DDL to serve as the basis for the YANG data modeling language, and worked as part of the six-member design team to propose solutions to the problems we had encountered over our 12 years of experience using DDL as the data modeling language for Junos. There are certain differences in the way DDL and YANG defines constraint. For example, both have a “must” constraint that limits acceptable values, but DDL’s was not XML-specific, where as YANG uses the XPath standard.


DDL’s ‘must’ constraint is proprietary



attribute allow {
    must (!(".. authentication-key" || ".. authentication-key-chain"));
    must-message "Should not be configured with authentication-key/chain";



YANG’s ‘must’ constraint is XPath



leaf-list allow {
    must "not (../authentication-key or ../authentication-key-chain)" {
        error-message "Should not be configured with authentication-key/chain”;


Other than some subtle differences, both languages are near identical.


Advantage Junos


In Junos, both DDL and YANG compiles into the same internal set of instructions hence the underlaying infrastructure treats them identically. That’s why it’s not very hard for Junos to provide a robust implementation of YANG which has access to all available feature of UI infrastructure.


The config data pertaining to DDL or YANG co-exists in Junos config database and without much effort, the features provided by DDL are readily available to YANG. For example, both DDL-defined and YANG-defined configuration can be modified within a single NETCONF RPC.


Let’s understand this using following examples. In this example, we have taken OpenConfig BGP YANG module from:


Once the OpenConfig BGP module has been loaded, Junos treats that module identically to native Junos module. All the features of Junos are automatically available to this model including “inactive”, “protect”, “config comparison”, “commit”, “rollback”, etc.,


Following are some of the examples.


Command line completion



user@router# set openconfig-bgp:bgp ?
Possible completions:
  <[Enter]>                Execute this command
+ apply-groups             Groups from which to inherit configuration data
+ apply-groups-except      Don't inherit configuration data from these groups
> global                   Global configuration for the BGP router
> neighbors                Configuration for BGP neighbors
> peer-groups              Configuration for BGP peer-groups
  |                        Pipe through a command



Configure OpenConfig BGP statements using Junos ‘set’ command



user@router# set openconfig-bgp:bgp neighbors neighbor config local-as 65001



Compare the configuration



user@router# show | compare
+  openconfig-bgp:bgp {
+      neighbors {
+          neighbor {
+              config {
+                  local-as 65001;
+              }
+          }
+      }
+  }


Note: only for CLI, openconfig-bgp:bgp is done to resolve name conflicts where openconfig-bgp is module name and bgp is node name in YANG module.



Deactivate OpenConfig BGP



user@router # deactivate openconfig-bgp:bgp
user@router # show | compare
!   inactive: openconfig-bgp:bgp { ... }






user@router # rollback 0
load complete



Export the configuration in XML



user@router# show openconfig-bgp:bgp | display xml
<rpc-reply xmlns:junos="">
            <bgp xmlns="">



All of the Junos manageability features are readily available with no extra code, no extra cost and no extra effort because modeling languages DDL and YANG compiles into the same internal set of instructions.


The examples provided are for CLI, though it can extend to other protocols using different data encoding that Junos supports as shown in following figure of Junos Management Plane.






Sometimes history helps to understand current system in detail and provides different perspective. That’s why this blog was written to take you through history explaining some of the key design decisions that Juniper has taken and it’s advantages we are reaping today.


In the next blog we will deep dive into the design and architecture of YANG story in Juniper.