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

"Susan Hares" <shares@ndzh.com> Mon, 14 November 2016 19:42 UTC

Return-Path: <shares@ndzh.com>
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 55AAB1299B8 for <netmod@ietfa.amsl.com>; Mon, 14 Nov 2016 11:42:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.945
X-Spam-Level:
X-Spam-Status: No, score=0.945 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845] autolearn=no 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 bkrM_eQ51kzs for <netmod@ietfa.amsl.com>; Mon, 14 Nov 2016 11:42:19 -0800 (PST)
Received: from hickoryhill-consulting.com (50-245-122-97-static.hfc.comcastbusiness.net [50.245.122.97]) (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 D371F1299B5 for <netmod@ietf.org>; Mon, 14 Nov 2016 11:42:18 -0800 (PST)
X-Default-Received-SPF: pass (skip=forwardok (res=PASS)) x-ip-name=31.133.152.135;
From: Susan Hares <shares@ndzh.com>
To: 'Juergen Schoenwaelder' <j.schoenwaelder@jacobs-university.de>, 'Ladislav Lhotka' <lhotka@nic.cz>
References: <m2zil2er5j.fsf@dhcp-8ee8.meeting.ietf.org> <20161114094210.GA45946@elstar.local>
In-Reply-To: <20161114094210.GA45946@elstar.local>
Date: Mon, 14 Nov 2016 14:39:50 -0500
Message-ID: <002801d23eae$de9bf4c0$9bd3de40$@ndzh.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQG5SlJiH2goOqf2sBknsgrAC9C9KQIa+yWLoPnvtbA=
Content-Language: en-us
X-Authenticated-User: skh@ndzh.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/5-kBENL3pJrDiznCrL40PR1kRy8>
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: Mon, 14 Nov 2016 19:42:20 -0000

Juergen and Lada: 

#2 - is interesting to me.  Is dynamic configuration protocol = I2RS? Or
control-plane protocols = I2RS? 
On #5 - how do you merge I2RS RIB static routes  + routing-configuration rib
routes?  Can you see the difference in the applied configuration? 

Thanks, 

Sue 

-----Original Message-----
From: netmod [mailto:netmod-bounces@ietf.org] On Behalf Of Juergen
Schoenwaelder
Sent: Monday, November 14, 2016 4:42 AM
To: Ladislav Lhotka
Cc: netmod@ietf.org
Subject: Re: [netmod] comments on revised-datastores-00

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.

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

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

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

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

_______________________________________________
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod