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 { "Response": { "@MajorVersion": "1", "@MinorVersion": "0", "Get": { "Operational": { "Interfaces": { "@MajorVersion": "8", "@MinorVersion": "0", "InterfaceBriefTable": { "InterfaceBrief": { "Naming": { "InterfaceName": "GigabitEthernet0/0/0/0" }, "Interface": "GigabitEthernet0/0/0/0", "ParentInterface": "None", "Type": "IFT_GETHERNET", "State": "IM_STATE_UP", "ActualState": "IM_STATE_UP", "LineState": "IM_STATE_UP", "ActualLineState": "IM_STATE_UP", "Encapsulation": "ether", "EncapsulationTypeString": "ARPA", "MTU": "1514", "SubInterfaceMTUOverhead": "0", "L2Transport": "false", "Bandwidth": "1000000", "Bandwidth64Bit": "1000000" } } } } }, "ResultSummary": { "@ErrorCount": "0" } } } RP/0/0/CPU0:R5#show operational Interfaces InterfaceBriefTable InterfaceBrief/InterfaceName=GigabitEthernet0/0/0/0 xml Wed Mar 19 20:53:52.407 PDT <?xml version="1.0"?> <Response MajorVersion="1" MinorVersion="0"> <Get> <Operational> <Interfaces MajorVersion="8" MinorVersion="0"> <InterfaceBriefTable> <InterfaceBrief> <Naming> <InterfaceName> GigabitEthernet0/0/0/0 </InterfaceName> </Naming> <Interface> GigabitEthernet0/0/0/0 </Interface> <ParentInterface> None </ParentInterface> <Type> IFT_GETHERNET </Type> <State> IM_STATE_UP </State> <ActualState> IM_STATE_UP </ActualState> <LineState> IM_STATE_UP </LineState> <ActualLineState> IM_STATE_UP </ActualLineState> <Encapsulation> ether </Encapsulation> <EncapsulationTypeString> ARPA </EncapsulationTypeString> <MTU> 1514 </MTU> <SubInterfaceMTUOverhead> 0 </SubInterfaceMTUOverhead> <L2Transport> false </L2Transport> <Bandwidth> 1000000 </Bandwidth> <Bandwidth64Bit> 1000000 </Bandwidth64Bit> </InterfaceBrief> </InterfaceBriefTable> </Interfaces> </Operational> </Get> <ResultSummary ErrorCount="0"/> </Response> Kind Regards, Jakob From: Mark Prosser <mark@zealnetworks.ca> Date: Wednesday, March 19, 2025 at 8:14 PM To: North American Network Operators Group <nanog@lists.nanog.org> Cc: Jakob Heitz (jheitz) <jheitz@cisco.com>, Tom Beecher <beecher@beecher.cc> Subject: Re: [NANOG] Re: The Network CLI -- Love it ? Hate it? Needed? On 2025-03-19 22:48, Tom Beecher via NANOG wrote:

I don't know if -XR does this, but on Junos , | display xml or display json.

Having some structure at least makes the scraping slightly less painful.

Sadly, it's not that easy on XR :( Warm regards, -- Mark Prosser // E: mark@zealnetworks.ca // W: https://zealnetworks.ca

On 2025-03-20 03:53, Saku Ytti via NANOG wrote:

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.

Yes, all of this, but it's probably worth noting that there, at least in the past, have been some JunOS management cli commands that just ran a shell command and dumped the output, therefore not supporting "| display json". A lot of the NTP commands used to be this way, though I think in later releases they've updated that to support the json display on them. Are there other commands that still do this? I'm personally not aware of anything, but it's posslbe. Additionally, that static transform into JSON from XML results in some really horrendous json to work with. It is workable, but it's not fun. This only applies to state data, the json rendering of config info "show config ... | display json" is as you would expect. There is a config switch that purports to output "compact" json for state commands, but it generates (usually) invalid json (doesn't put lists into "[...]"). -- Jeff McAdams

On Thu, 20 Mar 2025 at 15:47, Mark Prosser via NANOG <nanog@lists.nanog.org> wrote:

...

Additionally, that static transform into JSON from XML results in some really horrendous json to work with. It is workable, but it's not fun. This only applies to state data, the json rendering of config info "show config ... | display json" is as you would expect. There is a config switch that purports to output "compact" json for state commands, but it generates (usually) invalid json (doesn't put lists into "[...]").

I've noticed this as well. When I'm working with the piped outputs, I typically prefer xml & then utilize `xmltodict` and `jsonata` to get something workable for my use case.

