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

Anton Ivanov <anton.ivanov@kot-begemot.co.uk> Wed, 25 January 2017 09:37 UTC

Return-Path: <anton.ivanov@kot-begemot.co.uk>
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 333F812984C; Wed, 25 Jan 2017 01:37:03 -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, HTML_MESSAGE=0.001, 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 zOUVKEBh1Lml; Wed, 25 Jan 2017 01:37:00 -0800 (PST)
Received: from www.kot-begemot.co.uk (ivanoab5.miniserver.com [78.31.111.25]) (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 2B06112988D; Wed, 25 Jan 2017 01:36:59 -0800 (PST)
Received: from tun5.smaug.kot-begemot.co.uk ([192.168.18.6] helo=smaug.kot-begemot.co.uk) by www.kot-begemot.co.uk with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from <anton.ivanov@kot-begemot.co.uk>) id 1cWK0f-0003wo-J5; Wed, 25 Jan 2017 09:36:57 +0000
Received: from monstrousnightmare.kot-begemot.co.uk ([192.168.11.207]) by smaug.kot-begemot.co.uk with esmtp (Exim 4.84_2) (envelope-from <anton.ivanov@kot-begemot.co.uk>) id 1cWK0f-00034r-Bc; Wed, 25 Jan 2017 09:36:57 +0000
To: Giles Heron <giles.heron@gmail.com>, Benoit Claise <bclaise@cisco.com>
References: <000701d27594$28d12350$7a7369f0$@ndzh.com> <20170123.194721.1193117831378217486.mbj@tail-f.com> <010a01d275b0$183d7360$48b85a20$@ndzh.com> <20170123.212621.119545616051737472.mbj@tail-f.com> <afdfb4d3-0901-2ee0-8d87-f8f1aeeff37e@hq.sk> <019c01d275c4$edf51f30$c9df5d90$@ndzh.com> <20170123221458.GA34192@elstar.local> <029301d27636$f2514690$d6f3d3b0$@ndzh.com> <20170124115221.GD35835@elstar.local> <87f80f69-5a3c-18a0-8f4f-e560572417e8@kot-begemot.co.uk> <008d01d2766a$5387def0$fa979cd0$@ndzh.com> <7A14208D-2046-4421-AD8A-B8D3CED74D36@lucidvision.com> <6a06779b-fa72-c6c9-f9ea-99dc5e32e3a7@cisco.com> <1FD0813A-D31B-4BCE-BEBB-54D302F61DA6@gmail.com>
From: Anton Ivanov <anton.ivanov@kot-begemot.co.uk>
Message-ID: <4284518e-9d8c-a6b0-db05-d23b4d261793@kot-begemot.co.uk>
Date: Wed, 25 Jan 2017 09:36:56 +0000
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Icedove/45.5.1
MIME-Version: 1.0
In-Reply-To: <1FD0813A-D31B-4BCE-BEBB-54D302F61DA6@gmail.com>
Content-Type: multipart/alternative; boundary="------------C09A32E6B3D34E09F939AEA7"
X-Clacks-Overhead: GNU Terry Pratchett
Archived-At: <https://mailarchive.ietf.org/arch/msg/i2rs/efFZ2fYvLg4P-rwsM7m3YmwpJg8>
Cc: Thomas Nadeau <tnadeau@lucidvision.com>, IESG IESG <iesg@ietf.org>, i2rs@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: Wed, 25 Jan 2017 09:37:03 -0000

On 25/01/17 09:30, Giles Heron wrote:
> Hi Benoit
>
> agreed - the model should be independent of the protocol used to 
> access it.
>
> As mentioned earlier on the thread, OpenDaylight has implemented older 
> versions of the model.  Over time I’d expect each service in 
> OpenDaylight that uses the models to upgrade to the upcoming RFC.  In 
> general OpenDaylight implements the models as read-only (i.e. in its 
> operational data-store), though as Robert Varga has noted there’s a 
> case where we use the config data-store for device inventory (longer 
> term that will move to the ietf-network model but not 
> ietf-network-topology - though there might be use cases where you’d 
> have read-write access to ietf-network-topology, e.g when using it to 
> express intent.)
>
> OpenDaylight enables access to topology data using NETCONF and 
> RESTCONF as the north-bound protocoIs are independent of the models 
> accessed.  I believe there has also been some work on using AMQP as a 
> north-bound protocol, and that the Kafka plug-in could be used to send 
> data change notifications for the operational models (so you’d get a 
> message when a link went up or down etc.)   South-bound we have also 
> used ODL to read topology data from a device using NETCONF/YANG (IIRC 
> we showed a demo of this using Homenet running on OpenWrt at IETF a 
> couple of years back).
>
> I’m also working with other groups such as MEF and OpenROADM to 
> leverage the I2RS topology models for their YANG efforts.    So 
> clearly the models need to be used in a non-I2RS environment.

+1.

I am working on JSON RPC ODL southbound into non-ODL systems. For some 
of the use cases you may need to build topologies out of the information 
you receive from it.

