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