Subject: Re: [netconf] draft-lindblad-netconf-transaction-id

From: "Rob Wilton (rwilton)" <[email-masked]>
Date: Wed, 6 Oct 2021 13:26:47 +0000

// As a contributor

I can see benefits/simplifications for the client if there can be client allocated ids/labels, particularly for the more eventual-consistency based configuration models.

I was wondering if another way of thinking about this would be for the server to allocate unique transaction ids, but optionally allow the client to provide a transaction label with the edit-config request.  Allocation of the labels would be up to the client(s) and the server would not check that they are unique.

Yes, the server would need extra memory to store the labels (but only once for each label, and they should be small), they could be optional to support, and even if they are supported then the server could limit the size of labels that it is willing to support.  If we do support them, then I would suggest a minimum label length that all supporting servers must allow (e.g., 32 chars?).

When making a get/get-data/get-config request, the client could choose whether to have the server’s transaction-id and/or client’s transaction-label returned alongside the configuration as YANG meta-data.

Lastly, Jan, I note that you are suggesting that the transaction-id only goes as far as lists/containers and not leaves.  I can see how this would make server implementations easier or more efficient, but this potentially adds complexity to the client, and allowing the transaction-id to be bound all the way down to specific config leaves would probably make client implementations easier and more generic.

Rob

From: netconf <[email-masked]> On Behalf Of Jan Lindblad (jlindbla)
Sent: 30 September 2021 11:24
To: Kent Watsen <[email-masked]>; Andy Bierman <[email-masked]>; Benoit Claise <[email-masked]>
Cc: [email-masked]
Subject: Re: [netconf] draft-lindblad-netconf-transaction-id

Kent, Andy, Benoit, WG,

Kent wrote:

Clarifying my earlier “exact match” statement: I wish it to be possible that that server supporting both NC and RC may implement one (NC or RC) on top of the other.  The HTTP ETag/Timestamp attributes are quite good and absolutely trounces RFC 5717 partial locking when the attributes are sprinkled throughout the data tree.  RC lacks locks, which prevents both 2-phase commits (and efficient successive bulk-updates), so likely RC is on top of NC for now.  [Aside: several proposals for adding locks to RC have been floated on the list in the past, but never pick up enough traction.  I’m still optimistic that this will occur someday.]

Yes, I agree that makes good sense. There will be some aspects that are NC specific because of the differences between NC and RC. Then we have the debate about which party assigns the txids. I'm fine with that as an optional feature, that some server implementors support. This rides on top and would be compatible with the RC ETag solution.

Customer transaction tracking, which I’m not opposed to, is a different kind of problem.  That said, I don’t think such an ID should be used for consistency checking, for reasons Andy mentioned, as well as because it differs from RC.

The main reason for me proposing that clients should have the possibility to assign the txids are efficiency. In high cadence management scenarios, forcing clients to wait for (slow) servers is not very scalable. The possibility to tag transactions with service order numbers (or whatever) is a real world feature already implemented by some servers because of customer demand.

Andy wrote:

I am trying to understand this new feature.
It seems locking is not involved.
It the client has the config locked then nobody else can change it,
so IfMatch and ETags are not needed.

It seems to me that you assume locks would be held for extended periods of time. That is not the case in the use cases I work with. An orchestrator client is not going to hold locks towards thousands of servers ever, and not going to hold locks for any extended period of time even towards the few servers involved in a current transaction.

