Re- Comments on Chassis Mib
eah <eah@pau.synnet.com> Tue, 29 June 1993 23:43 UTC
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa15163; 29 Jun 93 19:43 EDT
Received: from CS.UTK.EDU by IETF.CNRI.Reston.VA.US id aa15159; 29 Jun 93 19:43 EDT
Received: from localhost by CS.UTK.EDU with SMTP (5.61+IDA+UTK-930125/2.8s-UTK) id AA25748; Tue, 29 Jun 93 19:08:24 -0400
X-Resent-To: chassismib@CS.UTK.EDU ; Tue, 29 Jun 1993 19:08:23 EDT
Errors-To: owner-chassismib@CS.UTK.EDU
Received: from pau.synnet.com by CS.UTK.EDU with SMTP (5.61+IDA+UTK-930125/2.8s-UTK) id AA25740; Tue, 29 Jun 93 19:08:20 -0400
Received: from mailgate.synnet.com by pau.synnet.COM (5.64/1.34) id AA24077; Tue, 29 Jun 93 19:05:08 -0400 (EDT)
Message-Id: <9306292305.AA24077@pau.synnet.COM>
Date: Tue, 29 Jun 1993 19:09:29 -0000
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: eah <eah@pau.synnet.com>
Subject: Re- Comments on Chassis Mib
To: arneson@ctron.com, kaycee@andr.ub.com
Cc: chassismib@cs.utk.edu
Subject: Time:6:58 PM OFFICE MEMO Re: Comments on Chassis Mib Date:6/29/93 This is going to be a rather long comment, so I apologize in advance for the length. I've been going over the current draft, and noticed something that I believe actually existed before this draft. The text of the draft on page 4 states: "A chassis can be thought of as a hierarchical relationship of one or more "physical locations", each physical location containing one or more physical modules, and where a physical module, or combinations of physical modules, might perform one or more network device functions. The relationship between physical location and physical module can be many to many." The actual mib, however, really only supports a one:many mapping for physical location to physical module. The current chasModuleTable only allows a reference to one physical location, but many modules may refer to the same physical location. The question is do we need a many:many mapping between physical locations and physical modules. I think we do. Consider the hypothetical case of a chassis which supports half slot modules (where two half slot modules may occupy the same slot simultaneously), single slot modules, and dual slot modules. If we use the current mib to represent a chassis containing each of these modules, we need two different location types, a single slot location type (for the half slot and single slot modules), and a dual slot location type for the dual slot modules. We also need to be able to determine what "type" a location is based on what type of module occupies it, rather than being able to determine it in advance. On the other hand, if the mapping is represented as many:many, the chassis locations can be described in terms of the more natural, single slot location type. Based on the above, and the comments from Dave Arneson and Mahendra J. Kaycee regarding the mappings I mentioned in my previous comments, below are some suggested changes to the current (June 24) draft: - Remove chasModuleLocationTypeIndex and chasModuleLocation from the chasModuleTable into a separate table, and re-instate the unique chasModuleIndex for each module: chasModuleTable chasModuleIndex chasModuleType chasModuleFwVersion chasModuleHwVersion chasModuleSerialNumber chasModuleDescription chasModuleLastChangeTime chasModuleAdminStatus chasModuleOperStatus - Add the following table to the chasPhysical group: chasModuleToLocationTable chasModuleToLocationModuleIndex chasModuleToLocationTypeIndex chasModuleToLocationLocation - Add the following table to the chasEntity group: chasEntityToModuleTable chasEntityToModuleEntity chasEntityToModuleModule - Change the chasResourceTable definition of chasResourceIndex to refer to a resource type as opposed to a specific resource, and add a chasResourceCount object to that table (basically handle this table similarly to the way the physical location table is handled so that there is one entry per "resource type"): chasResourceTable chasResourceIndex chasResourceType chasResourceCount - Add the following tables to the chasResource group: chasResourceToLocationTable chasResourceToLocationResourceTypeIndex chasResourceToLocationResource chasResourceToLocationLocationTypeIndex chasResourceToLocationLocation chasModuleToResourceTable chasModuleToResourceModule chasModuleToResourceTypeIndex chasModuleToResourceResource chasEntityToResourceTable chasEntityToResourceEntity chasEntityToResourceTypeIndex chasEntityToResourceResource - Change the chasPhyConfigTable to include a chasPhyConfigModuleID , and change the chasPhyConfigResourceID into two objects - chasPhyConfigResourceTypeIndex, and chasPhyConfigResourceIndex: chasPhyConfigTable chasPhyConfigLocationTypeIndex chasPhyConfigLocationIndex chasPhyConfigModuleID chasPhyConfigResourceTypeIndex chasPhyConfigResourceIndex chasPhyConfigEntityID - Change the chasLogConfigTable to include a chasLogConfigModuleID, and change the chasLogConfigResourceID into two objects - chasLogConfigResourceTypeIndex and chasLogConfigResourceIndex: chasLogConfigTable chasLogConfigEntityID chasLogConfigResourceTypeIndex chasLogConfigResourceIndex chasLogConfigModuleID chasLogConfigLocationTypeIndex chasLogConfigLocationIndex >>As for the problem with multiple mib views, personally I would prefer to >>have a "single entry point" to some entity's mib which allowed me >>to see what views are available for that particular entity. I would >>much rather see something along those lines, than have every view for >>every entity included in the chassis mib. > >How do you like the MIB view table that I currently have in the draft?> > > Ed Heiner > >/David Arneson I guesss what I was trying to say was rather than having a table of information about views for each entity, simply provide a single transport domain/transport address/community combination for V1 implementations that provides access to the view information for the V1 entity, or a single transport domain/transport address/dstParty/context combination for V2 implementations that could provide access to the context and view tables for the particular V2 entity. IMHO, having a whole table provides little benefit, since the entries don't actually identify what's available to each view (the management application still has to query the specific entity to determine what mib subtrees/objects are available to a given view). Ed Heiner
- Re- Comments on Chassis Mib eah
- Re: Re- Comments on Chassis Mib David L. Arneson
- Re: Re- Comments on Chassis Mib Steve Horowitz
- Re: Re- Comments on Chassis Mib M J Kaycee