Re: [netconf] Adoptation of NETCONF in the field of industrial automation

[Kent Watsen <[e-mail]>]

Hi Nemanja,

> On Oct 19, 2022, at 8:02 AM, Stamenic, Nemanja <[e-mail]> wrote:
> 
> WG,
>  
> In the scope of the work on “IEC/IEEE 60802 TSN Profile for Industrial Automation” we bumped into some open questions regarding NETCONF/YANG. We would like to ask the NETwork CONFiguration Working Group for support in our effort to adoptNETCONF/YANG in the field of industrial automation. 
>  
> Our use case includes the situation in which multiple clients request to write to the <candidate> Datastore concurrently. A global lock on the <candidate> Datastore, which refuses the requests from other clients and expects the clients to retry after unknown period of time is not acceptable. We are looking for a solution for this problem which ensures consistency (no race conditions) .

Have you checked partial locks (RFC 5717) or optimistic locking (draft-lindblad-netconf-transaction-id)?   Also, be advised that the WG may define support for private candidate datastores.


> How  would you solve this problem?
I don't understand the use-case well enough.  For instance, is the client-data overlapping?  How long are the clients holding the lock for?


> What is the best practice to keep the data consistent (working with “config-true” nodes) in such use cases?
The global lock is used in practice (partial-lock never took off, AFAIK).  RESTCONF uses an optimistic lock, which some prefer.


> Does the Pipelining (RFC 6241, Section 4.5.) apply to multiple NETCONF sessions or only to calls coming from a single session?
Pipelining is for each session.
 
> Let’s assume that the problem can be solved by defining custom RPCs (RFC 7950, Section 7.14) or actions (RFC 7950, Section 7.15):
> Does the Pipelining (RFC 6241, Section 4.5.) apply to them?
> For write operations only?
> For read and write operations?
> Do the same rules apply for  single NETCONF session and for multiple sessions?

Pipelining applies to all RPCs in each NETCONF session.

> Does the <lock> operation (RFC 6241, Section 7.5.) prevent custom RPCs (RFC 7950, Section 7.14) from writing to the Datastore
> In case of “config true” nodes?
> In case of “config false” nodes?

Yes, for "config true" nodes.  It is not possible for a client to write "config false" nodes.

> Is there a mechanism within NETCONF that makes sure that “config-false” data stays consistent in the case of concurrent write operations?
> In case of custom RPCs or actions?
> In case of system local write accesses?
> In case of custom RPCs or actions and system local write accesses?

Implementation detail, per the server's backend database(s).

 
> Thank you and best regards,
> Nemanja Stamenic
> Siemens AG

Kent // contributor