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

["Dongjie (Jimmy)" <[e-mail]>]

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