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

From: Benoit Claise <[email-masked]>
Date: Fri, 06 Mar 2015 11:48:02 +0100

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.

Regards, Benoit

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 6 Mar 2015 12:05:36 +0100

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

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.

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>

---

From: "Susan Hares" <[email-masked]>
Date: Fri, 6 Mar 2015 06:53:37 -0500

Juergen:

<chair hat on> 
Thank you for your input on location of work.  I will discuss this with Alia
and Jeff this morning.  If you do have input where a yang module updating
the Entity-MIB might be worked on, please drop me a note. 
<chair hat off>

Jie Dong, I, and other members of the I2RS topology task simply want to get
the inventory information added to some yang model.  In our multiple vendor
(Cisco, Ericsson, Juniper, Huawei, packet-design),  many people felt it was
reasonable.  

As technical advisor, do you know if the Entity-MIB work scheduled for
upgrading to a yang module?  If not, is there a working group where we could
suggest an equivalent model. 
  
As to config true,  this Data model seems IMHO (jie may correct me) one of
the I2RS model that wants to have ephemeral state but also change things in
the data store.  

<chair hat on> 
I asked the design teams to focus on the functions they desired in the
datastore so that we could see more test cases.  I hope you as the I2RS
technical advisor will help us dive into protocol issues with specific
models. 
<chair hat off> 

-----Original Message-----
From: Juergen Schoenwaelder [mailto:[email-masked]] 
Sent: Friday, March 06, 2015 6:06 AM
To: Benoit Claise
Cc: NETMOD Working Group; [email-masked];
[email-masked]
Subject: Re: [netmod] Inventory YANG model (entity-MIB)

On Fri, Mar 06, 2015 at 11:48:02AM +0100, Benoit Claise wrote:
> 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?

/js

---

From: Benoit Claise <[email-masked]>
Date: Fri, 06 Mar 2015 13:05:09 +0100

Hi Jürgen,
> 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 .

> That
> 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
Regards, Benoit

---

From: "Thomas D. Nadeau" <[email-masked]>
Date: Fri, 6 Mar 2015 07:20:32 -0500

> On Mar 6, 2015:7:05 AM, at 7:05 AM, Benoit Claise <[email-masked]> wrote:
> 
> Hi Jürgen,
> 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

> _______________________________________________
> netmod mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netmod
>

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 6 Mar 2015 14:38:10 +0100

On Fri, Mar 06, 2015 at 06:53:37AM -0500, Susan Hares wrote:
> upgrading to a yang module?

No.

> If not, is there a working group where we could suggest an
> equivalent model.

The NETMOD working group would likely be the first stop unless the
IESG wants to proceed with a more targetted approach. The NETMOD
charter says:

   The NETMOD WG may also develop any additional data models written
   in YANG that the WG considers core building blocks and that do not
   fall under the charters of other active IETF working groups.

> the I2RS model that wants to have ephemeral state but also change things in

Ephemeral is kind of surprising for me.

/js

---

From: "Susan Hares" <[email-masked]>
Date: Fri, 6 Mar 2015 08:47:41 -0500

Juergen:

If you are surprised on Ephemeral, I'll walk through the use case again with
the topology design team.  

Thank you for the feedback, 

Sue 

-----Original Message-----
From: Juergen Schoenwaelder [mailto:[email-masked]] 
Sent: Friday, March 06, 2015 8:38 AM
To: Susan Hares
Cc: 'Benoit Claise'; 'NETMOD Working Group';
[email-masked]; [email-masked]
Subject: Re: [netmod] Inventory YANG model (entity-MIB)

No.

> If not, is there a working group where we could suggest an equivalent 
> model.

The NETMOD working group would likely be the first stop unless the IESG
wants to proceed with a more targetted approach. The NETMOD charter says:

> As to config true,  this Data model seems IMHO (jie may correct me) 
> one of the I2RS model that wants to have ephemeral state but also 
> change things in the data store.

/js

---

From: Tina TSOU <[email-masked]>
Date: Fri, 6 Mar 2015 13:59:20 +0000

