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

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

Actually scratch that. I think we need to disambiguate what we mean 'first'.

Like are you saying, YANG is earlier in Junos stack, than XML?

Because I don't actually know what is the earliest form of data
description in Junos. I assume C struct, but I have low confidence.

Arista had some proprietary language (that they went to court with, as
co-founder claimed IP rights) that compiles to C++, and I assume for
Arista the earliest form of data is in this proprietary programming
language? Which they could then possibly translate into YANG
statically.


But whatever it is, it would seem absolutely bizarre to choose
anything where you don't control it completely. I don't know if Arista
is still using that proprietary language, but I think it's absolutely
brilliant and everyone who is going to have to support some program
with large teams over decades should probably fork a programming
language and compile into that target but control the language itself.
So there are more abstractions and more places to address commonly
occurring problems than hoping that people just don't make those
mistakes.

To me it is easy to understand how much benefit you can get, if you
control the language you write in. Because every language, be it C++
or rust, has to support everything, so there are very few assumptions
you can make, which makes the language more dangerous, tedious to
write and bug prone. But if you know the application the language is
going to be used for, you can make assumptions which will greatly help
people writing safer and less buggy code.



On Fri, 21 Mar 2025 at 18:13, Saku Ytti <saku () ytti fi> wrote:
> 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



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