Re: [netmod] questions about draft-rtgyangdt-rtgwg-device-model-00

Martin Bjorklund <> Wed, 26 August 2015 10:41 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 80C151B2A4F; Wed, 26 Aug 2015 03:41:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.911
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id UGh1Bbvk6IST; Wed, 26 Aug 2015 03:41:31 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 10CEC1B2A4A; Wed, 26 Aug 2015 03:41:31 -0700 (PDT)
Received: from localhost (unknown []) by (Postfix) with ESMTPSA id F2BE81AE049C; Wed, 26 Aug 2015 12:41:29 +0200 (CEST)
Date: Wed, 26 Aug 2015 12:41:29 +0200 (CEST)
Message-Id: <>
Subject: Re: [netmod] questions about draft-rtgyangdt-rtgwg-device-model-00
From: Martin Bjorklund <>
In-Reply-To: <>
References: <> <> <>
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: <>
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Routing Area Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 26 Aug 2015 10:41:32 -0000

Lou Berger <>; wrote:
> Martin,
> 	Sorry for the delayed response, was away for a bit.  Not sure if any of
> this is OBE as just starting to catch up on mail.
> On 08/20/2015 03:58 AM, Martin Bjorklund wrote:
> > Lou Berger <>; wrote:
> >> Martin,
> >>
> >> See below.
> >> On 08/19/2015 05:27 AM, Martin Bjorklund wrote:
> >>> Hi,
> >>>
> >>> Lou Berger <>; wrote:


> >> Deeper in the hierarchy the path becomes more significant, but you
> >> weren't really questioning this.
> > 
> > I am all for significant nodes in the path!  
> This is really good/useful to hear.  If disagreement is limited to the
> top level node, it's much easier (but not easy ;-) problem to solve.
> > My point is that /device
> > is insignificant.
> I think the fundamental discussion here, is who get's to say what's
> significant and we have (at least) two opposing views on this point.
> From my standpoint it comes down to how you view full set of models that
> may be seen.  From the device view, you might only (or, more likely,
> mostly) see models under /device -- so device doesn't add much value.
> BUT from the controller/NMS/EMS (or whatever you want to call it) view,
> you're likely to see all the models

Agreed, but see below.

> so /device plays a much more
> significant role in identifying logical model
> organization/understanding.  -- That said, I'm much more of a device
> person than an NMS builder, so I'm also willing to trust the opinion of
> folks who are clearly doing significant work on the controller/NMS
> side.

[This was briefly discussed in another mail thread, and I'll repeat it

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:


if we also have a top-level "/device" container we'd have:


(here you again can see that the "device" node in the device model
doesn't make much sense)

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 then you might also have a
controller-of-controllers. where the path might be:


Pushing all these concepts down into the device model clearly doesn't