Re: [netmod] Y34 - root node

Ladislav Lhotka <lhotka@nic.cz> Wed, 19 August 2015 12:55 UTC

Return-Path: <lhotka@nic.cz>
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4817B1A8A56 for <netmod@ietfa.amsl.com>; Wed, 19 Aug 2015 05:55:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.361
X-Spam-Level:
X-Spam-Status: No, score=-0.361 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, MIME_8BIT_HEADER=0.3, T_RP_MATCHES_RCVD=-0.01] autolearn=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 jehkHfQ75hGF for <netmod@ietfa.amsl.com>; Wed, 19 Aug 2015 05:55:54 -0700 (PDT)
Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D645D1A8AFC for <netmod@ietf.org>; Wed, 19 Aug 2015 05:55:53 -0700 (PDT)
Received: from birdie.labs.nic.cz (unknown [195.113.220.110]) by mail.nic.cz (Postfix) with ESMTPSA id 72F9018134A; Wed, 19 Aug 2015 14:55:52 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1439988952; bh=zYOLXgn5haXHjSMvqkWBQCQ6j3+2dtP2gE7CiCjbOnM=; h=From:Date:To; b=FJTcI75JOzFOmyTUTPC6zRC77qhdFKrOw9Mx8AjYGYPTcp9800/HnPIrVfpLDp8Td B+JPiSdsgLgOn+o21y2NMjO2CvFeU7EY5AYakCl7+cFblxnAys6Auf/y6qud0ul6m0 syrAI8qKKqO40MdeDIpjtVl7zMGlVx3f5IojJ7GY=
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2102\))
From: Ladislav Lhotka <lhotka@nic.cz>
In-Reply-To: <20150819.132555.871710491924929960.mbj@tail-f.com>
Date: Wed, 19 Aug 2015 14:55:52 +0200
Content-Transfer-Encoding: 7bit
Message-Id: <500BB0F6-69CF-4A14-A649-83E4BC03E920@nic.cz>
References: <55D36473.90609@cisco.com> <CABCOCHRP3omx37XmEJfPwg6eELuSKF=YL8pgpnvLh9PQxgV62A@mail.gmail.com> <55D45CAF.2070605@cisco.com> <20150819.132555.871710491924929960.mbj@tail-f.com>
To: Martin Björklund <mbj@tail-f.com>
X-Mailer: Apple Mail (2.2102)
X-Virus-Scanned: clamav-milter 0.98.7 at mail
X-Virus-Status: Clean
Archived-At: <http://mailarchive.ietf.org/arch/msg/netmod/GtTeSOB8c8RjxaEKNaZR00olnQQ>
Cc: netmod@ietf.org
Subject: Re: [netmod] Y34 - root node
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
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: Wed, 19 Aug 2015 12:55:56 -0000

> On 19 Aug 2015, at 13:25, Martin Bjorklund <mbj@tail-f.com> wrote:
> 
> Robert Wilton <rwilton@cisco.com> wrote:
>> 
>> 
>> On 18/08/2015 18:22, Andy Bierman wrote:
>>> This is how languages like SMIv2 and YANG work.
>>> A conceptual object is given a permanent "home" within the tree of
>>> object identifiers.
>>> Moving data is very expensive, since any clients working with the old
>>> data
>>> will break as soon as the data is moved.
>>> 
>>> I am not convinced the IETF can or should come up with a set of
>>> containers
>>> that covers every possible topic that can be modeled in YANG.
>> 
>> I mostly agree, but having some more structure/advice as to where to
>> place YANG modules may be helpful.  I'm thinking more along the lines
>> of broad categories rather than precise locations.
> 
> +1
> 
>>>    If someone wants to builds a YANG controller node that is managing
>>>    the configuration for a network of devices then wouldn't they want
>>>    a particular device's interface configuration to be located
>>>    somewhere like /network/device/<device-name>/interfaces/interface?
>>>    Ideally, they would be able to use the same YANG definitions that
>>>    are defined for /interfaces/ but root them relative to
>>>    /network/device/<device-name>/.
>>> 
>>> 
>>> 
>>> Yes -- some of us (like Martin) have pointed this out many times.
>>> The "device" container on an NE does not help at all wrt/
>>> aggregation on a controller. "/device" or "/" work the same for this
>>> purpose.
> 
> Actually, I would argue that / works better.  On the controller, you
> probably have a list of devices you control (this is how our NCS
> works, and how ODL works (I have been told)):
> 
>  container devices {
>    list device {
>      key name;
>      // meta-info about the device goes here, things like
>      // ip-address, port, auth info...
>      container data {
>        // all models supported by the devices are "mounted" here
>      }
>    }
>  }
> 
> So on the controller, the path to interface "eth0" on device "foo"
> would be:
> 
>  /devices/device[name='foo']/data/interfaces/interface[name='eth0']
> 
> if we also have a top-level "/device" container we'd have:
> 
>  /devices/device[name='foo']/data/device/interfaces/interface[name='eth0']
> 
>> What would the real resource location for
>> "/network/device/<device-name>/interfaces/interface" be?
> 
> I don't think there is such a thing as a "real" location.  The path is
> scoped in the system you work with; in the controller it might be as I
> illustrated above, in the device it starts with /interfaces, but in a
> controller-of-controllers it might be:
> 
>  /domains/domain[name='bar']/devices/device[name='foo']/data
>    /interfaces/interface[name='eth0']
> 
> Currently we have a proprietary way of "relocating" YANG modules, and
> ODL has its "mount", and I think Andy has some other mechanism.  Maybe
> the time has come to standardize how mount works, and maybe then also
> standardize the list of devices in a controller model.

+1

Lada

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

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