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

[Thomas Nadeau <[e-mail]>]

I'll add you to the agenda.



> On Mar 8, 2015, at 11:40 PM, Dongjie (Jimmy) <[e-mail]> wrote:
> 
> 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.
> 
> 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:[e-mail]] On Behalf Of Thomas D.
>> Nadeau
>> Sent: Friday, March 06, 2015 8:21 PM
>> To: Benoit Claise
>> Cc: [e-mail];
>> [e-mail]; NETMOD Working Group
>> Subject: Re: [netmod] Inventory YANG model (entity-MIB)
>> 
>> 
>>>> On Mar 6, 2015:7:05 AM, at 7:05 AM, Benoit Claise <[e-mail]>
>>> 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
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/netmod
>> 
>> _______________________________________________
>> netmod mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/netmod
>