Re: [i2rs] Call for Input from WG: I2RS error handling simplification for initial I2RS protocol
"Susan Hares" <shares@ndzh.com> Thu, 15 October 2015 15:45 UTC
Return-Path: <shares@ndzh.com>
X-Original-To: i2rs@ietfa.amsl.com
Delivered-To: i2rs@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 007D81B337C for <i2rs@ietfa.amsl.com>; Thu, 15 Oct 2015 08:45:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -99.055
X-Spam-Level:
X-Spam-Status: No, score=-99.055 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, USER_IN_WHITELIST=-100] 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 cf7dCgUOPSFe for <i2rs@ietfa.amsl.com>; Thu, 15 Oct 2015 08:45:15 -0700 (PDT)
Received: from hickoryhill-consulting.com (hhc-web3.hickoryhill-consulting.com [64.9.205.143]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4204C1A90BB for <i2rs@ietf.org>; Thu, 15 Oct 2015 08:45:15 -0700 (PDT)
X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=195.53.52.170;
From: Susan Hares <shares@ndzh.com>
To: 'Joe Clarke' <jclarke@cisco.com>, i2rs@ietf.org
References: <005901d10595$3f1fce10$bd5f6a30$@ndzh.com> <561CFF59.3020604@cisco.com> <01b601d106f8$69c836c0$3d58a440$@ndzh.com> <561FC0C1.5070704@cisco.com>
In-Reply-To: <561FC0C1.5070704@cisco.com>
Date: Thu, 15 Oct 2015 11:45:06 -0400
Message-ID: <016b01d10760$77cea020$676be060$@ndzh.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQEoIgrEBoPDtxDxKD7aeuKUQrt9ZAMAOITjAoWuDDkBs2I6OZ+EsYyQ
Content-Language: en-us
X-Authenticated-User: skh@ndzh.com
Archived-At: <http://mailarchive.ietf.org/arch/msg/i2rs/H8zqh2ggiPuRw2ZO9taTuOGy-ps>
Cc: jhaas@pfrc.org, 'Alia Atlas' <akatlas@gmail.com>
Subject: Re: [i2rs] Call for Input from WG: I2RS error handling simplification for initial I2RS protocol
X-BeenThere: i2rs@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "Interface to The Internet Routing System \(IRS\)" <i2rs.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/i2rs>, <mailto:i2rs-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/i2rs/>
List-Post: <mailto:i2rs@ietf.org>
List-Help: <mailto:i2rs-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/i2rs>, <mailto:i2rs-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 15 Oct 2015 15:45:18 -0000
Joe: Joe: Great questions - see below. -----Original Message----- From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Joe Clarke Sent: Thursday, October 15, 2015 11:06 AM To: Susan Hares; i2rs@ietf.org Cc: jhaas@pfrc.org; 'Alia Atlas' Subject: Re: [i2rs] Call for Input from WG: I2RS error handling simplification for initial I2RS protocol On 10/14/15 23:20, Susan Hares wrote: >> Joe: >> >> There will be some groups of data model have dependencies between objects. >> Some Client interactions will be orthogonal to each other. If there are >> groupings, then the dependencies may leave the I2RS agent and routing >> system in an unknown state. >Sure. >> >> The "all-or-nothing" is the normal case for NETCONF/RESTCONF. If >> clients are based on the Netconf/RESTCONF code base, this will be the >> simple upward change. >RESTCONF does do all-or-none, but typically operations apply to one data element at a time. >Clients would need to include multiple sub-operations for a, say, a PATCH. So, if I understand >correctly, there would be burden on the Client that uses RESTCONF and multi-messages for a >single "transaction" to handle the backout? Yes - multiple sub-operation in RESTCONF requires a PATCH, and the burden is on the client to handle the backing out of data in RESTCONF. You have hit upon the challenge. The I2RS client is bearing the burden of this back-out instead of the I2RS agent (Netconf "server" concept). Do you think this is reasonable to keep the I2RS agents simple? Will it make the I2RS clients unworkable? >Joe > > The I2RS agent needs to provide notification for error on writing for > priority conflict, and for other errors. The Stop-on-error would also need > to provide this input. > > Sue > > -----Original Message----- > From: Joe Clarke [mailto:jclarke@cisco.com] > Sent: Tuesday, October 13, 2015 8:56 AM > To: Susan Hares; i2rs@ietf.org > Cc: jhaas@pfrc.org; 'Alia Atlas' > Subject: Re: [i2rs] Call for Input from WG: I2RS error handling > simplification for initial I2RS protocol > > On 10/13/15 04:57, Susan Hares wrote: >> Currently the I2RS requirements have error handling having three parts: >> >> 1)"all-or-nothing", >> >> 2)"continue-on-error", and >> >> 3)"stop-on-error". >> >> To provide an easier first step for the I2RS Agent for the first >> implementation of an I2RS protocol, the I2RS protocol design team >> suggests reduce this to the "all-or-nothing" for the initial version. >> Later versions of the I2RS protocol can provide the "continue-on-error" >> or "stop-on-error" error handling. The earlier decision in the I2RS >> architecture was to support all 3 error handling pieces. > > It seems to me the latter two would be easier to implement as the Client > continues to fire (until not told to do so in the stop-on-error case) and > the Agent wouldn't have to track all operations for rollback. > > Is the assumption that most I2RS transactions will have mutual dependencies, > and this is the most common error case? > > Joe > _______________________________________________ i2rs mailing list i2rs@ietf.org https://www.ietf.org/mailman/listinfo/i2rs
- [i2rs] Call for Input from WG: I2RS error handlin… Susan Hares
- Re: [i2rs] Call for Input from WG: I2RS error han… Joe Clarke
- Re: [i2rs] Call for Input from WG: I2RS error han… Joel M. Halpern
- Re: [i2rs] Call for Input from WG: I2RS error han… Dongjie (Jimmy)
- Re: [i2rs] Call for Input from WG: I2RS error han… Susan Hares
- Re: [i2rs] Call for Input from WG: I2RS error han… Joe Clarke
- Re: [i2rs] Call for Input from WG: I2RS error han… Susan Hares
- Re: [i2rs] Call for Input from WG: I2RS error han… Joe Clarke
- Re: [i2rs] Call for Input from WG: I2RS error han… Susan Hares
- Re: [i2rs] Call for Input from WG: I2RS error han… Joel M. Halpern
- Re: [i2rs] Call for Input from WG: I2RS error han… Joel M. Halpern
- Re: [i2rs] Call for Input from WG: I2RS error han… Susan Hares
- Re: [i2rs] Call for Input from WG: I2RS error han… Susan Hares
- Re: [i2rs] Call for Input from WG: I2RS error han… Joe Clarke