Dear Tom,

Agree with you.

Topology can be collected from network element, can also be presented at network level in network manager/controller.

Inventory has little things collected from network element. It is more at the network manager/controller. 

Topology is like one active at work in the society, inventory is like one's different roles in his family.

There is an operator (Telefonica) led network topology draft.
http://datatracker.ietf.org/doc/draft-contreras-supa-yang-network-topo/

Thank you,
Tina

> On Mar 6, 2015, at 8:20 PM, Thomas D. Nadeau <[email-masked]> wrote:
> 
>

---

From: Benoit Claise <[email-masked]>
Date: Fri, 06 Mar 2015 15:08:47 +0100

Dear all,
> IESG wants to proceed with a more targetted approach.
Let's make it clear for everybody.
NETMOD is the place where an ENTITY-MIB based YANG model must happen.
As Jürgen points it out below, the charter was modified for this type of 
work.

So we discussed the WHERE, the next question is WHO?

Regards, Benoit (AD hat on)
> The NETMOD

---

From: "Susan Hares" <[email-masked]>
Date: Fri, 6 Mar 2015 09:17:48 -0500

Benoit:

Netmod is a great place to work.  Jie Dong mentioned he will be glad to
begin the work there, and he'd be glad to work with any other people on a
draft.  

Sue  

-----Original Message-----
From: Benoit Claise [mailto:[email-masked]] 
Sent: Friday, March 06, 2015 9:09 AM
To: Susan Hares; 'NETMOD Working Group';

Dear all,
>> As technical advisor, do you know if the Entity-MIB work scheduled 
>> for upgrading to a yang module?
> No.
>

---

From: Jeffrey Haas <[email-masked]>
Date: Sun, 8 Mar 2015 15:08:37 -0400

[speaking largely as a contributor and not i2rs-chair]

> make the interface to the routing system work.

As discussed later in thread, having this work owned by netmod is fine with
I2RS.

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.

The fact that the IETF already has good models for some of these things, the
ENTITY-MIB as an example, is good.  However, simple conversion of MIBs to
yang modules are likely to result in models that are good MIB replacements,
but might not be well tailored to re-use elsewhere.  Since much of the
motivation is for re-use, re-use is the discussion I would suggest is most
important.

As an example, SNMP tables probably should be converted into yang groupings.
There's also the matter of indexing of such conversions may not be fully
appropriate for such re-use and alternate indexes may be helpful.

>     already decided that I2RS is the home for all of this.

[speaking as one of the i2rs-chairs]

Topology was one of the use cases that was in-charter and we're not looking
to significantly expand our charter work.  But one thing we've noted over
the life of the group is that there has been a lot of push for micro-WG to
be formed for various yang efforts.  I personally believe we're better off
with some owning WG taking on the task but handling it within the context of
a design team.  The overhead of a full WG is likely not merited.

Which WG the design team reports to is, of course, up for discussion.

-- Jeff

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Sun, 8 Mar 2015 21:29:10 +0100

> appropriate for such re-use and alternate indexes may be helpful.

Nobody is insisting on an SNMP translation but whatever is done better
allows export via the ENTITY-MIB as well - things need to be aligned
at least. I note that many of the things you mention are not part of
draft-dong-i2rs-network-inventory-00.txt either.

> Which WG the design team reports to is, of course, up for discussion.

What was in the original I2RS charter was routing topology export
(read-only). Going from there to a generic topology model (which
likely should not be limited to config false) is quite a step. I
personally find it sub-optimal to do the generic model in WG A and
several extensions of the generic model in WG B plus some more
extensions in WG C, most likely crossing IETF areas. The coordination
resulting from this will most likely slow things down.

/js

---

From: Andy Bierman <[email-masked]>
Date: Sun, 8 Mar 2015 13:41:59 -0700

> So we discussed the WHERE, the next question is WHO?

I would be interested on working on the YANG version of the Entity MIB.
I think it should be updated so that SNMP agents can coexist with
the NETCONF/RESTCONF version with minimal or no impact
on existing instrumentation.

