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

"Jonathan Hansford" <jonathan@hansfords.net> Tue, 15 January 2019 10:36 UTC

Return-Path: <jonathan@hansfords.net>
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 A7712130E2B for <netconf@ietfa.amsl.com>; Tue, 15 Jan 2019 02:36:02 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.99
X-Spam-Level:
X-Spam-Status: No, score=-1.99 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_REMOTE_IMAGE=0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=hansfords.net
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 t1UKU7W1bcnE for <netconf@ietfa.amsl.com>; Tue, 15 Jan 2019 02:36:00 -0800 (PST)
Received: from mail.myfast.site (mail.myfast.site [109.203.117.12]) (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 21D32127133 for <netconf@ietf.org>; Tue, 15 Jan 2019 02:35:59 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=hansfords.net; s=default; h=Content-Type:Mime-Version:Reply-To:References: In-Reply-To:Message-Id:Date:Cc:Subject:To:From:Sender: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=NusI4y7JdPidaujuYrScMW7ohl6D3/6PBwKKpRQPzIQ=; b=CEeH8E81aGCPANaa8GZwU+QtS OluA2yVGKaP710GgjrkwfGA+2dHZRAfp8uuJbx4AusgA/4G8BTIWIHknLYxJDfg3u/v2Yfuc86wn0 EyCDcwrNvC+ecqM83JniMppkLvhq8S2HKhcYILjRDNOziJNJ3mmLxda9n/h2lwevDx05iCne/OigS rpai++55qlfzIyZq75rMNCJKE7fjSwk7xAbOMFNMWexdq2tW0KP5LJGsg4M0yHnpalHY5UO51b1lQ ogwcxmsD+dlZKXPrMM4cMIZwKTKLx6HEOWB9NF9aGLF8zF1aiwMX+Lvo3Dl0CAbEp4KolzSqzQnFr ciB9pvqCg==;
Received: from [51.52.247.166] (port=51405 helo=[172.16.1.65]) by mail.myfast.site with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.91) (envelope-from <jonathan@hansfords.net>) id 1gjM4c-004F8Q-4x; Tue, 15 Jan 2019 10:35:58 +0000
From: Jonathan Hansford <jonathan@hansfords.net>
To: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>
Cc: 'Andy Bierman' <andy@yumaworks.com>, netconf@ietf.org
Date: Tue, 15 Jan 2019 10:36:02 +0000
Message-Id: <em915d9278-7fc2-4163-b580-95e4d7ac5442@morpheus>
In-Reply-To: <20190115101409.jn4ygedezyy53nih@anna.jacobs.jacobs-university.de>
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> <20190115101409.jn4ygedezyy53nih@anna.jacobs.jacobs-university.de>
Reply-To: Jonathan Hansford <jonathan@hansfords.net>
User-Agent: eM_Client/7.2.34062.0
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="------=_MB466B7D08-3E34-4472-BFDB-63B7DC8B9847"
X-Antivirus: Avast (VPS 190115-0, 15/01/2019), Outbound message
X-Antivirus-Status: Clean
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - mail.myfast.site
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - hansfords.net
X-Get-Message-Sender-Via: mail.myfast.site: authenticated_id: jonathan@hansfords.net
X-Authenticated-Sender: mail.myfast.site: jonathan@hansfords.net
X-Source:
X-Source-Args:
X-Source-Dir:
Archived-At: <https://mailarchive.ietf.org/arch/msg/netconf/FgJFyM50eTqksr2c-ZTetdA5Sgg>
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:36:03 -0000


On 15/01/2019 10:14:09, "Juergen Schoenwaelder" 
<j.schoenwaelder@jacobs-university.de> wrote:

>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>
Section 8.4.1 states, 'A confirmed <commit> operation MUST be reverted 
if a confirming commit is not issued within the timeout period (by 
default 600 seconds = 10 minutes). The confirming commit is a <commit> 
operation without the <confirmed> parameter... the confirming commit ... 
MAY introduce additional changes to the configuration' So the 
confirmation comes in the form of a confirming commit which is not 
described as being different to any other commit, other than it 
completes a confirmed commit.

Section 8.3.4.1 states, 'The <commit> operation instructs the device to 
implement the configuration data contained in the candidate 
configuration.' So a confirming commit has to copy to <running> any 
changes, if any, that have been made to <candidate> since the previous 
confirmed commit.

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

---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus