Lada, Shortening the thread a bit, citing from your response: In fact, I think this intended-applied duality could be used for a sound definition of default contents: defaults would be present in applied but not in intended config. This would eliminate the need for with-defaults.
That’s indeed what I am after. A lot of kludgy things could fall into their place by applying intended/applied config sensibly. Default values are one of them. Derived state of non-explicitly configured leafs (i.e. not part of intended config) is another. That said, we consciously need to keep existing models and implementation into account. IMO the overall guideline using intended vs. applied config should be: 1. Intended config is owned by the client and can only be modified by the client. A Server may reject an intended config only if it is syntactically incorrect. 2. Applied config is owned by the server and can only be modified by the server to reflect configuration changes or to apply intended config 3. A client has rwx access to intended config and r access to applied config (x meaning to request the server to apply it in a certain way) 4. A server has r accesss to intended config and rw access to applied config 5. If after attempting to apply the intended config there are still differences between intended and applied, they shall be notified by the server to the client 6. The client shall resolve the differences by either modifying the intended config or by a maintenance action. In both cases, a difference is considered temporary. With that guideline in mind, for a properly configured server, the intended config is a true subset of the applied config with a 1:1 relationship. Gert From: Ladislav Lhotka <lho...@nic.cz<mailto:lho...@nic.cz>> Date: Tuesday 12 January 2016 10:23 To: Gert Grammel <ggram...@juniper.net<mailto:ggram...@juniper.net>>, Robert Wilton <rwil...@cisco.com<mailto:rwil...@cisco.com>> Cc: "netmod@ietf.org<mailto:netmod@ietf.org>" <netmod@ietf.org<mailto:netmod@ietf.org>> Subject: RE: [netmod] applied configuration and system-controlled entries Gert Grammel <ggram...@juniper.net<mailto:ggram...@juniper.net>> writes: -----Original Message----- From: netmod [mailto:netmod-boun...@ietf.org] On Behalf Of Ladislav Lhotka Sent: 11 January 2016 16:36 To: Robert Wilton Cc: netmod@ietf.org<mailto:netmod@ietf.org> Subject: Re: [netmod] applied configuration and system-controlled entries On 11 Jan 2016, at 15:58, Robert Wilton <rwil...@cisco.com<mailto:rwil...@cisco.com>> wrote: On 11/01/2016 14:27, Ladislav Lhotka wrote: On 11 Jan 2016, at 15:11, Juergen Schoenwaelder <j.schoenwael...@jacobs-university.de<mailto:j.schoenwael...@jacobs-university.de>> wrote: On Mon, Jan 11, 2016 at 02:54:36PM +0100, Martin Bjorklund wrote: Ladislav Lhotka <lho...@nic.cz<mailto:lho...@nic.cz>> wrote: Hi Gert, On 11 Jan 2016, at 14:25, Gert Grammel <ggram...@juniper.net<mailto:ggram...@juniper.net>> wrote: Lada, The requirement says: D. When a configuration change for any intended configuration node has been successfully applied to the server (e.g. not failed, nor deferred due to absent hardware) then the existence and value of the corresponding applied configuration node must match the intended configuration node. I don't see that this would limit the case you described below. In your case there is no intended config, hence there is no "corresponding applied configuration" either. You are right, the requirement can be interpreted this way. I thought that applied configuration was supposed to be identical to intended after some synchronization period. This is a very important point to clarify. Can there ever be data in "applied" that is not in "intended"? I think Anees & Rob previously said "no", but I might be wrong. If there is time delay between editing intended and the applied config matching the edits of intended, then I supose this can happen (I delete a resource from intended but it is still around until intended has been fully synced). I would find it interesting if some edits are Using applied config for system-controlled entries would require that such an entry stays (forever) in applied config even after it has been deleted from intended. I think that this would make life harder for clients. Hmm, I would say the opposite. For one, we could simplify the data models by reducing the duplicities in configuration and state trees. Let's look at a practical example and see if we can converge: 1) A Server is happily running with intended == applied config and operational state is aligned with intended config. 2) A new HW is plugged into that server and that HW has some kind of identification number This can practically fall into 3 cases: a) it's a plug&play device and it is accepted to be used b) it's an accepted device but shall be configured prior to become operational c) it's considered a harmful (unplanned) event and the device shall be removed In terms of a possible implementation, the event 1) would update the applied config which - among others - include the identification number and update the operational state of that HW in line with the applied config 2) Since the new applied config differs from the intended config, the client is notified about the change 3) Upon inspection of the config change, the client decides how to deal with the new item: a) accepting it the way it is: pushing down an intended config in line with the applied config information This shouldn't be necessary. Default values are also accepted as something the device operationally uses, but they needn't be copied to intended config. In fact, I think this intended-applied duality could be used for a sound definition of default contents: defaults would be present in applied but not in intended config. This would eliminate the need for with-defaults. Otherwise, your scenario looks good to me. Lada b) accepting it with modifications: pushing down a new intended config with additional leafs c) rejecting it: raising an alarm indicating the configuration mismatch, requiring manual intervention With the requirements as they are today, the client gives the intended config to the system, which it can monitor until the applied config matches the intended config. At this point it knows everything is good and the config is fully applied. Over time, if everything is behaving as expected, the client can reasonably expect that the applied configuration will always converge on the intended configuration. Which is the case above. By updating the intended config the client accepts the config change. One could argue that leafs with default values are in applied configuration before they appear in intended. So my idea was to extend this to default entries of certain lists. Using applied config for system-controlled entries would break the simple logical relationship between intended and applied configuration, since there are now some special entries for which this rule does not always apply. Don't get to the same conclusion, see above. The introduction of applied configuration would mean significant complications to all protocols, and perhaps even to YANG (although I'd hope not). Solving only the synchonicity issue with it is IMO insufficient payoff for all the troubles. Don't see this either. Lada always assumed to be synchronous but others may be asynchronous. And Lada, I think applied may happen to be never identical to intended if, for example, hardware is absent or other missing resources prevent certain parts of intended to become applied. Yes, this is the use case of pre-provisioning, which is important, too, but in fact opposite: the question here is whether applied can contain stuff that's not (and never been) in intended. I think that the answer is basically no, unless it is an error condition and it is representing configuration that should be deleted. Thanks, Rob Lada My understanding is that applied config in general forms an extended subset of intended config. And to fully understand what a device is doing, I may need to obtain its entire operational state since the applied config may not include state obtained dynamically from other sources. But I might still all be wrong... /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 <http://www.jacobs-university.de/> -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C _______________________________________________ netmod mailing list netmod@ietf.org<mailto:netmod@ietf.org> https://www.ietf.org/mailman/listinfo/netmod . -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C _______________________________________________ netmod mailing list netmod@ietf.org<mailto:netmod@ietf.org> https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C
_______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