> Regards, Benoit (AD hat on)

Andy

---

From: "Dongjie (Jimmy)" <[email-masked]>
Date: Mon, 9 Mar 2015 03:40:15 +0000

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

> From: netmod [mailto:[email-masked]] On Behalf Of Thomas D.
> Nadeau
> Sent: Friday, March 06, 2015 8:21 PM
> To: Benoit Claise
> Cc: [email-masked];
> [email-masked]; NETMOD Working Group
> >>> 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.
> >>>
> > 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:
> 
> 	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:
> 
> >> 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.
> >> 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

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Mon, 9 Mar 2015 09:05:23 +0000

+1

Dan

> From: netmod [mailto:[email-masked]] On Behalf Of Andy
> Bierman

> I think it should be updated so that SNMP agents can coexist with the
> NETCONF/RESTCONF version with minimal or no impact on existing
> instrumentation.
>

---

From: Thomas Nadeau <[email-masked]>
Date: Mon, 9 Mar 2015 05:29:17 -0400

Speaking as cochair, I'd encourage you to produce a draft. There seems to be good WG support to do this.

 If you need any support beyond andy's help please let me know.

Tom 

> On Mar 9, 2015, at 5:05 AM, Romascanu, Dan (Dan) <[email-masked]> wrote:
> 
> +1
> 
> Dan
>

---

From: Thomas Nadeau <[email-masked]>
Date: Mon, 9 Mar 2015 05:31:31 -0400

I'll add you to the agenda.

> On Mar 8, 2015, at 11:40 PM, Dongjie (Jimmy) <[email-masked]> wrote:
> 
> Hi Tom, 
>

---

From: "Dongjie (Jimmy)" <[email-masked]>
Date: Mon, 9 Mar 2015 09:57:38 +0000

Hi Juergen, 

Thanks a lot for your comments. Please see some replies inline:

> From: netmod [mailto:[email-masked]] On Behalf Of Juergen
> Schoenwaelder
> Sent: Friday, March 06, 2015 7:06 PM
> To: Benoit Claise

We will take a look at the ENTITY-MIB and see how to re-use and possibly update the materials in that MIB.

> references not repeated (this is what the ENTITY-MIB does). 

Agreed, reference or augment the interface module is reasonable and will be considered in next revision.

> different kind of hardware components). 

Agree we can make this more generic for different types of network equipments/components.

> I also notice that the model

The idea is that the inventory model not only can be used to query the information and status of the device/components, but also can be used/augmented to configure some generic and protocol-independent functions on the device/components. 

Best regards,
Jie

---

From: "Dongjie (Jimmy)" <[email-masked]>
Date: Mon, 9 Mar 2015 09:59:35 +0000

Hi Tom,

Thanks a lot.

-Jie

