On 2016-12-01 18:36, "Robert Wilton" <rwil...@cisco.com> wrote:
> > >On 12/01/2016 16:02, Gert Grammel wrote: >> >> On 2016-12-01 15:04, "Robert Wilton" <rwil...@cisco.com> wrote: >> >>> >>> On 12/01/2016 10:42, Gert Grammel wrote: >>>> On 2016-12-01 11:12, "netmod on behalf of Robert Wilton" >>>> <netmod-boun...@ietf.org on behalf of rwil...@cisco.com> wrote: >>>> >>>>> On 12/01/2016 09:05, Ladislav Lhotka wrote: >>>>>> Martin Bjorklund <m...@tail-f.com> writes: >>>>>> >>>>>>> Ladislav Lhotka <lho...@nic.cz> wrote: >>>>>>>>> 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. >>>>>>> This is the old idea of having the "operational state" datastore, >>>>>>> which would be all config true + all config false nodes. One issue >>>>>>> with this is that the semantics of the node is different in the >>>>>>> different data stores, even if the syntax (by definition!) is the >>>>>>> same. In order to handle this properly you need either two >>>>>>>different >>>>>>> description statements, or two "sections" within the description >>>>>>> statement. >>>>>> I think this is not much different from default values. Leaves and >>>>>> leaf-lists that have them defined in the data model may not be >>>>>>present >>>>>> in intended config, yet one can consider them to be in applied >>>>>>config. >>>>> I think that default values are logically just a way to make the >>>>> configuration data more concise. I.e. everywhere you have a default >>>>> value then the equivalent configuration could be expressed with a >>>>> explicit value set instead. >>>> I think default values are just what they are. A set of values on the >>>> server that have not been explicitly set by the client via >>>> intended-config. >>> The default values are determined by the schema and the intended >>> configuration. You need to know both to know what default values the >>> server is expected to use. >> No disagreement. The only point is whether default values *shall* or >>*may* >> be provisioned via intended config > >I meant "May". agreed: default values *may* be provisioned via intended config > >>> But in terms of what is actually applied, an intended configuration >>>with >>> defaults values can be mapped into an equivalent intended configuration >>> with all implicit defaults replaced by the equivalent explicit values. >>> What gets applied in the device should be the same in both cases. >>> >>> >>>> It is certainly possible to set default values in >>>> intended-config explicitly, but it is not strictly needed. >>> Yes, of course. >>> >>>>> As such, I think that the default values apply equally to both the >>>>> intended and applied configuration. >>>> While this is allowed (see above), I would consider default values >>>>apply >>>> in practice to the applied config >>> I think that I disagree on this point. >> OK, let’s keep this point for a further discussion. >>> The intended configuration is only complete when you consider its >>> associated YANG schema and implicit default values. >> True, but it doesn’t mean that the client which holds the complete >> intended config has to explicitly push everything down to the server. >> Again this is the distinction between *may* and *shall* and worth a >> discussion. >Yes, I think that it is "may". > >> >>> >>>>> If after a config request it takes time for the system to apply a >>>>> default value, then ideally the applied configuration should have an >>>>> explicit leaf to show what value is actually in effect until the >>>>> default >>>>> value has actually been applied in the system. >>>> If the client has an indication whether the configuration application >>>>is >>>> finished (with or without errors), it knows that the applied config is >>>> now >>>> stable to be read. Reading applied config during an operation should >>>>be >>>> avoided. Hence I would question the need for a per-leaf state and >>>> advocate >>>> for a per-server state. >>> I think that the whole purpose of the opstate requirements is that the >>> operators effectively want to be able to track on a per leaf element >>> rather than a per-server element. >> The point has been that the client wants to know whether it’s intended >> configuration has been applied. This information is missing from the old >> asynch model and hence creates uncertainty. Any read attempt of the >>client >> related to applied configuration may fall into a transition period and >>is >> only a snapshot of a wobbly state. >Yes, and that isn't a problem. Whether it is a problem depends on what for the information is used by the client. If the client periodically checks values to monitor the progress of an intended config application, it wouldn’t be a problem. This is what is actually done since there is a lack of information whether the intended configuration is fully applied. However if the client is collecting leaf information in order to derive an action, it has to rely on the state. So here there is information needed that can be relied upon. We are discussing whether that information should be on a tree or a leaf level. My preference goes for a higher level because it is more reliable to implement, but as with all preferences there needs to be consensus. If one implements state on a leaf level there are 3 cases to consider: A) rollback-on-error: All leafs touched in the config have to remain ‘dirty’ (see below for definition) until the last value has been applied or the rollback is finished. Then in a second step the dirty flag is removed. B) stop-on-error: first all leafs supposed to be touched by the intended config are marked, then config is applied and the ‘dirty’ flag can immediately be removed from the leafs. However if an error occurs the dirty flag of all subsequent leafs has to be cleared since there is no config in progress anymore C) continue on error: mark all affected leafs with the dirty flag and clear it after leafs have been configured (successfully or non-sucessfully) I fear that we’ll eventually end up with something like an orphan control daemon in the server to clean up all the forgotten states, rendering the fine level of state less useful than it appear. > >The intended config is updated, and then the applied config state >converges on the intended config. > >> Essentially we are discussing where to put a dirty-flag. In my (less >> granular) view it is prudent to put the dirty-flag high up in the tree >>and >> keep it true until the state change completed (irrespective if it was >> successful or not). Another way is to keep a very granular view and >>stick >> the dirty flag on all leafs that are supposed to be touched by the >> intended state and cleaning them up after *all* intended config has been >> attempted to apply. A bit of more hassle from an implementers point of >> view, and I am not sure if it is worth. > >Having a single dirty flag doesn't really meet the requirements (as >stated in the requirements draft). It means that config reads from the >server are unavailable (or stale) whilst a config change is in progress >(which could take a long time). Sorry, I was using a sloppy term without definition. I meant ‘dirty’ flag is a marker indicating that a configuration application is still running. Technically such a flag could be sticked at any point in the tree including leafs. In other words, a client can read whatever and whenever it wants. ‘dirty’ indicates that the attribute value cannot be relied upon, since a configuration is ongoing. Hope this clarifies that there is no unavailable or stale period for reading as stated in the requirements. > >Instead, the operators requirement is that the tracking is done on a per >leaf basis (e.g. like the OpenConfig YANG models on >https://github.com/openconfig/public), I believe with the expectation >that the server should update the leaves as the configuration is being >applied. I.e. if the server had processed half the configuration from a >1 million entry config then ideally it should be updating the applied >configuration leaves as it goes so that the client knows what is >currently programmed at that particular point in time. In the ideal >world the server should always be telling the client what configuration >is applied at that specific point in time that the request is processed. > >> >>> I might be wrong, but I think that the design being consider by the >>> opstate operators is along the lines of an eventual consistent model. >>> E.g. something along the lines of: >>> >>> At any point in time the operator knows what configuration state they >>> would a device to be in (i.e. the intended configuration). >> OK >>> Whenever the client changes their intended configuration, they push >>>down >>> the updated intended configuration to the device. >> OK, from now on the client is blind about the applied state of the >>server >> unless it can guess it from e.g. Derived state and so on. >No, the client can read the current state from the server at any point >in time, and ideally it should reflect the configuration at that point >in time (even if it is half way through a config request). While we are in agreement that the client can poll the applied state at any point in time (see above), it is not obliged to do so given that the server sends an indication when the config is applied. I also realized that I didn’t explain sufficiently what i meant with ‘blind’. Take the case of 2 different implementations of a server applying configuration: A) first set the new value in the internal database (aka. applied config) and then program the HW. B) first program the HW and then reflect the state in the internal database Say the client’s intention is to change a leaf value from X to Y. After configuring, the client is reading the leaf value between the first and the second write: A) will report Y, but still runs with X B) will report X, but runs already with Y After successful application (after step 2), both implementations will consistently execute in HW and report the same value in the applied config. However the client can’t rely on the information it reads in the meantime - that’s what I meant with ‘blind’. If the only purpose is to monitor the progress of applying the intended state, this level of information is good enough, but I would argue that there are less intense mechanisms to do so. If the client truly needs to rely on the information read, it has to wait for completion. > >>> The device starts applying the change (using the specified error >>> handling semantics) >> OK >>> They register for notification for changes to all intended/applied >>> config and derived state on the device so that they have a feedback >>> mechanism to know whether the configuration is being successfully >>>applied. >> OK, so from now on the client knows that the new intended config is >> active. It also means that the client can reliably read applied state. >The changes to the individual leaves can be notified independently as >they change state. See discussion above about rollback-on-error etc. requiring a careful definition on when to send notifications. > The client can reliably read the applied state at >any time. No agreement here. As discussed above: "A client can read applied state at any time, but it can’t reliably assume it being applied before completion of an ongoing configuration”. > > >>>>> This does open the question of how do you express the case that no >>>>> value >>>>> has been applied rather than a different value. For the opstate >>>>> encoding solution draft that I put forward (or using meta-data), >>>>>then I >>>>> think that it would probably be possible to extend the encoding to >>>>> explicitly include this information if required. >>>> Perhaps I am missing something here. If the value supposed to be >>>>applied >>>> is the same that already exists, just skip it in the server. >>> The case I was considering is where the server has no value applied >>> (e.g. for an optional feature) rather than the default value. >> Whatever value the server applied (none or default) shouldn’t be an >>issue >> unless the intended config imposes a certain value. >It is an issue because the client wants to know what configuration a >device is actually running. Ideally it wants a given device to exactly >implement the configuration that they are requesting. They don't really >want lots of random device specific values that will require custom >client code to handle. I think we are in agreement that the client *may* configure default values to address such cases. > > >> I guess you had in >> mind on how to deal with the opstate of a non-value. Pushing the opstate >> higher up the tree would probably address the issue (see above). >>>>> Alternatively, and for the other proposed opstate solutions, then I >>>>> expect that the most appropriate ideal semantics to handle this >>>>> scenario >>>>> would be to delay marking the parent object as being applied until >>>>> every >>>>> descendent child leaf with a default value set has a value applied in >>>>> the system, either to the expected default value (in which case the >>>>> child leaf wouldn't need to be present in the applied config), or >>>>> transiently to another value (which would be in the applied config >>>>> until >>>>> the system updated and the correct default values have actually been >>>>> applied). In real systems, I would have thought that the default >>>>> values >>>>> are often implicitly programmed when the parent containing object is >>>>> created anyway, so I suspect that this behaviour wouldn't actually be >>>>> that onerous to implement. >>>> It appears to me that we run into those issues by requiring the >>>>intended >>>> config to contain also the default values. That doesn¹t seem >>>>necessary. >>>> I >>> I can't see how you can have default values apply only to the applied >>> configuration and not the intended configuration. The intended >>> configuration cannot be correctly interpreted if you don't also >>>consider >>> the default values specified in the schema. >> Given that servers nowadays cover a huge amount of functionality where >> often only a subset is required by a client, I would consider quite a >>bit >> of default values irrelevant for the scope of the client. If e.g. You >>plan >> to use a router that supports VPLS, but you do not care since it is not >> needed, those defaults can just be left to the server. >YANG already takes care of this, as per RFC6020bis section 7.6.1, only >the defaults that are in scope for your configuration are relevant. In other words, all defaults that are not in scope remain as set by the supplier of the Server and will not be changed by the client. Looks we are in agreement. > >>>> would also argue that marking the Œapplied=intended¹ state per leaf is >>>> counter-productive. Assume the client sets an intended state of two >>>> values >>> Tracking intended vs applied on a per leaf basis is the essence of the >>> opstate requirements, please lets not rehash these all yet again. :-) >> See above, you can do this but it’s quite a bit of work. The requirement >> stems from a time where a client wasn’t able to figure out whether a >>leaf >> has been changed already or was about to change in future. To me it >> appears more of an implementation choice. >I disagree. The requirements are from the perceived deficiencies in >NETCONF/YANG that need to be fixed for operators to use YANG effectively. We agree that "Tracking intended vs applied on a per leaf basis” is a requirement, but it appears to me that we have different ideas on the interpretation of ‘applied' during the transition period. In an implementation draft I would consider something along those lines: If a server completed the application of intended config (with or without errors), the applied config SHALL reflect the actual configuration in force. All leaves where the value of intended == applied are in the state "intended = applied”. All leaves with intended != applied are in error (tbd) If a server is in the process to apply configuration, the reported applied value MAY NOT reflect the actual configuration in force. Then the fact that the values of intended equal those of applied SHOULD NOT be taken as reliable indication that the intended configuration is actually in force. Likewise a value of intended != applied SHOULD NOT be taken as reliable indication that the intended configuration is not in force. NOTE: whether the applied=intended state needs to be coded on a per-leaf-level or higher up in the tree is a separate issue. > > >>>> (A,B) on two different leafs with rollback-on-error semantic. If >>>> applying >>>> A succeeds and the client reads the applied state while applying B is >>>> still in progress, a rollback may still happen. That would invalidate >>>> the >>>> previous value of A. In other words it is unwise to read data from a >>>> source while it is actually writing. >>> No, this is fine, and isn't a problem. The server will eventually >>> converge on a state and the client will be notified of that state. >>> The >>> fact that a client might temporarily see a valid state that is >>> subsequently undone isn't a problem. >> I’d seriously question those two statements. When the server is updating >> its applied state you have at best a 50% chance to read the correct >>value. >> What meaningful conclusion is the client supposed to take from that? Out >> of desperation, current implementations use that ‘trick’ by polling >> various leaf values to figure out whether an intended state has already >> been applied or not. However such intensive polling cycles are no more >> needed once a server notifies the client upon completion of intended >>state >> application. >> If the client chooses to read applied state during that period, it is at >> least aware that the state is just a temporary snapshot. >The client doesn't poll. Instead it registers for notification of >changes and receives a continuous stream of updates. > >At any point in time, the value read by the client is correct, it just >happens that the system can be thought of being in the state of constant >flux. > >E.g. the global BGP routing table is constantly changing, but that >doesn't mean that you can't take a useful snapshot of it, or monitor how >it is changing. > >Thanks, >Rob > > >> >>> Thanks, >>> Rob >>> >>> >>>>> Thanks, >>>>> Rob >>>>> >>>>> >>>>>> Lada >>>>>> >>>>>>> list interface { >>>>>>> description-config >>>>>>> "The list of configured interfaces on the device. >>>>>>> ..."; >>>>>>> description-oper >>>>>>> "The list of interfaces on the device. >>>>>>> >>>>>>> System-controlled interfaces created by the system are >>>>>>> always present in this list, whether they are >>>>>>>configured or >>>>>>> not. >>>>>>> ..."; >>>>>>> } >>>>>>> >>>>>>> >>>>>>> /martin >>>>> _______________________________________________ >>>>> 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
