Re: [Netconf] Is there a problem with confirmed commits?

Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> Tue, 15 January 2019 10:14 UTC

Return-Path: <j.schoenwaelder@jacobs-university.de>
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E20E130DEA for <netconf@ietfa.amsl.com>; Tue, 15 Jan 2019 02:14:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=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 31CwpsRTRiNT for <netconf@ietfa.amsl.com>; Tue, 15 Jan 2019 02:14:13 -0800 (PST)
Received: from atlas5.jacobs-university.de (atlas5.jacobs-university.de [212.201.44.20]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 35242127133 for <netconf@ietf.org>; Tue, 15 Jan 2019 02:14:13 -0800 (PST)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas5.jacobs-university.de (Postfix) with ESMTP id ACE82679; Tue, 15 Jan 2019 11:14:11 +0100 (CET)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from atlas5.jacobs-university.de ([10.70.0.217]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10032) with ESMTP id WcT5G6VpAh4O; Tue, 15 Jan 2019 11:14:11 +0100 (CET)
Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas5.jacobs-university.de (Postfix) with ESMTPS; Tue, 15 Jan 2019 11:14:11 +0100 (CET)
Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 8BDD920046; Tue, 15 Jan 2019 11:14:11 +0100 (CET)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id d--arw_56KnL; Tue, 15 Jan 2019 11:14:11 +0100 (CET)
Received: from exchange.jacobs-university.de (sxchmb04.jacobs.jacobs-university.de [10.70.0.156]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "exchange.jacobs-university.de", Issuer "DFN-Verein Global Issuing CA" (verified OK)) by hermes.jacobs-university.de (Postfix) with ESMTPS id 2D36320045; Tue, 15 Jan 2019 11:14:11 +0100 (CET)
Received: from anna.localdomain (10.50.218.117) by sxchmb03.jacobs.jacobs-university.de (10.70.0.155) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.1591.10; Tue, 15 Jan 2019 11:14:10 +0100
Received: by anna.localdomain (Postfix, from userid 501) id 270003005A3FA2; Tue, 15 Jan 2019 11:14:09 +0100 (CET)
Date: Tue, 15 Jan 2019 11:14:09 +0100
From: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>
To: Jonathan Hansford <jonathan@hansfords.net>
CC: 'Andy Bierman' <andy@yumaworks.com>, <netconf@ietf.org>
Message-ID: <20190115101409.jn4ygedezyy53nih@anna.jacobs.jacobs-university.de>
Reply-To: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>
Mail-Followup-To: Jonathan Hansford <jonathan@hansfords.net>, 'Andy Bierman' <andy@yumaworks.com>, netconf@ietf.org
References: <em106ef27b-c989-4e0b-b819-413fef852d53@morpheus> <20190114135056.t6sow7dbcyow6qcn@anna.jacobs.jacobs-university.de> <em5dfb175c-7835-43eb-a767-38e270601427@morpheus> <20190114154026.tbevjbcdn3oh34uz@anna.jacobs.jacobs-university.de> <emd3042eae-a670-4eb3-8055-5f3379acc4d8@morpheus> <20190114162532.ptmzaxwghowda2o7@anna.jacobs.jacobs-university.de> <CABCOCHTTMPq54_HPYOLBGavX2Q1NqzHPXLv0BVofBaKSxd=TdQ@mail.gmail.com> <009301d4ac44$c55b0fe0$50112fa0$@hansfords.net> <20190114223221.ohkqjlqvtwbdjkx6@anna.jacobs.jacobs-university.de> <em2395bee5-1d9f-40c5-8162-314dad97f6d3@morpheus>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <em2395bee5-1d9f-40c5-8162-314dad97f6d3@morpheus>
User-Agent: NeoMutt/20180716
X-ClientProxiedBy: SXCHMB03.jacobs.jacobs-university.de (10.70.0.155) To sxchmb03.jacobs.jacobs-university.de (10.70.0.155)
Archived-At: <https://mailarchive.ietf.org/arch/msg/netconf/sDQVz9dzv1wic3YSnmp95HNGXXQ>
Subject: Re: [Netconf] Is there a problem with confirmed commits?
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Network Configuration WG mailing list <netconf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netconf>, <mailto:netconf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/netconf/>
List-Post: <mailto:netconf@ietf.org>
List-Help: <mailto:netconf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 15 Jan 2019 10:14:16 -0000

On Tue, Jan 15, 2019 at 10:02:09AM +0000, Jonathan Hansford wrote:
> The issue I am trying to address is one where the original session is
> terminated. This could occur, for example, if the device's IP address is
> changed by the confirmed commit. I have also worked with devices in the past
> where certain configuration changes caused the device to reboot. In both
> circumstances the <candidate> has been copied to <running> but the commit
> hasn't been confirmed. Consequently there is still the need to issue a
> confirming commit which, according to my reading of the RFC, would copy
> <candidate> to <running> again. Clearly if <candidate> hasn't changed the
> server can choose not to make any changes to <running> but, if another
> client has in the meantime updated <candidate>, the confirming commit should
> (by my reading) copy those changes over.

Why copy again? The flow would be:

  upon confirmed-commit:
     copy <candidate> to <running>
     reinitialize what needs to be reinitialized
     wait for the confirmation
     if (timeout) rollback <running>

> From the last few emails on this subject it seems the persist-id can be
> considered a de facto lock on both <candidate> and <running> that is
> released on a confirming <commit>, a timeout on the confirmed <commit> or a
> <cancel-commit>. Unlike other locks, this "lock" could be shared between
> clients by sharing the persist-id. Is that a fair summary?

Yes, this may be one way to look at it.

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103         <https://www.jacobs-university.de/>