Re: [netmod] Y34 - root node

Martin Bjorklund <mbj@tail-f.com> Wed, 19 August 2015 11:25 UTC

Return-Path: <mbj@tail-f.com>
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 8B4181B2A56 for <netmod@ietfa.amsl.com>; Wed, 19 Aug 2015 04:25:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.911
X-Spam-Level:
X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
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 l6omvzNwRRgk for <netmod@ietfa.amsl.com>; Wed, 19 Aug 2015 04:25:58 -0700 (PDT)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id E927D1B2A49 for <netmod@ietf.org>; Wed, 19 Aug 2015 04:25:57 -0700 (PDT)
Received: from localhost (unknown [173.38.220.43]) by mail.tail-f.com (Postfix) with ESMTPSA id E1ED31AE0486; Wed, 19 Aug 2015 13:25:55 +0200 (CEST)
Date: Wed, 19 Aug 2015 13:25:55 +0200
Message-Id: <20150819.132555.871710491924929960.mbj@tail-f.com>
To: rwilton@cisco.com
From: Martin Bjorklund <mbj@tail-f.com>
In-Reply-To: <55D45CAF.2070605@cisco.com>
References: <55D36473.90609@cisco.com> <CABCOCHRP3omx37XmEJfPwg6eELuSKF=YL8pgpnvLh9PQxgV62A@mail.gmail.com> <55D45CAF.2070605@cisco.com>
X-Mailer: Mew version 6.5 on Emacs 23.4 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/netmod/j9fMW0P21WIzbFTPJ3RZiaYY9Z0>
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 11:25:59 -0000

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.


/martin