Subject: Re: [netmod] system configuration sync mechanism

From: "maqiufang (A)" <[email-masked]>
Date: Thu, 1 Jul 2021 13:41:52 +0000

Hi, Kent:

From: Kent Watsen [mailto:[email-masked]]
Sent: Wednesday, June 30, 2021 6:51 AM
To: maqiufang (A) <[email-masked]>
Cc: [email-masked]; [email-masked]
Subject: Re: system configuration sync mechanism

[CC-ing NETMOD, as I think this discussion belongs on that list...please consider removing NETCONF in your reply]
[Qiufang Ma] Thanks, accepted.-:)

Hi Qiufang,

Hi, Kent:
Thanks for kicking off some discussion around this draft. Please see my reply inline.

I'm interested in this work, as it seems as if the <system> datastore was left out of the NMDA work.

1) I wish there were more examples, especially for "resource-independent” configuration.  I understand well enough "resource-dependent" (dynamic) configuration, but am unclear about what all "resource-independent” entails.  By example, JUNOS has a concept called “JUNOS defaults”, which is effectively read-only and hidden-by-default configuration that, most times, must be referenced in order to take effect.   For instance, check the examples halfway down this page: https://nextheader.net/2016/06/10/junos-defaults-group.  Is this similar to what you have in mind?
[Qiufang Ma]  Yes. Physical-resource-independent system configuration is generated when the device is powered on and has nothing to do with the physical resource. Loopback interface may be the most common physical-resource-independent system configuration. To my knowledge, many vendors ((e.g., Huawei NE40E and Cisco IOS XR) will provide several predefined user groups and/or task groups which are used for authentication, authorization and accounting (AAA) services. Since these configurations are provided by the device/system, they could  be treated as system configuration. I think your  information about the predefined hidden configuration group which contains preconfigured values should also be treated the same.
More examples about system configurations would be worked on and added in  the next version of the draft.:)

Right, the loopback interface is a common example but, more generally, I think "resource-independent” configuration might fall into exactly two categories:

            1) config that is “applied” immediately
                        - ex: interfaces/lo0/unit 0/family [ inet inet6 ]
                        - ex: system/login/password/minimum-length=6
                        - ex: system/ports/console-type=vt100
                        - ex: system/syslog/archive-size=256k;
                        - ex: chassis/cluster/fabric-monitoring/heartbeat-interval=1000;
                        - ex: security/zones/security-zone/junos-host;
                        - ex: security/alg/sip/inactive-media-timeout=120;

            2) config that is “applied” only after being referenced by other config (e.g., ACLs)
                        - ex: applications/ftp/…
                        - ex: applications/tftp/...
                        - ex: applications/smtp/…
                        - ex: utm/custom-objects/Adult_Material/...
                        - ex: utm/custom-objects/Religion/...
                        - ex: utm/custom-objects/Gambling/…
[Qiufang Ma] I don’t quite understand this kind of configuration, could you please expand? Do you mean that the predefined configurations  for a certain application(e.g., ftp) will not take effect until being referenced/enabled? I am wondering if these configuration will present in the <operational>(which contains all the configuration actually used by the device) before they’re referenced.

It would be good if we could determine if there are any other "resource-independent” configuration categories here.
[Qiufang Ma] Do you think there exists conditional system configuration(if the preceding configurations you mentioned above is not)? For example, if SSH is enabled on a device, SSH-related keys are automatically generated. Such configurations are generated at the moment when a special functionality is enabled.

As for "resource-dependent” configuration, I wonder how this is supposed to work…more specifically, I wonder to what extent the IETF needs to care how if works (perhaps the same could be said for "resource-independent” configuration too).  For instance, in JUNOS, there exists a config-template that is automatically applied to any user-defined interface, such as:

    junos-default-profile {
        interfaces {
            "$junos-interface-ifd-name" {
                unit "$junos-underlying-interface-unit" {
                    family inet;
                    family inet6;
                }
            }
        }
    }
Notably, RFC 8342 mentions templates as something that might be expanded when converting <running> to <intended>.  Actually, knowing that it is <intended> that is subject to validation, it seems that much (if not all) of <system> should be consumed when converting <running> to <intended> - agreed?
[Qiufang Ma] Do you mean that  <intended> should include the system configuration which is generated due to the expansion of templates?  I notice that RFC8342 says in sec.4.1
“One of the observations:
Some implementations have proprietary mechanisms that allow
clients to define configuration templates in <running>.  These
templates are expanded automatically by the system, and the
resulting configuration is applied internally.”
So I am wondering whether the system-predefined config-template would be present in the <running> and updating <intended>  through performed template-expansion.
My understanding is that if the config-template is configured in <running>, the expanded configuration in the <intended> should still be the client configuration.
If the template is preconfigured by the system, the configuration generated through performed template-expansion should be only present in the <operational> if not explicitly re-configured in <running> by the client.

2) Please treat NETCONF and RESTCONF equally.  Currently the draft speaks only to how it impacts NETCONF, but it should equally show how RESTCONF in impacted.
[Qiufang Ma] Thanks for bringing it to my attention, I would take RESTCONF into consideration and see how the proposal works on RESTCONF.

It will work nearly transparently, if not completely so.

What you need to do, mostly, is search/replace “NETCONF” —> “YANG-driven management protocols such as NETCONF and RESTCONF”

…and also “…The following example is provided using NETCONF, but could just as easily be provided using RESTCONF, in XML or JSON.”   Alternately, and perhaps better, have a mix of both kinds of examples throughout your document.
[Qiufang Ma] I am also thinking  the same effective way, thanks.

3) The “basic mode” term sounds too close to the “with-defaults” basic modes...can we please pick another name (e.g., system-datastore-operating-mode)?
[Qiufang Ma] Yes, agree. Actually we don’t really want to cause any confusion or misunderstandings. This term controls whether the device will update <running> with system configuration change or not.
Your proposal looks good to me, other suggestions are also welcome here.

Ack.

 Regarding your question below I don’t feel ready to comment on it yet.  I do understand the JUNOS model and, if it is compatible, would recommend considering, as it is implemented and seems to be working well enough.  That said, it might be the case that every vendor has defined their own way and each needs to be documented in turn...
[Qiufang Ma] The issue we try to resolve here is that in order for system configurations being referenced or to make sure a successful validation when the system configuration is in the when/must statement, the system configuration must be retrieved from <operational> firstly and then copied into <running> manually, which is cumbersome. In this case, we would like to define some kind of mechanism to synchronize system configuration into <running>. Currently two system configuration data handling modes are specified. One will update <running> with any system configuration change automatically, and the other will not, so that the implementer may choose the mode more suitable for them. Hopefully this clarifies what we try to do. Please feel free to comment or suggest.

I’m beginning to think that:
·         auto-copying into <running> is likely never a good idea, because it violates the definition of <running>
[Qiufang Ma] I am quite aware that different datastores in NMDA represents different views of data nodes.  And <running> represents a configuration datastore holding the current configuration of the device.
Should we consider system configuration also be part of current configuration of the device? From my perspective, the difference between system configuration and  client-configuration lies only in who provides it.
·         having in <operational> doesn’t make sense, since the tweaks wouldn’t go thru <running> --> <intended> validation.

I’m wondering if a model like below would work for everyone - thoughts?
[Qiufang Ma] <intended> represents the configuration after all configuration transformations to <running> have been performed, so I think it is only coupled to <running>.
Anyway, the <system> should also interacts with <operational>.  Agreed?

Best Regards,
Qiufang Ma

     +-------------+                 +-----------+
     | <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
                      +------------+
                      | <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) |
                    +---------------+

Best Regards,
Qiufang Ma

K. // contributor

---

From: Kent Watsen <[email-masked]>
Date: Fri, 2 Jul 2021 20:41:11 +0000

[Thanks for removing NETCONF from the CC]

Hi Qiufang,

<snip>
> [Qiufang Ma] I don’t quite understand this kind of configuration, could you please expand? Do you mean that the predefined configurations  for a certain application(e.g., ftp) will not take effect until being referenced/enabled?

For the second category, imagine <system> containing some predefined objects.  These objects follow the standard data-model allowed by the YANG.  Operators could have defined these objects as well but, because there may be hundreds of these objects, and the objects are the same for everyone, the vendor decides to pre-define them as a convenience for their customers.  This way, operators only have to define custom objects for what is unique in their environments.    By example, imagine this in <system>:

	system-defined-defaults {
		applications {
			application ftp {
				protocol tcp;
				destination-port 21;
			}
			application tftp {
				protocol udp;
				destination-port 69;
			}
			application smtp {
				protocol tcp;
				destination-port 25;
			}
			...
		 }
	}

