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
>> 
>> 
>