ON THIS PAGE
Advantages of Using the NETCONF XML Management Protocol and Junos XML API
The NETCONF XML management protocol and Junos XML API fully document all options for every supported Junos OS operational request and all elements in every Junos OS configuration statement. The tag names clearly indicate the function of an element in an operational request or configuration statement.
The combination of meaningful tag names and the structural rules in a DTD makes it easy to understand the content and structure of an XML-tagged data set or document. NETCONF and Junos XML tag elements make it straightforward for client applications that request information from a device to parse the output and find specific information.
Parsing Device Output
The following example illustrates how the Junos XML API makes it easier to parse device output and extract the needed information. It compares formatted ASCII and XML-tagged versions of output from a device running the Junos OS. The formatted ASCII follows:
Physical interface: fxp0, Enabled, Physical link is Up Interface index: 4, SNMP ifIndex: 3
The corresponding XML-tagged version is:
<interface> <name>fxp0</name> <admin-status>enabled</admin-status> <operational-status>up</operational-status> <index>4</index> <snmp-index>3</snmp-index> </interface>
When a client application needs to extract a specific value
from formatted ASCII output, it must rely on the value’s location,
expressed either absolutely or with respect to labels or values in
adjacent fields. Suppose that the client application wants to extract
the interface index. It can use a regular-expression matching utility
to locate specific strings, but one difficulty is that the number
of digits in the interface index is not necessarily predictable. The
client application cannot simply read a certain number of characters
after the Interface index: label,
but must instead extract everything between the label and the subsequent
label, which is
, SNMP ifIndex
A problem arises if the format or ordering of output changes
in a later version of the Junos OS, for example, if a Logical index field is added following the interface
index number:
Physical interface: fxp0, Enabled, Physical link is Up
Interface index: 4, Logical index: 12, SNMP ifIndex: 3
An application that extracts the interface index number delimited
by the Interface index: and SNMP ifIndex labels now obtains an incorrect result.
The application must be updated manually to search for the following
label instead:
, Logical index
In contrast, the structured nature of XML-tagged output enables
a client application to retrieve the interface index by extracting
everything within the opening <index> tag and closing </index> tag. The
application does not have to rely on an element’s position in
the output string, so the NETCONF server can emit the child tag elements
in any order within the <interface> tag
element. Adding a new <logical-index> tag element in a future release does not affect an application’s
ability to locate the <index> tag element
and extract its contents.
Displaying Device Output
XML-tagged output is also easier to transform into different display formats. For instance, you might want to display different amounts of detail about a given device component at different times. When a device returns formatted ASCII output, you have to design and write special routines and data structures in your display program to extract and store the information needed for a given detail level. In contrast, the inherent structure of XML output is an ideal basis for a display program’s own structures. It is also easy to use the same extraction routine for several levels of detail, simply ignoring the tag elements you do not need when creating a less detailed display.