Re: [netmod] Adding system configuration to running [was: Re: Comments on NMDA-04]

[Kent Watsen <[e-mail]>]

> I agree with Balazs that system-created nodes in running are quite common and
> the vendors doing it have no intention of changing it.

Of course, what else were they going to do pre-NMDA…and also before require-instance
false?  Green-field deployments wouldn't be encumbered with backwards-compatibility.
Existing implementations are in a bind, but I'd recommend following nmda-guidelines.

For UC1: the loopback would only show in <operational> (as an applied instance of a
config true leaf), and the leafref would be require-instance false.  When committing
configuration that referenced loopback, the server sees that the referenced leaf is not in
<running>/<intended>, but it could see that it is or is-not in <operational>.  And, if it
is not in <operational>, the server might return a warning to the client, or not, assuming
the  client will use other mechanisms to discover what configuration was not applied.

For UC2: similar response.  The server could return a warning (e.g., a synchronous
update) or the client can discover the unapplied config afterwards using other
mechanisms.


> If the added nodes need to be saved in non-volatile storage then then definitely
> belong in <running>.

Neither of Balazs's use-cases regard persisted data, at least I didn't read it that way.


> IMO the architecture is rather opaque wrt/ the interactions between datastores,
> especially the interactions between <running> and <intended>. Now it not only
> prunes inactive nodes, it adds system nodes?

A template in <running> could be flattened, which has the apparent side-effect
of creating nodes, but not any nodes, just those per the input from <running>.
As the draft says: <intended> does not persist across reboots; its relationship
with <running> makes that unnecessary.   Generically speaking, <running>
can contain processing instructions that are consumed at commit time to
simultaneously create the <intended> view, and these PIs are the only thing
that can cause a deviation between the two datastores.


> Maybe it is too early for NMDA to be making lots of rules about how
> YANG works with new (and unimplemented) datastores.

Juniper has the equivalent of <intended> already.  I think others said they had
something like it as well.


Kent // contributor