Re: [netmod] questions about draft-rtgyangdt-rtgwg-device-model-00
Nadeau Thomas <tnadeau@lucidvision.com> Thu, 20 August 2015 12:34 UTC
Return-Path: <tnadeau@lucidvision.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 0A0D01ACDEF; Thu, 20 Aug 2015 05:34:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.012
X-Spam-Level:
X-Spam-Status: No, score=-2.012 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_PASS=-0.001, 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 H_ylaBrRYKUc; Thu, 20 Aug 2015 05:34:32 -0700 (PDT)
Received: from lucidvision.com (lucidvision.com [64.71.170.115]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 88E211ACDEE; Thu, 20 Aug 2015 05:34:32 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lucidvision.com; s=default; t=1440074013; bh=6YfQkE62hCHhIimRiuOYsR4JMtEllmgMIPUE52p52qM=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=alAdYcRYvm4pquWvZ2JutZ44Ijsl86f8eeFuTtf+jPTS8Ub+tuL4ufTREFd0KLy54 cVk8Is1MFgcO2cXqgQmlAjq/Fn+C+swWwoJMQ/XwPG97a6sW9v/HYckWC+ZDMZGbow Sx8fK+PznrLebYGQeZ5sDVjMNP3YEoCRnEnTDPYY=
X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=50.255.148.181;
Content-Type: text/plain; charset="windows-1252"
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\))
Subject: Re: [netmod] questions about draft-rtgyangdt-rtgwg-device-model-00
From: Nadeau Thomas <tnadeau@lucidvision.com>
In-Reply-To: <55D53BEF.2060009@labn.net>
Date: Thu, 20 Aug 2015 08:34:30 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <053F2D30-8DC2-4389-8A24-19E75987C616@lucidvision.com>
References: <CABCOCHQRAMscWbHbg0CrsiHNOD09XjjJqwsyTBoD9AuZXgj6MQ@mail.gmail.com> <55D3DDFC.2080107@labn.net> <29B312B3-287D-4E61-8447-CFDF8F6C1734@lucidvision.com> <55D53BEF.2060009@labn.net>
To: Berger Lou <lberger@labn.net>
X-Mailer: Apple Mail (2.2104)
X-Authenticated-User: tnadeau@lucidvision.com
X-Info: aspam skipped due to (g_smite_skip_relay)
X-Encryption: SSL encrypted
X-ShareWhite: 50.255.148.181
X-MyRbl: Color=Yellow Age=0 Spam=0 Notspam=17 Stars=0 Good=0 Friend=0 Surbl=0 Catch=0 r=0 ip=50.255.148.181
X-IP-stats: Notspam Incoming Last 0, First 97, in=943, out=0, spam=0 Known=true ip=50.255.148.181
Archived-At: <http://mailarchive.ietf.org/arch/msg/rtgwg/sPGp6X0ogvCYDdl9x3nNf97fSgE>
Cc: Routing WG <rtgwg@ietf.org>, Andy Bierman <andy@yumaworks.com>, netmod WG <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 12:34:35 -0000
> On Aug 19, 2015:10:31 PM, at 10:31 PM, Lou Berger <lberger@labn.net> wrote: > > On 08/19/2015 08:48 AM, Nadeau Thomas wrote: >> >>> On Aug 18, 2015:9:38 PM, at 9:38 PM, Lou Berger <lberger@labn.net> wrote: >>> >>> [Adding authors and RTG WG.] >>> >>> Hi Andy, >>> I'm not sure who you are looking to hear from as you addressed this >>> mail to the netmod list. I'm happy to give my opinion as it seems you >>> might have been aiming this at the draft authors. (but then again >>> perhaps not.) >>> >>> On 8/18/2015 8:01 PM, Andy Bierman wrote: >>>> Hi, >>>> >>>> I assume this draft is what we should be reviewing and not >>>> the obsolete openconfig draft? >>> >>> My personal view / hope is that the openconfig draft will be revised to >>> cover requirements >> >> Can you be specific about which requirements you feel are not covered ? >> >> —Tom >> > > I wasn't commenting on what's covered/not covered. I was saying that I > don't think the openconfig draft should disappear, rather it should be > revised to just focus on requirements. > > Lou Fair enough. —Tom > >> >>> while the DT draft leads to an agreed upon approach >>> to addressing those requirements. Again, just stating my view, not the >>> view of the DT, co-authors or OC draft authors. >>> >>>> >>>> >>>> https://tools.ietf.org/html/draft-rtgyangdt-rtgwg-device-model-00 >>>> >>>> >>>> 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? >>> >>>> >>>> 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. But again, this more of a requirements >>> discussion. >>> >>>> 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” >>> >>>> The hierarchy seems quite router-centric. >>> It is intended to be network device centric, routers, switches, >>> firewalls, etc. >>> >>>> Is the expectation that all YANG-based devices will use this >>>> data hierarchy, or only some devices? >>> The proposal is to provide a framework for any device that supports a >>> protocol or other mechanism defined within the routing area. (Or at >>> least that's our understanding of what we were asked to do.) >>> >>>> >>>> Is the expectation that all YANG modules will use this >>>> data hierarchy, or only some modules? >>> >>> I personally think there will be siblings to /device, e.g., /service - >>> but this is beyond the scope of this draft. >>> >>>> Is it just >>>> for IETF routing modules or more than that? >>>> >>> I think this is the same question and answer as above. >>> >>>> 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? >>> >>> Also not the text says: >>> ... possible technology-specific augmentations using example >>> technologies .. >>> and >>> >>> The interfaces container includes a number of commonly used >>> components as examples: >>> >>>> Q3) virtual devices >>>> >>>> The model supports the potentially independent system management >>>> functions and configuration per logical network element. This >>>> permits, for example, different users to manage either the whole >>>> device or just the associated logical network element. >>>> >>>> Sec 2.2.1 shows the system management tree but it is wrong. >>> >>> Yes, good catch of a cut-and-past bug. thankfully it is correct both >>> immediately before in the section intro and the details >>> >>>> The following tree is what the YANG model defines: >>>> +--rw device >>>> +--rw logical-network-elements >>>> -rw logical-network-element* [network-element-id] >>>> +--rw network-element-id uint8 >>>> +--rw network-element-name? string >>>> +--rw default-networking-instance-name? string >>>> +--rw system-management >>>> | +--rw device-view? boolean >>>> | +--rw syslog >>>> | +--rw dns >>>> | +--rw ntp >>>> | +--rw statistics-collection >>>> | +--rw ssh >>>> | +--rw tacacs >>>> | +--rw snmp >>>> | +--rw netconf >>>> What about devices that do not have logical network elements? >>> It would have only a single network-element-id >>> >>>> This hierarchy may be appropriate for very large routers >>>> but nothing else. >>> The intent is to cover all implementations independent of vendors. We >>> had a good range of view points both in the DT and in the RTGWG >>> discussion. Not saying there was full agreement, just that we have a >>> proposed starting point. >>> >>>> How can this tree represent both the physical view and the virtual view? >>> 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. >>> >>>> It seems to assume this is the "root user physical view". >>>> Please explain how device-type=VIRTUAL is used. >>> >>> This is a bit different and hasn't been a major point of discussion in >>> the WG -- we brought this over from the openconfig draft. I read this >>> as being pretty uninteresting and simply set based on if the device is >>> running on dedicated special purpose h/w (e.g, a classic >>> "name-your-vendor" router) or as a VM (aka NFV). I'll defer to the OC >>> or other DT folks if their opinion differs. >>> >>> Thanks for the comments/discussion! >>> >>> Lou >>> >>>> Andy >>>> >>>> >>>> _______________________________________________ >>>> netmod mailing list >>>> netmod@ietf.org >>>> https://www.ietf.org/mailman/listinfo/netmod >>> >>> >>> _______________________________________________ >>> netmod mailing list >>> netmod@ietf.org >>> https://www.ietf.org/mailman/listinfo/netmod >> >> >
- 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