And this in <running>

		# custom objects
		applications {
			application my-app-1 {
				protocol tcp;
				destination-port 2345;
			}
			application my-app-2 {
				protocol udp;
				destination-port 69;
			}
		 }

		// an ACL policy referencing both sys-defined and custom objects
		policy from-zone untrust to-zone untrust {
			policy allow-external-access-to-foobar-app {
				match {
					source-address any;
					destination-address any;
					application [ ftp tftp, my-app-1, my-app-2 ];
				}
				then {
					permit;
				}
			}
		}

Note that, <running> by itself would not pass validation, due to missing leafrefs.  Thankfully, NMDA never says that validation runs on <running>.  But once <running> and <system> have been merged, to become <intended>, the result does pass validation.

> I am wondering if these configuration will present in the <operational> (which contains all the configuration actually used by the device) before they’re referenced.

I think that it would depend in the specific server’s behavior, regarding if *unused* predefine objects are present in <operational>.  Certainly the unused objects would not have to be present in <operational>.  If I were implementing the server, the unused objects would NOT be present in <operational>.

> [Qiufang Ma] Do you think there exists conditional system configuration (if the preceding configurations you mentioned above is not)? For example, if SSH is enabled on a device, SSH-related keys are automatically generated. Such configurations are generated at the moment when a special functionality is enabled.

I’m unsure what you mean in general by "conditional configuration”, but I can speak to your specific example. Though I must preface my comments that I imagine there are a number of ways servers might go about enabling `sshd`.  What follows is my personal view, forged by being around systems for awhile  ;)

In general:

	- `sshd` is NOT enabled by default.
	- `sshd` is enabled via a configuration knob.
	- the SSH host key is dynamically generated the first time `sshd` is enabled.
	- the SSH host key itself is in <operational> (not <running>)

This view is consistent with the first paragraph in Section 3 of the “keystore” draft (reproduced below):

	3.  Support for Built-in Keys

	   In some implementations, a server may support built-in keys.  Built-
	   in keys MAY be set during the manufacturing process or be dynamically
	   generated the first time the server is booted or a particular service
	   (e.g., SSH) is enabled.

As a closing thought, this model (which I stated upfront may not be universal) would have no presence-in or interaction-with <system>…though, perhaps, there may be some predefined values for what key-algorithms and/or key-lengths to use when generating the SSH host key...

> If the template is preconfigured by the system, the configuration generated through performed template-expansion should be only present in the <operational> if not explicitly re-configured in <runn…

Firstly, I again have to preface my comment that there are likely many ways that templating mechanisms can be defined.    But, in general, once a templating mechanism has been defined, then it stands to reason that templates could be defined either in <running> (by operators) or in <system> (by the manufacturer).  In one implementation I’m familiar with, the templates are objects that are referenced/parameterized by other parts of the configuration.  (Same as with the predefined objects discussion above.)  

To answer your questions:

1) Yes, it is my opinion that *activated* templates in <system> will be expanded and present in <intended>.

2) I would never suggest that the system-defined templates are present in <running>, though they may be referenced/parameterized by config in <running>.

3) if a config-template is configured in <running> (i.e., it is operator-defined) then, yes, the expanded configuration in <intended> is "client configuration” (note, "client configuration” is not a formal term).  That said, it seems fair to say that a template defined in <system> and then referenced by "client configuration” in <running> is also expanded as "client configuration” in <intended>.

4) I don’t not understand your last sentence, that the expansion of <system> templates are only present in <operational>.  Maybe you’re saying something subtle, e.g., that servers currently don’t support GET on <intended>.  But, in theory, the expansion of <system> templates should (IMO) be present in <intended>, so that they may be subject to validation.   Of course, all the <intended> configuration (whether originating in <running> or <system>) that is successfully “applied” will also be present in <operational>.

<big snip>
> Should we consider system configuration also be part of current configuration of the device? From my perspective, the difference between system configuration and  client-configuration lies only in…

<running> holds the current *operator-specified* configuration of the device.  System-provided configuration is NOT specified by operators (though system-defined objects may be referenced by operator-specified config in <running>).   I believe that this arrangement is consistent with the definition of <running>.  Agreed?

> Anyway, the <system> should also interacts with <operational>.  Agreed?

I don’t agree that <intended> must only be coupled to <running>.  Specifically, I think that it is okay (compatible with NMDA) to define a <system> that also impacts <intended>.   This is the only (IMO) sane approach, as it enables the combination <running> + <system> to be validated.

> Qiufang Ma

Cheers,
Kent // contributor