> From: Thomas Nadeau [mailto:[email-masked]]
> Sent: Monday, March 09, 2015 5:32 PM
> To: Dongjie (Jimmy)
> Cc: Benoit Claise; [email-masked];
> > 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.
> >
> >>>> On Mar 6, 2015:7:05 AM, at 7:05 AM, Benoit Claise
> >>>> <[email-masked]>
> >>> wrote:
> >>>
> >>> Hi Jürgen,
> >>>>> http://etherpad.tools.ietf.org:9000/p/i2rs-interim-march-5-2015-v-
> >>>>> bl
> >>>>> uesheets
> >>>>>
> >>>>> (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?
> >>>>> 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.
> >>>> My first question is (perhaps not surprising) whether inventory
> >>>> falls into the I2RS charter, I2RS = interface to the routing system.
> >>> No it doesn't.
> >> happy if the inventory work be done somewhere else. Hence this email
> >>    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.
> >>
> >> 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:
> >>
> >>    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:
> >>
> >>>> 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.
> >>>> 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

---

From: Andy Bierman <[email-masked]>
Date: Mon, 9 Mar 2015 10:24:12 -0700

> draft-dong-i2rs-network-inventory-00.txt either.

I start to worry about I2RS boiling the ocean when I see
inventory data models in that WG. I question the value
of converting every OID to a YANG identity, or
making gratuitous name changes to every leaf.

Perhaps an SMI to YANG translation of the ENTITY-MIB will
be a good enough starting point. I prefer to see IETF YANG work
focus on configuration, rather than reinvent monitoring solutions
that have been deployed for many years.

Andy

---

From: "Susan Hares" <[email-masked]>
Date: Mon, 9 Mar 2015 14:00:41 -0400

Andy: 

The I2RS chairs and others suggested these features from the L2 topology draft get moved to an inventory draft, and that the draft get moved to netmod. 

Jie Dong (who originated the draft) is looking for co-authors or looking to collaborate.  The  vendors (Cisco, Huawei and others) are looking for a solution.  I hope you will help them find a solution that revises the right things from the ENTITY MIB for a solution that allows combines topology and Entity MIB information for their solutions.  

Sue 

-----Original Message-----
From: Andy Bierman [mailto:[email-masked]] 
Sent: Monday, March 09, 2015 1:24 PM
To: Juergen Schoenwaelder; Jeffrey Haas; Benoit Claise; NETMOD Working Group; [email-masked]; [email-masked]
Subject: Re: [netmod] Inventory YANG model (entity-MIB)

On Sun, Mar 8, 2015 at 1:29 PM, Juergen Schoenwaelder <[email-masked]> wrote:
>> > falls into the I2RS charter, I2RS = interface to the routing 
>> > system. 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.
>>
>> As discussed later in thread, having this work owned by netmod is 
>> fine with I2RS.
>>
>> 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.
>>
>> The fact that the IETF already has good models for some of these 
>> things, the ENTITY-MIB as an example, is good.  However, simple 
>> conversion of MIBs to yang modules are likely to result in models 
>> that are good MIB replacements, but might not be well tailored to 
>> re-use elsewhere.  Since much of the motivation is for re-use, re-use 
>> is the discussion I would suggest is most important.
>>
>> There's also the matter of indexing of such conversions may not be 
>> fully appropriate for such re-use and alternate indexes may be helpful.
>

I start to worry about I2RS boiling the ocean when I see inventory data models in that WG. I question the value of converting every OID to a YANG identity, or making gratuitous name changes to every leaf.

Perhaps an SMI to YANG translation of the ENTITY-MIB will be a good enough starting point. I prefer to see IETF YANG work focus on configuration, rather than reinvent monitoring solutions that have been deployed for many years.

>> Topology was one of the use cases that was in-charter and we're not 
>> looking to significantly expand our charter work.  But one thing 
>> we've noted over the life of the group is that there has been a lot 
>> of push for micro-WG to be formed for various yang efforts.  I 
>> personally believe we're better off with some owning WG taking on the 
>> task but handling it within the context of a design team.  The overhead of a full WG is likely not merited.
>>

Andy

---

From: "Dongjie (Jimmy)" <[email-masked]>
Date: Tue, 10 Mar 2015 02:44:06 +0000

Hi Andy,

Thanks for your feedback. Please see my replies inline:

> Sent: Tuesday, March 10, 2015 1:24 AM
> To: Juergen Schoenwaelder; Jeffrey Haas; Benoit Claise; NETMOD Working
> Group; [email-masked];
> I start to worry about I2RS boiling the ocean when I see inventory data models
> in that WG. I question the value of converting every OID to a YANG identity, or

The inventory model was motivated by some discussion in the I2RS interim, and we are open to move this work to Netmod if people are more interested to do this work here.
As Jeff said, simple conversion of MIB to Yang is not exactly our goal. Hopefully we can make good use of Yang to build a base inventory model, which is extensible with augmentation to build more specific models.

> Perhaps an SMI to YANG translation of the ENTITY-MIB will be a good enough
> starting point. I prefer to see IETF YANG work focus on configuration, rather
> than reinvent monitoring solutions that have been deployed for many years.

To my understanding, SMI to Yang translation gives you read-only models, while with Yang we can do both read and write. I'd agree that the inventory yang model should not limit its scope for monitoring, and we need to discuss what configurations should be considered as part of the inventory model. We'd appreciate your contributions on both aspects. Thanks.

Best regards,
Jie

---

From: Andy Bierman <[email-masked]>
Date: Mon, 9 Mar 2015 20:09:04 -0700

On Mon, Mar 9, 2015 at 7:44 PM, Dongjie (Jimmy) <[email-masked]> wrote:
>....

I am not that concerned where the work gets done, but rather with
SNMP integration.  Some vendors have invested quite a lot of resources
supporting that particular classification system.  The overhead and complexity
of supporting 2 inventory systems seems rather unjustified.

> To my understanding, SMI to Yang translation gives you read-only models, while with Yang we can do both read and write. I'd agree that the inventory yang model should not limit its scope for monito…

Inventory is usually read-only.
Annotations can be added with indexing (not directly within the
operational data).

I would suggest starting by explaining why the
existing SMIv2 data cannot be used (via SMI to YANG translation)
and explain what new features that are needed by I2RS
in order to write to the RIB.

Andy

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 10 Mar 2015 08:11:12 +0100

On Tue, Mar 10, 2015 at 02:44:06AM +0000, Dongjie (Jimmy) wrote:

> To my understanding, SMI to Yang translation gives you read-only
> models, while with Yang we can do both read and write. I'd agree
> that the inventory yang model should not limit its scope for
> monitoring, and we need to discuss what configurations should be
> considered as part of the inventory model. We'd appreciate your
> contributions on both aspects.

Perhaps it helps if people can explain which problem is to be solved
with the inventory data model. The ENTITY-MIB primarily exports the
internal structure of a physical device (a containment hierarchy of
physical components) to management applications. Some extensions
provide access to more detailed state information and to sensors often
attached to hardware components. Most of this is not configurable
(although you can attach deployment specific identifiers and
descriptions).

Can someone provide a concise description which problems the inventory
data model is trying to solve? Is it essentially adressing the same
functionality as the ENTITY-MIB or something different? If so, I
assume there is not much too configure - a few 'postit' objects and
perhaps an administrative state object.

/js

PS: I am attaching the combined tree of the ENTITY*MIB modules
    published by the IETF.

---

From: Benoit Claise <[email-masked]>
Date: Tue, 10 Mar 2015 15:55:42 +0100

Hi Jie,
> 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

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

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 10 Mar 2015 18:23:52 +0100

> to the interface, to the ENTITY YANG model, and I guess others.

It does not link, it repeats information. If the generic data model is
done well, linkage to other pieces should be handles quite naturally.
I also do not understand the 'tunnels' question (what precisly is the
question?).

/js

---

From: Benoit Claise <[email-masked]>
Date: Tue, 10 Mar 2015 18:55:17 +0100

On 10/03/2015 18:23, Juergen Schoenwaelder wrote:
> It does not link, it repeats information.
I know. It should not, as mentioned to I2RS.
> If the generic data model is
That's a different story. I should have not copied this one.

Regards, B.

---

From: "Dongjie (Jimmy)" <[email-masked]>
Date: Wed, 11 Mar 2015 05:59:13 +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:[email-masked]]
Sent: Tuesday, March 10, 2015 10:56 PM
To: Dongjie (Jimmy); Thomas D. Nadeau
Cc: [email-masked]; [email-masked]; NETMOD Working Group
Subject: Re: [netmod] Inventory YANG model (entity-MIB)