The client would take a lock in order to obtain the current txid and ensure it is still valid a moment later when following up with an edit-config (assuming the txid matched the client's expectation).

Even with a If-Match feature implemented, the client would probably lock the server, just to get transactional behavior between the edit-config, validate, commit and confirm.

If locking is not used, then the ETag becomes relevant.
The client (1) retrieves the resource with its current ETag and
(2) creates an edit based on the returned data node values.
Then it can (4) send an edit with If-Match(etag). The server rejects
the edit if the resource was changed since (1).

The timeline with steps (1), (2) and (4) matches the use case I have in mind, but I think it may be worth pointing out that (1) may happen quite some time before (2), say 17 days. Not a stretch of time you'd like to keep a lock for.

If the client sends an edit with If-Match(my-etag-value) then it will always
fail because the current target resource ETag has a different value and the If-Match
test will not pass.  That seems to be the biggest problem with client-provided ETags

There are two mechanisms at play here. One is the If-Match feature, where the client can adorn the edit-config with transaction ids for select containers, lists and list entries. If the server sees that any of them are amiss, the transaction is aborted. This is similar to how things already work in RFC8040, except that only one If-Match header can be supplied in RC. That approach needs a bit of translation in NC. I propose to use attributes, and in that case we might as well allow adding more than one If-Match attribute.

If the server goes through with the edit-config, it needs to update the ETag and timestamp value of all changed nodes. It could either make up a random value, or it could accept a suggestion from the client, if provided. There are use cases where allowing the client to suggest the new value makes a big difference in scalability.

Andy also wrote:

The only way the client can be sure the config has not changed is to lock it,
and so the transaction-id is irrelevant.  Whether the client is reading the current txid
or setting a new artificial txid, no other client can change anything in the locked config.
So if this client can decide what edit to send. No other edit can show up instead
so picking the id does not help.

See discussion about locks above.

Retrieving the current txid does not take minutes, but rather milliseconds.
Operations (like lock) could be replaced so the current ID is returned,
removing even this 1 roundtrip.

While removing roundtrips is always nice (and this roundtrip would be removed by the proposed draft), I'm not worried about this roundtrip. That is not the point here.

Does the server check the txid to see if it is already used, or just allow the id
to be used over?

There is no such check in the proposal. If a client wants to do this for whatever (good or bad) reason, I don't see this being important enough to prevent.

What if 2 clients happen to pick the same id?

I'd say that's the client's problem.

What if the server has storage size limits?
Storage of an arbitrary string for every transaction can use a lot of memory.

All servers I have worked with have had a storage size limit. Clients that don't need the ability to assign the txid are free not to. If that saves any measurable amount of memory is unclear to me, but I do know that quite a few NC users out there today, when given the choice, have decided that these are bytes well worth spending.

Benoit wrote:

I believe that a single per server top-level id solves one of my specific problem.
The router config was just changed, who is responsible for that?
Or going back in the past, I start to see weird behaviours in my network today at 2:00 AM. Who was the last client who modified the config, what was the transaction Id => let me review the applied changes.
...
I'd like to think about the following lines: the client assigns the transaction Id (as you proposed) but the server keeps the following mappings:
    - a single increasing id per server +associated time
    - which client applied the modification, along with transaction Id (ideally a service Id)
    - and maybe more info such as the "touched" subtree, the protocol (NETCONF, RESTCONF), the status (finished, ongoing, etc.)
So basically a YANG module in the server.
Add the on-change notification on the above YANG module, for communication with an entity monitoring the network state (which is, most of the time, NOT the orchestrator/controller) and we would have a flexible solution.

I agree that the functionality you describe is useful and note that many servers implement something proprietary along these lines. I also think that the transaction-id mechanism would a good base component to import into a standard model for this purpose. The transaction-id draft is a NETCONF specific, low-level protocol mechanism. I think much of the functionality you describe here should go in a separate module, and probably discussed in NETMOD.

Best Regards,
/jan

---

From: "Jan Lindblad (jlindbla)" <[email-masked]>
Date: Wed, 6 Oct 2021 13:35:09 +0000

Andy, all,

Kent wrote:

Andy wrote:

I am not aware of any actual usage of RFC 5717.

I agree, I don't see this being used much at all.

Global locking is too coarse a lock and rarely gets used.

Very coarse indeed, but I do see datastore locks being heavily used for the duration of a single transaction, i.e. from discard-changes to confirming commit.

The lightweight edit collision detection provided by the well-known ETag
and associated headers like If-Match could be useful in NETCONF.

Excellent, I agree.

What I would be curious to understand is how you envision this to be mapped to NETCONF. I think everybody who said something on this thread more or less agrees that we need RC's ETag approach in NC. The question is just exactly what that means, since NC isn't RC. How would you propose to implement this mechanic in NC?

Adding a comment to an edit transaction does not really provide any consistency checking.
It is completely unrelated to the problem of detecting changes to a target resource or datastore
due to multiple clients modifying the configuration at once.

Yes, I wouldn't associate this consistency checking, but it could provide quite useful as input to audit trails. I think we can leave this part of the discussion for later, however. We may need to set the foundations straight before we discuss the color of the icing.

Best Regards,
/jan

---

From: "Jan Lindblad (jlindbla)" <[email-masked]>
Date: Wed, 6 Oct 2021 13:46:57 +0000

Rob,

// As a contributor

That works for me, as long as the/some If-Match mechanism could be used towards the labels.

I'm not against tracking individual leafs per se, but it wouldn't come for free. In the proposal I settled for containers and list elements because I worried that the communications cost would be quite high if we track changes at this very fine grained level. In the "real world" trace I used for getting some numbers on this, the communications overhead for this mechanism would increase dramatically if every leaf was tracked, I believe.

Best Regards,
/jan

From: netconf <[email-masked]<mailto:[email-masked]>> On Behalf Of Jan Lindblad (jlindbla)
Sent: 30 September 2021 11:24
To: Kent Watsen <[email-masked]<mailto:[email-masked]>>; Andy Bierman <[email-masked]<mailto:[email-masked]>>; Benoit Claise <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [netconf] draft-lindblad-netconf-transaction-id

Kent, Andy, Benoit, WG,

Kent wrote:

Andy wrote:

Andy also wrote:

Benoit wrote:

Best Regards,
/jan

_______________________________________________
netconf mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/netconf

---

From: Andy Bierman <[email-masked]>
Date: Wed, 6 Oct 2021 10:02:39 -0700

On Wed, Oct 6, 2021 at 6:35 AM Jan Lindblad (jlindbla) <[email-masked]>
wrote:

> Andy, all,
>
> Kent wrote:
>
> Clarifying my earlier “exact match” statement: I wish it to be possible
>> that that server supporting both NC and RC may implement one (NC or RC) on
>> top of the other.  The HTTP ETag/Timestamp attributes are quite good and
>> absolutely trounces RFC 5717 partial locking when the attributes are
>> sprinkled throughout the data tree.  RC lacks locks, which prevents both
>> 2-phase commits (and efficient successive bulk-updates), so likely RC is on
>> top of NC for now.  [Aside: several proposals for adding locks to RC have
>> been floated on the list in the past, but never pick up enough traction.
>> I’m still optimistic that this will occur someday.]
>>
>
> Andy wrote:
>
> Very coarse indeed, but I do see datastore locks being heavily used for
> the duration of a single transaction, i.e. from discard-changes to
> confirming commit.
>
> What I would be curious to understand is how you envision this to be
> mapped to NETCONF. I think everybody who said something on this thread more
> or less agrees that we need RC's ETag approach in NC. The question is just
> exactly what that means, since NC isn't RC. How would you propose to
> implement this mechanic in NC?
>

The most interoperable approach is to have a single config-id that is
applied
to the entire datastore. Then a single if-match input parameter refers to
this config-id.
This is workable if the device is not edited often by multiple clients. If
the server rejects
the if-match request, then the client can use global locks, check the
diffs, etc.
Most of the time an if-match failure will mean that a <get-config> is
needed (because another client changed something).

For per-node if-match testing, an if-match attribute that applied to the
node containing the attribute
could be used.  The mechanisms for retrieving and testing an opaque
resource-id are quite simple.
Maybe this is good enough and specifying how a server is supposed to change
the per-node resource ID
over time is out of scope. That is not simple, especially since edit-config
implementations can vary so much.

Andy

> Customer transaction tracking, which I’m not opposed to, is a different
>> kind of problem.  That said, I don’t think such an ID should be used for
>> consistency checking, for reasons Andy mentioned, as well as because it
>> differs from RC.
>>
>
> Yes, I wouldn't associate this consistency checking, but it could provide
> quite useful as input to audit trails. I think we can leave this part of
> the discussion for later, however. We may need to set the foundations
> straight before we discuss the color of the icing.
>
> Best Regards,
> /jan
>
>

---

From: "Jan Lindblad (jlindbla)" <[email-masked]>
Date: Thu, 7 Oct 2021 14:35:19 +0000

Andy, all,

Excellent, I agree.

The most interoperable approach is to have a single config-id that is applied
to the entire datastore. Then a single if-match input parameter refers to this config-id.
This is workable if the device is not edited often by multiple clients. If the server rejects
the if-match request, then the client can use global locks, check the diffs, etc.
Most of the time an if-match failure will mean that a <get-config> is
needed (because another client changed something).

I agree that the single top-level transaction id is a good solution for an interesting class of servers and use cases.

It is absolutely not sufficient for the class of servers and use cases I care most about, however. In fact, this mechanism is counter productive in many cases. There are many servers that support some proprietary top-level transaction id mechanism already, and many of our users are turning this feature off. In their environment, it only slows things down, with no upside. In this class of use cases, a full get-config resync every time the top level txid has moved is just not scalable. Instead they turn off the txid check, and hope for the best (and use other techniques for detecting and handling possible client change collisions).

What I'm looking for is a solution that can easily scale from a single top-level txid, to a few per subsystem txids, to txid per interface and subinterface, or whatever other units make sense. Possibly all the way to txid per individual leaf, as suggested by Rob.

For per-node if-match testing, an if-match attribute that applied to the node containing the attribute
could be used.  The mechanisms for retrieving and testing an opaque resource-id are quite simple.

Could you maybe spend a few minutes to sketch this out? This sounds very much like what I proposed, but I'm not sure I follow exactly, and I'm definitely interested in getting suggestions.

Maybe this is good enough and specifying how a server is supposed to change the per-node resource ID
over time is out of scope. That is not simple, especially since edit-config implementations can vary so much.

/jan

Best Regards,
/jan

---

From: Andy Bierman <[email-masked]>
Date: Thu, 7 Oct 2021 10:37:25 -0700

On Thu, Oct 7, 2021 at 7:35 AM Jan Lindblad (jlindbla) <[email-masked]>
wrote:

> I agree that the single top-level transaction id is a good solution for an
> interesting class of servers and use cases.
>
> It is absolutely not sufficient for the class of servers and use cases I
> care most about, however. In fact, this mechanism is counter productive in
> many cases. There are many servers that support some proprietary top-level
> transaction id mechanism already, and many of our users are turning this
> feature off. In their environment, it only slows things down, with no
> upside. In this class of use cases, a full get-config resync every time the
> top level txid has moved is just not scalable. Instead they turn off the
> txid check, and hope for the best (and use other techniques for detecting
> and handling possible client change collisions).
>

Datastore validation can be complicated and not at all compatible with the
desire to
treat individual (random) edits as transactions.  Concurrent datastore
transactions
are even more complicated and not in scope.  I agree with Kent that we
should
limit the scope to the mapping of the RESTCONF If-Match feature.

> What I'm looking for is a solution that can easily scale from a single
> top-level txid, to a few per subsystem txids, to txid per interface and
> subinterface, or whatever other units make sense. Possibly all the way to
> txid per individual leaf, as suggested by Rob.
>

IMO only containers and lists should be in scope.
Leaf-level support is possible but should be optional or left out.

> Could you maybe spend a few minutes to sketch this out? This sounds very
> much like what I proposed, but I'm not sure I follow exactly, and I'm
> definitely interested in getting suggestions.
>
>
It is similar to your proposal I think

1) augment retrieval operations to add <with-resource-ids /> input parameter
2) add metadata attribute "resource-id" that is used to specify the current
resource-id for a data node
3) add metadata attribute "if-match" that is used in <edit-config> in the
data nodes
    for lists and containers
