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

"Dongjie (Jimmy)" <jie.dong@huawei.com> Wed, 11 March 2015 05:59 UTC

Return-Path: <jie.dong@huawei.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 BD27B1A0397 for <netmod@ietfa.amsl.com>; Tue, 10 Mar 2015 22:59:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.209
X-Spam-Level:
X-Spam-Status: No, score=-4.209 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, WEIRD_PORT=0.001] 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 W6TbQcdNpHKp for <netmod@ietfa.amsl.com>; Tue, 10 Mar 2015 22:59:24 -0700 (PDT)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0F1181A0393 for <netmod@ietf.org>; Tue, 10 Mar 2015 22:59:22 -0700 (PDT)
Received: from 172.18.7.190 (EHLO lhreml404-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BQC55107; Wed, 11 Mar 2015 05:59:21 +0000 (GMT)
Received: from NKGEML403-HUB.china.huawei.com (10.98.56.34) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 11 Mar 2015 05:59:20 +0000
Received: from NKGEML512-MBX.china.huawei.com ([169.254.7.106]) by nkgeml403-hub.china.huawei.com ([10.98.56.34]) with mapi id 14.03.0158.001; Wed, 11 Mar 2015 13:59:13 +0800
From: "Dongjie (Jimmy)" <jie.dong@huawei.com>
To: Benoit Claise <bclaise@cisco.com>, "Thomas D. Nadeau" <tnadeau@lucidvision.com>
Thread-Topic: [netmod] Inventory YANG model (entity-MIB)
Thread-Index: AQHQV/sWQ/8m3BSs+0WHTuyrX71fWp0OxN8AgAAQo4CAAARMAIAEor+ggAHR7wCAAVWLQA==
Date: Wed, 11 Mar 2015 05:59:13 +0000
Message-ID: <76CD132C3ADEF848BD84D028D243C927338526B1@nkgeml512-mbx.china.huawei.com>
References: <54F985E2.6020304@cisco.com> <20150306110536.GA73575@elstar.local> <54F997F5.8080500@cisco.com> <2D3BC67E-9B26-488E-BF4D-0FC899C3A8CA@lucidvision.com> <76CD132C3ADEF848BD84D028D243C92733850607@nkgeml512-mbx.china.huawei.com> <54FF05EE.2070607@cisco.com>
In-Reply-To: <54FF05EE.2070607@cisco.com>
Accept-Language: en-US, zh-CN
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.111.97.131]
Content-Type: multipart/alternative; boundary="_000_76CD132C3ADEF848BD84D028D243C927338526B1nkgeml512mbxchi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <http://mailarchive.ietf.org/arch/msg/netmod/moRDMsZfJ5xTaIkHqvuECu2cL-c>
Cc: "draft-dong-i2rs-network-inventory@tools.ietf.org" <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: Wed, 11 Mar 2015 05:59:30 -0000

Hi Benoit,

Thanks for your comments.

So now we all agree that the inventory yang model work is needed. As for in which way to build that model, currently there are different opinions, and we are open to discuss this.

The intention of draft-dong-i2rs-network-inventory was to describe the features and capabilities of the network nodes and their components, as during the discussion of the L2 topology model, we realized that such information should be specified in a separate model.  So in our opinion this inventory model would include both the information listed in the ENTITY-MIB, and also a set of generic features and capabilities of the nodes and components, for which some configurations could apply.  Thus it would be more than the translation of MIB. As you said, this model could have links to the interface Yang model and some other models. Whether a Yang version of the ENTITY-MIB should be linked or integrated needs further discussion.

Best regards,
Jie

From: Benoit Claise [mailto:bclaise@cisco.com]
Sent: Tuesday, March 10, 2015 10:56 PM
To: Dongjie (Jimmy); Thomas D. Nadeau
Cc: draft-dong-i2rs-network-inventory@tools.ietf.org; i2rs-chairs@tools.ietf.org; NETMOD Working Group
Subject: Re: [netmod] Inventory YANG model (entity-MIB)

Hi Jie,

Hi Tom,



Happy to know that Netmod has interests on the inventory Yang model, and we would be glad to move draft-dong-i2rs-network-inventory-00 to Netmod if it is decided by the ADs and chairs.
There are two different work items.
1. a YANG version of the ENTITY-MIB. This should be done in NETMOD

2. the mapping between the topology work and inventories. I like the way Jeff expressed it

The structure of the generic topology draft is leading to interesting

questions about how information present in that model can link to higher and

lower layers.  As seen in the I2RS presentations at the most recent interim,

this eventually leads to questions like "inventory".  I also raised the

question about tunnels which will lead to other models as well.
This item 2 should be done in I2RS. I understood that draft-dong-i2rs-network-inventory was covering this item 2, with links to the interface, to the ENTITY YANG model, and I guess others.

Regards, Benoit






Could we ask for a time slot of 10 mins to present the current inventory model draft and discuss the next-steps? Thanks.



Contributions and discussions on this model are welcome.



Best regards,

Jie



-----Original Message-----

From: netmod [mailto:netmod-bounces@ietf.org] On Behalf Of Thomas D.

Nadeau

Sent: Friday, March 06, 2015 8:21 PM

To: Benoit Claise

Cc: draft-dong-i2rs-network-inventory@tools.ietf.org<mailto:draft-dong-i2rs-network-inventory@tools.ietf.org>;

i2rs-chairs@tools.ietf.org<mailto:i2rs-chairs@tools.ietf.org>; NETMOD Working Group

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





On Mar 6, 2015:7:05 AM, at 7:05 AM, Benoit Claise <bclaise@cisco.com><mailto: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-bl

uesheets



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<mailto:netmod@ietf.org>

https://www.ietf.org/mailman/listinfo/netmod





_______________________________________________

netmod mailing list

netmod@ietf.org<mailto:netmod@ietf.org>

https://www.ietf.org/mailman/listinfo/netmod

.