Re: [Netconf] Does <discard-changes> do the same thing as <copy-config>-ing 'running' to 'candidate'?

Attila Vangel <vangel.attila@gmail.com> Mon, 28 May 2018 06:32 UTC

Return-Path: <vangel.attila@gmail.com>
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 DF38E120454 for <netconf@ietfa.amsl.com>; Sun, 27 May 2018 23:32:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level:
X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 yp4KnAIOW7hr for <netconf@ietfa.amsl.com>; Sun, 27 May 2018 23:32:02 -0700 (PDT)
Received: from mail-io0-x232.google.com (mail-io0-x232.google.com [IPv6:2607:f8b0:4001:c06::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2E4AA12751F for <netconf@ietf.org>; Sun, 27 May 2018 23:32:02 -0700 (PDT)
Received: by mail-io0-x232.google.com with SMTP id o185-v6so12949914iod.0 for <netconf@ietf.org>; Sun, 27 May 2018 23:32:02 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Oil/We7oLVcrgqAtuSBt3c7hsL1RDX38ynkVl24UJ6o=; b=lI2Xpvlhliwb1expbRU6bS3hBthVO3ekZRCCAQG3TsnRfhEJZ2fr/4zAj7O9yX0maj h7uwcBeuz7mpYqHzNyKMm7FQlL3shSOH8rRuZI+h6acIZg0mBfPlNpwNXaSXL4jV70i2 eQVi+PV422vQC4b1hb30qnVjhO3k0zrB+KFRBeBGvwu11h+FVijAfvgvL4/d1mbIGwvw /GzydK9kL6b39Rk7cvTukA4MRdVL68Gov05ny8FwDnin4OzDeqsKTeKC1zyD5b1CBSKJ vHKPu09a0oXa62uLZM7Xx7wxWKoYVWIZ5n/h0yTprXf1QtGmuVRD5hxnA9ZmxrHYWNOq 1lQw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=Oil/We7oLVcrgqAtuSBt3c7hsL1RDX38ynkVl24UJ6o=; b=ekgHytr/3VHdByJzyofi6SxYAUrn4QQFFrQP1tTHnFvxBUkZWDZigeMmQMuKp1ibsR tdtR0PZPMoRTZCWOaOfTqrXgVbLicLlnfpT4N/ejB9L4jyd4bBiYxo4RikEUoHJ98w6o OFK1jdCt+HVD/iI+wPCC/DHJpJLFQ504q7C9Er2I8vxv1//kHvLvseZAPT/ZXUBFO4LY 3721U1h3rzDRz+AomiApETiyzPlZLzz85QLuK5Z+UFDxtVbc48NZtTpji2bJEUaMRmCg 9jlC8YlBZK+aGNDVMx4WpRTvOgdzHxMr+hvJ2W6SIvTW+gAw6MJsPDWc+3jPiadzXcGV mrlw==
X-Gm-Message-State: ALKqPweoliZYndMFnq6CJqokS3Rx1RPhkyR6Fsaf93v4U4IkPZGY0CRQ PM0byCF+jxkma/gmN9hFcSjYiwba2aWClJmn9GI=
X-Google-Smtp-Source: ADUXVKIr86pSG/GiiwfLK8a/FSG9yiYkH+um6aqednMEaxiSZIhZdJ91x2sTeGLdKLWd/fKbMSmnKXWID0EH5Lx22cs=
X-Received: by 2002:a6b:8bd8:: with SMTP id n207-v6mr4123636iod.145.1527489121384; Sun, 27 May 2018 23:32:01 -0700 (PDT)
MIME-Version: 1.0
Received: by 2002:ac0:9ed7:0:0:0:0:0 with HTTP; Sun, 27 May 2018 23:32:00 -0700 (PDT)
In-Reply-To: <44facb91-7ae6-a75b-dafa-8b5bb43f944c@cisco.com>
References: <CAGSQd2-_S+5-ZmzbPB10DBch7ns8M=X8w5-0H4j+7TRk7USJpA@mail.gmail.com> <20180525122148.jz296uxlw0w4448w@webmail.eurecom.fr> <CAGSQd2_i+KWiU2gqKq8qBPKWO1DZ_nu13b3-nQYDb1qT43OPZQ@mail.gmail.com> <44facb91-7ae6-a75b-dafa-8b5bb43f944c@cisco.com>
From: Attila Vangel <vangel.attila@gmail.com>
Date: Mon, 28 May 2018 08:32:00 +0200
Message-ID: <CAGSQd283g8t+0bARZDhT7ViSeFBjvznkJVBQg-cHq=6rn-P2oQ@mail.gmail.com>
To: Robert Wilton <rwilton@cisco.com>
Cc: Ariel Otilibili Anieli <otilibil@eurecom.fr>, netconf@ietf.org
Content-Type: multipart/alternative; boundary="0000000000007a8048056d3e4681"
Archived-At: <https://mailarchive.ietf.org/arch/msg/netconf/thW6aUQUb7gPxb-6FXJcTHPxFlI>
Subject: Re: [Netconf] Does <discard-changes> do the same thing as <copy-config>-ing 'running' to 'candidate'?
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.22
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: Mon, 28 May 2018 06:32:06 -0000

Hi Ariel, Robert,

Thank you very much for the clarifications!

Regards,
Attila

On Fri, May 25, 2018 at 3:49 PM, Robert Wilton <rwilton@cisco.com> wrote:

> Hi Attila,
> On 25/05/2018 13:01, Attila Vangel wrote:
>
> Hi Ariel,
>
> Thanks for the quick turnaround! See my comment below.
>
> On Fri, May 25, 2018 at 12:21 PM, Ariel Otilibili Anieli <
> otilibil@eurecom.fr> wrote:
>
>> Hi Attila,
>>
>> Comments below.
>>
>> Regards,
>> Ariel
>>
>> Quoting Attila Vangel <vangel.attila@gmail.com>:
>>
>> Hi,
>>>
>>> N00b question on netconf. Could somebody please clarify?
>>>
>>> 1. Does <discard-changes> (
>>> https://tools.ietf.org/html/rfc6241#section-8.3.4.2) have totally the
>>> same
>>> effect as <copy-config>-ing 'running' to 'candidate'?
>>>
>> In terms of the contents of the candidate datastore then I would say yes
> the operations are the same.
>
> However, if the server is tracking config commits, then it could store
> different associated meta data for the two operations.
>
> No.
>>
>>>
>>> "This operation discards any uncommitted changes by resetting the
>>>    candidate configuration with the content of the running
>>>    configuration."
>>>
>>> If so, was it introduced as a shorter alternative of copying?
>>> If not, what is the difference between them?
>>>
>> <copy-config> copies the content of a datastore to another, whatever it
>> is; <discard-changes> discards the changes made on the 'candidate'
>> datastore.
>>
>
> In this case the description for <discard-changes> is incorrect in RFC,
> because it states: "resetting the
>    candidate configuration with the content of the running
>    configuration" (see above). So looks like this is a bug in the RFC.
> Anyway, I get the point now.
>
> I don't think that RFC is wrong.
>
> Is is just that <candidate> normally starts with a copy of <running>.
> Then the client modifies the contents of <candidate>, and finally it gets
> committed to <running>, at which point both datastores then have the same
> contents again.
>
> So the <discard-changes> is effectively removing any pending changes in
> candidate, which is equivalent to reverting the contents back to <running>,
> and would also be equivalent to doing <copy> from <running> to <candidate>,
> if that is supported by the server.
>
> So I think <discard-changes> is really just syntactic sugar.
>
> Thanks,
> Rob
>
>
>
> Attila
>
>
>>
>>> 2. I got confused because I watched a tutorial on youtube which used both
>>> commands, first <discard-changes> before locking any config datastores,
>>> and
>>> <copy-config>-ing 'running' to 'candidate' after locking these
>>> datastores.
>>> (The assumption in this example is that the device supports 'candidate'.)
>>>
>> I suppose they wanted to edit 'candidate' from 'running', that's why they
>> <copy-config> before edition.
>>
>>>
>>> 3. For the first time I was puzzled why to do <discard-changes> before
>>> doing any locking, but then I read in the RFC that lock would fail if
>>> 'candidate' was "dirty" (https://tools.ietf.org/html/rfc6241#section-7.5
>>> ):
>>>
>>> A lock MUST NOT be granted if any of the following conditions is
>>>       true:
>>>
>>>       *  A lock is already held by any NETCONF session or another
>>>          entity.
>>>
>>>       *  The target configuration is <candidate>, it has already been
>>>          modified, and these changes have not been committed or rolled
>>>          back.
>>>
>>>       <...>
>>>
>>> Another thing on <lock>
>>
>>> But still I am not sure about 1. If these commands do the same thing,
>>> using
>>> <copy-config> in this tutorial was just for showcasing doing it yet
>>> another
>>> way in 2.?
>>>
>>> (I was not sure whether to share the link for the tutorial, maybe it
>>> would look like as advertising the company/author who did the
>>> tutorial.)
>>>
>>> Best regards,
>>> Attila
>>>
>>>
>>
>>
>> ------------------------------------------------------------
>> -------------------
>> This message was sent using EURECOM Webmail: http://webmail.eurecom.fr
>>
>>
>
>
> _______________________________________________
> Netconf mailing listNetconf@ietf.orghttps://www.ietf.org/mailman/listinfo/netconf
>
>
>