When people started talking about OpenConfig YANG data models, my first thought (being a grumpy old XML/XSLT developer) was “that should be really easy to implement for someone with XML-based software and built-in XSLT support” (read: Junos with SLAX).

Here’s how my simplistic implementation would look like:

Get OpenConfig request;

Transform OpenConfig XML data into proprietary XML data using XSLT transformation;

Execute an internal NETCONF call with transformed data.

XSLT is data transformation language that can be used to transform an XML document into another XML document, HTML web page (that’s why I used it) or even plain text. SLAX is a human-readable alternative (XSLT uses XML markup, resulting in great fun for developers).

As always, things are not as easy as they look. Apart from changing configuration (EDIT-CONFIG) decent NETCONF implementation should support configuration retrieval (GET-CONFIG) and operational data retrieval (GET), and all three of them have to be transformed between internal data structures and OpenConfig data structures.

It took Juniper almost exactly a year between the time they started talking about OpenConfig support in Junos in present tense (aka Marketing Grammar) and the time they actually shipped the code (Junos release 16.1R1), but they finally got there, and they did it with style.

That’s a pretty useful data point: when a marketer says we have X it really means it’s a least a year out.

Here are a few highlights of what they did:

Implement support for custom YANG modules. IETF and OpenConfig YANG modules are probably the most common use case; you could also create a package that would support any data model you design (in theory, you might be able to make a Junos switch pretend it’s a Nexus OS switch);

The custom YANG package includes translation scripts that translate your data model into Junos standard configuration. The translation script is run as a commit script, which means that your data model appears in active and saved configurations;

appears in active and saved configurations; Similarly, you can define translation scripts for RPC modules (NETCONF calls) to get operational data from the device, and define your own action scripts that execute the RPC commands. You can also tie the action scripts to show commands, effectively extending the traditional CLI.

commands, effectively extending the traditional CLI. Finally, using Junos ODL (Output Definition Language, not the other ODL), you can define your own transformation of XML documents into ASCII printouts produced by CLI commands.

Long story short: assuming you have too much time you can make a Junos device behave like anything you’d like… or you could download OpenConfig or IETF packages from Juniper’s web site and start configuring your network devices using standard data models. It took more than a decade (first NETCONF IETF drafts were written around 2003), but we finally got there.

To be fair: have to mention that Juniper isn’t the only vendor supporting OpenConfig and IETF data models. Various Cisco IOS XR and XE also support a significant number of IETF or OpenConfig data models but not nearly as elegantly as Junos. Anyone else? Write a comment!