Attributes sequencing in Netconf operation

Question

My device wants attribute X to be set before attribute Y. How do we implement it in an NMS/EMS?

My understanding is that irrespective of the protocol being used such as Netconf, SNMP, etc, my NMS has to send 2 SET/EDIT PDUs. But, ConfD Kick Start Guide mentioned that NMS doesn’t need to bother with the sequencing. How is that possible?

I have pasted ConfD Kick Start Guide below.

From this perspective, any requirements that certain parameters must be specified on the same command line, or must be sent in separate PDUs, or that attribute X must be sent before attribute Y are just pointless bottlenecks in the flow of ideas from the manager to device...... With a transactional interface, the network management application doesn’t need to bother with this serialization, sequencing or error recovery. With a suitable encoding like NETCONF, the whole idea can also be transferred directly, without any need to break it down into individual commands.

Answer 1

NETCONF provides the building components needed to implement transactional behavior when applying configuration changes to devices. They are built into the protocol. Your two configuration modifying PDUs may be sent in any order as parts of the same transaction or as a single PDU, which can also represent a single transaction.

The candidate datastore may be changed in steps (several operations) and changes made to it need not be valid (some constraints are not checked upon datastore content modifications), not until a commit or an explicit validation request is made - making it possible for Y to exist before X in device configuration, although unused.

It is also possible (normal) to set many configuration objects in a single operation (single <edit-config>/<edit-data>) and treat it as a single transaction with conditions in tow (set everything as requested or rollback on error, for example) - making it possible to set both X and Y at the same time and leave the sequencing issues for the device to handle.

You cannot achieve the same with SNMP unless the NMS/EMS handles all aspects of such transactional behavior itself.

This is most likely what the quoted text is referring to.

Answer 2

Just adding to an excellent answer by predi -- the YANG language has a rich set of functionality for defining which configurations are valid and which are invalid, mainly via the when statement and also via some language-level features. However, these rules do not have any level of access to the "outside world". That is, the decision whether some YANG data are valid or not valid is always deterministic, and it does not depend on any externalities. The computation of that valid/invalid depends only on the YANG model, and on a snapshot of the YANG-modeled data. There is no concept of referring to other snapshots of data (like the previous state), or to, say, current system time, and also not to the operational data such as current device temperature. This, in my opinion, is one of the strengths of the YANG language, but it indeed also imposes some limitations.