On Wed, May 7, 2014 at 3:56 AM, Susan Hares <[email protected]> wrote: > Andy: > > > > Thank you for detailed discussion with Tom Petch/Jeff/Juergen/Tom Nadeau: > > > > <snip> > > I imagine I2RS will be completely separate from NETCONF and it should have > its own datastore -- so "i2rs-config" is appropriate because I2RS is the only > protocol using that datastore. The combined "operational state" is not > editable. > > > > Yes, that makes sense. Then if at some point in time you want to save the > running config (i2rs), the system has to explicitly copy it over. But until > then, its separate. The only question is: what is the complete running > config represented as? And what if Netconf wants to modify the running > config (i.e.: and the RIB in particular)? > > > > That copy-to-local-config feature would be extra, outside the scope of the > i2rs-config. > > </snip> > > ----- > > > > Why only is the copy-to-local-config feature out of scope for the > I2rs-config? How can the work be interoperable if this feature (required > or optional) does not work the same in different vendor's boxes? If the > implementations are different, this is great (differentiated products = > good); but IMHO this feature actions has to be interoperable... that is give > the same effective response in the different vendors. > > > > Can you explain further? > > >
Writing to the local config is the charter of the NETCONF WG, not I2RS. In order to copy from the I2RS data model to the configuration data model, a detailed mapping is required. Since the local-config is out of scope, the config data corresponding to the I2RS data is not required to exist. If it does exist, it can be vendor-specific, right? So the mapping is vendor specific. I would agree with you if I2RS was planning on standardizing data models for configuration and RIB editing. It that were the case, then I would re-ask the question Ron Bonica raised in London -- why would we want to write config data models with 1 language and I2RS data models with a different language? > <snip> > > > > Right. If we take that approach we need to have a way of the i2rs > "protocol" to signal that the config > > needs to be saved "soon". That is, its not done in real time, but rather > as a background process. > > Its probably. This can either be through a single keyword that is added > under the i2rs-config section, or > > per element or even per-element, if we decide to be more granular. > > </snip> > > > > IMHO it is important to know when the write to local-config is done even > if done in background. Are you indicating there is no > write-config/ack-complete-write config interaction? > > > > <snip> > > You seem to be suggesting that the I2RS behavior of forgetting all > injected state > > if the router happens to reboot is not that useful, and therefore it needs > to be > > saved in the background (best-effort). > > > > I think it is up to all the I2RS clients to always be around to receive > some > > sort of agent-reboot event, and re-install any required I2RS config. > > I can't imagine any use cases where the operator thinks "I only need to > > install this RIB data until that router accidentally reboots". > > </snip> > > > > If you re-install any required I2RS config, are you sure this is what the > I2RS client wants? > The protocol request would indicate what the client wants (e,g, copy-to-local config flag set). Since notifications are unreliable, a client will poll the 'agent-boots' counter frequently to see if needs to re-install lost state. This design does not scale well and introduces significant latency. It is much more convenient to have the agent deal with reinstall-after-reboot. > > Sue > > > Andy
_______________________________________________ i2rs mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2rs
