Re: Interface Table
kzm@hls.com (Keith McCloghrie) Wed, 09 September 1992 05:52 UTC
Return-Path: <owner-chassismib>
Received: by CS.UTK.EDU (5.61++/2.8s-UTK) id AA11982; Wed, 9 Sep 92 01:52:47 -0400
Received: from LANSLIDE.HLS.COM by CS.UTK.EDU with SMTP (5.61++/2.8s-UTK) id AA11978; Wed, 9 Sep 92 01:52:43 -0400
Received: from nms.netman (nms.hls.com) by lanslide.hls.com (4.1/SMI-4.0) id AA25348; Tue, 8 Sep 92 22:52:55 PDT
Received: by nms.netman (4.1/SMI-4.1) id AA03097; Tue, 8 Sep 92 22:51:13 PDT
From: kzm@hls.com
Message-Id: <9209090551.AA03097@nms.netman>
Subject: Re: Interface Table
To: rlstewart@eng.xyplex.com
Date: Tue, 08 Sep 1992 22:51:13 -0700
Cc: chassismib@cs.utk.edu
In-Reply-To: <9209081852.AA20485@xap.xyplex.com>; from "Bob Stewart" at Sep 8, 92 1:52 pm
Organization: Hughes LAN Systems
X-Mailer: ELM [version 2.2 PL0]
I believe that several messages ago Bob succinctly summarized the issues on this topic as: utility, ubiquity, and a good MIB definition. In his latest message, Bob said: > Dave says we need specific information to map internal segments to > interfaces/ports. I agree. Well, the three of us seem to agree on the utility. > We seem to have a bit of technical difficulty > with a table that will clearly specify that mapping for all types of > relationships (beyond MIB-II interfaces). So far the technical solution that > seemed closest to correct was what Keith suggested. Just recognizing that > difficulty is sufficient without discussing the solution at the moment. I think the technical difficulty is because of trying to make a separate table out of this information. If you recall, my suggestion was to add 2 more columnar objects (indexType and indexValue) within the chasConfigTable, without changing its indexing. This obviates the indexing problems of the additional table. Also the definition of indexType as an OBJECT IDENTIFIER provides not only for interfaces, but for repeater ports as well. (Note that in retrospect, I think that ifIndex values are the appropriate type/values for bridge ports, but I'm willing to be convinced otherwise.) So, I would like to repeat my suggestion that we consider just adding these 2 objects to the chasConfigTable. > I do not agree that this information HAS to be in the Chassis MIB. If the > Chassis MIB tells me what entities are in the chassis and how to find them, > that is sufficient, on the assumption that those entities MUST know how they > are configured relative to the chassis. I would not expect them to depend on > the Chassis MIB for their individual configurations. In fact, they can't > because (I believe) we decided the information would be read only. The > difficulty we're having in defining this information indicates to me that the > solution may be too dependent on the type of entity. I think you are, in effect, suggesting that the information belongs in the entities' MIBs, rather than in the Chassis MIB. I don't agree for two reasons: 1) to have them in the entities says they have to be effectively in MIB-II, and applicable to every device; and, 2) I think the only way to ensure a common numbering scheme for the segments is to have the information centralized in the Chassis MIB (i.e., I think it's harder to get the segment numbers into the individual devices, than to get the index types/values into the Chassis MIB.) On the question of ubiquity, I have seen a number of people's messages suggesting they could implement indexType and indexValue and supply them with values, at least in most cases. Equally, I'm sure there are those who cannot supply values. This is why I suggested that indexType (as an OBJECT IDENTIFIER) could have a few well-known values (e.g., unKnown), which are perfectly compliant, so as not to penalise those who cannot obtain the specific type/value. As such, there is no need to make these objects optional. So, if some number of people can fill in specific values and everybody can fill in compliant values, then I claim there is ubiquity. The worst case scenario (none of Jeff's relations!!) would be if implementation experience later shows that everybody fills in non-specific values, then we deprecate these objects at that time. So, if at least some of you were to agree that my indexType/IndexValue suggestion was sufficient to qualify as a good MIB definition, then I think we've got a solution. Is this wishful thinking ? Keith.
- Interface Table David L. Arneson (arneson@ctron.com)
- Re: Interface Table Bob Stewart
- Re: Interface Table David L. Arneson (arneson@ctron.com)
- Re: Interface Table Bob Stewart
- Re: Interface Table Keith McCloghrie