Hi, I’ve read this thread and looked at RFC 8342 and system-configuration datastore.
For me, I think that the example below for PIR, is probably a red-herring, as in, I don’t think that is intended to be system-configuration, at least, not when we were originally discussing NMDA. Basically, I think that this example is of a system change that we didn’t really consider. I.e., we considered that the operational value might differ because it was overridden by a protocol (i.e., learned), or due to ephemeral configuration (i.e., dynamic), and we considered configuration that always exists, e.g., loopback, or interface configuration whose existence is tied to the presence of some hardware (i.e., system), but I don’t think that we considered a case where the configuration system would accept one value for a leaf and then proactively decide to operationally apply a different value instead that wasn’t due to any other external influence. Further, I don’t think generally that system configuration (or configuration identified as origin system) should override configuration from running, it should always be the other way around. In the same way that a default value should not be able to override an explicitly configured value. So, my conclusion is that I think that the configuration represented in the system datastore should be the same as the system configuration shown in RFC 8342. I.e., really this is a change in the NMDA architecture to allow system configuration to be merged with running before validation occurs (on the assumption that device validation is really done against intended). As Kent indicates, these should use the same system origin, because they are the same thing. Hence, I would say that PIR example (and the MTU example given previously) shouldn’t be using origin system. Instead, they should have a different origin value, unfortunately one that hasn’t been defined yet. But I think that using origin:system when overriding explicitly configured values ends up being confusing. I also share the concern raised by Juergen as to whether they various updates to NMDA are going to leave us with a consistent coherent architecture. I.e., there is part of me that is wondering whether we should have been bis’ing RFC 8342 instead, since it feels that we are fundamentally changing the architecture because system feeds into the validation of intended. Regards, Rob From: Jason Sterne (Nokia) <[email protected]> Date: Thursday, 21 November 2024 at 17:19 To: Kent Watsen <[email protected]>, Jürgen Schönwälder <[email protected]>, maqiufang <[email protected]> Cc: [email protected] <[email protected]> Subject: [netmod] Re: origin "system" in system-config-09 I’m not sure. The discussion has caused some doubt in my mind. If <system> is merged with <running> to form <intended>, then it is a little odd that the origin (when reading <operational>) isn’t just or:intended. (on the other hand, I can see it being useful to know that some piece of config came from <system> instead of <running>) RFC8342 shows “system configuration” merging *after* intended. In that case it is a little easier to see how the origin would be or:system. But even if we put that issue aside (and just allow some config in <intended> to have origin = or:system when it comes from the <system> DS), I’m not certain I agree that all elements that appear in the <operational> DS with origin = or:system must necessarily also show up in the <system> DS. For built-in referenceable list entries (e.g. qos polices, system interface) I can see how they are 1:1 between the <system> DS and or:system in the <operational> DS. But I’m less certain that we’ve considered all potential types of elements or scenarios where reading something from the <operational> DS can return or:system. For example: · User configures pir = 1022 (e.g. some QoS policing parameter) · Server accepts pir = 1022, but rounds/maps it to a value that is actually supported on that particular hardware platform, so the system is actually using pir = 1024 · Reading <operational> should return pir = 1024, but could the origin be or:system in this case? · I think it would be odd for pir to suddenly show up in the <system> DS in this situation (and I don’t think we should mandate that) Jason From: Kent Watsen <[email protected]> Sent: Thursday, November 21, 2024 8:29 AM To: Jürgen Schönwälder <[email protected]>; Jason Sterne (Nokia) <[email protected]>; maqiufang <[email protected]> Cc: [email protected] Subject: Re: [netmod] origin "system" in system-config-09 CAUTION: This is an external email. Please be very careful when clicking links or opening attachments. See the URL nok.it/ext for additional information. Juergen, Thank you for helping to close this item. Jason, Are you okay with this resolution? Qiufang, Please update the draft to define what happens in case an update to <system> schema and/or data causes <intended> to become invalid. As a participant, I wonder if it would be possible to enumerate such cases. For instance, let’s assume a software-update removes or renames a “shared object” in <system> that is being used. In this case, I would hope that the installer would check for use of the old shared object and prompt the user what to do. For instance, if the shared object was removed, the installer could auto-create the shared object in <running>. Similarly, if the shared object was renamed, the installer could auto-update the leafref in <running> to point to the new name. Likely it will be impossible to enumerate all possibilities, and so some generic catch-all text will be needed. For instance (please rephrase), “Servers MUST ensure that updates to <system> schema and/or data do not result in <intended> becoming invalid. It is out of scope of this document to define specific remediation mechanisms." Kent while re-reading parts of the I-D, I tend to agree that using or:system seems about right. Perhaps more explanation would be helpful how to resolve problems is if client config depends on <system> confif and changes to <system> cause <intended> to become invalid. Or is the undefined merge going to "unmerge" stale client config in this situation? Or does the device reboot to signal it had an internal problem? ;-) Section 6 details that such a situation is possible, it does not detail how system changes leading to an invalid <intended> are handled. /js -- Jürgen Schönwälder Constructor University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
_______________________________________________ netmod mailing list -- [email protected] To unsubscribe send an email to [email protected]
