[j-nsp] NETCONF in Junos

[Phil Shafer]

Martin T writes:
>Thanks! So as I understand, the general idea is that it doesn't matter
>much for Junos if the command is executed in the CLI or from the
>remote(management server) NETCONF manager, i.e. Junos is basically
>built around the NETCONF? However, local calls(for example if one
>executes "show version" in Junos CLI) do not travel internally over
>SSH as remote calls would, do they?

Yes, JUNOS is built around NETCONF.  More precisely, the plumbing
in JUNOS is what NETCONF was based on.  We built (way back in
JUNOS-4.1) an API on top of our CLI infrastructure as a no-additional-cost
perk of our heavy use of meta-data.  Our config data is all described
in data models (read: YANG) so we can easily emit our data in text,
XML, or JSON.

The JUNOS UI consists of two major pieces, the CLI and MGD.  The
CLI really just handles the terminal.  It does command line input
processing (emacs keybindings) and output rendering (xml-to-text
and automore).  There's not just in the CLI itself.  It's about as
dumb as I could make it.  All the real magic happens in the MGD
daemon.

CLI and MGD talk to each other over a unix-domain socket, so there's
no SSH overhead for CLI commands.

When you issue a command at the CLI, the CLI packages it up and
ships it (in XML) to MGD (the management daemon) who parses it into
an internal form.  When an API client send XML to a JUNOS device,
MGD builds the same internal form.

>From that point on, the code path of the command/RPC is shared.
It's forwarded to the responsible subcomponent (e.g. RPD), who emits
an XML response, which is forwarded back to the CLI or API client.

The CLI would then convert that XML into text for human readers.
(The "display xml" pipe really just turns off that rendering in the
CLI and the "display xml rpc" pipe really just returns that "internal
form" object mentioned above to the CLI, who renders it.)

The real value is that the API comes for free, since it's using the
same internal plumbing.  This means that when a feature ships in
the CLI, it's immediately available in the API.  No lag.  No
additional cost.  No missing bits.  It's literally all there (with
the exception of terminal-oriented commands like "monitor interface",
etc).

Our use of meta-data also means that we can more easily implement
UI features like config groups, "deactivate", and "protect" since
their implementation is entirely within the UI.

It also means (moving forward) that our forthcoming loadable YANG
features will ride for free over the same plumbing.

Sorry if this got a bit long, but honestly it was a soft pitch and
I couldn't resist bragging about my baby.  ;^)

Thanks,
 Phil