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.
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).
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.
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
