Asynchronous operations

NETCONF
1

Hi ,

There are some operations on the device , which accepts a certain config and returns ok .
But in reality the side effects of the config are deleted in background.

Does the standard propose any notification method or return type to notify that a transaction was only partial and its not a true state ?

Any pointers towards the standards and/or have confd dealt with this before would be very helpful.

Many Thanks Experts

2

I’ll take a stab at this common issue that there has been extensive chapters in books written about. See for example http://dataintensive.net/

The strategy you choose basically depends on your use-case, although there are some fundamental rules that apply to something like 99.9% of all use-cases.

For YANG based network management protocols such as NETCONF and RESTCONF, the NMDA RFC 8343 gives an introduction https://tools.ietf.org/html/rfc8342#section-1 to the problem you describe together with the objectives section in that RFC. https://tools.ietf.org/html/rfc8342#section-2
The section on the background is very valuable too https://tools.ietf.org/html/rfc8342#section-4
The appendixes give great guidelines to various use-cases.
https://tools.ietf.org/html/rfc8342#appendix-A

As you will notice, that the device itself deletes config that a manager, e.g. a NETCONF client, has entered through a transaction makes automation of service deployments to devices/nodes very very hard. It breaks what the NETCONF standard address and makes automation significantly more complex to achieve.

Instead, your device/node should never delete configuration that a manager has set, and never set a transaction “partially”. See the “A” in “ACID” for example here: https://en.wikipedia.org/wiki/Database_transaction.
Without knowing anything about your use case, usually you have these options to choose from (or a combination) for configuration that may fail to be implemented by your device:

  1. If the transaction fail after the transaction’s “point-of-no-return”, leave the configuration as it is, and, for example, send an alarm to the manager that set the configuration so that the manager, e.g. NETCONF client become aware of the issue and can decide what to do.
  2. Test the new configuratio as part of the transaction, in for example ConfD’s validation and prepare phases, where you can still abort the transaction. Or even set the configuration in the prepare phase of the transaction, but if so, be prepared to also unset it if it is aborted by your device, but a loss of connection to the manager. or aborted by the manager.
  3. Implement the RFC 8343 NMDA intended and operational state datastores for the configuration that may fail.
  4. implement your own operational state by duplicating the YANG model for the configuration that may fail after commit, and use the *config true" configuration duplicated as “config false” nodes reflect the operational state. Appendix A of the YANG Hardware Management RFC is a nice, well described, example of such an implementation based on the hardware mgmt use-case. https://tools.ietf.org/html/rfc8348#appendix-A

So rule0: never touch/change the manager / client owned running(/intended) data store configuration. Instead, use verification phases of a transaction, alarms, and operational state data to reflect the operational status of the managers, e.g. NETCONF client, intended configuration

3

@cohult

Thanks a lot.
Will take a read.

4

Thanks Cohult,

So im trying to understand controllers action here.
My understanding is that with the NDMA architecture , the operational and config state can vary .
From the controller point of view ,
Is it expected to query the state ?
Does server need to send an indication that the operational state is different so it should query back.

Just cant envision the flow starting from client config.

Thanks again in advance @cohult

5

@cohult,

Just a reminder . Just wanted to know if you are aware how the controller is expected to use this multiple stores ?

6

Poll or use notifications.

Regarding notifications, either you write your own notifications:
See https://tools.ietf.org/html/rfc8639
examples.confd/netconf_notifications_rfc_8639/

Or you wait for ConfD.74-7.5 YANG Push
See https://tools.ietf.org/html/rfc8641

1 Like