Hi Jie,

Hi Tom,

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

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

Best regards,

Jie

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

Nadeau

To: Benoit Claise

Cc: [email-masked]<mailto:[email-masked]>;

[email-masked]<mailto:[email-masked]>; NETMOD Working Group

On Mar 6, 2015:7:05 AM, at 7:05 AM, Benoit Claise <[email-masked]><mailto:[email-masked]>

wrote:

Hi Jürgen,

Dear all,

http://etherpad.tools.ietf.org:9000/p/i2rs-interim-march-5-2015-v-bl

uesheets

(and RFC 7223 btw).

ENTITY-MIB?

What do you think?

No it doesn't.

vendor vacuum.

 --Tom

That

Yes, I made that point.

So what is

sure how this is supposed to use.

device actually has?

/js

Regards, Benoit

netmod mailing list

[email-masked]<mailto:[email-masked]>

netmod mailing list

[email-masked]<mailto:[email-masked]>

.

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 11 Mar 2015 08:01:31 +0100

On Wed, Mar 11, 2015 at 05:59:13AM +0000, Dongjie (Jimmy) wrote:
 
> 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.

You need to detail what these 'generic features and capabilities of
the nodes and components' would be. Note that there is already RFC
7317.

/js

---

From: "Dongjie (Jimmy)" <[email-masked]>
Date: Wed, 11 Mar 2015 09:43:21 +0000

