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

From: "Susan Hares" <[email-masked]>
Date: Mon, 2 Mar 2015 17:27:17 -0500

I2RS WG: 

We are trying to wrap of the protocol requirements for I2RS within March.
This post ask 3 questions regarding the I2RS requirements.  

Question 1 context:  

The I2RS architecture states in section 1.1 that the I2RS interface should
be: programmatic, asynchronous, and offers fast, interactive access for
atomic operations.  This posts asks if we need to require a checkpoint to
make asynchronous functions work. 

In a review by the security directorate, the reviewer asked:  "Is security
and the support for the asynchronous nature of the protocol fully
supported?"  In the reviewers mind Asynchronous usually means the following:

1)      The protocol can launch operations and then check back later whether
they successfully completed.

2)       If you want to execute a second operation only if a first succeeds
(or to guarantee the order in which they execute), you need to at some point
wait for operations to complete.

3)      There is also substantial overhead in supporting asynchronous
operation in that all transactions need labels so that they can be queried?

Question 1:  Do we believe that netconf or restconf augmented by the
traceability requirements and the pub/sub requirements provides this
support?  

Question 2: Do we need a checkpoint (monotonically incrementing counter to
accomplish #2)? 

Question 3 Context:

The security directorate reviewer of the I2RS architecture stated: 

" A conceptually simpler strategy [than the asynchronous strategy] is to say
that since a client can make multiple parallel connections to an agent that
in cases where a client wants asynchronous operation he opens multiple
connections and launches one asynchronous operation on each. The cost is
that is has lower performance in cases where there are large numbers of
parallel operations tying up lots of connection state." 

In my understanding RESTCONF provides one operations per session. 

Question 3: If the I2RS client requires a tradeoff where that restricts the
space requirements for parallel sessions, is the space requirement for
output only (so that pub/sub requirements) are sufficient.  Or should this
tradeoff be considered in the I2RS protocol requirements. 

Thank you for your help,

Sue Hares

---

From: Melinda Shore <[email-masked]>
Date: Mon, 02 Mar 2015 13:44:39 -0900

On 3/2/15 1:27 PM, Susan Hares wrote:
> This posts asks if we need to require a
> checkpoint to make asynchronous functions work.

Hi, Sue:  I don't really understand the question.  If you're
going to specify that there's going to be support for
asynchronous event processing, you need a model for that.  It
can be polling-based, callback-based, interrupt-based, and so
on, and what data structures you'll require will depend on the
model you choose.  That includes both for naming and for
coordination/scheduling.  I'm not sure exactly what you mean
by "checkpoint" (semaphores?  locks?) but it may actually be
out of scope - an implementation question.

At any rate the first place to start is with coming up with a
concurrency (or asynchrony) model, and then proceeding from
there.

Melinda

---

From: "Joel M. Halpern" <[email-masked]>
Date: Tue, 03 Mar 2015 03:45:49 -0500

As written, it is hard to answer the questions.  Particularly since 
RestConf is still under development, I expect that most of the 
requirements can be met.  But I do not have enough information to know 
whether they are met.

Further, the questions seem to assume specific means of meeting the 
requirement.  They may well be the best means, but it is not obvious.

Further comments in-line.
Yours,
Joel

On 3/2/15 5:27 PM, Susan Hares wrote:
> I2RS WG:
>
> We are trying to wrap of the protocol requirements for I2RS within
> March.  This post ask 3 questions regarding the I2RS requirements.
>
> *Question 1 context: *
>
> The I2RS architecture states in section 1.1 that the I2RS interface
> should be: programmatic, asynchronous, and offers fast, interactive
> access for atomic operations.  This posts asks if we need to require a
> In a review by the security directorate, the reviewer asked:  “Is
> security and the support for the asynchronous nature of the protocol
> fully supported?”  In the reviewers mind Asynchronous usually means the
> following:
>
> 1)The protocol can launch operations and then check back later whether
> (or to guarantee the order in which they execute), you need to at some
> point wait for operations to complete.
>
> 3)There is also substantial overhead in supporting asynchronous
> *Question 1:*  Do we believe that netconf or restconf augmented by the

Drawing on the traceability requirement here assumes that the 
traceability reporting is to be within I@RS.  This was not obvious.  Inf 
act, if one is trying to diagnose problems / corruption of I2RS 
activity, one might well want traceability via means other than I2RS.

It is clear that one can create an information model with access contro 
recording the results of operations, and allowing a reader to determine 
what has happened.  It is not at all clear that pub/sub is needed to 
meet these requirements, although one could subscribe to such a table to 
get notifications of success / failure, which is not one of the listed 
requirements, but is clearly nice to have.

Statement 3 asserts taht there is substantial overhead associated with 
this.  While I would have to agree that there is overhead, I have 
trouble seeing it as "substantial".

>
> *Question 2:* Do we need a checkpoint (monotonically incrementing
> counter to accomplish #2)?

I can imagine multiple techniques to achieve goal #2.  A monotonically 
increasing counter, across multiple clients, seems like one of the 
harder answers to actual use, although it would seem to work.

> “ A conceptually simpler strategy [than the asynchronous strategy] is to
> say that since a client can make multiple parallel connections to an
> agent that in cases where a client wants asynchronous operation he opens
> multiple connections and launches one asynchronous operation on each.
> The cost is that is has lower performance in cases where there are large
> numbers of parallel operations tying up lots of connection state.”
>
> *Question 3:* If the I2RS client requires a tradeoff where that
> restricts the space requirements for parallel sessions, is the space
> requirement for output only (so that pub/sub requirements) are
> sufficient.  Or should this tradeoff be considered in the I2RS protocol
> requirements.

I am unable to parse the question.  Is the question "should we allow 
multiple parallel sessions, but restrict the number of such sessions?" 
Or is the question whether we want to require parallel sessions to be 
used for asynchronous operations?  The driver I understood for this 
requirement was that some operations may take time, and / or may produce 
significant volumes of response.

>
> Thank you for your help,
>
> Sue Hares
>
>
>
> _______________________________________________
> i2rs mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/i2rs
>

---

From: "Susan Hares" <[email-masked]>
Date: Tue, 3 Mar 2015 17:08:05 -0500

Melinda:

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
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.
3) pub/sub based - meaning the I2RS clients sign up to receive publications
of results. 
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). 

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. 

2) call-back item
If another higher priority interrupt, interrupts the write with call-back
response - then an error message would indicated the interrupt.  If a lower
priority commands tries to interrupt, the architecture indicates the lower
priority command will receive an error in the call-back.  If a same priority
command tries to interrupt the command, it is an error and both commands
should be flagged. In my understanding, the checking point is not of a use
in this case. 

3) pub/sub item 
A checkpoint may provide an indication if something changes between
subsequent updates from a pub/sub.  This information may be sent in the
pub/sub message sequences. 

4) atomic groupings of commands that return with a command. 
The atomic groupings of a commands either succeeds or fails based on same
circumstances as the call-back.   A checkpoint really doesn't aid the result
here. 

My understanding on the support of each of these four functions in
RESTCONF/NETCONF depends on Ephemeral data store issues.  Without a NETCONF
solution to the ephemeral datastore, only restconf can share definitions and
data between I2RS agent models and netconf data models.  IMHO this sharing
makes data-model creation a lot easier.  Therefore, let me comment on the
RESTCONF support for the four functions: 
 
1) polling - RESTCONF GET/QUERY can poll for data I2RS data (no ephemeral
data store issues) 
2) call/back item: RESTCONF RPC mechanism seem to be supported as well as
the POST, PUT, PATCH, and DELETE. 
 
3) pub/sub:  call-home features exist and a pub/sub feature solution has
been proposed.  
4) atomic group: RESTCONF provides the automatic 

RESTCONF provides integrity and confidentiality of the data and mutually
authenticated client-server identities. 	

Sue Hares  

-----Original Message-----
From: Melinda Shore [mailto:[email-masked]] 
Sent: Monday, March 02, 2015 5:45 PM
To: Susan Hares; [email-masked]; [email-masked]
Subject: Re: [secdir] Asynchronous Nature of the I2RS Protocol - vs RESTCONF
and NETCONF

On 3/2/15 1:27 PM, Susan Hares wrote:
> This posts asks if we need to require a checkpoint to make 
> asynchronous functions work.