4) When processing the <edit-config> request, the server compares the
if-match="xyz" to the
current resource-id for the node. All if-match tests must pass or the
entire edit is rejected.

Note that this only works for merge and replace.
The client should continue to rely on operation="create" (or "delete") to
test for these edit collision types.

> the per-node resource ID
> over time is out of scope. That is not simple, especially since
> edit-config implementations can vary so much.
>
>
>
>
>
> /jan
>

Andy

---

From: "Jan Lindblad (jlindbla)" <[email-masked]>
Date: Fri, 8 Oct 2021 09:18:06 +0000

Andy, WG,

Datastore validation can be complicated and not at all compatible with the desire to
treat individual (random) edits as transactions.  Concurrent datastore transactions
are even more complicated and not in scope.  I agree with Kent that we should
limit the scope to the mapping of the RESTCONF If-Match feature.

The draft proposal is not changing anything related to transaction validation.

The use case I'm interested in involves concurrency on the network level, i.e. there are several clients in the network, and they work asynchronously side by side. I expect clients to use the server's datastore lock(s) to prevent concurrent edits towards that server, so I don't see any concurrent transactions towards any specific server.

This feels very reasonable to me.

I'd be happy to run some experiments around this as well. There is a kind of beauty with going all the way. Before we decide what to do about txid for individual leafs, I think we should collect some more (performance) data.