Hi Juergen, 

We did checked RFC7317 when we wrote this draft, and found that (please correct me if I'm wrong) the features described in that RFC are mainly for the management of the device. 

As described in the -00 version of draft-dong-inventory, the "generic features and capabilities" means the networking functions and services that the network nodes and components can provide, e.g. IP unicast, multicast, ethernet bridging, mpls, traffic-engineering, etc. The set of the functions will be completed in future revision. Our intention is to abstract those control plane independent functions in this model, and let the protocol specific models to cover the details of each protocol.

Best regards,
Jie

> Sent: Wednesday, March 11, 2015 3:02 PM
> To: Dongjie (Jimmy)
> Cc: Benoit Claise; Thomas D. Nadeau;
> [email-masked]; [email-masked];
> NETMOD Working Group
> > 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.
> 
> You need to detail what these 'generic features and capabilities of the nodes
> and components' would be. Note that there is already RFC 7317.
> 
> /js
> 
> --

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 11 Mar 2015 11:22:24 +0100

> As described in the -00 version of draft-dong-inventory, the "generic features and capabilities" means the networking functions and services that the network nodes and components can provide, e.g.…

I think this is not how we organize work in the IETF. If a device
supports ethernet briding (for example), it will announce an ethernet
bridging data model that is extending the generic interface data model
with ethernet bridging specific configuration and state objects. This
has already been done for IP and it follows the way the IETF
previously organized MIB modules. This is also largely how routing
data models that are currently written are organized (a core routing
data model plus routing protocol specific extensions).

I do not think that what you are describing fits into the scope of an
inventory data model given the way the IETF used partion work so far.

/js

---

From: "Thomas D. Nadeau" <[email-masked]>
Date: Wed, 11 Mar 2015 08:13:42 -0400

> On Mar 11, 2015:1:59 AM, at 1:59 AM, Dongjie (Jimmy) <[email-masked]> wrote:
> 
> Hi Benoit,
>  

	Having spoken with a variety of people on this now, it seems fairly clear that we need to separate out the Entity MIB from the inventory. Juergen gave a very straight-forward explanation of why this is the case: if its done an a separate component, the inventory and other models are free to include it. This encourages reuse of those components and doesn't glue them only to inventory.  To this end, I'd like to as you to take this approach with your model.  I am also going to direct a few interested people to start a design team which I will manage, to construct the Entity MIB model. I will send email out in a second explaining this. 

	--Tom

>  
> Best regards,
> Jie
>  
> From: Benoit Claise [mailto:[email-masked] <mailto:[email-masked]>] 
> Cc: [email-masked] <mailto:[email-masked]>; [email-masked] <mailto:[email-masked]>; NETMOD Working Group
> From: netmod [mailto:[email-masked] <mailto:[email-masked]>] On Behalf Of Thomas D.
> Nadeau
> Cc: [email-masked] <mailto:[email-masked]>;
> [email-masked] <mailto:[email-masked]>; NETMOD Working Group
> On Mar 6, 2015:7:05 AM, at 7:05 AM, Benoit Claise <[email-masked]> <mailto:[email-masked]>
> wrote:
>  
> Hi Jürgen,
> http://etherpad.tools.ietf.org:9000/p/i2rs-interim-march-5-2015-v-bl <http://etherpad.tools.ietf.org:9000/p/i2rs-interim-march-5-2015-v-bl>
> uesheets
>  
> (http://datatracker.ietf.org/doc/draft-dong-i2rs-network-inventory/ <http://datatracker.ietf.org/doc/draft-dong-i2rs-network-inventory/>)
> http://www.ietf.org/archive/id/draft-medved-i2rs-topology-im-01.txt <http://www.ietf.org/archive/id/draft-medved-i2rs-topology-im-01.txt>
>  
> https://datatracker.ietf.org/doc/draft-amante-i2rs-topology-use-cases/ <https://datatracker.ietf.org/doc/draft-amante-i2rs-topology-use-cases/>
>  
>  --Tom
>  
>  
> That
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/netmod <https://www.ietf.org/mailman/listinfo/netmod>
>  
>  
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/netmod <https://www.ietf.org/mailman/listinfo/netmod>
> .
>  
>

---

From: Mahesh Jethanandani <[email-masked]>
Date: Wed, 11 Mar 2015 17:15:19 +0100

And I would suggest that Ethernet Bridging Model is something that needs to be modeled by IEEE 802.1Q WG, where I have just submitted a PAR for discussion to develop just that.

Mahesh Jethanandani
[email-masked]

> On Mar 11, 2015, at 11:22 AM, Juergen Schoenwaelder <[email-masked]> wrote:
>

---

From: "Dongjie (Jimmy)" <[email-masked]>
Date: Fri, 13 Mar 2015 01:18:37 +0000

Hi Juergen, 

> Sent: Wednesday, March 11, 2015 6:22 PM
> To: Dongjie (Jimmy)
> > As described in the -00 version of draft-dong-inventory, the "generic features
> and capabilities" means the networking functions and services that the network
> nodes and components can provide, e.g. IP unicast, multicast, ethernet bridging,
> mpls, traffic-engineering, etc. The set of the functions will be completed in
> future revision. Our intention is to abstract those control plane independent
> functions in this model, and let the protocol specific models to cover the details
> of each protocol.
> 
> I think this is not how we organize work in the IETF. If a device supports
> ethernet briding (for example), it will announce an ethernet bridging data model
> that is extending the generic interface data model with ethernet bridging
> specific configuration and state objects. This has already been done for IP and it
> follows the way the IETF previously organized MIB modules. This is also largely
> how routing data models that are currently written are organized (a core
> routing data model plus routing protocol specific extensions).

Agree that for each network protocol or function, specific model is needed for the detailed states and configurations of that technology. 

What the inventory model intends to cover is a summary of the capability set that the networks nodes and components can support. Such summary information may be helpful to the upper layers.

Best regards,
Jie

---

From: "Dongjie (Jimmy)" <[email-masked]>
Date: Fri, 13 Mar 2015 01:24:33 +0000

Hi Mahesh, 

Agree that the detailed data model for Ethernet Bridging would belong to IEEE 802.1Q.

The inventory model just provide a summary of the functions and capabilities the network nodes and components can support, and Ethernet Bridging is just listed as one of the capabilities.

Best regards,
Jie

> From: Mahesh Jethanandani [mailto:[email-masked]]
> Sent: Thursday, March 12, 2015 12:15 AM
> To: Juergen Schoenwaelder
> Cc: Dongjie (Jimmy); [email-masked];
> [email-masked]; NETMOD Working Group
> And I would suggest that Ethernet Bridging Model is something that needs to be
> modeled by IEEE 802.1Q WG, where I have just submitted a PAR for discussion
> to develop just that.
> 
> Mahesh Jethanandani
> [email-masked]
> 
> > On Mar 11, 2015, at 11:22 AM, Juergen Schoenwaelder

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 13 Mar 2015 07:46:26 +0100

> The inventory model just provide a summary of the functions and capabilities the network nodes and components can support, and Ethernet Bridging is just listed as one of the capabilities.

I do not see why summary information would be worth additional
complexity. The interface model tells a management application what
kind of interfaces there are. The data models announced by a device
tells a management application what it can work with.

/js