I think it's absolutely crucial to realise that the trade-off is between: 1) no formal serialised data 2) formal serialised data with format that you don't quite agree with As a programmer, it is very easy for me to choose which trade-off I want. To me having 100% coverage is important, and I'll gladly trade off on how subjectively well thought-out the data is. I think netconf and yang completely misunderstood what our problem is. Problem wasn't that as a programmer I couldn't work with MIB/ASN1, the problem was, MIB/ASN1 didn't have the coverage that I needed. Now we are in the same exact place, except instead of having poor coverage MIB we have poor coverage MIB and poor coverage YANG. So we pay more to be in the same position. Standard MIB and YANG are pipe dreams and the benefit is actually somewhat marginal. It is not hard ask when you add a new vendor, that you punch 1:1 mapping to old vendor - new vendor OIDs/YANGs. It's all formal data, you just figure out keys from old to new, and your whole stack works. You could ask the vendor to provide this mapping as part of procurement. AFAIK the only vendor who had 100% coverage in MIB was Nokia, because their internal provisioning system used that API. Any vendor who did this correctly to begin with, had Internal Representation of state in some proprietary format. Which they then programmatically transform to Config ASCII, enterprise MIB/YANG, and those are not pretty, but they always could offer you 100% coverage. There is no way to transform the internal state into any standard representation, it will never be a thing because it cannot be. There the problem continues, because we keep asking for the wrong thing. If vendors had always done what Nokia did, always have 100% coverage of Internal State to MIB, we would have all automated this decades ago. And you'd just have this mapping infra of OIDs to vendors for your provisioning needs. -- ++ytti

On Fri, 2025-03-21 at 14:07 +0100, nanog--- via NANOG wrote:

Conclusion: this was mostly just rambling because I suck at writing, but I think the conclusion is that while YANGs are cool and it would make sense for everything to be YANG, and you could build a system from scratch where everything was a YANG, I can't really blame other vendors for not fully integrating their existing systems with YANGs because it's hard.

I don't think it even has to be YANG. To be honest, I don't like YANG, it's overly complex, and doesn't accomplish what it aimed for. I'm a bit frustrated that the networking industry as a whole seems hell-bent on rolling our own solutions, when so many of the approaches to these problems are really pretty well fleshed out in the rest of the IT world. How awesome would it be if we, as networking folk, could use the same tooling and technologies that all of the rest of the IT world uses to talk to our gear and systems and leverage all of the expertise that exists in other teams? We can't, though, but we insist on developing our own transports and tooling, on developing our data modeling languages, and on developing our own observability protocols. Forget standardized YANG data models, forget YANG altogether. The rest of the IT world is using REST as a lowest common denominator, and each vendor is creating their own data model that makes sense for their own systems. And the rest of the IT world is eating it up and building amazing things. I'd love to see a networking system where the core data model is available and exposed through various industry standard (not network industry, IT industry overall) methods, probably first and foremost would be REST (with an OpenAPI schema published), those same data models can be used and sent in other transports as well, but quit trying to use standardized MIBs/YANGs/Data Models. Vendors, roll your own data model, but make that data model interaction be the very first class part of managing your device and let everything else be an interaction with that. I think this is what Saku Ytti is getting at as well. The data model is primary, and expose that data model, then you can mechanically transform that to YANG, or SNMP, or GNMI, or whatever. -- Jeff McAdams

On Sun, 2025-03-23 at 18:11 +0100, nanog--- via NANOG wrote:

On 21/03/25 15:06, Jeff McAdams via NANOG wrote:

...

How awesome would it be if we, as networking folk, could use the same tooling and technologies that all of the rest of the IT world uses to talk to our gear and systems and leverage all of the expertise that exists in other teams? We can't, though, but we insist on developing our own transports and tooling, on developing our data modeling languages, and on developing our own observability protocols.

There isn't some other universal data model or meta-model out there, that's better that we're obviously stupid not to use. They all suck in their own ways. YANG is no worse than any of the others.

YANG is worse than the others, because there's a whole ecosystem of tooling that isn't YANG (or build around YANG) that the networking world has forgone using. OK, maybe it isn't that YANG itself is worse (although, I do think it is, but reasonable people could disagree), but the ecosystem of tooling around YANG is just pitiful compared to the tools and techniques that the rest of IT is using. Let me be clear, it's not about the data model, it's not about standardized MIBs or YANG models, or whatever. Let each vendor build their own model that fits their implementation, again, like the rest of the IT world does when building their systems that are running circles around the networking world in interoperability. Of course, YANG isn't a data model at all, it's a method of encoding data models. OpenConfig is (at least partly) a data model, and it's so ridiculously complex and malleable as a result of trying to make it "standard" that it's a royal PITA to use.

