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? 

 


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

 

Sue 

 

_______________________________________________
i2rs mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/i2rs

Reply via email to