Very good, thanks for sharing your thoughts.

Would this operation flag mean that the server should report all the txids it keeps within the scope of the data the operation returns?

2) add metadata attribute "resource-id" that is used to specify the current resource-id for a data node

I read this as matching the draft proposal (albeit using a different name of the attribute).

3) add metadata attribute "if-match" that is used in <edit-config> in the data nodes
    for lists and containers

I read this as matching the draft proposal (albeit using a different name of the attribute).

4) When processing the <edit-config> request, the server compares the if-match="xyz" to the
current resource-id for the node. All if-match tests must pass or the entire edit is rejected.

I read this as matching the draft proposal.

Create and delete operations should definitely continue to have their traditional meaning, but I don't see why an if-match attribute could not apply to a delete operation. "Reject the transaction if the object about to be deleted do not bear the expected txid"?

Best Regards,
/jan

/jan

Andy

Best Regards,
/jan

---

From: Andy Bierman <[email-masked]>
Date: Fri, 8 Oct 2021 11:22:09 -0700

On Fri, Oct 8, 2021 at 2:18 AM Jan Lindblad (jlindbla) <[email-masked]>
wrote:

>> I agree that the single top-level transaction id is a good solution for
>> an interesting class of servers and use cases.
>>
> The use case I'm interested in involves concurrency on the network level,
> i.e. there are several clients in the network, and they work asynchronously
> side by side. I expect clients to use the server's datastore lock(s) to
> prevent concurrent edits towards that server, so I don't see any concurrent
> transactions towards any specific server.
>
>

