WG, Regarding yesterday’s <system> datastore presentation, there seemed to be support for "Option #2”, which is to have <system> merge into <intended>.
It was noted that this then would mean that client-validation of <running> would necessitate understanding how the merge works, to expand templates, resolve leafrefs, etc. My thoughts are, so? Firstly, a client that doesn’t understand that there may be some <system> defined configuration will, for the most part, be none the wiser. The client *will* discover <system> configuration in <operational>, but this is already the case today. One new thing is that <operational> should use “origin:system” for configuration originating from the <system> datastore. This last point might surprise clients…as the definition of “with-origin” doesn’t state that clients must ignore any unrecognized “origin” identities: https://datatracker.ietf.org/doc/html/rfc8527#section-3.2.2. Secondly, no shared object defined in <system> will be activated until client-supplied config references it. But any client able to do this already knows how <system> merges into <intended> and is accounting for it. Thoughts? Kent > On Jul 16, 2021, at 6:24 AM, maqiufang (A) <[email protected]> wrote: > > Hi, Kent, > Please see my reply inline. > > From: Kent Watsen [mailto:[email protected]] > Sent: Friday, July 16, 2021 2:55 AM > To: maqiufang (A) <[email protected]> > Cc: [email protected] > Subject: Re: [netmod] system configuration sync mechanism > > Hi Qiufang, > > [snip] > The question is if the server implementation prunes dangling/unused objects > when <intended> is applied, updating <operational>. My assumption is that > the server will discard any object that doesn’t actually impact the running > configuration of the system (i.e., values are consumed by the underlying > operating system, drivers, etc.). Thusly, it is my opinion that only the > referenced objects are applied. Hence why, to answer your last question, I > wrote that these configurations (manufacturer-defined objects) are not > applied immediately but only after they are referenced. Makes sense? > [Qiufang Ma] Yes, try to sum up our discussion about the categories of the > system configuration: > · Physical-resource-dependent--> whether this sort of system > configuration exists in <system> dependents on if the physical resource is > present(e.g., physical interface). > · Physical-resource-independent-->which is provided by the device > system > o Further classification from the perspective of “applied” time(dependents > on whether the system configuration impacts the running of the system) > § Config that is applied immediately(e.g., the loopback, the predefined > minimum length of password…) > § Config that is applied only after being referenced by other configs(e.g, > definitions for applications ftp/tftp…) > o Further classification from the perspective of generation time > § Config that is generated unconditionally at each boot time(e.g, loopback, > predefined minimum length of password, ftp/tftp…) > § Config that is generated conditionally during the device running(e.g., > system-generated local-port and remote-port for a new established BGP > connection) > > Keep in mind that what is described above is just one aspect of what can be > in <system>. In addition to defining reference-able objects, <system> can > also define/apply configuration immediately (e.g., the loopback interface). > That is, configuration not does not have to be referenced in order to become > activated. > [Qiufang Ma] Noted. > > > > 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. > [Qiufang Ma] The referenced instance must also exist for the data to be > valid since the require-instance defaults to true if not present. Is this > what you had in your mind? Yes, NMDA says that it is <intended> which is > subject to validation. But I also notice that In section 5.1.3 of the > NMDA:”<running> MUST always be a valid configuration data tree, as defined > in Section 8.1 of [RFC7950]. ” So my thought here is that <running> should > also conform to the YANG model constraints and that’s to say, a referenced > system-defined data item should also exists in <running>. > Therefore, if system configurations do not exist in <running>, they still > need to be configured in <running> manually in order for being referenced. > In this case, the original purpose of predefining some system configurations > for user convenience is lost. This is the reason why we would like to define > some mechanism here to synchronize <system> into <running>. > > > I see in RFC 8342 "<running> MUST always be a valid configuration data tree, > as defined in Section 8.1 of [RFC7950]”. > > But the question remains if it is possible for the system is able to validate > <running> without, e.g., expanding templates. There may be a 'leafref' or > ‘must’ expression somewhere that will fail because the evaluation occurs > without expanding a template that supplies the missing parts. > [Qiufang Ma] On condition that <running> should be valid, the operators will > need to retrieve from the <intended> or <operational> to get the > template-expanded configurations and then create them in the <running>, > right? > My feeling is that it loses the meaning of predefining and seems no > differences between operator-defined configurations if operators have to > create system configures in <running> before they use them. So I am beginning > to think, if it’s possible to expand the system-defined template during the > copying between <system> and <running>? > > If this draft “updates” RFC 8342 (NMDA), then it can supply a clarifying > statement about what it means that "<running> MUST always be a valid > configuration data tree”. Either that, or an Errata if it’s determined that > the statement isn’t correct. > > You make a good technical point, but I think that we should *want* to avoid > having to copy <system> (or <operational>) configuration into <running> if we > can avoid it. Agreed? > [Qiufang Ma] tend to agree. Maybe we should try to avoid it, unless we have > to. > > FWIW, also in RFC 8342, Section 5.1.4.: > > <intended> is tightly coupled to <running>. Whenever data is written > to <running>, the server MUST also immediately update and validate > <intended>. > > <intended> MAY also be updated independently of <running> if the > effect of a configuration transformation changes, but <intended> MUST > always be a valid configuration data tree, as defined in Section 8.1 > <https://datatracker.ietf.org/doc/html/rfc7950#section-8.1> > of [RFC7950] <https://datatracker.ietf.org/doc/html/rfc7950#section-8.1>. > > > > > > > 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] Yes, if the predefined system configurations is unused, then I > also tend to agree that they would not be present in <operational> but may > also depend on the vendor implementation. > > > Yup, this is the same conclusion is in my response above. > [Qiufang Ma] :) > > > > > 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. > > 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... > [Qiufang Ma] By “conditional system configuration”, I was meaning some of the > system configurations are not generated immediately after the device is > powered on. Instead, they are generated when a specific condition is > satisfied during the device running(e.g., a functionality is enabled due to > some client configurations). I am not sure if it really exists, maybe not, > just try to explore the possibilities of various resource-independent system > configurations.:) > > To this point I agree..as does RFC 8342 (NMDA), Section 5.3.3.: > > Sometimes, resources are controlled by the device and the > corresponding system-controlled data appears in (and disappears from) > <operational> dynamically. If a system-controlled resource has > matching configuration in <intended> when it appears, the system will > try to apply the configuration; this causes the configuration to > appear in <operational> eventually (if application of the > configuration was successful). > [Qiufang Ma] See above, as I summarized as the system configurations that is > generated conditionally during the device running. > > 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>. > [Qiufang Ma] Assume that there is no <system> and this work, the expansion of > system templates are only present in <operational>. Because this is > compatible with system configuration definition in NMDA. > But if system configurations are only present in <operational>, the > predefined system configurations still need to be retrieved and created into > <running> explicitly when being referenced. I think we’ve reached an > agreement on the need for <system> to exist, and our main point of > disagreement is whether <system> should be copied into <running>. Your point > is that being merged into <intended> is enough to make sure a success > validation. But my understanding is that the referenced system configuration > data item must also exist in the <running> to obey the model constraints. > > Yes, I believe that you provided an accurate description of the difference in > our opinions. Per my earlier response, you make a valid technical point, my > goal is to waive that interpretation to the side so that a simpler solution > can emerge. It would be good to get other opinions on list, otherwise we’ll > take it into the meeting. > [Qiufang Ma] OK. Hopefully someone else would share some opinions here. > Otherwise let’s take this into the IETF meeting. > > [BTW, in keeping with this thread moving from the NETCONF to the NETMOD > mailing lists, would it make sense to move the IETF 111 presentation slot > from NETCONF to NETMOD too? I think it does and, further, it would help with > scheduling (NETCONF is over, NETMOD is under). Would you be okay with this? > AD Rob and the NETCONF chairs discussed this morning, and think it's okay, > but would still need to confirm with the NETMOD chairs.] > [Qiufang Ma] I am happy with the proposal, if it’s also okay for NETMOD > chairs:-). I have sent an email to the NETMOD chairs to request to move this > presentation slot from NETCONF to NETMOD. > A new version of the draft will also be submitted to NETMOD when the > draft-submitting window reopens. > > > <big snip> > > 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. > > <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? > [Qiufang Ma] Yes. Actually we are not trying to violate the principles of > NMDA and the definition of <running>. The issue we try to resolve here is > that system configurations cannot be used(referenced or overwritten) by the > operators directly and need to be created into <running> explicitly. This > actually loses the meaning of “predefining and bringing convenience”. If > auto-copying is not a good idea, what do you think about defining an RPC > operation for the operators to do the copy(which is also what Rob suggests at > the meeting)? > > If we have to copy into <running>, then I think that I agree an RPC > (<edit-config>?) would be better. > [Qiufang Ma] From my perspective, <edit-config> is feasible but not efficient > because operators still need to retrieve <system>/<operational> firstly. If > we could define a RPC to copy the entire <system> into <running>, it seems > more convenient for operators. However, some system configurations which are > not going to be referenced or modified may also be copied into <running>. I > don't have a strong feeling about which one is preferred. Anyway, we need to > figure out whether it would be fine for <running> to missing referenced > system configurations. > > You mention “overwritten” by the operators? Why wouldn’t the operators just > define their own? For instance, if they don’t like the vendor’s > “vendor-foobar” object, they could copy/paste/edit their own “my-foobar” > object with the values needed, yes? > [Qiufang Ma] Yes, defining their own would be okay. By overwriting, I mean > sometimes the operators would like to modify the specific system > configuration, e.g., the MTU value of a specified interface(identified by its > name). > If the operators want to modify the system configurations, there is no way > but redefine them in <running>. > > > Best Regards, > Qiufang Ma > > > > > > > · 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? > > 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] Please see above. If <running> is OK to miss referenced system > configuration, your proposal makes sense to me. > > Ack. > > > > Best Regards, > Qiufang Ma > > > Kent // contributor
_______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
