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