Hi, Sue:  I don't really understand the question.  If you're going to
specify that there's going to be support for asynchronous event processing,
you need a model for that.  It can be polling-based, callback-based,
interrupt-based, and so on, and what data structures you'll require will
depend on the model you choose.  That includes both for naming and for
coordination/scheduling.  I'm not sure exactly what you mean by "checkpoint"
(semaphores?  locks?) but it may actually be out of scope - an
implementation question.

At any rate the first place to start is with coming up with a concurrency
(or asynchrony) model, and then proceeding from there.

Melinda

---

From: Jeffrey Haas <[email-masked]>
Date: Wed, 4 Mar 2015 14:42:44 -0500

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

> 1) polling based - I2RS client queries at a set of agents to receive status

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

> 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

E.g. netconf notifications

> (if you think I've missed one, please let me know). 

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

> 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

---

From: Jeffrey Haas <[email-masked]>
Date: Wed, 4 Mar 2015 15:29:17 -0500

>From memory, NETCONF will support async operations.  RESTCONF will support
asynchronous operations for Yang RPC.  

> Question 2: Do we need a checkpoint (monotonically incrementing counter to

I articulated a case for it in a later message.  It's really there to handle
the exception case of a restart by the I2RS agent.  Such an item would
require eventual protocol support, but should not be a factor that prevents
work from advancing on I2RS applications in the short term.

> tradeoff be considered in the I2RS protocol requirements. 

This is likely to be a multi-variable equation.

While the system may have limits on the number of sessions it is willing to
support, the system may also have resource contention for the multiple
operations that have been queued by the various sessions.  The ability to
pipeline work and the mechanisms to best optimize that will likely be
somewhat implementation specific.

In terms of protocol, I don't think there's a specific tradeoff.

-- Jeff

---

From: Jeffrey Haas <[email-masked]>
Date: Wed, 4 Mar 2015 15:38:12 -0500

> asynchronous operations for Yang RPC.  

Kent Watsen corrects me in that netconf (section 4.5) current requires
pipelining RPC operations.  Things may still be submitted asynchronously,
but completion order is not independent.

-- Jeff

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 5 Mar 2015 00:09:40 +0100

On Wed, Mar 04, 2015 at 02:42:44PM -0500, Jeffrey Haas wrote:
> 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 simple solution is to make "A B C" one atomic edit.

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

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

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 5 Mar 2015 09:18:02 +0100

On Wed, Mar 04, 2015 at 03:57:50PM -0800, Andy Bierman wrote:
> On Wed, Mar 4, 2015 at 3:09 PM, Juergen Schoenwaelder
> <[email-masked]> wrote:
> 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.
>

Thanks, this all makes sense. So there is a viable mechanism to create
a sequence of linked edits. The main trade-off, however, between a
single atomic edit and a sequence of linked edits is who is taking the
pain to cleanup the mess if things fail in the middle. If you write a
client, you love the server to do it. If you write a server, you love
the client to do it. ;-)

/js

---

From: Andy Bierman <[email-masked]>
Date: Wed, 4 Mar 2015 15:57:50 -0800

> clients responsible to clean up the mess.

Andy

---

From: Andy Bierman <[email-masked]>
Date: Fri, 6 Mar 2015 10:08:45 -0800

On Fri, Mar 6, 2015 at 10:04 AM, Jeffrey Haas <[email-masked]> wrote:
> On Thu, Mar 05, 2015 at 09:18:02AM +0100, Juergen Schoenwaelder wrote:
> It's all pain, but some component has to deal with it.
>
> I'm glad that restconf seems to have this situation covered, Andy.  Is there
> a similar mechanism in netconf that I've missed?  If so, this completely
> deals with the need for i2rs to have to ask for anything new. :-)
>

NETCONF has no support at all for this sort of thing.

Andy

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 6 Mar 2015 20:21:39 +0100

> deals with the need for i2rs to have to ask for anything new. :-)

I think the NETCONF solution is more geared towards a single
transaction solution, i.e., you can ship stuff into the candidate
datastore and then commit the whole change set in one go.

/js

---

From: Jeffrey Haas <[email-masked]>
Date: Fri, 6 Mar 2015 13:04:34 -0500

-- Jeff