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

"Jonathan Hansford" <jonathan@hansfords.net> Tue, 15 January 2019 10:02 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 8028F130DEA for <netconf@ietfa.amsl.com>; Tue, 15 Jan 2019 02:02:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Level:
X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] 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 8xMgSePhsRsH for <netconf@ietfa.amsl.com>; Tue, 15 Jan 2019 02:02:05 -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 E1351130E27 for <netconf@ietf.org>; Tue, 15 Jan 2019 02:02:04 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=hansfords.net; s=default; h=Content-Transfer-Encoding:Content-Type: Mime-Version:Reply-To:References:In-Reply-To:Message-Id:Date:Cc:Subject:To: From:Sender: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=PXdK8RSBrxFTnT0qLQtwl6FHnBkP28slUhdVnd0WW+A=; b=cjSN41+tjlSEOzmsDhQekgnKJO RukB5xtyjmvOzSbopGQUBMOrTtl7IhpuVGW56tMwul+9HVfxCeraWEx+1eoHTW0AwpHNdQY4GXHoB fG+uxObY+FD4zLJ5sBvrIlFzvpqKOkkKVda6rUPyLO41wrUYzflEvGy7Of8VMt99Sp8hsPUfYGW9j NieRwuepCMIcQa5dXDZNblXK1sJUjL2EBe7VKObx4hdgbZ54gnqL2lKjx+YHhDe9GPCI8VFYggnMs EcidA4L7TFIFJ5Wdgkz+hEMd/86l/Te4jbYr+OkfhNPuSuMJfa45ciGmt+R5UyXzdpSh3Pb4Ic+nH MTLsCQng==;
Received: from [51.52.247.166] (port=51078 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 1gjLXm-0043G3-86; Tue, 15 Jan 2019 10:02:02 +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:02:09 +0000
Message-Id: <em2395bee5-1d9f-40c5-8162-314dad97f6d3@morpheus>
In-Reply-To: <20190114223221.ohkqjlqvtwbdjkx6@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>
Reply-To: "Jonathan Hansford" <jonathan@hansfords.net>
User-Agent: eM_Client/7.2.34062.0
Mime-Version: 1.0
Content-Type: text/plain; format=flowed; charset=utf-8
Content-Transfer-Encoding: quoted-printable
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/JDjKGI-6M1xc9R5K3EE5ZnHZ5ns>
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:02:09 -0000

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.

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

------ Original Message ------
From: "Juergen Schoenwaelder" <j.schoenwaelder@jacobs-university.de>;
To: jonathan@hansfords.net
Cc: "'Andy Bierman'" <andy@yumaworks.com>;; netconf@ietf.org
Sent: 14/01/2019 22:32:21
Subject: Re: [Netconf] Is there a problem with confirmed commits?

>On Mon, Jan 14, 2019 at 08:07:26PM -0000, jonathan@hansfords.net wrote:
>>
>>  Just as a footnote, if the cause of the session termination was the device rebooting and the :startup capability was supported, the <running> configuration datastore will contain whatever was in the <startup> configuration datastore. However, a confirming commit on a persistent confirmed commit would still commit the <candidate> configuration datastore to <running>. If the purpose of the confirmed commit was to test the new configuration prior to making it permanent, it would therefore make sense to copy the <candidate> configuration datastore to the <startup> configuration datastore prior to the confirmed commit.
>>
>
>My understanding of a confirmed commit is:
>
>     copy condidate to running and wait for a confirmation that
>     everything is OK; if no confirmation is received within a certain
>     time window, rollback to the original state of <running>.
>
>The situation you describe is a bit unclear for me; when does the
>device reboot, after the confirmed commit has been issued but before
><candidate> was copied to <running>? That would be a rare situation
>and I have some doubts that implementations after the reboot would
>start the confirmed commit or they would not execute a reboot before
>copying <candidate> to <running>.
>
>/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