Re: [i2rs] Kathleen Moriarty's No Objection on draft-ietf-i2rs-yang-l3-topology-08: (with COMMENT)

Martin Bjorklund <mbj@tail-f.com> Mon, 23 January 2017 22:25 UTC

Return-Path: <mbj@tail-f.com>
X-Original-To: i2rs@ietfa.amsl.com
Delivered-To: i2rs@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B1C6B12996C; Mon, 23 Jan 2017 14:25:58 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.1
X-Spam-Level:
X-Spam-Status: No, score=-5.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-3.199, 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 m2v_PkkGmQ6b; Mon, 23 Jan 2017 14:25:57 -0800 (PST)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id E54B8126B6D; Mon, 23 Jan 2017 14:25:56 -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 DE8071AE02EF; Mon, 23 Jan 2017 23:25:55 +0100 (CET)
Date: Mon, 23 Jan 2017 23:25:55 +0100
Message-Id: <20170123.232555.71314888595817367.mbj@tail-f.com>
To: shares@ndzh.com
From: Martin Bjorklund <mbj@tail-f.com>
In-Reply-To: <019c01d275c4$edf51f30$c9df5d90$@ndzh.com>
References: <20170123.212621.119545616051737472.mbj@tail-f.com> <afdfb4d3-0901-2ee0-8d87-f8f1aeeff37e@hq.sk> <019c01d275c4$edf51f30$c9df5d90$@ndzh.com>
X-Mailer: Mew version 6.7 on Emacs 24.5 / 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/i2rs/VA_kfEMqXN8ucqki4He9GM4Aq-8>
Cc: i2rs@ietf.org, draft-ietf-i2rs-yang-l3-topology@ietf.org, j.schoenwaelder@jacobs-university.de, i2rs-chairs@ietf.org, nite@hq.sk, Kathleen.Moriarty.ietf@gmail.com, iesg@ietf.org
Subject: Re: [i2rs] Kathleen Moriarty's No Objection on draft-ietf-i2rs-yang-l3-topology-08: (with COMMENT)
X-BeenThere: i2rs@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "Interface to The Internet Routing System \(IRS\)" <i2rs.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/i2rs>, <mailto:i2rs-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/i2rs/>
List-Post: <mailto:i2rs@ietf.org>
List-Help: <mailto:i2rs-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/i2rs>, <mailto:i2rs-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 23 Jan 2017 22:25:59 -0000

"Susan Hares" <shares@ndzh.com> wrote:
> Robert and Martin: 
> 
> I agree with Robert that the current implementations of the ODL topology
> models are handled as part of the configuration data store with ephemeral
> state.   I will point out that these implementation are pre-standards
> implementations of the I2RS YANG Data model.  
> 
> While standardizing the topology data models, the I2RS WG have been asked to
> align with the draft-ietf-netmod-revised-datastores-00.txt NETMOD WG
> document.  This NETMOD WG document moves the I2RS ephemeral data store from
> configuration data store to a Control Plane data store.   If we follow this
> draft, the I2RS Topology models are part of the I2RS ephemeral data store.
> If you disagree with the placement of the Topology data models, please
> indicate this to the NETMOD WG and to Benoit.  Could you propose a way that
> you would see the ephemeral state working with the configuration data store
> to the NETMOD WG?   
> 
> Quite frankly, I feel a bit of whip-lash on this topic.   NETMOD WG asks for
> Control Plane Data store.  You ask for configuration data store (which was
> the I2RS initial proposal).

Not really; I ask for clarification.

> It is possible for either one to work for I2RS
> Topology models - if the right details are taken care of.   How do we make
> progress on choosing one method so we can write the I2RS Topology Models
> security considerations.? 

One problem is that relying on the solution in
draft-ietf-netmod-revised-datastores-00 is a bit premature - in fact,
that document does not yet provide any details at all on the I2RS
ephemeral datastore.

So I see two alternatives.  Either wait with these documents, or
publish them with their datamodels as is (i.e., no new additional
notes), for the existing protocols and architecure.  This would allow
them to be implemented just like any other YANG data model.  This
would mean that the normal YANG security considerations guidelines
should be followed.



/martin

> 
> Sue 
>   
> -----Original Message-----
> From: Robert Varga [mailto:nite@hq.sk] 
> Sent: Monday, January 23, 2017 4:11 PM
> To: Martin Bjorklund; shares@ndzh.com
> Cc: i2rs@ietf.org; draft-ietf-i2rs-yang-l3-topology@ietf.org;
> j.schoenwaelder@jacobs-university.de; i2rs-chairs@ietf.org;
> Kathleen.Moriarty.ietf@gmail.com; iesg@ietf.org
> Subject: Re: [i2rs] Kathleen Moriarty's No Objection on
> draft-ietf-i2rs-yang-l3-topology-08: (with COMMENT)
> 
> On 01/23/2017 09:26 PM, Martin Bjorklund wrote:
> >> I'm pulling your questions to the top of this email. 
> >>
> >>  
> >>
> >> Question 1: Ok.  Just to make sure I understand this correctly - 
> >> these topology models are intended to be I2RS-specific, and they 
> >> cannot be used for any other purpose.  If anyone needs a general 
> >> topology model outside of the I2RS protocol, they will have to design 
> >> their own model.  Is this correct?
> >>
> >>  
> >>
> >> Response 1:  Not really.  
> > Ok, so are you saying that the models are in fact generic, and can be 
> > used outside of I2RS?  I.e., they *can* be used with the normal 
> > configuration datastores?
> > 
> 
> From implementation experience, yes, they can be used for storing
> configuration. OpenDaylight uses (an ancient predecessor of)
> yang-network-topo to store configure details about devices in its managed
> networks.
> 
> Regards,
> Robert
> 
>