Re: [netmod] questions about draft-rtgyangdt-rtgwg-device-model-00
Nadeau Thomas <tnadeau@lucidvision.com> Wed, 19 August 2015 12:49 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 054361A0389; Wed, 19 Aug 2015 05:49:02 -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 gK5Ri4IVLvaq; Wed, 19 Aug 2015 05:48:59 -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 BCCD71A0155; Wed, 19 Aug 2015 05:48:59 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lucidvision.com; s=default; t=1439988481; bh=VAOVeRsCqNGyNLH8APmVy5I5rLs3x+c0efHfhN6MVpE=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=1z4GgwgeTUAD1Nez11jWX5WcLLC/ApoGeexRaekUYk7TWxro94IhphMX3o4IYJvEw rDpuTOPapnOivxFyZyIgchUC3mYAmpjczMznDY0pUgcwfhb3yQxCli3BDslVmY7kJ9 bRvqNId9cdsjDKlYfYcjlZ2wYKrzS1bakW9xXuNQ=
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: <55D3DDFC.2080107@labn.net>
Date: Wed, 19 Aug 2015 08:48:28 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <29B312B3-287D-4E61-8447-CFDF8F6C1734@lucidvision.com>
References: <CABCOCHQRAMscWbHbg0CrsiHNOD09XjjJqwsyTBoD9AuZXgj6MQ@mail.gmail.com> <55D3DDFC.2080107@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=18 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 96, in=906, out=0, spam=0 Known=true ip=50.255.148.181
Archived-At: <http://mailarchive.ietf.org/arch/msg/rtgwg/y3MycWoHKQfuWm3MslrN7o2Z1Ec>
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: Wed, 19 Aug 2015 12:49:02 -0000
> 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 > 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