Hi Rob,
Guess we have a terminology issue here, hope that one cuts it:
attempt to
intended apply applied operational
config config config values
X-------------------X----------X-------------------X
^
this is when "block"
would return
From: Robert Wilton <rwil...@cisco.com<mailto:rwil...@cisco.com>>
Date: Monday 19 October 2015 14:57
To: Gert Grammel <ggram...@juniper.net<mailto:ggram...@juniper.net>>, Martin
Bjorklund <m...@tail-f.com<mailto:m...@tail-f.com>>
Cc: "netmod@ietf.org<mailto:netmod@ietf.org>"
<netmod@ietf.org<mailto:netmod@ietf.org>>
Subject: Re: [netmod] opstate-reqs #3: Is there a requirement for asynchronous
systems to provide a blocking config update?
Hi Gert,
I'm not sure whether your diagram might have been mangled by email, but please
can you explain in words when you think that a synchronous blocking config
event would return.
Thanks,
Rob
On 19/10/2015 13:39, Gert Grammel wrote:
Martin,
Attempting to apply a config appears to me as a process, not a state. So in my
mind the little drawing should look like this then:
receive updated Attempting to
intended intended apply intended applied operational
config config config config values
X----------X-------------------------------------X-------------------X
^
this is when "block"
would return
Gert
From: netmod
<<mailto:netmod-boun...@ietf.org>netmod-boun...@ietf.org<mailto:netmod-boun...@ietf.org>>
on behalf of Martin Bjorklund <m...@tail-f.com<mailto:m...@tail-f.com>>
Date: Monday 19 October 2015 13:06
To: "<mailto:rwil...@cisco.com>rwil...@cisco.com<mailto:rwil...@cisco.com>"
<rwil...@cisco.com<mailto:rwil...@cisco.com>>
Cc: "<mailto:netmod@ietf.org>netmod@ietf.org<mailto:netmod@ietf.org>"
<netmod@ietf.org<mailto:netmod@ietf.org>>
Subject: Re: [netmod] opstate-reqs #3: Is there a requirement for asynchronous
systems to provide a blocking config update?
Robert Wilton <rwil...@cisco.com<mailto: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.
/martin
_______________________________________________
netmod mailing list
<mailto:netmod@ietf.org>netmod@ietf.org<mailto:netmod@ietf.org>
<https://www.ietf.org/mailman/listinfo/netmod>https://www.ietf.org/mailman/listinfo/netmod
_______________________________________________
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
