Re: [netmod] questions about draft-rtgyangdt-rtgwg-device-model-00
Martin Bjorklund <mbj@tail-f.com> Thu, 20 August 2015 07:58 UTC
Return-Path: <mbj@tail-f.com>
X-Original-To: rtgwg@ietfa.amsl.com
Delivered-To: rtgwg@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C72881A1BBD; Thu, 20 Aug 2015 00:58:58 -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 2d7zIXuE8JhW; Thu, 20 Aug 2015 00:58:56 -0700 (PDT)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id AE69B1A1BB9; Thu, 20 Aug 2015 00:58:55 -0700 (PDT)
Received: from localhost (unknown [173.38.220.43]) by mail.tail-f.com (Postfix) with ESMTPSA id 90B441AE035B; Thu, 20 Aug 2015 09:58:53 +0200 (CEST)
Date: Thu, 20 Aug 2015 09:58:53 +0200
Message-Id: <20150820.095853.255503105278478154.mbj@tail-f.com>
To: lberger@labn.net
Subject: Re: [netmod] questions about draft-rtgyangdt-rtgwg-device-model-00
From: Martin Bjorklund <mbj@tail-f.com>
In-Reply-To: <55D53A13.4080505@labn.net>
References: <55D3DDFC.2080107@labn.net> <20150819.112730.1689479932571514728.mbj@tail-f.com> <55D53A13.4080505@labn.net>
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: <http://mailarchive.ietf.org/arch/msg/rtgwg/zAXSeAZlxDwg9Xz6ZhcbY1Z1w0A>
Cc: rtgwg@ietf.org, andy@yumaworks.com, netmod@ietf.org, draft-rtgyangdt-rtgwg-device-model@ietf.org
X-BeenThere: rtgwg@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Routing Area Working Group <rtgwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtgwg>, <mailto:rtgwg-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/rtgwg/>
List-Post: <mailto:rtgwg@ietf.org>
List-Help: <mailto:rtgwg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtgwg>, <mailto:rtgwg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 20 Aug 2015 07:58:59 -0000
Lou Berger <lberger@labn.net> wrote: > Martin, > > See below. > On 08/19/2015 05:27 AM, Martin Bjorklund wrote: > > Hi, > > > > Lou Berger <lberger@labn.net> 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" > > modules. > > > Or device additions can augment the base model. > > > 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. > > > > I think this is a good topic to discuss. The second sounds lighter > weight as long as it is followed while the first makes it hard to not > follow. I see advantages in both. > > > > >>> 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? > > > > I personally see the top level as more about logical separation of model > types/classes This then sounds like meta data about the model. What kind of model is it - see draft-bogdanovic-netmod-yang-model-classification. I don't think it is a good idea to encode meta data into the data hierarchy. It would be better IMO to keep this either inline in the module definition (yang-model-type device;) or externally in a separate registry. > like a top level directory structure. So IMO it's a bit > subjective and really about establish and agreeing upon conventions. -- > and there's a group of users who say they really like it one way. > > 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! My point is that /device is insignificant. > >>> What is the scope of this work? > >> see slide 7 of > >> https://www.ietf.org/proceedings/93/slides/slides-93-rtgwg-3.pdf > >> > >>> 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. > > A very fair point and why it's important to discuss in this WG. No > discussion happened in the prague session largely due to multiple > scheduling conflicts. > > > > >>> Q2) interfaces > >>> > >>> The interface model is taken from [RFC7223 <https://tools.ietf.org/html/rfc7223>] and includes possible > >>> technology-specific augmentations using example technologies defined > >>> in [RFC7277 <https://tools.ietf.org/html/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. > > And this is certainly an important point, and I personally think we > should have a full discussion of if it's worth preserving RFC 7223 or > open the door for changing it. We had many discussions on this in the > DT and while multiple wanted to do an even larger change, in the end the > consensus was to try minimize impact to the this and other RFCs -- even > if it meant using somewhat more cumbersome mechanisms. > > > > > 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? > > > > as mentioned above, I personally think this is about logical separation > of model types/classes, like a top level directory structure. So IMO > it's a bit subjective and really about establish and agreeing upon > conventions. -- and there's a group of users who say they really like it > one way. Hopefully, a decision to change all existing models (including vendor models!) will be based on something more technical than the fact that a group of people "really like it" some other way. > > 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. > > Why do you say only one top level node. This isn't my exception, nor do > I see this stated in the draft. I do think we say one top level node > dealing with device configuration. In light of what you explained, I can rephrase this: On any given implementation there will always only be one top-level node. For example, on a device, the top-node is always /device. Correct? > > Instead of having N > > top-level nodes, we would have N nodes under /device. Why is this > > better? > > N would contain only device configuration related modules. There could > be others, e.g., /services has been mentioned by some. > > > > >> 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 > >> https://www.ietf.org/proceedings/93/slides/slides-93-rtgwg-3.pptx) > >> > >> 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? > > The intent was multiple logical-network-elements and when > device-view=false, any management operation taking place in the context > of that LNE would only have visibility and ability to control that LNE. > This matches a pretty common feature set. Ok, so this means that there is still just one configuration for all logical-network-elements, right? E.g., if a user from logical-network-element A locks the datastore, he will lock out a user from logical-network-element B; if user from A saves running to startup changes for B will also be saved, etc? /martin > > > > > 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). > > I think this would be used too. For example user1 would have ro access > while user2 has rw. > > > You don't need this "device-view" in order to do this. > Agreed, but this is something different and matches how a multiple > devices from multiple vendors function today. > > > > > 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). > I think we're interested in a form of the first. > > Lou > > > > > > > > > /martin > > >
- Re: [netmod] questions about draft-rtgyangdt-rtgw… Lou Berger
- Re: [netmod] questions about draft-rtgyangdt-rtgw… Martin Bjorklund
- Re: [netmod] questions about draft-rtgyangdt-rtgw… Andy Bierman
- Re: [netmod] questions about draft-rtgyangdt-rtgw… Nadeau Thomas
- Re: [netmod] questions about draft-rtgyangdt-rtgw… Nadeau Thomas
- Re: [netmod] questions about draft-rtgyangdt-rtgw… Juergen Schoenwaelder
- Re: [netmod] questions about draft-rtgyangdt-rtgw… Andy Bierman
- Re: [netmod] questions about draft-rtgyangdt-rtgw… Lou Berger
- Re: [netmod] questions about draft-rtgyangdt-rtgw… Lou Berger
- Re: [netmod] questions about draft-rtgyangdt-rtgw… Lou Berger
- Re: [netmod] questions about draft-rtgyangdt-rtgw… Martin Bjorklund
- Re: [netmod] questions about draft-rtgyangdt-rtgw… Nadeau Thomas
- Re: [netmod] questions about draft-rtgyangdt-rtgw… Lou Berger
- Re: [netmod] questions about draft-rtgyangdt-rtgw… Acee Lindem (acee)
- Re: [netmod] questions about draft-rtgyangdt-rtgw… Lou Berger
- Re: [netmod] questions about draft-rtgyangdt-rtgw… Martin Bjorklund
- Re: [netmod] questions about draft-rtgyangdt-rtgw… Martin Bjorklund
- Re: [netmod] questions about draft-rtgyangdt-rtgw… Lou Berger
- Re: [netmod] questions about draft-rtgyangdt-rtgw… Nadeau Thomas
- Re: [netmod] questions about draft-rtgyangdt-rtgw… Nadeau Thomas
- Re: [netmod] questions about draft-rtgyangdt-rtgw… Martin Bjorklund
- Re: [netmod] questions about draft-rtgyangdt-rtgw… Martin Bjorklund
- Re: [netmod] questions about draft-rtgyangdt-rtgw… Acee Lindem (acee)
- Re: [netmod] questions about draft-rtgyangdt-rtgw… Nadeau Thomas
- Re: [netmod] questions about draft-rtgyangdt-rtgw… Nadeau Thomas
- Re: [netmod] questions about draft-rtgyangdt-rtgw… Andy Bierman
- Re: [netmod] questions about draft-rtgyangdt-rtgw… Nadeau Thomas
- Re: [netmod] questions about draft-rtgyangdt-rtgw… Andy Bierman
- Re: [netmod] questions about draft-rtgyangdt-rtgw… Nadeau Thomas
- Re: [netmod] questions about draft-rtgyangdt-rtgw… Juergen Schoenwaelder
- Re: [netmod] questions about draft-rtgyangdt-rtgw… Juergen Schoenwaelder
- Re: [netmod] questions about draft-rtgyangdt-rtgw… Kent Watsen
- Re: [netmod] questions about draft-rtgyangdt-rtgw… Lou Berger
- Re: [netmod] questions about draft-rtgyangdt-rtgw… Lou Berger
- Re: [netmod] questions about draft-rtgyangdt-rtgw… Andy Bierman
- Re: [netmod] questions about draft-rtgyangdt-rtgw… Lou Berger