Hi all, I’m not super excited about the concept that clients should reverse-engineer proprietary server transformations and replicate those in the client. It may not be too difficult for the active/inactive node transformation, but configuration groups (apply groups) are not as straightforward and there is not a single objective “right” way to do those IMO (more complex function with a number of options on how to transform for various situations). If these transformations were standardized that might be a possible path (that won’t be an easy road though given multiple deployed implementations of config groups out there).
At the moment I don’t see RFC 8342 as allowing running (as exactly presented in a <get-data> response from the server) to be invalid. Section 5.1.3 says the following: However, <running> MUST always be a valid configuration data tree, as defined in Section 8.1 of [RFC7950]<https://www.rfc-editor.org/rfc/rfc7950#section-8.1>. I’ve heard arguments that the “spirit” of that statement was really to mean that running + transformations is valid, but IMO that’s a bit of hand waving that isn’t clearly laid out in any RFC right now (or is at the least confusing and contradictory vs the quoted sentence above). Section 5.1.4 goes on to say that intended must always be valid as well. Jason From: netmod <[email protected]> On Behalf Of Jan Lindblad (jlindbla) Sent: Friday, October 27, 2023 2:46 AM To: Kent Watsen <[email protected]> Cc: [email protected]; [email protected] Subject: Re: [netmod] MUST offline-validation of <running> alone be required? possible solution and further discussion 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. Kent, Very good. Our products are leveraging the features you mention in Junos systems, and we have similar functionality in our own. I certainly see good value in these "configuration transformations”, but I also know that much of this value can be realized without changes to YANG, since in fact we already have such features implemented while also supporting an always valid running at the same time. I agree more value could potentially be made available if the config transformations could be expressed more freely, but in my world, trading such a gain for the loss of a robust machine readable interface is a huge net negative. You are pointing to the crucial spot below when you say '''clients can "offline-validate <running>", when such features are in use, by groking and applying the processing-logic behind the features'''. If we can make a client grok and apply that processing logic by either a) applying processing logic defined in a standards track document, or b) applying a machine readable recipe (which is provided by the server) of what the transformations do exactly, I think this is a discussion worth pursuing. If, on the other hand, the suggestion is that clients should reverse engineer the black box transformation logic of each version of each type of system from each vendor and keep it up to date, then I think the potential value we're discussing here is dwarfed by the maintenance cost and interoperability concerns. So there you have it. To progress this idea of a changed definition of what "valid <running>" means, I think we would need to standardize the transformation logic in some way. There is some potential value, but surely a lot of work. Are we up for it? Best Regards, /jan RFC 8342 defines the ability for "configuration transformations” to map <running> to <intended>, which is "subject to validation”. Section 5.1.4 describes cross-cutting features, such as deactivating nodes and templating, that can result in an invalid <running>, when <running> is considered alone. However, clients can "offline-validate <running>", when such features are in use, by groking and applying the processing-logic behind the features (mimicking that which the server does to produce <intended>), and then YANG-validate the result (same as the server). All this is well understood, expected, and good - right? FWIW, these features have been implemented in Junos for as long as I know. And yes, the Juniper NMS systems I worked on offline-validated “<running>” before <edit-config> by mimicking the processing logic locally, as described above. What Qiufang proposes now adds to this. It is one more thing for clients wishing to offline-validate <running> to mimic. In this case, they need to mimic the merging of <running> and <system>, which entails the clients also fetching <system> from the server, in case they don’t have it already. None of this takes away from transactional interfaces, machine readable constraints, high automation levels, or the ability for clients to express intent. With regards to owner and consumer value, I see each of these three features (deactivating nodes, templating, and <system>) as providing clients greater/better flexibility/control/insight. Agreed? Kent On Oct 26, 2023, at 10:42 AM, Jan Lindblad (jlindbla) <[email protected]<mailto:[email protected]>> wrote: Qiufang, While we have tools that actually do offline validation a lot, I am not against discussing removing that possibility from YANG (in a multi-year plan), if there are strong benefits with this idea. So far I haven't seen them. In the old SNMP world, we had MIB models. They described what you could read and write, but not when you could do so or how things interacted. Now we have YANG-based interfaces that are transactional (sequencing no longer a client concern) and with machine readable constraints. I don't see any way to reach the high automation levels we are enjoying today without this. These principles are bringing a lot of very tangible owner and consumer value $€¥ every day. Running reflects the client's intent. If an upcoming intent can no longer be validated by anybody else than the system being managed, and the rules by which it validates running depends on a black box, then it becomes very hard for the client to express its intent. Sounds like we'd be going back to the SNMP age. If anyone can explain a) how a client should go about expressing its intent in a world where running no longer needs to be valid, and b) what the strong benefits of this model would be, I'd be happy to discuss. Best Regards, /jan I want to bring up a key issue that has been discussed before but hasn’t really been agreed upon: MUST offline-validation of <running> alone be required? The question behind this issue is about: must referenced system config always be copied into <running> to satisfy referential integrity constraints, or <running> is implicitly valid if <intended> is valid by merging <system> and <running> (after config transformation like removal of inactive config and expansion of templates) to create its contents, <running> alone doesn’t have to be offline valid. It feels like the WG has a mixed viewpoints, and I would like to find a solution and seek convergence here. Actually I am thinking, instead of directly stating in the draft that any referenced system config must be contained in <running>, we can point to RFC 7950 and RFC 8342 and state that <running> MUST always be a valid configuration data tree. So that we just leave it there and interpretations may vary. Anyway, the client can always explicitly copy referenced system config into <running> or use the “resolve-system” parameter if an offline-validation of <running> is needed. If we can reach an agreement on this handling, I believe then we can move on. One the other side, I also understand that we should not shy away from this issue and need effectively work it out. Below are some thoughts and inputs from the WG: • Yes, <running> alone must be offline valid o Pros • Clients can easily offline validate <running> without offline merging <system> and <running> (which would bring extra complexity to clients) o Cons: • Painful copy is needed. • Need to deal with the scenario where the system config has updated and a stale copy is still in <running> • No, Offline validation of <running> MAY consider other datastores as well, two options: o Treat it as a bug-fix in existing RFCs • Cons: might break legacy clients and existing tool chains o Wait for a new version of YANG/NC/RC • Cons: might incur delay Any further thoughts on this? Comments and suggestions would be much appreciated. Best Regards, Qiufang _______________________________________________ netmod mailing list [email protected]<mailto:[email protected]> https://www.ietf.org/mailman/listinfo/netmod _______________________________________________ netmod mailing list [email protected]<mailto:[email protected]> https://www.ietf.org/mailman/listinfo/netmod
_______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
