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

Jeffrey Haas <jhaas@pfrc.org> Wed, 04 March 2015 20:29 UTC

Return-Path: <jhaas@slice.pfrc.org>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB5FF1ACE73; Wed, 4 Mar 2015 12:29:18 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.578
X-Spam-Level:
X-Spam-Status: No, score=-1.578 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VluP8SX9BdHE; Wed, 4 Mar 2015 12:29:17 -0800 (PST)
Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id CE0A21ACE71; Wed, 4 Mar 2015 12:29:17 -0800 (PST)
Received: by slice.pfrc.org (Postfix, from userid 1001) id 78853C1B5; Wed, 4 Mar 2015 15:29:17 -0500 (EST)
Date: Wed, 4 Mar 2015 15:29:17 -0500
From: Jeffrey Haas <jhaas@pfrc.org>
To: Susan Hares <shares@ndzh.com>
Message-ID: <20150304202917.GC9142@pfrc>
References: <01c301d05538$0b4846c0$21d8d440$@ndzh.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <01c301d05538$0b4846c0$21d8d440$@ndzh.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Archived-At: <http://mailarchive.ietf.org/arch/msg/secdir/q38o0oK1EwOiibXcV-swe1R307g>
X-Mailman-Approved-At: Wed, 04 Mar 2015 14:11:57 -0800
Cc: 'Jeffrey Haas' <jhaas@pfrc.org>, i2rs@ietf.org, secdir@ietf.org
Subject: Re: [secdir] [i2rs] Asynchronous Nature of the I2RS Protocol - vs RESTCONF and NETCONF
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/secdir/>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 04 Mar 2015 20:29:18 -0000

On Mon, Mar 02, 2015 at 05:27:17PM -0500, Susan Hares wrote:
> 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?  

>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
> accomplish #2)? 

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.


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

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