IMO the <system> DS was more about explicitly showing list entries that the system has populated under the hood, that can be referenced by the <running>. It came about because many implementations today support leafrefs in running to those list entries (even though they aren’t in running). Built-in qos policies. Built-in system interface. That sort of thing.
In my example, the leaf “foo” only exists in any DS (running and operational) once the user explicitly configures it. But it just so happens that the underlying implementation can’t exactly program 1500 into the datapath, and needs to adjust it for various reasons so the value 1492 is actually in use. So that gets reflected in the <operational> DS. But I think it would be odd for that leaf to suddenly appear in the system DS. It wouldn’t be in there if the user/client didn’t explicitly configure that leaf in <running> (e.g. with the value 1500). Jason From: Kent Watsen <[email protected]> Sent: Thursday, November 7, 2024 9:33 AM To: Jason Sterne (Nokia) <[email protected]> Cc: Jürgen Schönwälder <[email protected]>; [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. Hi Jason and Juergen, This email responds to both of your messages, i.e., keep scrolling! ;) Kent // contributor On Nov 7, 2024, at 1:35 PM, Jason Sterne (Nokia) <[email protected]<mailto:[email protected]>> wrote: Hi Kent, My thinking was along the lines of what Jurgen mentions here: there are some values in operational that come from the system, but don't come from the system DS. Before a server implements ietf-system, *all* such values fall into that category, right? Now assume in the next release the server implements ietf-system, which just indicates what values are/were selected before. Nothing else (e.g., internal code) changes. Did the value suddenly come from the <system> datastore, or is it more that the <system> datastore accurately modeled the system’s behavior? I think that it is that latter, but read on... I don't think the intention was that *anything* marked with origin "system" is also sitting there in the system DS. That would entail the data-tree in <system> being perfectly complete and accurate, which is ideal but highly unlikely. FWIW, I view this point as supporting my perspective of not trying to over engineer this. My example of node "foo" having different values was between <running> and <operational> (nothing to do with system DS). In the current specs (without the new DS draft), do you agree the origin of foo would be "or:system"? Yes. I'm simply talking about a situation where the user asks for 1500 in the <running> but the server can't quite program that in the h/w due to some other constraints, or some rounding function, etc and can only do 1492 so that is what they report in <operational>. I don't think it makes sense for that leaf to suddenly now show up in the system DS. Why not? The system-config draft indicates that the contents of the <system> datastore may change based on events such as a software/hardware/license change. What else of you think the draft intends then? [keep scrolling] Jason -----Original Message----- From: Jürgen Schönwälder <[email protected]<mailto:[email protected]>> Sent: Thursday, November 7, 2024 4:02 AM To: Kent Watsen <[email protected]<mailto:[email protected]>> Cc: Jason Sterne (Nokia) <[email protected]<mailto:[email protected]>>; [email protected]<mailto:[email protected]> Subject: Re: [netmod] Re: 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. On Thu, Nov 07, 2024 at 08:01:14AM +0000, Kent Watsen wrote: I think it is important to keep the distinction between 'or:system' and 'sysds:system' since config generated by the system is different than config originating from a system datastore. I saw this comment last night and it didn’t sit right. Assume a server initially has no <system> datastore, and so reports a node’s origin as “ds:system”. Then later supports the <system> datastore, trying to expose some of what it does internally. Nothing has changed with the internal code, only the datastore was created. Why should the node’s origin change? For me, a valued copied from a datastore is different than a value generated by some program logic buried somewhere inside the system. I assume we have different understandings what a system datastore is all about, which then may be a bigger problem. I appreciate this perspective, but I also think that the entire goal of the <system> datastore is to model (as best as possible) the values that the buried program logic generates. Regarding a value in <operational> varying from a value in <system>, this just seems like a bug in the YANG defined for the <system> datastore. For me, the origin indicates where I can find the source of a value. If the source is the system datastore, then I expect that to be reported and I expect to find the value also in the system datastore. If the source of the value is the system itself, then I expect that to be reported and I do not necessarily expect to find the value in the system datastore. I get that but, again, I see any variance as an opportunity for the server-developer to update the values populated in <system> to better model the system’s true behavior. I fear we may have a bigger problem by not agreeing on what the system datastore actually is... Indeed. It might help to think about the use-case that <system> intends to support. My understanding is that it’s trying to reveal more about what the buried program logic does, so that the network’s functioning can be better understood, e.g., to implement a digital twin. K. /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]<mailto:[email protected]> To unsubscribe send an email to [email protected]<mailto:[email protected]>
_______________________________________________ netmod mailing list -- [email protected] To unsubscribe send an email to [email protected]
