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

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

On 21 March 2025 7:18:46 am GMT+01:00, Saku Ytti via NANOG <nanog () lists nanog org> wrote: 
> 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.

I have some experience with this. When I worked at Aviat several years ago, it was on a new generation of products that 
was built on some YANG-first (note: not NETCONF-first) hype. When we had to make some third-party code configurable, we 
translated it to a YANG model. For example we had a translation layer between YANG operations and sending control 
packets to the NTP daemon (as well as starting/stopping the NTP daemon and so on).

The CLI was completely built with a vendor product (ConfD by Tail-f - recommended, thought it has warts) upon annotated 
YANG models, so our YANG models were often designed based on how we thought the CLI should look, and this usually 
resulted in YANGs that were also pretty suitable for NETCONF use, though not always. Standard YANGs (not many existed 
at that time) rarely resulted in a good auto-generated CLI - so we rarely used them. Sometimes we had a request to 
support a particular standard YANG so we implemented it as well.

The web UI used the same YANGs as the CLI (but with more code in front) and the limited support for SNMP was also 
implemented as a mechanical MIB-to-YANG translation, followed by a handwritten YANG-to-YANG translation. (That worked 
okay but the performance wasn't ideal - especially certain SNMP GETNEXT requests in large tables could cause us to have 
to walk over the whole table, fetching one row at a time by RPC call, and then sorting it in this layer because the 
underlying table wasn't in SNMP-compatible order.

[That's a leaky abstraction, and probably if we went for an architecture with fewer abstraction layers, we could have 
kept the table indexed in both SNMP order and NETCONF order. After I left that job I've learned more about the pitfalls 
of layered architectures - they can seem great in principle, keeping concerns separate and so on, but they can easily 
prevent you from writing mechanically sympathetic code that actually runs well.])

Other issues with translating everything are edge cases where some data that looked consistent on the outer-facing 
model would violate a constraint internally and you'd get an incomprehensible error message back. Or it just silently 
fails - I don't remember exactly what happened if you tried to set an interface as half-duplex gigabit, but I remember 
there was a problem around this. It might have accepted but silently ignored all port configuration updates until you 
set it back to auto. The underlying component was sending an error code back, asynchronously, after the configuration 
has been accepted.

Another issue is when some outer-facing-layer operations are non-idempotent, non-commutative or non-reversible because 
some internal secondary object gets created whenever you're using a certain feature, for example. This could also 
confuse the transaction manager because it sees a client created something and deleted it, yet the data store is 
different from how it started. In most of these cases it makes no difference whether the internal edit gets reverted or 
committed, but it still causes weird transaction semantics.
# exit
Do you want to commit your changes? (commit/discard/cancel) cancel
# show config changes
No uncommitted changes.
#

You have to make sure each client doesn't see overlapping views of data, or it can write conflicting data 
simultaneously to different places because the transaction layer isn't aware of the translation going on (and I'm not 
sure how it would - you could set the entire configuration in a single Netconf operation). We had hacks so that 
<default-operation>replace wouldn't delete all the inner-facing models. (Were I the architect on a similar design, I'd 
at least consider running an entirely separate database process for each translation)

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.
_______________________________________________
NANOG mailing list 
https://lists.nanog.org/archives/list/nanog () lists nanog org/message/YIHHJJX2N2JKMVEJN2DP6JYQV6KBHQKB/