Re: [secdir] [i2rs] Asynchronous Nature of the I2RS Protocol - vs RESTCONF and NETCONF

[Jeffrey Haas <[e-mail]>]

To expand on some of Sue's details in-line:

On Tue, Mar 03, 2015 at 05:08:05PM -0500, Susan Hares wrote:
> Thank you for your clear question - let me try to unpack and answer your
> question.  I really appreciate your aid in working through these cases. 
> 
> <chair-hat off> 
> The asynchronous models we've discussed are:
> 1) polling based - I2RS client queries at a set of agents to receive status
> information

An example of this is the GET operation in NETCONF or RESTCONF.

> 2) call-back based - the I2RS Client performs an action (adds an interface)
> and the I2RS agent returns a response after the sequence is done.

An example of this is creating a subscription against interface state, then
taking an action (edit-config, RPC) that adds that interface.

> 3) pub/sub based - meaning the I2RS clients sign up to receive publications
> of results. 

E.g. netconf notifications

> 4) atomic based - a sequence of commands that are done and then returned
> with a call-back.  
> (if you think I've missed one, please let me know). 

Most of our cases fit this and are aligned with RESTCONF.

> 
> IHMO the use of a checkpoint in each of the cases is the following. 
> 1) polling 
> The checkpoint (or revision counter) would be used to indicate if something
> else had written or change the portion of the tree after the polling began.
> This checkpoint can be for the whole tree or a model.  The keeping of a
> checkpoint per item within a model may be prohibited. 

This checkpoint detail is something that we will likely need to raise to the
netconf group as a component to assist in I2RS scenarios.  Here's a high
level description of how it might work.

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

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


-- Jeff