IETF Logo Mail Archive

Re: [Netconf] [netmod] WG adoption poll draft-nmdsdt-netmod-revised-datastores-00

Robert Wilton <rwilton@cisco.com> Mon, 19 December 2016 10:50 UTC

Return-Path: <rwilton@cisco.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 6C29E1296FC; Mon, 19 Dec 2016 02:50:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -17.622
X-Spam-Level:
X-Spam-Status: No, score=-17.622 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-3.1, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 Y-Hbqs4pvmqO; Mon, 19 Dec 2016 02:50:50 -0800 (PST)
Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2AF52129887; Mon, 19 Dec 2016 02:48:40 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2481; q=dns/txt; s=iport; t=1482144521; x=1483354121; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=+GcnLQAOV8Z12lB15Xbozb79KNz40GIVWbNRNBJmvfw=; b=RYxJ7LtXFtmjKq+LPCqt654lcqWEI+xRqYVgZS0iAeCvFkEnXW9kOHW7 FpaeaY+niudQ44UO8UQedNVXkpoLmTVTc8ZNjAV+Zxrxx12AJtSSCAJz/ 1XQNk2YMZ6dqTlbBv3jHW8FqJT6KdQpVzF5JDwF/4qG8D8GRsHiP7o8Wm M=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0CXAgDOuVdY/xbLJq1dGQEBAQEBAQEBAQEBBwEBAQEBgywLAQEBAQF5gQaOQpVkh3aNGIIKHwuFLkoCglYSAQIBAQEBAQEBYiiEaAEBAQQBARAmNgsMBAsRAQMBAQEnByEGHwMGCAYBDAYCAQEXB4gvAxcOnkIBkB6HJw2DVwEBAQEBAQEBAQEBAQEBAQEBAQEBARgFhjaBfQiCVIJIh1kFiFuHaIl4NY1Cg3KBdIgqhi+HcIFyUoNlhA8mDSOBAhUOK4NdHBiBRT40iFwBAQE
X-IronPort-AV: E=Sophos;i="5.33,373,1477958400"; d="scan'208";a="690562521"
Received: from aer-iport-nat.cisco.com (HELO aer-core-3.cisco.com) ([173.38.203.22]) by aer-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 19 Dec 2016 10:48:39 +0000
Received: from [10.63.23.74] (dhcp-ensft1-uk-vla370-10-63-23-74.cisco.com [10.63.23.74]) by aer-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id uBJAmcZ2008163; Mon, 19 Dec 2016 10:48:39 GMT
To: Jonathan Hansford <jonathan@hansfords.net>, 'Ladislav Lhotka' <lhotka@nic.cz>, 'Andy Bierman' <andy@yumaworks.com>, 'Mehmet Ersue' <mersue@gmail.com>
References: <beb56258-c0ae-f625-a2d4-50f6a4c0bf26@labn.net> <B0E8B70F-56B8-48BF-95E8-83A241DD7A45@nic.cz> <20161205093858.GA97253@elstar.local> <9448A315-D0B4-46E3-8456-C648698B50A0@nic.cz> <20161205120210.GA97559@elstar.local> <CABCOCHQZJvCp2=Ay=nMfZPqwLkKe2OCZAZhTaKVryNEKThitNw@mail.gmail.com> <CAGyj0qOOJZg2b9UA2q7oAEkdEJaNLUd6n_Dc+CE5=U8N7ifsrw@mail.gmail.com> <F8614A0D-518C-4A05-BB7D-C460CD3D5972@nic.cz> <52c8547e61354c1a9adefc69ff07a4a7@XCH-RTP-013.cisco.com> <CABCOCHToDs98tr3o5Np1vjvKa9uMS_MWKJZHo8GQtNj_1xXEiQ@mail.gmail.com> <004101d25589$a0cd5f20$e2681d60$@gmail.com> <CABCOCHTnCu4uE=da2Z+rOArGBoMXcicsofgLQP8LPLGkR-ho5Q@mail.gmail.com> <m2mvfyr3jd.fsf@birdie.labs.nic.cz> <001001d259cf$3d5a0de0$b80e29a0$@hansfords.net>
From: Robert Wilton <rwilton@cisco.com>
Message-ID: <1665b254-b9eb-3260-9b66-1e82662b36ac@cisco.com>
Date: Mon, 19 Dec 2016 10:48:34 +0000
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0
MIME-Version: 1.0
In-Reply-To: <001001d259cf$3d5a0de0$b80e29a0$@hansfords.net>
Content-Type: text/plain; charset="windows-1252"; format="flowed"
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/netconf/0UUds7RZvtIA2nzlWDuTfQiiwVY>
Cc: 'NetMod WG Chairs' <netmod-chairs@ietf.org>, 'NetConf WG Chairs' <netconf-chairs@ietf.org>, 'NetMod WG' <netmod@ietf.org>, 'Netconf' <netconf@ietf.org>
Subject: Re: [Netconf] [netmod] WG adoption poll draft-nmdsdt-netmod-revised-datastores-00
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.17
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, 19 Dec 2016 10:50:51 -0000

Hi Jonathan,

These are just my thoughts ...

I'm not advocating getting rid of candidate/locking, but if I was 
designing a new network management solution, I would not plan on using 
candidate/locking.

Candidate is great when you have got a human operator typing in some 
config on the CLI and want to stop anyone (or anything) else changing 
the config at the same time under their feet.

But once you only have machines programming the config, then they should 
be able to easily construct a single message for each edit of the config 
(which can be applied/failed in its entirety). Candidate and locking 
don't seem to help here.

Further, if you want to update multiple devices at the same time then 
you end up in the realm of distributed transactions which get very 
complicated and are hard to get right in a fully robust fashion.

It is at this point, that I would try hard to build a network management 
architecture that doesn't rely on transactions or locking, and instead 
only relies on individual updates being consistently applied in a 
serialized fashion.


Rob


On 19/12/2016 08:09, Jonathan Hansford wrote:
>> -----Original Message-----
>> From: netmod [mailto:netmod-bounces@ietf.org] On Behalf Of Ladislav
>> Lhotka
>> Sent: 14 December 2016 14:25
>> To: Andy Bierman <andy@yumaworks.com>; Mehmet Ersue
>> <mersue@gmail.com>
>> Cc: NetMod WG Chairs <netmod-chairs@ietf.org>; NetConf WG Chairs
>> <netconf-chairs@ietf.org>; NetMod WG <netmod@ietf.org>; Netconf
>> <netconf@ietf.org>
>> Subject: Re: [netmod] [Netconf] WG adoption poll draft-nmdsdt-netmod-
>> revised-datastores-00
>>
> :
>> As for candidate, it is optional and we all know that it is quite
> problematic if
>> concurrent access of multiple clients is possible. Therefore, it would IMO
> be a
>> good riddance.
> For someone who is yet to see NETCONF and YANG used in anger, can you
> explain why judicious use of candidate and lock is problematic with
> concurrent access and why, as a consequence, it should be got rid of? One of
> the features of NETCONF that attracted us to it is its support for
> transactioning, a feature which it would appear came from previous
> experience with JUNOS. Is it current guidance that transactioning should not
> be used?
>
> Jonathan
>
>> Lada
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
> .
>

v2.23.0 | Report a Bug | By Email