Best practices for a YANG model + confd architecture for a chassis based system with varying blades?


I’m pretty new to NETCONF, YANG and confd, and I’m trying to figure out how one would go on about designing a solution for the system I’m working on.

This is a chassis based system, with a couple of redundant management boards and a selection of different models of service blades, the vast majority of which are not stand-alone.

From the management perspective, I want the boards to instantiate their own managed object tree with their own data model inside the chassis managed object tree. The data model underlying a blade should change (at runtime) if the blade is replaced with another one. Configuration data incompatibilities should be flagged, but the typical use case would be for the configuration data of a blade to be wiped out before the blade is replaced with a completely different one.

Moreover from the development point of view, the development lifecycle of a service blade can be more or less independent from the one of the management board. In other words, if possible we don’t want to have the management board have all the data model files for all possible service blades and their compatible versions thereof. Ideally, the management board would load the data model from the blade itself once it is plugged and booted, and include it in the chassis data model at runtime.

Skimming through the confd user manual and internet did not give me a definitive answer about how to go on about it, and I would appreciate any pointers in the right direction.

The chapter in the confd user manual about master and subagents seems related, but there is an explicit statement that that solution is meant for subagents (blades) that can also be standalone, which is mostly not the case here.

Another part of the manual I looked into was the “In-service data model upgrade” one, to cover the dynamic loading of YANG data models at runtime, but the restriction about HA threw me a bit off.

Another investigation direction I took was with YANG mount points ( but I’m still not completely sure it’s what I’m looking for. The confd user manual also mentions the annotations tailf:mount-point and tailf:mount-point-id, but without documentation about how they work, so there also I’m unable to understand whether it’s related to what I’m looking for.

Thanks in advance for any help!


Your use case seems to match the IETF “YANG Hardware Management” RFC It defines the hardware setup in a dynamic maner similar to how you describe your use-case.
In addition, it makes use of the IETF “NMDA” RFC that ConfD currently partially support and will fully support as of ConfD 7.4 (e.g. “origin” support added) end of June.

So I recommend you make use of the IETF Hardware YANG model for your use case. The benefit of NMDA is that you will only have a single copy of the YANG model for both the manager’s intended configuration and the actual operational state desired.
If you instead want to do things the old pre-NMDA way , i.e. have both a config copy of the YANG model for the manager’s intended config and a state copy of the same YANG model for the operational state, see Appendix A. of that RFC.

Best regards

thanks a lot for the useful pointer!