On 19/10/2015 13:18, Martin Bjorklund wrote:
Robert Wilton <rwil...@cisco.com> wrote:
Hi Martin,
On 19/10/2015 12:06, Martin Bjorklund wrote:
Robert Wilton <rwil...@cisco.com> wrote:
On 16/10/2015 22:32, Kent Watsen wrote:
Will there ever be a server that operates in synchronous mode, given
that applied will not match intended if hardware is missing?
Will a client ever use "block" mode if it means that it might hang
forever (or at least until some hw is plugged in)?
I think the key is in the phrase "The server MUST fully *attempt* to
apply..."
+1.
So today we have this situation:
intended operational
config values
X--------------------------------------------------X
(time ->)
When the edit-config returns, running (intended) has been updated, and
the operational state may or may not have been updated. Internally to
the system, there may be a chain of things that need to happen before
the intended config has been pushed out to all software/hardware
components.
The NMS/operator writes to intended config, ang verifies by checking
the operational state.
With applied config we have this situation:
intended applied operational
config config values
X------------------------------X-------------------X
In some cases, the applied config is an approximation of the
operational values (if e.g., a single config leaf is used by two
different components), and in other cases the applied config is just
one of the internal stages the config value flows through before
reaching the end component.
With async/sync systems we now have:
attempted
intended applied applied operational
config config config values
X-------------------X----------X-------------------X
^
this is when "block"
would return
To me it seems we're exposing another internal state to
the
NMS/operator. But in reality nothing has changed from the first
picture - the NMS/operator still needs to check the operational values
in order to know that the system behaves as it should.
I see it slightly differently.
I think that "attempted applied config" is effectively the same time
point as "applied config" above.
But if I pre-configure an interface for which the hw is not present,
it has been said that this config will exist in intended but not in
applied. And you said that you didn't want "block" to wait for the hw
to be present. So the server will return before this data shows up in
applied.
My thinking is:
For a synchronous operation (with continue-on-error option):
- the hw dependent config is updated to intended, probably an
error/warning is returned for those leaves to indicate that it can't be
applied because the hardware isn't present.
- at some given point in the future, i.e. as a completely separate
event, the hardware may be inserted and the intended config is applied
at that time.
For a synchronous operation (with rollback-on-error option):
- the configuration would fail because the hw isn't present (same
errors/warnings returned as above) and hence the entire config operation
is completely undone due to the rollback-on-error semantics.
Thanks,
Rob
As in the server has attempted to
apply all the configuration and for every it has either succeed,
failed, or can't be applied because the hardware isn't present.
Yes.
So using your time line above:
1. If you have an async config operation then the server returns at
time "intended config".
2. If you have a sync (blocking) config operation then the server
returns at time "applied config".
3. If you have an existing netconf config operation that is neither
explicitly sync nor async then the server may return at any time
between "intended config" and "applied config".
Sure. My time line shows how the new value trickels down from
intended to oper.
/martin
.
_______________________________________________
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
