On Tue, Oct 13, 2015 at 12:13 PM, Juergen Schoenwaelder < j.schoenwael...@jacobs-university.de> wrote:
> On Tue, Oct 13, 2015 at 01:59:52PM +0100, Robert Wilton wrote: > > >As said before, an OS kernel usually does not track where resource > > >parameters were coming from. (An interface has a set of IP addresses > > >and the kernel usually does not know which addresses were coming from > > >a configuration daemon, a dhcp daemon, a tunneling daemon, a command > > >line utility, ...) The same may be true for line card. So in order to > > >implement a very tight definition, one has to either 'guess' which > > >'subset' of operational state can be related 'somehow' to the intended > > >config and then report the result of the guess work as applied config > > >or one would have to to change daemons/kernels/linecards to have a > > >tracking number or something like that. > > > > Inferring the applied config state from the operation state is one way > > of doing this. > > > > An alternative way is for the NC/RC server to maintain separate internal > > state for intended vs applied cfg nodes. Then the NC/RC server would > > update the applied cfg node when the internal IPC to program that > > configuration had completed for all affected subsystems. > > But the reality is that the NC/RC won't know. I invoke a system call > to tell the kernel what I want changed. The kernel sometimes says OK > before all components have been finally updated. The problem remains > to define what exactly applied config is. So are we only talking about > implementations that do not initiate the 'IPC' immediately or that > initiate the 'IPC' but may not wait for a completion of the 'IPC'? > > I agree -- even closed system code can be layered such that the server does not know if the command has been fully applied or not. > Since this all sounds somewhat academic, do we have operational > evidence that NC/RC implementations do exhibit significant delays > between ACKing a config change and the config change becoming > communicated to the subsystems affected? > > I have asked this question several times, but no answer so far. It certainly depends on the data models and the implementation. How slow is slow enough so that retrieving a lot of meta-data is worthwhile? 5 sec? 5 min? 5 hours? Nobody seems to know. > /js > Andy > > -- > 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/> > > _______________________________________________ > 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
