On Wed, Mar 4, 2015 at 3:09 PM, Juergen Schoenwaelder <[email protected]> wrote: > 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. >
We use entity tags and If-Match in RESTCONF so the client can be sure it is editing the correct version of the resource instance. This works nicely for persistent configuration, especially if the server can reboot with the same config ETags. If-Match will cause the edit to fail if the server reboots and the I2RS state is gone. The client will get a 412 Precondition Failed response and know it might have to start over. RESTCONF only requires the server to maintain an ETag for the config root. Finer granularity (e.g., the parent resource has an ETag) is probably needed to support multiple concurrent edits. >> 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 > 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/> > > _______________________________________________ > i2rs mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/i2rs _______________________________________________ i2rs mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2rs