I am not convinced NETCONF really needs a partial solution like If-Match
and not interested
in starting any standards effort for concurrent transactions.

> I'd be happy to run some experiments around this as well. There is a kind
> of beauty with going all the way. Before we decide what to do about txid
> for individual leafs, I think we should collect some more (performance)
> data.
>
> Would this operation flag mean that the server should report all the txids
> it keeps within the scope of the data the operation returns?
>

In order for an ETag mechanism to work, the server must remember the
current value for a data node.
This parameter would mix with the other filter parameters, like
with-defaults.

> Create and delete operations should definitely continue to have their
> traditional meaning, but I don't see why an if-match attribute could not
> apply to a delete operation. "Reject the transaction if the object about to
> be deleted do not bear the expected txid"?
>
>

You are right.  It adds "delete only if exists and this etag", to "delete
only if exists".
It cannot be used for create.

Andy

>>> Yes, I wouldn't associate this consistency checking, but it could
>>> provide quite useful as input to audit trails. I think we can leave this
>>> part of the discussion for later, however. We may need to set the
>>> foundations straight before we discuss the color of the icing.
>>>
>>> Best Regards,
>>> /jan
>>>
>>
>

---

From: "maqiufang (A)" <[email-masked]>
Date: Sat, 9 Oct 2021 14:27:33 +0000

