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 > > >
- [Netconf] Does <discard-changes> do the same thin… Attila Vangel
- Re: [Netconf] Does <discard-changes> do the same … Ariel Otilibili Anieli
- Re: [Netconf] Does <discard-changes> do the same … Attila Vangel
- Re: [Netconf] Does <discard-changes> do the same … Ariel Otilibili Anieli
- Re: [Netconf] Does <discard-changes> do the same … Robert Wilton
- Re: [Netconf] Does <discard-changes> do the same … Attila Vangel