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

Lou Berger <lberger@labn.net> Thu, 20 August 2015 02:31 UTC

Return-Path: <lberger@labn.net>
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 DED821A901C for <rtgwg@ietfa.amsl.com>; Wed, 19 Aug 2015 19:31:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.667
X-Spam-Level:
X-Spam-Status: No, score=-1.667 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no
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 3sjj0nzmX6dm for <rtgwg@ietfa.amsl.com>; Wed, 19 Aug 2015 19:31:27 -0700 (PDT)
Received: from gproxy2-pub.mail.unifiedlayer.com (gproxy2-pub.mail.unifiedlayer.com [69.89.18.3]) by ietfa.amsl.com (Postfix) with SMTP id 7BC851A8F4D for <rtgwg@ietf.org>; Wed, 19 Aug 2015 19:31:25 -0700 (PDT)
Received: (qmail 29612 invoked by uid 0); 20 Aug 2015 02:31:19 -0000
Received: from unknown (HELO CMOut01) (10.0.90.82) by gproxy2.mail.unifiedlayer.com with SMTP; 20 Aug 2015 02:31:19 -0000
Received: from box313.bluehost.com ([69.89.31.113]) by CMOut01 with id 6qXE1r0012SSUrH01qXHib; Wed, 19 Aug 2015 20:31:18 -0600
X-Authority-Analysis: v=2.1 cv=EbVbHpWC c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=wU2YTnxGAAAA:8 a=cNaOj0WVAAAA:8 a=4g2epv4a4k0A:10 a=N659UExz7-8A:10 a=-NfooI8aBGcA:10 a=uEJ9t1CZtbIA:10 a=uRRa74qj2VoA:10 a=48vgC7mUAAAA:8 a=gkdtDajsWwLqmO3Mto4A:9 a=eqejzZtndsl9Yf3K:21 a=hvPfSzf2mG6uObun:21 a=pILNOxqGKmIA:10
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:References:Subject:CC:To:MIME-Version:From:Date:Message-ID; bh=shxWceI27m2WNZc4nsZ1CFaYDdmFn1mwzE5jwhZ+r0w=; b=LfQaPNLfHJ3MCOpQpkWzC2BpYxLldqgLsNpsQMwEFpIsIycDghKDQprmavGr6QmcP8wmTpFV27HVnoe6z9HIX35zfSB6T7yxXh4Ufv5xejHagnZvtX1En/YnGw1XUYud;
Received: from box313.bluehost.com ([69.89.31.113]:42071 helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.84) (envelope-from <lberger@labn.net>) id 1ZSFdK-0005Md-JC; Wed, 19 Aug 2015 20:31:14 -0600
Message-ID: <55D53BEF.2060009@labn.net>
Date: Wed, 19 Aug 2015 22:31:11 -0400
From: Lou Berger <lberger@labn.net>
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:31.0) Gecko/20100101 Thunderbird/31.7.0
MIME-Version: 1.0
To: Nadeau Thomas <tnadeau@lucidvision.com>
Subject: Re: [netmod] questions about draft-rtgyangdt-rtgwg-device-model-00
References: <CABCOCHQRAMscWbHbg0CrsiHNOD09XjjJqwsyTBoD9AuZXgj6MQ@mail.gmail.com> <55D3DDFC.2080107@labn.net> <29B312B3-287D-4E61-8447-CFDF8F6C1734@lucidvision.com>
In-Reply-To: <29B312B3-287D-4E61-8447-CFDF8F6C1734@lucidvision.com>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 8bit
X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net}
Archived-At: <http://mailarchive.ietf.org/arch/msg/rtgwg/uXzz4KIe4NvZMJX4UHOyJy6KlxE>
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 02:31:30 -0000

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

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