Subject: [Netconf] Does NMDA support synchronous configuration operation?

From: Henry Yu <[email-masked]>
Date: Fri, 22 Jun 2018 16:33:04 -0400

Hi all,

Does NMDA (RFC 8341) support the synchronous configuration operation,
defined in [draft-ietf-netmod-opstate-reqs-04]?

 [draft-ietf-netmod-opstate-reqs-04] and its solution
[draft-kwatsen-netmod-opstate-02] have been replaced by RFC 8341.
However, it seems that RFC 8341 only requires asynchronous config
operations. i.e., When an intended configuration is received by the
sever, it is written to <intended> once it passes the schematic
validation, and applying the configuration to devices is a separate
action. Is that a correct understanding?  (I read some discussions [3]
from the archive, but I am still not quite certain. Any clarification
is appreciated.)

Thanks,
Henry

 [draft-ietf-netmod-opstate-reqs-04]
https://tools.ietf.org/html/draft-ietf-netmod-opstate-reqs-04
[draft-kwatsen-netmod-opstate-02]
https://www.ietf.org/archive/id/draft-kwatsen-netmod-opstate-02.txt
[3] https://www.ietf.org/mail-archive/web/netmod/current/msg15113.html

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Sat, 23 Jun 2018 00:47:31 +0200

This is not really a question of NMDA as defined in RFC 8341 since RFC
8341 does not detail the protocol operations.

The edit-data operation defined in draft-ietf-netconf-nmda-netconf-06
is, in the sense of draft-ietf-netmod-opstate-reqs-04, basically
synchronous. There is no option to force it to be synchronous, i.e.,
to block until all affected components and the server's applied
configuration have been updated.

Some servers may have the property that all edit-data operations
effectively are synchronous - but then you may see errors (and perhaps
noticable delays) if you want to configure hardware that currently is
not present or slow to get updated.

/js

On Fri, Jun 22, 2018 at 04:33:04PM -0400, Henry Yu wrote:
> _______________________________________________
> Netconf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netconf

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103         <https://www.jacobs-university.de/>

---

From: Henry Yu <[email-masked]>
Date: Sat, 23 Jun 2018 18:34:58 -0400

Thanks for pointing me to draft-ietf-netconf-nmda-netconf-06.  Since
(mentioned in the draft),  "the error behaviour of <edit-data>
corresponds to the  "error-option" "rollback-on-error" ", it follows
that <edit-data> is synchrhrouous operation. Is that correct
understanding?

If so, then I have one more query. I am implementing a RESTCONF
server, and RFC 8040 does not seem to mention that RESTCONF offers the
"rollback-on-error" capability. Does that mean that RESTCONF
operations are asynchronous? i.e., I could simply implement RESTCONF
operations (PUT/POST/DELETE) as straight CRUD operations on data store
resources?

Thanks again.  Henry

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Sun, 24 Jun 2018 10:29:54 +0200

Dear Henry,

the edit-data operation is synchronous on the datastore it operates
on. This should not be confused with the application of the change to
real resources, which is in general asynchronous.

For example, if you modify the leafs A, B, and C using a single
edit-config in the <running> datastore, then all changes are applied
or none in the <running> datastore. The change of <running>, however,
does not require that all changes have propagated to <operational>. In
fact, the change of B may never propagate to <operational> if for
example B depends on resources (i.e., hardware) not present.

/js

---

From: Henry Yu <[email-masked]>
Date: Sun, 24 Jun 2018 22:24:17 -0400

Thanks a lot for the clarification, Juergen. Please allow me to check
again if my understanding is correct. Your explanation of edit-data
(as well as the example of edit-config) seems to fall into the
definition of Asynchronous Configuration Operation defined in
[draft-ietf-netmod-opstate-reqs-04]. i.e., the reply of edit-data only
indicates whether there are any errors in updating the <running>
datastore. Applying the configuration, however, is a separate
activity.

In contrast, the definition of Synchronous Configuration Operation in
[draft-ietf-netmod-opstate-reqs-04] states that "the server MUST fully
attempt to apply the configuration change to all impacted components
in the server, updating both the server's intended and applied
configuration, before replying to the client. The reply to the client
indicates whether there are any errors in the request or errors from
applying the configuration change."

What I'd like to confirm is that the RESTCONF operations (e.g.,
PUT/POST/PATCH/DELETE) fall into the definition of Asynchronous
Configuration Operation, rather than that of Synchronous Configuration
Operation. The answer would fundamentally impact our implementation of
the RESTCONF server.