Hi, all:
For the containers and lists level (and even per-leaf level) resource-ID, do we assume that the server maintains the resource-IDs for all config-true containers and lists, or only some of them?
If there is only one list B as the sub-hierarchy  of a container A, maintaining an ID either for container A or for list B seems enough.
If some containers/lists may have resource-ID associated, others may not, do we need some mechanism to enable/disable a resource-ID for a container/list dynamically?

And I am also wondering whether it is possible for the datastore level resource-ID to provide a potential solution for datastore transactions(e.g., the server compares a ID XXX in the “if-match=XXX” to the resource-ID of datastore it maintained when receiving a <commit> operation)…

Best Regards,
Qiufang Ma

From: netconf [mailto:[email-masked]] On Behalf Of Andy Bierman
Sent: Saturday, October 9, 2021 2:22 AM
To: Jan Lindblad (jlindbla) <[email-masked]>
Cc: [email-masked]
Subject: Re: [netconf] draft-lindblad-netconf-transaction-id

On Fri, Oct 8, 2021 at 2:18 AM Jan Lindblad (jlindbla) <[email-masked]<mailto:[email-masked]>> wrote:
Andy, WG,

I am not convinced NETCONF really needs a partial solution like If-Match and not interested
in starting any standards effort for concurrent transactions.

In order for an ETag mechanism to work, the server must remember the current value for a data node.
This parameter would mix with the other filter parameters, like with-defaults.

You are right.  It adds "delete only if exists and this etag", to "delete only if exists".
It cannot be used for create.

Best Regards,
/jan

Andy

/jan

Andy

Best Regards,
/jan

---

From: "Jan Lindblad (jlindbla)" <[email-masked]>
Date: Mon, 11 Oct 2021 12:09:08 +0000

Andy, Qiufang, all,

Qiufang wrote:

The draft states that it is up to the server implementor to decide which containers and list entries that support this feature.

If you are the server implementor, I think it should be up to you to decide where to maintain the txid. Having said that, I actually think there are strong reasons to maintain a txid on each list entry *as well as* on the surrounding container. Maintaining a txid on the surrounding container will save a lot of communications and computations when there is no change to any list entry, and the list contains many entries; a frequently occurring situation.

I have not come across a use case where this would be beneficial, but I would be eager to learn about yours.

You mean as a way to remove the need for the lock operation? Yes, I suppose that would be possible. Let's discuss.

Andy wrote:

I don't quite understand this comment. Could you elaborate? What does "partial solution" refer to? Based on your previous comments, I don't believe you mean to say global or partial locking is the solution to handling multiple clients, and if RESTCONF's If-Match isn't either, then I'm not sure what you have in mind.

and not interested

As far as I can tell, nobody is suggesting work on concurrent transactions towards a single server. In a large network, there may be clients executing concurrent transactions towards disjunct groups of servers. That is nothing new, just an observation.

Yes, I believe we are in agreement on this point as well as bullets 1-4 above. In the draft I wrote something slightly different on bullet 1, but what you write could work too.

Best Regards,
/jan

---

From: Andy Bierman <[email-masked]>
Date: Mon, 11 Oct 2021 09:25:03 -0700

On Mon, Oct 11, 2021 at 5:09 AM Jan Lindblad (jlindbla) <[email-masked]>
wrote:

