On 11/01/2016 14:11, Juergen Schoenwaelder 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
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.
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...
I think that your articulation is correct.
Thanks,
Rob
/js
_______________________________________________
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
