Hi Qiufang, Good comments. Please see inline …
From: maqiufang (A) <[email protected]> Date: Thursday, 19 December 2024 at 11:42 To: Rob Wilton (rwilton) <[email protected]>, Kent Watsen <[email protected]>, [email protected] <[email protected]> Subject: [netmod] Re: 3rd WGLC on system-config-10 (was "2nd") Hi, Rob, Kent, (6) p 9, sec 6.1. May Change via Software Upgrades or Resource Changes * Servers reject the operation to change system configuration (e.g., software upgrade fails) and needs the client to update the configuration in <running> as a prerequisite. Servers are RECOMMENDED to include some hints in error responses to help clients understand how <running> should be updated. I think that the "MUST" is probably too strong, and perhaps would be better as "SHOULD". I think that there are certain actions, e.g., software upgrade where systems may struggle to guarantee that <intended> always stays valid, and one valid option for handling this is to allow it to become invalid, and then require the first edit-config/edit-data operation to get <running>/<intended> back to being a valid datastore again. I'm not entirely sure whether we should be providing examples here. If you do provide any examples then I think that you should definitely strip any RFC 2119 language, but I would probably strip the text about alerting clients or returning errors responses. Since, handling this is out of scope, the less that is said the better, IMO. Juergen that stated that it must not be possible for a change in <system> to invalidate <intended>. For me, I have a slightly looser requirement. I don’t think that the device should be modifying and making the configuration invalid on its own. E.g., for interface entries that are tied to hardware existence, then that configuration can become unapplied if the hardware is missing. If the configuration is changing (or being broken) due to some client instructed management operation (e.g., upgrade or downgrade the software), then I agree that it is better for the client to warn and encourage the configuration to be fixed before the operation is performed, but I’m sure that corner cases exist where this simply doesn’t happen, or the client may want to force the upgrade/downgrade to happen because that is more important than keeping the configuration consistent. In that scenario, I think that the pragmatic solution is that the device forces the configuration to become valid again on the next write config operation. Another example would be a license that expires, such that a subset of the configuration is no longer valid. Choices could be: Configuration is left as it is, but the configuration is no longer valid, and the configuration becomes unapplied. Attempts to configure the feature without a valid license would be rejected with an error during validation. Configuration is automatically removed from running by the device (but I don’t like this option). I prefer if the client *always* controls the contents of running. Always allow the configuration, even if there is no valid license present) but just don’t apply it if there isn’t a valid license (this seems like generally less helpful behaviour to me). So, in summary, perhaps not as clean as a MUST, but maybe more pragmatic/realistic? And he’s right for automations to succeed. That said, if there a human-in-the-loop, it seems possible that the system could offer your idea as an option. Maybe a sentence could be added to say that? I’m not sure – I’m sort of after less words/examples rather than more … For me, I interpret this as: SHOULD always stay consistent. If, for any reason, it becomes inconsistent then SHOULD* be made consistent on the first operation taken. (*) I was going to write this as MUST, but I know of cases where customers are unhappy of systems not letting them shutdown an interface because of an another, entirely separate, part of the configuration is not valid. Hence, I think that some systems at least, have a “force” mode to force the configuration change to made (perhaps still with some level of constraints). My concern is related to the statement in RFC 8342: <intended> MUST always be a valid configuration data tree. If a client references an interface eth0 in <running> which is afterwards physically removed and thus disappears from <system>, we end up with dangling reference in <intended>. This one is a bit more concerning. RFC 8342’s answer to this problem was for the client to put the referenced interface into <running> so that regardless of whether the interface is present in the hardware or not, the configuration is valid. But I think for that solution to really be robust the client needs to also configure the interface type, or the system needs to be able to infer what the interface type is, since the when statements for other configuration is predicated on that interface type. But there seems to be four choices here: 1. Don’t allow the forward reference into <system> in the first place, i.e., require the interface (and perhaps interface type) to always be in <running>. I.e., as per RFC 8342. 2. Modify the running configuration if the hardware is removed. E.g., remove the configuration that is referencing, or inject the referenced system configuration. 3. Allow the configuration to become invalid. 4. Keep interfaces in system, even for removed hardware, if that interface is referenced by any running configuration. This is arguably similar to 2,but avoids actually modifying running. My assumption is that the interface would still be removed from operational because it can no longer be instantiated. Similarly, If the upgrade/downgrade happens before keeping the configuration consistent, the invalidity of configuration between t1 (the upgrade/downgrade) and t2 (the first operation to make configuration consistent) seems also a violation of that statement. This one worries me less. Ultimately if the previous configuration is no longer valid with the new version of software then the configuration has to be changed, or the software change prevented (or reversed). Forcing the client to create a configuration that MUST be valid both in the old and new configuration seems like creating extra work for the client, probably for little benefit. I kind of agree that we should say less rather than more, especially when this is beyond the scope of the document. The examples here are used only to enlighten some possible solutions, we can remove these, but I am really unsure we should relax MUST to SHOULD here. But if you don’t relax the MUST then how to handle the upgrade/downgrade case? Regardless of what the RFC states, what do implementations actually do here? For the OS that I’m familiar with, I think that we will remove parts of configuration from running after the software change, if that configuration is no longer valid. Regards, Rob Regards, Rob Best Regards, Qiufang
_______________________________________________ netmod mailing list -- [email protected] To unsubscribe send an email to [email protected]
