Subject: Re: [netmod] Should the origin="system" be required for system configurations copied/pasted into <running>?

From: "Sterne, Jason (Nokia - CA/Ottawa)" <[email-masked]>
Date: Thu, 9 Dec 2021 16:15:23 +0000

+1. If a value was explicitly configured in <running>, that takes precedence as origin whether it matches <system> or not (just like it takes precedence as the value in <intended>).

For config that is *not* in <running>, and comes from <system>, then we should probably go with "system" as the origin.  It is a bit confusing that <system> flows into <intended>, but then some data from intended has origin=intended and some has origin=system. That effectively means origin information can be added before the data flows into intended and is passed through transparently.  Maybe the model is that unlabelled data flowing thru <intended> gets labelled with origin=intended, but anything with an origin upon entry into <intended> keeps that origin.  New datastores that get defined (e.g. <system>) that feed into <intended> can define if they tag an origin.

Jason

> -----Original Message-----
> From: netmod <[email-masked]> On Behalf Of Rob Wilton
> (rwilton)
> Sent: Wednesday, November 24, 2021 5:17 AM
> To: Juergen Schoenwaelder <[email-masked]>;
> maqiufang (A) <maqiufang1=[email-masked]>
> Cc: [email-masked]
> Subject: Re: [netmod] Should the origin="system" be required for system
> configurations copied/pasted into <running>?
> 
> +1 to Juergen's comment.
> 
> // As a contributor.
> 
> 
> -----Original Message-----
> From: netmod <[email-masked]> On Behalf Of Jürgen
> Schönwälder
> Sent: 24 November 2021 09:25
> To: maqiufang (A) <maqiufang1=[email-masked]>
> Cc: [email-masked]
> Subject: Re: [netmod] Should the origin="system" be required for system
> configurations copied/pasted into <running>?
> 
> On Wed, Nov 24, 2021 at 03:21:14AM +0000, maqiufang (A) wrote:
> >
> > But suppose the node is a list entry (e.g., an interface) or a leaf with the
> same value.  In this case, it is not clear which origin should be used.  I think it
> would be ok to use "system" in this case.
> 
> For me, <running> is explicit config and hence it has precedence. The
> precedence must be a function of how the datastores related, it should
> not depend on which values a config leaf has.
> 
> /js
> 
> --
> 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/>
> 
> _______________________________________________
> netmod mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netmod
> 
> _______________________________________________
> netmod mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netmod

---

From: "Sterne, Jason (Nokia - CA/Ottawa)" <[email-masked]>
Date: Thu, 9 Dec 2021 16:24:51 +0000

I think it may be a server implementor's choice whether they would put a loopback interface into <system> (i.e. consider it as system provisioned configuration), or into <operational> (and not system, i.e. consider it as state information).

The primary <system> config use cases I see aren't so much interfaces, cards, etc. It is more for things like built in qos profiles and other handy policy objects that are more static (e.g. like Kent's JUNOS examples he has described).  I'm not necessarily saying we preclude some of the resource-based dynamic system config proposed in the draft, but maybe those parts are more confusing/contentious.

Jason 