So from my extremely selfish implementer perspective having topology 
models which is stapled to a particular protocol and are not allowed to 
be used in a more generic way, namely in a non-I2RS environment, is a 
definitive NO GO.

A.

>
> Giles
>
>> On 24 Jan 2017, at 22:04, Benoit Claise <bclaise@cisco.com 
>> <mailto:bclaise@cisco.com>> wrote:
>>
>> Dear all,
>>
>> The thread that grows faster than you can read...
>>
>> Let me repeat what I mentioned already on the I2RS mailing list:
>>
>>     This document contains a YANG model, a generic YANG model that could be accessed by NETCONF, RESTCONF, or the future I2RS protocol.
>>     This document doesn't say (and that would be a mistake IMO if it would) that this YANG model can only be accessed by the I2RS protocol.
>>     Hence I'm advocating that the security considerations diligently followhttps://trac.ietf.org/trac/ops/wiki/yang-security-guidelines, and that they don't go in the I2RS protocol specific details.
>>
>> This comment was made for draft-ietf-i2rs-yang-network-topo, but is 
>> equally applicable to this draft-ietf-i2rs-yang-l3-topology draft.
>> I still maintain this point of view: it would be a mistake to limit a 
>> data model usage to a particular protocol. These topology documents 
>> are not I2RS YANG models, these are YANG models, which can be used in 
>> different contexts. I'm very concerned if we start having per-WG or 
>> per context data models in the IETF.
>> Btw, I haven't seen a RFC specifying what the I2RS protocol is, only 
>> the requirements.
>> We can't modify the current generic YANG security considerations for 
>> an I2RS control plane and a new datastore that are not yet specified. 
>> If you want to describe how I2RS will be using those topology YANG 
>> models (and any YANG models btw), then it's suitable to include this 
>> part of the I2RS protocol spec or part of an I2RS applicability 
>> statement. This is typically where you would describe some protocol 
>> specific information such as "write contention for two clients 
>> writing a node using I2RS priority (linked to I2RS User-ID)".
>>
>> Let me make my point differently. Let's assume for a moment that I2RS 
>> needs to use the IETF interface YANG model, does it mean that you 
>> will require RFC 7223bis with an updated security considerations? 
>> This can't be.
>>
>> I still think the generic YANG security guidelines is suitable, as it 
>> relates to IETF specified protocols NETCONF and RESTCONF. Addition of 
>> some generic information about the data model (not I2RS protocol) 
>> might be useful though. For example, text around "there is a risk 
>> that a write to a topology may create a looping topology or overload 
>> a particular node". Note that I don't think the the security 
>> considerations is the best section for this though.
>>
>> Regards, Benoit
>>> 	Sue:
>>>
>>> 	The implication of that statement is that actual implementations (like ODL etc) now
>>> need to copy/paste this model without the I2RS text to use them in other ways. This seems
>>> strange and just about the most inefficient way to use these that I can think of.
>>>
>>> 	—Tom
>>>
>>>
>>>
>>>> On Jan 24, 2017:12:50 PM, at 12:50 PM, Susan Hares<shares@ndzh.com>  wrote:
>>>>
>>>> Anton:
>>>>
>>>> See earlier message to Martin.  Topology models are I2RS YANG Models
>>>> designed for ephemeral state with specific security concerns.  This is not
>>>> your basic YANG model no matter which data store ephemeral gets linked to.
>>>> Where is ephemeral state?  By IESG Design of charter, I2RS is not in charge
>>>> of defining ephemeral state solution.  NETMOD/NETCONF are.  Go ask them.
>>>>
>>>> Do not blame the messenger echoing NETMOD results,
>>>>
>>>> Sue
>>>>
>>>> -----Original Message-----
>>>> From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Anton Ivanov
>>>> Sent: Tuesday, January 24, 2017 8:30 AM
>>>> To:i2rs@ietf.org
>>>> Subject: Re: [i2rs] Kathleen Moriarty's No Objection on
>>>> draft-ietf-i2rs-yang-l3-topology-08: (with COMMENT)
>>>>
>>>> On 24/01/17 11:52, Juergen Schoenwaelder wrote:
>>>>> Susan,
>>>>>
>>>>> so are these YANG models regular YANG models or are these YANG models
>>>>> specific to the yet to be defined I2RS protocol and yet to be defined
>>>>> datastores?
>>>>>
>>>>> I think this is the core of Martin's and my question. A simple clear
>>>>> and concise answer would be nice.
>>>> +1.
>>>>
>>>> A.
>>>>
>>>>
>>>> _______________________________________________
>>>> i2rs mailing list
>>>> i2rs@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/i2rs
>>>>
>>>> _______________________________________________
>>>> i2rs mailing list
>>>> i2rs@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/i2rs
>>> _______________________________________________
>>> i2rs mailing list
>>> i2rs@ietf.org
>>> https://www.ietf.org/mailman/listinfo/i2rs
>>
>> _______________________________________________
>> i2rs mailing list
>> i2rs@ietf.org <mailto:i2rs@ietf.org>
>> https://www.ietf.org/mailman/listinfo/i2rs
>