On Wed, Mar 04, 2015 at 02:42:44PM -0500, Jeffrey Haas wrote:
> 
> There is a presumption that it may be possible for the I2RS agent to
> restart.  Given that a number of I2RS operations are likely to be built
> using multiple interactions with the agent, it's necessary to understand
> what state the agent may be in with regard to last-reset.  A simple but
> unscalable way to implement this is to preceed each operation with a
> get/get-config to verify the state of the system prior to sending in the
> next I2RS operation.
>

If this is a problem (which I am not sure), then send a get/get-config
before each edit operation won't buy you much since the agent can
still restart inbetween.

> What is likely more stable is simply knowing whether
> the system is in the same state as when you last interacted with it.
> 
> A version numbering system of some sort, whether system-wide or potentially
> as part of some models (perhaps even just I2RS models) would be sufficient
> to provide such a checkpoint.
> 
> An example of the problem space this would address presuming three
> operations must be completed to accomplish a given I2RS goal, "A B C".
> If the agent crashes after B has been done, C may either complete with no
> errors, or may fail before the setup state for A and B are no longer in the
> system.

The simple solution is to make "A B C" one atomic edit.

> An analogous mechanism in SNMP to address such issues are discontinuity
> objects.

No, not really. Discontinuity objects help with monitoring, not so
much with sets. SNMP folks invented TestAndIncr (RFC 2579), which is
used to implement so called spin-lock objects. While this can be made
to work, I am not sure I would recommend this approach. While this
method allows to detect that edits were conflicting, it makes the
clients responsible to clean up the mess.

/js

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

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

Reply via email to