> Sent: Thursday, November 25, 2021 6:48 AM
> To: Rob Wilton (rwilton) <[email-masked]>
> Cc: maqiufang1=[email-masked]; [email-masked]
> I personally believe this notion of a system datastore is actually a
> bad idea. A loopback interface, for example, is system generated and
> it exists in operational but usually not in intended. I think it is
> wrong to think that a system datastore feeds into intended. After all,
> system config also comes and goes at the will of the system. I am not
> following this in detail but I fear this work likely creates more
> damage than that is solves serious real-world problems.
> 
> /js
> 
> On Thu, Nov 25, 2021 at 09:45:56AM +0000, Rob Wilton (rwilton) wrote:
> > Hi Martin,
> >
> > I think that the proposal is that <system> should feed into <intended>
> rather than directly into <operational>.  The reasoning for this is to allow
> configuration to depend on system defined configuration during validation
> without requiring that configuration to be copied into <running>.  Clients
> would still be allowed to explicitly express the system configuration is
> running as well - e.g., if they wanted a full configuration that they can
> validate off box.
> >
> > In your example below, I would probably mark the origin of the lo
> interface, the name leaf, and description leaf as "intended", but the type is
> "system".  I think that this would be similar to how I would expect a default
> value to be reported.  I.e., if the running config explicitly sets a leaf to its
> default value, I think that it is more informative to report that as origin
> "intended" rather than "origin" default.  But I don't think that RFC 8342
> proscribes what is be used in these cases.
> >
> > Regards,
> > Rob
> >
> > // As a contributor
> >
> >
> > > From: netmod <[email-masked]> On Behalf Of Martin
> Björklund
> > > Sent: 24 November 2021 10:44
> > > To: [email-masked]
> > > Cc: maqiufang1=[email-masked]; [email-masked]
> > > Jürgen Schönwälder <[email-masked]> wrote:
> > > Here's a simple example.
> > > Suppose <system> has:
> > >    <interface>
> > >      <name>lo</name>
> > >      <type>loopback</type>
> > >      <description>added by system</description>
> > >    </interface>
> > >
> > > and <intended> has:
> > >
> > >    <interface>
> > >      <name>lo</name>
> > >      <description>set by a client</description>
> > >    </interface>
> > >
> > > Now we follow the picture in RFC 8342:
> > >
> > >                       +------------+
> > >                       | <intended> | // subject to validation
> > >                       | (ct, ro)   |
> > >                       +------------+
> > >                             |        // changes applied, subject to
> > >                             |        // local factors, e.g., missing
> > >                             |        // resources, delays
> > >                             |
> > >        dynamic              |   +-------- learned configuration
> > >        configuration        |   +-------- system configuration
> > >        datastores -----+    |   +-------- default configuration
> > >                        |    |   |
> > >                        v    v   v
> > >                     +---------------+
> > >                     | <operational> | <-- system state
> > >                     | (ct + cf, ro) |
> > >                     +---------------+
> > >
> > >
> > > So now we merge intended and system into operational state.  First we
> > > add system to get:
> > >
> > >   <interface origin="system">
> > >     <name>lo</name>
> > >     <type>loopback</type>
> > >     <description>added by system</description>
> > >   </interface>
> > >
> > > and then we add intended to arrive at:
> > >
> > >   <interface origin="system">
> > >     <name>lo</name>
> > >     <type>loopback</type>
> > >     <description origin="intended">set by a client</description>
> > >   </interface>
> > >
> > >
> > > Doesn't this make sense?
> > >
> > >
> > >
> > > /martin
> > >

---

From: "Sterne, Jason (Nokia - CA/Ottawa)" <[email-masked]>
Date: Thu, 9 Dec 2021 16:27:23 +0000

> We’ve always maintained that <running> should only contain client-provided
> config, right?

+1

Or at least the clients (or at least operators of a network element) should have the option of avoiding any config appearing in the running besides what they put in there.

If config can magically appear in running, IMO that should be some optional behavior that can be turned off (or specifically requested via config, or RPCs).

> From: netmod <[email-masked]> On Behalf Of Kent Watsen
> Sent: Monday, November 29, 2021 5:50 PM
> To: Andy Bierman <[email-masked]>
> Cc: [email-masked]
> Hi Andy,
> > RFC 7950 rules about leafref validation are very clear.
> > Adding a new datastore to these rules requires a massive change to NMDA
> > and all implementations.
> 
> Not really or, rather, it seems like it would be just part of adding support for
> <system>, which implies adding support for <intended> (if not supported
> already) and doing the validation on <intended> instead.
> 
> 
> > 2) As Juergen points out, servers populate the system config in <running>
> and the operator is
> > free to ignore it, reference it, or possibly change it.  The premise of
> <system> seems to
> > be that this approach is not "pure enough" for NMDA and <running> MUST
> only contain
> > operator-created configuration. Why? What real problems would this
> change solve?
> 
> Servers populating <running> (beyond coping <startup> into <running>) has
> never been a supported idea.  We’ve always maintained that <running>
> should only contain client-provided config, right?
> 
> I’m unsure what the “change” in your last question points to.  But note that
> on JUNOS-based systems, there are many hundreds of system-defined
> nodes available to be referenced by config in <running>.  Putting all these
> nodes into <running> would clutter the config immensely.
> 
> FWIW, JUNOS “solves” this by *hiding* these system-nodes, such that
> clients must use a special command just to discover them.   And, yes, if ever
> any of these are hidden-nodes are reference, offline-validation of <running>
> will fail.  The <system> datastore being discussed effectively mimics this
> aspect of the JUNOS solution.
> 
> There is a separate thread for if *offline* validation of <running> *alone*
> must succeed.  The soft (fallback) solution is to have clients copy/paste the
> referenced-subset of the system-defined nodes into <running>.  The theory
> being that, since it’s just a subset, it won’t clutter things up too badly and, as
> it is already the case that some system-defined nodes must be copy/pasted
> into <running> in order for clients to configure descendent nodes (e.g., some
> tunable for the system-defined “lo” interface), the water is already over the
> bridge, so to speak, on the copy/pasting debate.  The only holdout  for not
> already demanding client’s also copy/paste the subset of referenced system-
> defined nodes is that it is completely unnecessary, unless trying to ensure
> offline validation of <running> alone.
> 
> 
> 
> > Andy
> 
> Kent, as a contributor.
> 
> 
>

