[NANOG] Re: The Network CLI -- Love it ? Hate it? Needed?

[Saku Ytti via NANOG <nanog () lists nanog org>]

On Thu, 20 Mar 2025 at 05:58, Jakob Heitz (jheitz) via NANOG
<nanog () lists nanog org> wrote:

> XR has “show operational … json” or “… xml” commands. For example:
> RP/0/0/CPU0:R5#show operational Interfaces InterfaceBriefTable InterfaceBrief/InterfaceName=GigabitEthernet0/0/0/0 
> json

I think it's important to also know that in Junos |display json|xml is
guaranteed, because CLI is not the 1st class citizen (except for some
PFE/shell commands, but most never use those once). CLi does XML RPC
calls and the structured XML data is the first-class citizen. There is
a static transform from the XML RPC into JSON, no one has to write any
code for JSON coverage of new commands.

Whereas in IOS-XR it's not architectural design that everything emits
structured data, which is then re-rendered as free-from CLI data.
Cisco needs to put a lot of effort into all this, which is free for
Juniper.

Further there is no separation for the config/data team and protocol
team. If you are a person writing ISIS code, you also own the config
gen bits and all the problems that might cause commit to fail. So if
my commit in XR from A config to B config fails, it doesn't go to some
config infra team, it goes to the team who owns the bits of config
that fail. It is pretty tall ask and you need to have a lot of context
in your head to make sure it works.
Therefore we never see A=>B commit failures in Junos, and we do see
those in XR, but Cisco always will fix them.

If the protocol team emits structured data only that is consumed by
the abstraction layer, they don't have to understand anything about
the commit process, as the structured data consumption is entirely a
problem for people who are experts on that.


-- 
  ++ytti
_______________________________________________
NANOG mailing list 
https://lists.nanog.org/archives/list/nanog () lists nanog org/message/46PXCLQGLWBSBYGCUHAGLIYNUVURNYUJ/