> Andy, Qiufang, all,
>
> Qiufang wrote:
>
> For the containers and lists level (and even per-leaf level) resource-ID,
> do we assume that the server maintains the resource-IDs for all config-true
> containers and lists, or only some of them?
>
>
> The draft states that it is up to the server implementor to decide which
> containers and list entries that support this feature.
>
> If there is only one list B as the sub-hierarchy  of a container A,
> maintaining an ID either for container A or for list B seems enough.
>
>
> If you are the server implementor, I think it should be up to you to
> decide where to maintain the txid. Having said that, I actually think there
> are strong reasons to maintain a txid on each list entry *as well as* on
> the surrounding container. Maintaining a txid on the surrounding container
> will save a lot of communications and computations when there is no change
> to any list entry, and the list contains many entries; a frequently
> occurring situation.
>
> If some containers/lists may have resource-ID associated, others may not,
> do we need some mechanism to enable/disable a resource-ID for a
> container/list dynamically?
>
>
> And I am also wondering whether it is possible for the datastore level
> resource-ID to provide a potential solution for datastore
> transactions(e.g., the server compares a ID XXX in the “if-match=XXX” to
> the resource-ID of datastore it maintained when receiving a <commit>
> operation)…
>
>
> You mean as a way to remove the need for the lock operation? Yes, I
> suppose that would be possible. Let's discuss.
>
> Andy wrote:
>
> I don't quite understand this comment. Could you elaborate? What does
> "partial solution" refer to? Based on your previous comments, I don't
> believe you mean to say global or partial locking is the solution to
> handling multiple clients, and if RESTCONF's If-Match isn't either, then
> I'm not sure what you have in mind.
>

The If-Match solution is not going to work if there are lots of edits from
multiple clients.
If any of the clients are not using If-Match then their edits will go
through while the clients
constantly getting If-Match failures will get effectively locked out.
This is even worse for the use-case of long duration edits.

This mechanism works in REST because it operates on 1 resource and the
resources are independent of each other.  A YANG datastore is not a
collection
of independent resources.

Andy

> As far as I can tell, nobody is suggesting work on concurrent transactions
> towards a single server. In a large network, there may be clients executing
> concurrent transactions towards disjunct groups of servers. That is nothing
> new, just an observation.
>
> Yes, I believe we are in agreement on this point as well as bullets 1-4
> above. In the draft I wrote something slightly different on bullet 1, but
> what you write could work too.
>
> Best Regards,
> /jan
>
>

---

From: "maqiufang (A)" <[email-masked]>
Date: Tue, 12 Oct 2021 09:50:34 +0000

Hi, Andy, Jan, all:

Please see my reply inline.
From: Andy Bierman [mailto:[email-masked]]
Sent: Tuesday, October 12, 2021 12:25 AM
To: Jan Lindblad (jlindbla) <[email-masked]>
Cc: maqiufang (A) <[email-masked]>; [email-masked]
Subject: Re: [netconf] draft-lindblad-netconf-transaction-id

On Mon, Oct 11, 2021 at 5:09 AM Jan Lindblad (jlindbla) <[email-masked]<mailto:[email-masked]>> wrote:
Andy, Qiufang, all,

Qiufang wrote:

I have not come across a use case where this would be beneficial, but I would be eager to learn about yours.
[Qiufang Ma] I think we are in agreement that the server is not required to maintain that resource-ID/txid for all the containers and list elements.
If there are multiple clients handling the same NETCONF server simultaneously, each client may have its own interest and care about a particular part of the configuration, which may involve the update of an overlapping part of the datastore. It seems reasonable to only maintain revision ids for overlapping sections of configuration data nodes.
Alternatively, a client can enable this resource-ID/txid  for the configuration it is interested in, given that it may need to know if the configuration has changed since last connection. And it can disable this feature when it’s no longer interested.
Such an “versioned feature” enable/disable mechanism for privileged client might be more flexible. But I think this can also be designed by a server implementor according to certain guidelines.

