Re: [netmod] Inventory YANG model (entity-MIB)

"Thomas D. Nadeau" <tnadeau@lucidvision.com> Fri, 06 March 2015 12:20 UTC

Return-Path: <tnadeau@lucidvision.com>
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C40E21ACDCE for <netmod@ietfa.amsl.com>; Fri, 6 Mar 2015 04:20:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.896
X-Spam-Level:
X-Spam-Status: No, score=0.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.793, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, WEIRD_PORT=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 vI6V0M13lZ20 for <netmod@ietfa.amsl.com>; Fri, 6 Mar 2015 04:20:34 -0800 (PST)
Received: from lucidvision.com (unknown [50.255.148.178]) by ietfa.amsl.com (Postfix) with ESMTP id 2AB151ACDCD for <netmod@ietf.org>; Fri, 6 Mar 2015 04:20:34 -0800 (PST)
Received: from [192.168.1.134] (unknown [50.255.148.177]) by lucidvision.com (Postfix) with ESMTP id 9AC7E2FE0828; Fri, 6 Mar 2015 07:20:33 -0500 (EST)
Content-Type: text/plain; charset="windows-1252"
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\))
From: "Thomas D. Nadeau" <tnadeau@lucidvision.com>
In-Reply-To: <54F997F5.8080500@cisco.com>
Date: Fri, 06 Mar 2015 07:20:32 -0500
Content-Transfer-Encoding: quoted-printable
Message-Id: <2D3BC67E-9B26-488E-BF4D-0FC899C3A8CA@lucidvision.com>
References: <54F985E2.6020304@cisco.com> <20150306110536.GA73575@elstar.local> <54F997F5.8080500@cisco.com>
To: Benoit Claise <bclaise@cisco.com>
X-Mailer: Apple Mail (2.2070.6)
Archived-At: <http://mailarchive.ietf.org/arch/msg/netmod/fLdspdRXMnoagRGyWPToGsgNhsA>
Cc: draft-dong-i2rs-network-inventory@tools.ietf.org, "i2rs-chairs@tools.ietf.org" <i2rs-chairs@tools.ietf.org>, NETMOD Working Group <netmod@ietf.org>
Subject: Re: [netmod] Inventory YANG model (entity-MIB)
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list <netmod.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netmod/>
List-Post: <mailto:netmod@ietf.org>
List-Help: <mailto:netmod-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 06 Mar 2015 12:20:35 -0000

> On Mar 6, 2015:7:05 AM, at 7:05 AM, Benoit Claise <bclaise@cisco.com> wrote:
> 
> Hi Jürgen,
>> On Fri, Mar 06, 2015 at 11:48:02AM +0100, Benoit Claise wrote:
>>> Dear all,
>>> 
>>> The I2RS interim meeting yesterday focused on topology.
>>> Let me cut/paste a high level slide, with pointers to the relevant drafts.
>>> 
>>> 
>>> If interested, the meeting minutes are at
>>> http://etherpad.tools.ietf.org:9000/p/i2rs-interim-march-5-2015-v-bluesheets
>>> 
>>> Part of the inventory draft
>>> (http://datatracker.ietf.org/doc/draft-dong-i2rs-network-inventory/)
>>> discussion, the overlap with the ENTITY-MIB RFC 6933 was discussed (and
>>> RFC 7223 btw).
>>> 
>>> 
>>> The message was that I2RS should not re-invent something similar to the
>>> ENTITY-MIB
>>> So, are you aware of any initiatives to "YANGify" the ENTITY-MIB?
>>> It's true that there is a way to translate MIB into YANG with RFC 6643.
>>> This could be a good start. However, I wonder if a hand-written YANG
>>> model that closely follows the entPhysical would not be more beneficial.
>>> Is this something we should take on board in NETMOD?
>>> 
>>> What do you think?
>>> 
>>> Note: As commented by the I2RS people, indexing is appropriate in the
>>> MIB module for its original purpose, but may not be for the topology.
>>> I'm not sure we want to change the indexing just for the topology, but
>>> the integration within the topology draft should be thought of.
>>> 
>> My first question is (perhaps not surprising) whether inventory falls
>> into the I2RS charter, I2RS = interface to the routing system.
> No it doesn't.
> As mentioned during the interim yesterday by the I2RS people, they would be happy if the inventory work be done somewhere else. Hence this email thread. I believe this work should be picked up by NETMOD .

	I agree with Juergen's assessment; this seems like it should be done in NETMOD. We should figure out a way to leverage the entity MIB but given that module's age, we should also be open to updates because the world has changed since that was published.  

	So there is a wider question as Juergen asked at the end of the thread: should here be a concentrated effort to do topology/inventory that applies to all areas ?  I'd say yes.  While not a super complicated, long effort, this is something that needs to be done in a way that it applies to more than just the use cases of a specific routing use case.  With that in mind, its important to get the network operators involved on this effort so that this is not done in a vendor vacuum.

	Speaking as an individual, I will point out that the topology model that I've worked on with Jan et al you can see the approach taken on network topology. This has been implemented in ODL, which means its being tried in production environments right now and works quite well:

http://www.ietf.org/archive/id/draft-medved-i2rs-topology-im-01.txt

	Another data point here. Shane and others have been been clear that an inventory is needed and how it is a bit different than network topology as specified above, but that it should be consistent in certain places too:

https://datatracker.ietf.org/doc/draft-amante-i2rs-topology-use-cases/

	--Tom


> That
>> said, RFC 6643 gives you a read-only translation. There are not many
>> read-write objects in the ENTITY-MIB so perhaps this is good enough
>> for now. I guess it would help what I2RS needs to know in order to
>> make the interface to the routing system work.
>> 
>> Anyway, if YANG models overlapping the ENTITY-MIB are done, they they
>> should at least allow implementation of both in a predictable manner.
>> Looking at draft-dong-i2rs-network-inventory-00, it seems the whole
>> interface list is already covered by RFC 7223 and interfaces should be
>> references not repeated (this is what the ENTITY-MIB does).
> Yes, I made that point.
> Similarly, this draft should reference a inventory YANG model
> 
>> So what is
>> left is essentially a (not yet hierarchy) of 'cards' that seem to more
>> or less match the entPhysicalTable of the ENTITY-MIB (but then the
>> ENTITY-MIB has a more flexible model that distinguishes between
>> different kind of hardware components).
>> I also notice that the model
>> in draft-dong-i2rs-network-inventory-00 is config true - so I am not
>> sure how this is supposed to use.
>> Is the idea that this model is an
>> interface to an inventory database where I configure what I have
>> instead of a model sitting on a device where I can query what the
>> device actually has?
>> 
>> /js
> Regards, Benoit
>> 
>> PS: I personally would have preferred if generic topology and perhaps
>>     inventory would have split off into a short-lived targeted WG
>>     instead of doing all of this in I2RS but it seems leadership has
>>     already decided that I2RS is the home for all of this.
>> 
> 
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
>