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.