On 21 March 2025 7:18:46 am GMT+01:00, Saku Ytti via NANOG
<[email protected]> 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/[email protected]/message/YIHHJJX2N2JKMVEJN2DP6JYQV6KBHQKB/