You mean as a way to remove the need for the lock operation? Yes, I suppose that would be possible. Let's discuss.
[Qiufang Ma] From my perspective, locking operation can be really inefficient sometimes. Thinking about a safe <commit> operation, both <candidate> and <running> need to be locked. And there is a possibility to cause deadlock. E.g., client A holds the lock of <candidate> and waits for client B to release the lock of <running>, while client B holds the lock of <running>, waiting for client A to release the lock of <candidate>.
Thinking about a commit operation that does not need to be locked, Perhaps it requires the resource-ID/txid values of both <running> and <candidate>. The server can reject a new commit operation if it has accepted a commit RPC which has not been canceled or confirmed. Make sense?

Andy wrote:

The If-Match solution is not going to work if there are lots of edits from multiple clients.
If any of the clients are not using If-Match then their edits will go through while the clients
constantly getting If-Match failures will get effectively locked out.
This is even worse for the use-case of long duration edits.
[Qiufang Ma] If there are lots of edits from multiple clients, a finer grained level(e.g., per-leaf) may avoid if-match failure as much as possible. But other costs(e.g., storage, communication bandwidth) must also be taken into consideration.

Best Regards,
Qiufang Ma

This mechanism works in REST because it operates on 1 resource and the
resources are independent of each other.  A YANG datastore is not a collection
of independent resources.

Andy

and not interested

Best Regards,
/jan

---

From: "Jan Lindblad (jlindbla)" <[email-masked]>
Date: Tue, 12 Oct 2021 21:26:58 +0000

Qiufang, Andy, all,

Thanks a lot for your comments. My thoughts inline.
If some containers/lists may have resource-ID associated, others may not, do we need some mechanism to enable/disable a resource-ID for a container/list dynamically?

Interesting. I must confess I have not thought about this possibility before. While I think it sounds a bit complicated, both for server and client, and also for ensuring clients do not step on each other when deciding what to track, I do see real world appeal with this line of thought.

You mean as a way to remove the need for the lock operation? Yes, I suppose that would be possible. Let's discuss.
[Qiufang Ma] From my perspective, locking operation can be really inefficient sometimes. Thinking about a safe <commit> operation, both <candidate> and <running> need to be locked. And there is a possibility to cause deadlock. E.g., client A holds the lock of <candidate> and waits for client B to release the lock of <running>, while client B holds the lock of <running>, waiting for client A to release the lock of <candidate>.
Thinking about a commit operation that does not need to be locked, Perhaps it requires the resource-ID/txid values of both <running> and <candidate>. The server can reject a new commit operation if it has accepted a commit RPC which has not been canceled or confirmed. Make sense?
Very good comments. I agree about the deadlock possibility, but it's not something I see often in the real world so far. Still, would be nice to eliminate. Removing the lock opens up for one client's edit-config\/validate\/commit two-phase (or edit-config\/validate\/commit\/confirm three-phase) transaction sequence being jumbled up with another client's. While the txid would detect that, restarting the transactions would not come for free. I'm not sure this would give better/faster results than plain locking. Do you think it's worth doing some simulations/measurements around this?

Yes, I agree with Qiufang here. Clearly, a single top level txid does not work well in the presence of multiple clients working side by side towards the same servers. I know many users who have access to a top level txid mechanism turn it off for just this reason. Something more fine grained is required to deal with this use case; a mainstream use case in my world. Partial proprietary solutions exist and are in wide use, so we know that something like this is feasible and effective in production networks.

You may not believe it, but a lot of people are running rather huge networks with multiple clients asynchronously working towards the same set of servers. I'm not saying it's easy to design the management systems, and I'm not saying there aren't issues and breakdowns, but I am saying that it's a real world requirement. It would be great to improve the coping strategies in production use today with a standards based mechanism like If-Match.

Best Regards,
/jan