REST isn't even a real protocol. It's an idea that your API should be built around state, rather than operations.

Maybe in original theory. In practice is a set of practices and behaviors that the IT world is using to build amazing things. Yes, occasionally augmented by some other tooling/protocols/etc.

That is, ConfigurePort(1, {duplex=full, mtu=1500, stp=disabled}) rather than SetPortDuplex(1, full); SetPortMTU(1, 1500); STPDisablePort(1);

NETCONF is REST.

Whether NETCONF is REST or not isn't the point. The point is that NETCONF (and YANG) is, effectively, only used in the networking world. To a rounding error, no SREs use it, no systems engineers use it, no storage engineers use it, no database engineers use it.... My point is that networking as a whole is so insular, that we can't even, as a group by and large, see where IT has moved on with the techniques and tooling that they use, with the result that we're stuck 10 years in the past relative to their capabilities. -- Jeff McAdams

One issue I have had with Yang Models is the vendor not implementing NetConf RPC calls for everything in the model. It’s in the model, but there is no RPC call behind it. Shane

On Mar 24, 2025, at 3:46 PM, nanog--- via NANOG <nanog@lists.nanog.org> wrote:

On 23/03/25 20:33, Jeff McAdams via NANOG wrote:

...

...

...

How awesome would it be if we, as networking folk, could use the same tooling and technologies that all of the rest of the IT world uses to talk to our gear and systems and leverage all of the expertise that exists in other teams? We can't, though, but we insist on developing our own transports and tooling, on developing our data modeling languages, and on developing our own observability protocols. There isn't some other universal data model or meta-model out there,

On Sun, 2025-03-23 at 18:11 +0100, nanog--- via NANOG wrote: On 21/03/25 15:06, Jeff McAdams via NANOG wrote: that's better that we're obviously stupid not to use. They all suck in their own ways. YANG is no worse than any of the others. YANG is worse than the others, because there's a whole ecosystem of tooling that isn't YANG (or build around YANG) that the networking world has forgone using. OK, maybe it isn't that YANG itself is worse (although, I do think it is, but reasonable people could disagree), but the ecosystem of tooling around YANG is just pitiful compared to the tools and techniques that the rest of IT is using.

What tooling do you feel that is? I haven't encountered it yet.

We've got meta-models like JSON schemas (suck), XML DTDs (suck), XSD schemas (better than DTDs, but suck), protobufs (very limited), UML (what are you smoking?), MIBs (suck because everything has to fit OID tables. You don't get the full power of ASN.1).

At least YANG reasonably attempts to model the data itself instead of the serialization format. It has XML-isms, but very few that can't be transposed easily enough to a JSON serialization (sometimes the string representation of datatypes in constraints is problematic). This makes it better suited for its purpose than something like protobufs, MIBs, or XML schemas. It has an expressive constraint language, allowing for validation other than by trial and error.

...

Let me be clear, it's not about the data model, it's not about standardized MIBs or YANG models, or whatever. Let each vendor build their own model that fits their implementation, again, like the rest of the IT world does when building their systems that are running circles around the networking world in interoperability. Agree. Standard models are good but only if they work well. If they don't work well then don't use them. Working well on this device is more important than being identical on all devices, although both are important. The standard may be implemented as a compatibility layer over the non-standard model. Of course, YANG isn't a data model at all, it's a method of encoding data models. i.e. a meta-model, a model of models

...

REST isn't even a real protocol. It's an idea that your API should be built around state, rather than operations. Maybe in original theory. In practice is a set of practices and behaviors that the IT world is using to build amazing things. Yes, occasionally augmented by some other tooling/protocols/etc. What are the specific practices? I know some people treat it as a synonym for "an API that uses HTTP and JSON" but surely you have something more specific in mind. That is, ConfigurePort(1, {duplex=full, mtu=1500, stp=disabled}) rather than SetPortDuplex(1, full); SetPortMTU(1, 1500); STPDisablePort(1); NETCONF is REST. Whether NETCONF is REST or not isn't the point. You strongly hinted that we should be using REST instead of NETCONF, no? The point is that NETCONF (and YANG) is, effectively, only used in the networking world. To a rounding error, no SREs use it, no systems engineers use it, no storage engineers use it, no database engineers use it.... Well, they should. It's pretty cool. Remind me to incorporate it into my next project, possibly as a model for JSON files. My point is that networking as a whole is so insular, that we can't even, as a group by and large, see where IT has moved on with the techniques and tooling that they use, with the result that we're stuck 10 years in the past relative to their capabilities. Can you explain what these techniques, tooling and capabilities are? I haven't seen any concrete examples in this discussion. Apart from OpenAPI.