Thanks again.
Henry

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 25 Jun 2018 08:21:18 +0200

Since we move to RESTCONF, the definitions of NMDA datastore resources
can be found in draft-ietf-netconf-nmda-restconf-04.txt.

My understanding is that PUT/POST/PATCH/DELETE on datastore resources
are like the NETCONF operations not blocking until changes to the
datastore have been applied to all impacted components in the server.

/js

---

From: Kent Watsen <[email-masked]>
Date: Mon, 25 Jun 2018 14:46:54 +0000

Hi Henry,

> applying the configuration change."

It is accurate that both nmda-netconf and nmda-restconf drafts do not
yet implement this "requirement" (in quotes since the opstate-reqs
draft was never published as an RFC).

Kent

---

From: Ladislav Lhotka <[email-masked]>
Date: Mon, 25 Jun 2018 16:50:19 +0200

> operations (PUT/POST/DELETE) as straight CRUD operations on data store

It would certainly be useful if RESTCONF is more explicit about these
things and gives the client more control. My individual draft

https://tools.ietf.org/html/draft-lhotka-netconf-restconf-transactions-00

is in fact a step in this direction.

Lada

-- 
Ladislav Lhotka
Head, CZ.NIC Labs
PGP Key ID: 0xB8F92B08A9F76C67

---

From: Henry Yu <[email-masked]>
Date: Mon, 25 Jun 2018 14:28:41 -0400

Hi Kent and all,

Thanks for your responses. It would be nice if the nmda-restconf (or
nmda-netconf) would provide a narrative to explicitly point out the
asynchronous behavior of the operations. Our developers have worked on
products that provide RESTful APIs for device configuration, and those
APIs are synchronous blocking calls that return to client only after
the configurations are applied to hardware. When they implement
RESTCONF server, they would naturally assume that RESTCONF operations
are also synchronous in terms of applying config to the hardware.

Thanks,
Henry

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 25 Jun 2018 21:00:14 +0200

If for certain devices configuration operations are synchronous (i.e.,
changes of <running> immediately and always lead to corresponding
changes of <operational>), then this should not be a problem for
clients that are written to deal with asynchronous behaviour.

Note that once you deal with pluggable hardware, you often loose the
synchronous behaviour since <running> and <operational> can deviate
depending on hardware resources present. (This may also be true for
pluggable software, i.e., software features controlled by licenses.)

/js

---

From: Henry Yu <[email-masked]>
Date: Mon, 25 Jun 2018 19:11:11 -0400

Hi Juergen,

On Mon, Jun 25, 2018 at 3:00 PM Juergen Schoenwaelder
<[email-masked]> wrote:
[snip snip snip]
> pluggable software, i.e., software features controlled by licenses.)

You mentioned, in an earlier response as well, that "the change of
<running>, however, does not require that all changes have propagated
to <operational>".  I interpret it as that, in case of this pluggable
hardware scenario, when client, for example, POST a configuration,
server should save it into <running>, even when the target pluggable
is unavailable. This, of course, would cause difference between
<running> and <operational>. But the POST operation itself is
successful and returns success to client.

The above would be my implementation of the server. However, some
people believe a different implementation:  that the config should not
be saved to <running> if the pluggable is unavailable. And when
pluggable is unavailable, server should fail the POST config operation
and return error to client. We need to know which implementation is
correct. That's why I asked for clarification.

Thanks,
Henry

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 26 Jun 2018 08:42:35 +0200

> correct. That's why I asked for clarification.

NMDA was designed to make it easy to expose differences between
<running> and <operational>. As said earlier, an edit-data operation
on <running> succeeds if <running> is valid after the configuration
change. It is not required that the configuration change has been
applied, i.e., is reflected in <operational>.

Systems that support pluggable hardware usually accept config for
hardware which is not present and when new hardware appears, the
config system checks whether there is matching configuration and if so
applies it. Note that the alternative where <running> always is
restricted to the (pluggable) hardware present leads to some odd
behaviour if you unplug hardware - in this case you would have to
remove config from <running> in order to keep <running> consistent
with the hardware. This will take clients by surprise and it will take
people by surprise (you unplug an interface card and you plug it back
a second later and all config has been lost).

Since you design a new implementation, I suggest you design it
following the NMDA model, i.e., the first option you describe above.
(Note that this is also the spirit of RFC 6241; the main difference
between RFC 6241 and the NMDA extension of RFC 6241 is that RFC 6241
did not expose <operational> and the notion of applied configuration.)

/js