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

[Juergen Schoenwaelder <[e-mail]>]

On Mon, Jun 25, 2018 at 07:11:11PM -0400, Henry Yu wrote:
> Hi Juergen,
> 
> On Mon, Jun 25, 2018 at 3:00 PM Juergen Schoenwaelder
> <[e-mail]> wrote:
> >
> [snip snip snip]
> >
> > 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.)
> 
> 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.

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

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: [phone]         Campus Ring 1 | 28759 Bremen | Germany
Fax:   [phone]         <https://www.jacobs-university.de/>