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. 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
I meant "May".
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.
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).
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).
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. The client can reliably read the applied state at
any time.
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 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.
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.
(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
