[netconf] Re: comments on draft-ietf-netconf-transaction-id-06

["Jan Lindblad (jlindbla)" <[e-mail]>]

Andy,

Thank you for your comments on the transaction-id draft. See my responses below marked [janl].

From: Andy Bierman <[e-mail]>
Date: Tuesday, 1 October 2024 at 20:49
To: Netconf <[e-mail]>
Subject: [netconf] comments on draft-ietf-netconf-transaction-id-06

Hi,

I do not have time to do a full document review, but I have a few comments
on the solution approach.

[janl] Excellent, this is helpful.

The RESTCONF ETag and Last-Modified fields were adapted from HTTP to
apply to datastore contents, not abstract representations. This draft adapts
the RESTCONF mechanisms to NETCONF.

The RESTCONF solution is much simpler than this draft.
- mechanism applies to a single resource
- metadata is separate from the YANG data

[janl] Prior to the work on this draft, I was instrumental in making sure Cisco implemented a proprietary transaction-id mechanism that works on the datastore top level. We have it implemented on both the client and server sides for a wide flora of network devices. No small feat, if you ask me. Unfortunately, I have had to watch as a lot of real world users disable this feature. It draws some resources and adds roundtrips. It is susceptible to false positives, and the pay back is therefore often negative in typical large deployment real world scenarios. Mea culpa. Back to the drawing board. The result is the transaction-id draft.

There are 2 basic features derived from the txid or timestamp
1) protect configuration edits from making changes if the target data is changed
2) reduce data retrieval payloads by skipping data that has not changed

I don't think problem (1) is possible to solve for NETCONF or RESTCONF.
YANG datastores are full of cross-reference dependencies, unlike simple HTTP resources.
The txid attributes can get very complicated for a client to manage.

[janl] Since we have implemented this with promising results, the “I don't think problem (1) is possible to solve”-conclusion is somewhat overstated IMHO.

If the client provides too many txid attributes, or not deep enough,
then the edit could be rejected because data unrelated to this edit has changed.
This is especially true for cases where an ancestor container changed.

If the client does not provide enough txid attributes, then the write protection is incomplete.
There is a lot of complexity placed on the client to pick the correct nodes to tag.

[janl] You are perfectly correct in that the client has to consider carefully which txid attributes to specify. They have to correspond exactly to the client’s view of what a “configuration clash” is. Don’t place txid attributes where the client don’t care. Use wherever it’s important for the use case at hand that nothing changed. When attributes are placed properly, I do think it gives clients great ability to control the implementation of their intent.

All this work, instead of using the mandatory global locking.
For high-speed concurrent edit transactions, the private candidate approach
is much simpler and more robust for the client to use.

[janl] Yes. The need for global locking and/or the shared candidate is one of the top concerns in most of the management scenarios in my world. I agree that private candidates will fit perfectly into this picture, but without txid I don’t think it will make much difference, since global locks would have to be used anyway in scenarios with multiple clients. The basic “configuration clash” detection & resolution in the private candidate draft alone is not sufficient in my world.

For problem (2), the extensive use of attributes makes it hard to use.

[janl] Since the txid values are related to each and any of the leafs and containers in the YANG model, attributes make good sense, IMHO. This is exactly the sort of meta-level information where attributes shine.

For filtering, only the Last-Modified timestamp can be used because the txid (Etag)
does not support less-than and greater-than. It only supports equals comparisons,
so a filter for 'all the nodes changed since txid 4219' is not possible.
A filter for 'all nodes changed since a timestamp' would be useful,
but it is hard to tell if a node is missing from the reply because it was deleted
or because it has not changed since the timestamp.

[janl] I think while skimming the draft, you may have missed the Txid History concept. Search for it, you will find references throughout the document, and especially in sections 3.3, 3.4, 3.6, and 3.6.2. The point about deleted nodes is a good one, but this mechanism is the best approach I have been able to come up with.

Many thanks for taking the time to comment!

Best Regards,
/jan