On 12/01/2016 10:41, Ladislav Lhotka wrote:
On 12 Jan 2016, at 11:12, Robert Wilton <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.
As such, I think that the default values apply equally to both the intended and
applied configuration.
It is useful if the operator is able to retrieve the parameter values that the
device is really using - which is the stated purpose of applied config. There
may also be vendor-specific defaults that aren't documented in a data model, or
defaults that are computed dynamically.
OK, so in essence you are proposing that the intended and applied config
nodes have different schemas, in that any default values in the YANG
schema only apply to the leaves in the intended config schema and not
the applied config schema. As such, because the applied config schema
doesn't haven't default values in the schema it must report all values
it is using.
But if we were to do this, then I'm not entirely sure why you would keep
default values in the intended configuration schema (other than
backwards compatibility, and potentially for documentation purposes)?
Personally, I think that default values are a useful way to simply and
shorten the configuration data set, but arguably this can apply equally
to both intended and applied configuration. For me, the main argument
for not allowing default values in the applied config is because of the
difficultly for the server to differentiate between a leaf that hasn't
been applied at all (e.g. for an optional feature) and the same leaf
that is applied with the default value.
I.e. I think that the applied configuration nodes already solve the
problem of the device defaults not matching the configuration schema,
since these differences should be reported in the applied configuration
(or alternatively as deviations to the original schema that is being
supported).
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.
My uderstanding is that default values come from the device so they needn't be
applied. For example, if an interface card is activated, it will typically use
some default values (e.g. MTU) without waiting for any configuration.
Yes. But if the default values that are actually being used by the
device don't match the implicitly expected value from leaf defaults then
these should be reported in the applied configuration with the value set
to the actual applied value.
Thanks,
Rob
Lada
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.
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.
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
--
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C
.
_______________________________________________
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
