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

Martin Bjorklund <mbj@tail-f.com> Mon, 14 November 2016 21:10 UTC

Return-Path: <mbj@tail-f.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 8506A12948C for <netmod@ietfa.amsl.com>; Mon, 14 Nov 2016 13:10:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.398
X-Spam-Level:
X-Spam-Status: No, score=-3.398 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.497, SPF_PASS=-0.001] 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 nArQL3hSjq0F for <netmod@ietfa.amsl.com>; Mon, 14 Nov 2016 13:10:35 -0800 (PST)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id D272C12946B for <netmod@ietf.org>; Mon, 14 Nov 2016 13:10:34 -0800 (PST)
Received: from localhost (h-13-76.a165.priv.bahnhof.se [155.4.13.76]) by mail.tail-f.com (Postfix) with ESMTPSA id 7862D1AE049C; Mon, 14 Nov 2016 22:10:32 +0100 (CET)
Date: Mon, 14 Nov 2016 22:10:32 +0100
Message-Id: <20161114.221032.493268666299851173.mbj@tail-f.com>
To: shares@ndzh.com
From: Martin Bjorklund <mbj@tail-f.com>
In-Reply-To: <002801d23eae$de9bf4c0$9bd3de40$@ndzh.com>
References: <m2zil2er5j.fsf@dhcp-8ee8.meeting.ietf.org> <20161114094210.GA45946@elstar.local> <002801d23eae$de9bf4c0$9bd3de40$@ndzh.com>
X-Mailer: Mew version 6.5 on Emacs 24.3 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/8cZiNRnhk8QZ0oUTGTpjfBrjvDQ>
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 21:10:37 -0000

Hi,

"Susan Hares" <shares@ndzh.com> wrote:
> Juergen and Lada: 
> 
> #2 - is interesting to me.  Is dynamic configuration protocol = I2RS? Or
> control-plane protocols = I2RS? 

Details tbd, but this architecture allows for a new kind of datastore
("control-plane datastore") which could be defined for i2rs.

> On #5 - how do you merge I2RS RIB static routes  + routing-configuration rib
> routes?

That is not covered by this architecture.  It has to be defined in i2rs.

> Can you see the difference in the applied configuration? 

You can see the result in the applied configuration, and you can see
the statically configured routes in <intended> and the i2rs-defined
routes in the-new-i2rs-datastore.


/martin


> 
> 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
> 
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
>