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

Martin Bjorklund <> Wed, 19 August 2015 09:27 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 66C401AD379; Wed, 19 Aug 2015 02:27:35 -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 KESuQejgrdgm; Wed, 19 Aug 2015 02:27:33 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 01F881AD370; Wed, 19 Aug 2015 02:27:32 -0700 (PDT)
Received: from localhost (unknown []) by (Postfix) with ESMTPSA id A85431AE0486; Wed, 19 Aug 2015 11:27:30 +0200 (CEST)
Date: Wed, 19 Aug 2015 11:27:30 +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=utf-8
Content-Transfer-Encoding: base64
Archived-At: <>
X-Mailman-Approved-At: Wed, 19 Aug 2015 03:41:38 -0700
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, 19 Aug 2015 09:27:35 -0000


Lou Berger <>; wrote:
> On 8/18/2015 8:01 PM, Andy Bierman wrote:
> > Q1) scope
> >
> >
> > sec 2:
> >
> >    The model organization can itself be thought of as a "meta-model",
> >    in that it describes the relationships between individual models.  We
> >    choose to represent it also as simple YANG model consisting of lists
> >    and containers to serve as anchor points for the corresponding
> >    individual models.
> >
> >    As shown below, our model is rooted at a "device", which represents a
> >    network router, switch, or similar network element.  
> >
> >
> > Why is this a meta-model?
> because the aim to to show how other models inter-relate rather than
> define the details of all models. As stated in the intro:
>    This document aims to provide an extensible structure that can be
>    used to tie together other models. It allows for existing, emerging,
>    and future models. The overall structure can be constructed using
>    YANG augmentation and imports.
> > It looks like a real YANG data model where ad-hoc classification is
> > being done
> > using container names.
> Sure, we're using YANG, or at least trying, to document our proposal. 
> Do you think there's a better way to formally document the work?

I can see two approaches:

  1) Define a YANG module with the structural hierarchy.  Then
     other modules augment this module at the correct place in the
     hierarchy.  This module will probably be updated pretty often,
     especially if the idea to have ONE module with the complete
     hierarchy for ALL types of devices.

     A variant is to define such a module for routing-specific modules
     only to augment.  Other areas can define similar "structural"

  2) Document the hierarchy as a guideline.  When it is time to work
     on a new module, lets say mpls, we look into this guideline and
     define the necessary hierarchy in the mpls module.

> > If vendors augment this tree with their own ad-hoc hierarchy, then how
> > is this
> > any better than what we have now?
> >
> This goes to requirements which is really in the scope of
> draft-openconfig-netmod-model-structure.  From my perspective it comes
> down to how much information is needed from an actual device in order to
> come up with its yang-based configuration, and the principle that there
> is benefit in this being minimized.  For example, consider the case
> where a config is generated before a specific device is fielded or
> perhaps even purchased/selected.

As long as the device implements standard data models, why does it
matter for pre-provisioning if the standard path to configure an
interface is /devices/interfaces/interface or /interfaces/interface?

> > What is the scope of this work?
> see slide 7 of
> > It appears to be only for "routers switches or similar network elements".
> >
> >From the slide:
>    From DT charter: An overall architecture for
>    “the protocols and functionality contained inside the Routing Area”

But the design you propose has huge impact on all models, also models
from other areas.

> > Q2) interfaces
> >
> >    The interface model is taken from [RFC7223 <>] and includes possible
> >    technology-specific augmentations using example technologies defined
> >    in [RFC7277 <>].
> >   +--rw interfaces
> >       |  +--rw interface* [name]
> >       |     +--rw name                       string
> >       |     +--rw bind-network-element-id?   uint8
> >       |     +--rw ethernet
> >       |     |  +--rw bind-networking-instance-name?   string
> >       |     |  +--rw aggregates
> >       |     |  +--rw rstp
> >       |     |  +--rw lldp
> >       |     |  +--rw ptp
> >       |     +--rw vlans
> >       |     +--rw tunnels
> >       |     +--rw ipv4
> >       |     |  +--rw bind-networking-instance-name?   string
> >       |     |  +--rw arp
> >       |     |  +--rw icmp
> >       |     |  +--rw vrrp
> >       |     |  +--rw dhcp-client
> >       |     +--rw ipv6
> >       |        +--rw bind-networking-instance-name?   string
> >       |        +--rw vrrp
> >       |        +--rw icmpv6
> >       |        +--rw nd
> >       |        +--rw dhcpv6-client
> >
> >
> > Actually the interface model is quite different than the one in RFC 7223.
> > Seems rather ethernet-centric.  I notice the "type" leaf was removed,
> > along with everything else.  Is the plan to toss out RFC 7223,
> > recharter the interfaces work, and start over?
> >
> So this may be our/my inexperience at play here.  I didn't think it
> appropriate for a document that is augmenting an existing model to
> redefine the current model - I actually thought this was part of the
> power of YANG augmentation.  Are you saying we should have included the
> whole 7223 model to augment it, or something different?

As long as you want to have /device/interfaces, you need to obsolete
the model in RFC 7223 (and all other published YANG models) and
rewrite them.  However, if we get rid of the /device container, the
existing model in RFC 7223 fit in nicely in your hierarchy.

I think many of us have said this before, but the top-level container
/device doesn't really solve any problem.  Suppose we have a module
today with a top-level node /FOO.  Why would this module work better
if it augemented /device to give /device/FOO?

Maybe the problem you are trying to solve with "/device" is what is
written in section 3.1:

   One of the challenges in assembling existing YANG models is that they
   are generally written with the assumption that each model is at the
   root of the configuration or state tree.  Combining models then
   results in a multi-rooted tree that does not follow any logical
   construction and makes it difficult to work with operationally.  In
   some cases, models explicitly reference other models (e.g., via
   augmentation) to define a relationship, but this is the case for only
   a few existing models.

First of all I don't really agree with this.  We just have a few
module published, but for example ietf-ip augments ietf-interfaces,
and the idea with ietf-routing is that routing-specific modules
augment it.  In fact, I think the published modules follow your
proposed hierarchy (with some exception) - if it wasn't for the
/device node.

Second, if we want to be conservative with top-level nodes (I am not
convinced that this is a problem) we can solve that without going into
the extreme of having *one* top-level node.  Instead of having N
top-level nodes, we would have N nodes under /device.  Why is this

> Are you referring to section 2.3?  If so, I think we all agree (and said
> as much in Prague) that this section could be clearer.  We/I tried to
> explain it in the Prague slide 25 (for this you may want to see the
> animation in
> Basically the amount of information provided depends on the
> logical-network-element context used to access this information.  So if
> a model is "retrieved" via an IP address associated with a
> network-element-id  with device-view=true (e.g., the left side of slide
> 25), then the device's full view is provided.  And when a model is
> "retrieved" via an IP address associated with a network-element-id  with
> device-view=false (e.g., the ride side of slide 25, either color) only
> information related to the network-element-id is provided.

Do you want the user from a particular IP address to have access to
just his part of the tree, or do you want that user to have his own
"sandbox" that he can control independently of other users?

In the first case, you can use NACM to set up rules to give each user
proper access (based on user identity rather than IP address though).
You don't need this "device-view" in order to do this.

In the latter case, I don't think the proposed design works.  (I can
go into details if it turns out that this what you had in mind).