Rob, I realize that the pre-conditions of the example made weren't clear. There is certainly the possibility to pre-configure a node in the intended config and wait until some HW is inserted. Indeed in a Telco environment this is the preferred case and will stay so for a while.
Lada mentioned a case which didn't have an intended config to begin with and asked how it fits in the model. I was using the HW insertion case to show how it can be dealt with: either by physical intervention (removing the HW) or by updating the intended config to accept the server state. Admittedly this is not the norm, but rather an exception. In any event, the difference between intended and applied is temporary. --Gert >-----Original Message----- >From: Robert Wilton [mailto:rwil...@cisco.com] >Sent: 11 January 2016 17:58 >To: Gert Grammel; Ladislav Lhotka >Cc: netmod@ietf.org >Subject: Re: [netmod] applied configuration and system-controlled entries > >Hi Gert, > >Please see inline ... > >On 11/01/2016 16:19, Gert Grammel wrote: >> >>> -----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 >>> Subject: Re: [netmod] applied configuration and system-controlled >>> entries >>> >>> >>>> On 11 Jan 2016, at 15:58, Robert Wilton <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> wrote: >>>>>> On Mon, Jan 11, 2016 at 02:54:36PM +0100, Martin Bjorklund wrote: >>>>>>> Ladislav Lhotka <lho...@nic.cz> wrote: >>>>>>>> Hi Gert, >>>>>>>> >>>>>>>>> On 11 Jan 2016, at 14:25, Gert Grammel <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 >I think that you can solve this more cleanly with interfaces-state or >equivalent. >I don't think that a device should be creating configuration, the configuration >should solely be controlled by the operator, and hence the ownership and flow >of information is well defined. > I would rephrase your words a bit: I don't think that a device should be creating *intended* configuration, the *intended* configuration should solely be controlled by the operator, and hence the ownership and flow of information is well defined. Instead the applied configuration should represent the server as-is and an inserted HW can't be changed by SW. However HW can be put in an operational state that inhibits it from being used. > >> >> This can practically fall into 3 cases: >> a) it's a plug&play device and it is accepted to be used >In this case, it could generate a YANG notification from something like the >Entity YANG model (or equivalent), and instantiate the new resources in >interfaces-state as appropriate (or equivalent). The operator can then >discover >this and apply whatever configuration is appropriate (or perhaps they have put >the configuration in previously waiting for the hardware to be inserted). That would practically mean some pre-provisioning is already in the intended (and applied) config, and the operational state is aligned with the applied configuration upon insertion. > >> b) it's an accepted device but shall be configured prior to become >> operational >Same as above. > >> c) it's considered a harmful (unplanned) event and the device shall be >> removed >It generates a syslog error message, and perhaps Entity YANG model >notification. The system doesn't accept any configuration related to the >unsupported HW. Which would mean there is an intended (and applied) config present in the server that would require HW insertion to generate a syslog message. There are certainly environments where unplanned insertion of HW shall trigger syslog error messages. However it wouldn't be a clean solution to require Error messages triggering a Client to update the server's intended config. > > >> >> 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 >> 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 > >I don't think that you need to use applied config to solve this. You can >support >this using operational state and notifications, this then allows the >configuration to be controlled by a single entity (i.e. the operator). > >> >>>> 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. >Personally I don't think that it should be up to the client to >accept/reject a config change that the server is making. The server >should only notify what has changed in the system and leave it to the >client to decide what configuration should be put on the system. > >Besides, I'm not sure that there is a clean way for the client to reject >such an applied config change. I.e. I can't see how it can delete the >configuration from the intended config because it already isn't there - >it would need some special semantics and I don't think that they really >help simplify this problem. > >Thanks, >Rob > > >>> 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 >>>>> 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 >> . >> _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
