Re: [netmod] comments on revised-datastores-00

Ladislav Lhotka <lhotka@nic.cz> Tue, 15 November 2016 00:48 UTC

Return-Path: <lhotka@nic.cz>
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A1DE9129411 for <netmod@ietfa.amsl.com>; Mon, 14 Nov 2016 16:48:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=no
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 u0ts91djknwE for <netmod@ietfa.amsl.com>; Mon, 14 Nov 2016 16:48:45 -0800 (PST)
Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id CD99F129452 for <netmod@ietf.org>; Mon, 14 Nov 2016 16:48:44 -0800 (PST)
Received: from localhost (dhcp-8ee8.meeting.ietf.org [31.133.142.232]) by trail.lhotka.name (Postfix) with ESMTPSA id 539801CC02A7; Tue, 15 Nov 2016 01:48:45 +0100 (CET)
From: Ladislav Lhotka <lhotka@nic.cz>
To: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>
In-Reply-To: <20161114094210.GA45946@elstar.local>
References: <m2zil2er5j.fsf@dhcp-8ee8.meeting.ietf.org> <20161114094210.GA45946@elstar.local>
Date: Tue, 15 Nov 2016 09:48:35 +0900
Message-ID: <m2eg2d600s.fsf@dhcp-8ee8.meeting.ietf.org>
MIME-Version: 1.0
Content-Type: text/plain
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/1zoc06naV0Oa2uM7JO8cEcISRos>
Cc: netmod@ietf.org
Subject: Re: [netmod] comments on revised-datastores-00
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: NETMOD WG list <netmod.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/netmod/>
List-Post: <mailto:netmod@ietf.org>
List-Help: <mailto:netmod-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 15 Nov 2016 00:48:46 -0000

Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> writes:

> On Mon, Nov 14, 2016 at 11:23:04AM +0900, Ladislav Lhotka wrote:
>> Hi,
>> 
>> I've read the revised-datastores-00 document, in general I like it, here
>> are my initial comments and questions:
>> 
>> 1. Even if <intended> is valid, it can still be in conflict with the
>>    actual content of <applied> that may come from e.g. dynamic
>>    configuration protocols. How are such cases supposed to be resolved?
>
> Yes. The whole idea is to expose these potential differences instead
> of hiding them behind a curtain.

That's fine but it doesn't answer my question.

>
>> 2. What is the distinction between dynamic configuration protocols and
>>    control-plane protocols?
>
> Good question. I believe this to be at the end implementation specific.
> The question I think really is whether a control-plane protocol interacts
> with the configuration management component or not.

OK, perhaps it can be said that dynamic configuration protocols modify
"config true" data. Maybe a term like "configuration interface" may be
better because it needn't be a communication protocol, and it needn't be
any more dynamic than NETCONF/RESTCONF is.

>
>> 3. Shared <candidate> has known problems. Maybe it's time to part with
>>    it in this new datastore model?
>
> This clearly was not the focus of this work.

Then I would suggest to remove it entirely as a protocol-specific thing.

>
>> 4. Templates are briefly mentioned in several places, it would be useful
>>    to explain this concept in more detail.
>
> I agree.
>
>> 5. Is it necessary that "<operational-state> datastore contains all
>>    configuration data actually used by the system"? For example, static
>>    routes should appear in RIBs, so having them separately in operational
>>    state seems redundant.
>
> I do not understand your question. Is the RIB exposed or not? Anyway,
> we need a general model and not a model for specific aspects such as
> routing. Yes, there can be redundancy but there can also be semantic
> differences. The <operational-state> datastore tells me what is
> actually used (regardless of what has happened with the statically
> configured values). In other words, if I want to debug what my box is
> actually doing, looking at the <operational-state> datastore is
> probably a good idea.

But could this part of operational state be possibly different from
what's already in <applied>?

Lada

>
> /js
>
> -- 
> Juergen Schoenwaelder           Jacobs University Bremen gGmbH
> Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
> Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>

-- 
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C