---

From: "Sterne, Jason (Nokia - CA/Ottawa)" <[email-masked]>
Date: Thu, 9 Dec 2021 16:31:05 +0000

> will fail.  

Other implementations have a similar concept with the same consequence.

> The <system> datastore being discussed effectively mimics this

Yes - so only users/clients with this requirement would need to explicitly configure the referenced subset. Anyone else can just do nothing and continue on as they do today.

Jason

---

From: "Sterne, Jason (Nokia - CA/Ottawa)" <[email-masked]>
Date: Thu, 9 Dec 2021 16:33:07 +0000

Hi Andy,

The actual system instance data isn't in a YANG model, but that instance data sits in schema defined in the YANG model. It is typically a list entry populated by the system.  But there may also be other list entries created by the users/clients, and other areas of the YANG model may reference those lists using leafrefs.

Jason

From: netmod <[email-masked]> On Behalf Of Andy Bierman
Sent: Monday, November 29, 2021 6:14 PM
To: Kent Watsen <[email-masked]>
Cc: [email-masked]
Subject: Re: [netmod] Should the origin="system" be required for system configurations copied/pasted into <running>?

On Mon, Nov 29, 2021 at 2:49 PM Kent Watsen <[email-masked]<mailto:[email-masked]>> wrote:
Hi Andy,

> Adding a new datastore to these rules requires a massive change to NMDA

Not really or, rather, it seems like it would be just part of adding support for <system>, which implies adding support for <intended> (if not supported already) and doing the validation on <intended> instead.

> 2) As Juergen points out, servers populate the system config in <running> and the operator is
> free to ignore it, reference it, or possibly change it.  The premise of <system> seems to
> be that this approach is not "pure enough" for NMDA and <running> MUST only contain
> operator-created configuration. Why? What real problems would this change solve?

Servers populating <running> (beyond coping <startup> into <running>) has never been a supported idea.  We’ve always maintained that <running> should only contain client-provided config, right?

I’m unsure what the “change” in your last question points to.  But note that on JUNOS-based systems, there are many hundreds of system-defined nodes available to be referenced by config in <running>.  Putting all these nodes into <running> would clutter the config immensely.

FWIW, JUNOS “solves” this by *hiding* these system-nodes, such that clients must use a special command just to discover them.   And, yes, if ever any of these are hidden-nodes are reference, offline-validation of <running> will fail.  The <system> datastore being discussed effectively mimics this aspect of the JUNOS solution.

There is a separate thread for if *offline* validation of <running> *alone* must succeed.  The soft (fallback) solution is to have clients copy/paste the referenced-subset of the system-defined nodes into <running>.  The theory being that, since it’s just a subset, it won’t clutter things up too badly and, as it is already the case that some system-defined nodes must be copy/pasted into <running> in order for clients to configure descendent nodes (e.g., some tunable for the system-defined “lo” interface), the water is already over the bridge, so to speak, on the copy/pasting debate.  The only holdout  for not already demanding client’s also copy/paste the subset of referenced system-defined nodes is that it is completely unnecessary, unless trying to ensure offline validation of <running> alone.

