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

[nanog--- via NANOG <nanog () lists nanog org>]

On 23/03/25 20:33, Jeff McAdams via NANOG wrote:
> 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.

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/HTEUZIRGGU7OZHFSUXQ32ACTFKUZPM4R/