Re: comments on latest draft...

"David L. Arneson" <> Thu, 24 June 1993 04:19 UTC

Received: from by IETF.CNRI.Reston.VA.US id aa23535; 24 Jun 93 0:19 EDT
Received: from CS.UTK.EDU by IETF.CNRI.Reston.VA.US id aa23531; 24 Jun 93 0:19 EDT
Received: from localhost by CS.UTK.EDU with SMTP (5.61+IDA+UTK-930125/2.8s-UTK) id AA02632; Wed, 23 Jun 93 23:31:31 -0400
X-Resent-To: chassismib@CS.UTK.EDU ; Wed, 23 Jun 1993 23:31:30 EDT
Errors-To: owner-chassismib@CS.UTK.EDU
Received: from by CS.UTK.EDU with SMTP (5.61+IDA+UTK-930125/2.8s-UTK) id AA02624; Wed, 23 Jun 93 23:31:28 -0400
Received: from by id aa27572; 23 Jun 93 23:32 EDT
Received: from ([]) by (4.1/SMI-4.1) id AA27071; Wed, 23 Jun 93 23:32:12 EDT
Received: from yeti.ctron by (4.1/SMI-4.1) id AA09336; Wed, 23 Jun 93 23:32:02 EDT
Received: by yeti.ctron (4.1/SMI-4.1) id AA02617; Mon, 21 Jun 93 12:48:27 EDT
Message-Id: <9306211648.AA02617@yeti.ctron>
To: Andrew Bierman <>
Subject: Re: comments on latest draft...
In-Reply-To: Your message of "Fri, 18 Jun 93 15:40:22 PDT." <9306182240.AA11623@donatello>
Date: Mon, 21 Jun 93 12:48:25 -0400
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: "David L. Arneson" <>

It's good to see a bit more activity on the list.

>I have been trying to evaluate the chassis MIB with the following
>   1) Could I implement this MIB on the assortment of platforms
>      and devices I have to support?
>   2) Could I use this MIB to effectively manage all of these 
>      devices? 
>short answer:
>   1) yes -- with a great deal of effort. But it won't be pretty
>      mapping existing management structures to the "resource/entity"
>      model
>   2) no -- there are too many abstractions and not enough real
>      information to manage an arbitrary entity or physical resource.
>long answer:
>      I think the MIB will end up being used to find out what's in a 
>      chassis, and enough information about each "thing" to point to 
>      the "real" MIB used to manage that "thing". (This is a feature, not a bug.)
>      I don't think the MIB needs to provide control of every "thing"
in the chassis.
>      The MIB provides detailed inventory information that in itself is
>      useful to generic NMS applications. I envision an app using
>      the MIB to find out what entities are present on what modules...
I tend to agree with you.  Yes some people may be able to switch their
repeaters from one network to another.  However trying to do that in
the chassis MIB tends to make this MIB somewhat unusable.

>      A user might click on a bridge icon shown on some sort of
>      front panel display, generated from the chassis MIB inventory
>      data, and the app might use the bridge MIB (not the chassis MIB) 
>      to find out about the configuration of the bridge and all of its ports,
>      in order to display a new management screen for the bridge.
>      It's hard for me to comment on individual objects when I 
>      don't agree with the goals established for this MIB. 
>      I think it's enough to provide the inventory and 
>      "common chassis" support (e.g. fans, PS, sensors)
>      in a standard MIB. (So I'll reserve my comments on
>      chasModuleAdminStatus and chasEntityAdminStatus
>      until I see if anyone agrees with me ;-)
>      I suppose this doesn't matter because an Agent can disallow
>      setting of the adminStatus objects, but I think it will take 
>      a great deal of effort to reach closure on these objects.
I guess I like the ability to disable an entity at this level.  By doing
this I can control when that device is a bridge, when it is a router etc.
This is something that can be done from the entity specific MIBs but the
central control is nice.

Now if the admin status objects cause a major stumbling block I'm willing
to let them die off.

>      Thanks mostly to the work of the four previously mentioned 
>      participants, there is a workable model (albeit complicated)
>      for representing the logical and physical parts of a chassis (assuming 
>      that many:many entity-resource mapping is added in some form).
So you support the many to many mapping that has been proposed.  I do tend
to belive that this tends to be a bit more usable.
>      Since an NMS app could ascertain all of the logical chassis
>      information simply by fishing for SNMP agents, and then fishing 
>      for MIBs on each agent, one unique capability of the chassis
>      MIB is providing the logical to physical mapping of each entity.
>      And I think this MIB can do that. Plus you get power-supply
>      info thrown in for free.
I think the MIB view information that is being supplied is also very
useful.  The different modules that make up a chassis may be managable
on their own and given that it is very useful to have a central collection
point for that information.

>      However...
>model bash:
>      In general, I believe it will require great effort to map existing
>      (and even new) products into this model. Knowing what all the
logical and physical 
>      resources are for each entity and card will be hard enough, but 
>      actually managing things via this model will be even harder. 
>      And I'm not sure it's worth it...if I want to manage bridge ports
>      I will use the bridge MIB, and use the repeater MIB for repeater ports.
>      In fact, for just about any "thing" that can be a resource or entity,
>      that "thing" will be more accurately managed via a MIB designed
>      for just that purpose, than with the chassis MIB. And that MIB will
>      probably be easier to implement than the chassis MIB.
>      I think I already know the answer to this question, but is there a way
>      to make the resource tables optional, and still be able to associate
>      logical entities with their physical location within the chassis?
I tend to agree that if I'm going to play games switching bridge ports
or any of the possible resource entity connections that I would rather do
this from the entities specific MIB.  This then implies that those objects
that control this operation are read-only.

Actually that may not be that bad.  No I don't think that we can
use the logical to physical view that resources buy us.  However there
may be a solution to the problem.  The only problem with this is that
we actually provide 2 differnt models within the same MIB.  I'm not sure
that is the best form.  I will throw this out for consideration.

Consider breaking the configuration group into a physical config group
and a logical config group.

The physical config group would be optional and provide a table similar
to this:
		INDEX { Physical location type index,
		        physical location,
			entity ID }
This would provide a basic brute force approach to perform the mapping of
entities onto physical modules.  It provides no information on how that
is accomplished it just resolves the mapping for you.

The logical config group would also be optional and would be basically
what is currently proposed:
	chasResourceTable - Lists all resources within the chassis
	chasLogConfigTable - The many to many mapping between modules,
		resources and entities that has currently been proposed.

Well its a thought perhaps I can edit the existing draft with some of
these ideas so people can see some of the proposals in more detail.

/David Arneson