IMO the least disruptive solution possible should be used.
There is a use-case for adding "origin" support to the <running> datastore in the <get-data> operation.
This allows an NMDA client to identify system config that is not being used in <operational>.

All "resource" oriented data models should have some mechanism to require the resources
to be utilized or enabled somehow, within the data model. Unfortunately this cannot be standardized
with a 1-size-fits-all solution.

A vendor must somehow populate these data models with origin=system data nodes.
The "hidden system" data uses proprietary logic to decide what nodes to add (and when).
This data is probably not represented with YANG models.  Transforming the hidden system data
to the appropriate YANG models in any datastore is an implementation detail, out of scope
for standardization.

Kent, as a contributor.

Andy

---

From: Kent Watsen <[email-masked]>
Date: Mon, 13 Dec 2021 21:05:33 +0000

> On Nov 30, 2021, at 3:00 AM, Jürgen Schönwälder <[email-masked]> wrote:
> 
> On Tue, Nov 30, 2021 at 02:24:52AM +0000, Kent Watsen wrote:
>> Hi Juergen,
>> 
>> 
>>> On Nov 29, 2021, at 6:49 PM, Jürgen Schönwälder <[email-masked]> wrote:
>>> 
>>> On Mon, Nov 29, 2021 at 03:14:06PM -0800, Andy Bierman wrote:
>>>> 
>>> Looking at Figure 2 of RFC 8342, I wonder how system config gets into
>>> running - other than a client writing it into running, at which point
>>> the config becomes explicit config subject to the usual update rules
>>> of <running>. Conceptually, you can have a system daemon acting as a
>>> client updating <running> (perhaps even controllable by NACM). The
>>> "origin" was not designed to track from which application config data
>>> in <running> is originating, that's to be solved by other mechanisms.
>> 
>> This idea is to mimic RFC6243’s “default” annotation and the "with-defaults" RPC.  Just like with the “explicit” mode server, if a client writes to <running> and default value w/o the annotation, the server assumes it is explicit config (not the default anymore).  Same here, if the client writes a “system” node w/o the annotation, the server assumes it is explicit config (not the <system>-defined node).  In both cases, if the client includes the appropriate annotation, and the value/node matches the default/system value, then the server assumes that it’s actually the default/system value/node.
>> 
>> FWIW, about 5 months ago (June 29), I offered this modified version of Figure 2  (Note the <system> box on the left).  The “underlay” comment is meant to imply that <running> always overrides <system> when they’re merged:
>> 
>> 
>>     +-------------+                 +-----------+
>>     | <candidate> |                 | <startup> |
>>     |  (ct, rw)   |<---+       +--->| (ct, rw)  |
>>     +-------------+    |       |    +-----------+
>>            |           |       |           |
>>            |         +-----------+         |
>>            +-------->| <running> |<--------+
>>                      | (ct, rw)  |
>>                      +-----------+
>>                            |
>> +----------+               |        // configuration transformations,
>> | <system> |-------------->|        // e.g., removal of nodes marked as
>> | (ct, ro) | // underlay   |        // "inactive", expansion of
>> +----------+               |        // templates
>>                            v
>>                      +------------+
> Your first paragraph does not match the figure. In your figure, system
> config does not go into <running> instead it goes into a magic merge
> box which is not shown (there is just an arror pointing to an arrow)
> and then the result goes into intended.

The diagram is fine (to me) and consistent with the first paragraph.  The goal of that diagram was to minimally-edit the RFC 8342 diagram.

But. more importantly, do you now understand the with-system/default-annotation relation?  If not, why not?  If so, does it make sense now?  

K.

---

From: Kent Watsen <[email-masked]>
Date: Tue, 14 Dec 2021 01:36:42 +0000

Hi Jason,

> The primary <system> config use cases I see aren't so much interfaces, cards, etc. It is more for things like built in qos profiles and other handy policy objects that are more static (e.g. like Ke…

I agree about the primary focus being on the “shared objects”…at least, that’s 90% of what’s in the JUNOS junos-defaults “datastore” (in quotes because it’s not really a datastore).

K.