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. Leafs 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
>
>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.
>
>
>>
>>> 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.
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.
>
>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.
>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.
>
>>
>>> 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. 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.
>
>> 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.
>
>> (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.
>
>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