---

NANOG mailing list https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/HTEUZIRG...

Yes. Juniper has done it day1, not with MIBs tho, but XML. Of course they could have delivered static translation to MIBs, if there was market demand, like they did for YANG. And this is both desirable and most we can ask. And the next time someone comes up with an idea of standard models, in a new format, vendors can sigh and write a static translator and wait for the market to realise why it doesn't work. Instead of spending a lot of time on redoing the fantasy of standard MIBs, we should figure out how to create an ecosystem where model2model translations are easier to do and are work-preserving. So that if one of us does model translation, they can share that, and we can consume both models and that translation in any programming language. So instead of internally everyone doing the same work every time they need to support a new model, we'd first check if someone has published the translation that we need. We can create perfect 100% coverage YANG models representing a snapshot in time but the further we drift in time the more useless that model becomes. Like today we mostly use a subset of IF-MIB as standard, everything else is enterprise. Even BGP is usually enterprise, because things like IPv6 happened, and there wasn't a standard available so people migrated to enterprise MIB, plenty of examples like this and today we've mostly given up, we don't even try to catch-up and deliver standard MIBs. Proposing the above problem can be solved by changing model language is weird, but that's basically what we are as an industry saying. 100% on board data-first/model-first internal representation (I think Junos, SROS, maybe others today?) 0% on board for standard models On Fri, 21 Mar 2025 at 16:12, Mikael Abrahamsson <swmike@swm.pp.se> wrote:

On Fri, 21 Mar 2025, Saku Ytti via NANOG wrote:

...

If vendors had always done what Nokia did, always have 100% coverage of Internal State to MIB, we would have all automated this decades ago. And you'd just have this mapping infra of OIDs to vendors for your provisioning needs.

Well, several of the vendors have been doing this for a while now, with their internal yang modeled configuration engines. So their proprietary models have full coverage (can't create configuration without creating model).

-- Mikael Abrahamsson email: swmike@swm.pp.se

-- ++ytti

Junos absolutely isn't YANG model first, it is absolutely the same XML it's always been. But which can be statically translated to anything else, as long as it's not standard. I'm highly sceptical if anyone anywhere would decide to use anything standard for their internal representation and yield flexibility and control away, seems very inefficient and ends up with having to solve problems in the wrong place, because you can't change the internal format arbitrarily upon new problems that are best addressed by changes to the internal representation. On Fri, 21 Mar 2025 at 17:13, Mikael Abrahamsson <swmike@swm.pp.se> wrote:

On Fri, 21 Mar 2025, Saku Ytti wrote:

...

100% on board data-first/model-first internal representation (I think Junos, SROS, maybe others today?) 0% on board for standard models

Juniper (JunOS), Nokia (SROS) and Cisco (XR) are all YANG-model-first with proprietary models needed to do anything in the configuration engine, so their proprietary models are feature complete from a configuration pov.

I've run into others as well, for instance the ones made using Conf-D.

When discussing translation, question is what to translate to/from. The only way would be to create a standard model, which is exactly what's being done in multiple SDOs, for instance openconfig and ietf. As you say, they'll always be a subset, but if you can get by with openconfig for some of the functionality then devices supporting the openconfig model from multiple vendors can be configured for that subset using a single model instead of using the proprietary models.

-- Mikael Abrahamsson email: swmike@swm.pp.se

-- ++ytti

On Thu, 20 Mar 2025 at 15:24, jeffm--- via NANOG <nanog@lists.nanog.org> wrote:

Yes, all of this, but it's probably worth noting that there, at least in the past, have been some JunOS management cli commands that just ran a shell command and dumped the output, therefore not supporting "| display json". A lot of the NTP commands used to be this way, though I think in later releases they've updated that to support the json display on them. Are there other commands that still do this? I'm personally not aware of anything, but it's posslbe.

Yeah there are gaps, particularly on shell/3rd_party commands. It is kinda hard to fix problem. Either you write your own 'ps' or you give users familiar output. Even those shell things which are XMLRPC tend to be <blob>output</blob> instead of properly serialised data. Juniper did take steps to fix the root cause - https://github.com/Juniper/libxo So you can do things like this: command = '''start shell command "ps --libxo json -Saxo 'pid ppid comm etimes dsiz rss time majflt msgrcv msgsnd inblk oublk nsigs nivcsw nswap'"''' To get json output from 'ps'. Strangely, they don't use it themselves, but 'show system process' output just returns a blob. So you can't do 'show system processes | display json', but have to do it like above :) -- ++ytti