Re: Chassis MIB

["David L. Arneson ([e-mail])" <[e-mail]>]

>Date: Mon, 7 Dec 92 09:25:48 GMT
>From: [e-mail] (Niels Ole Brunsgaard)
>Message-Id: <[e-mail]>
>To: [e-mail]
>Subject: Chassis MIB
>X-Charset: ASCII
>X-Char-Esc: 29
>
>
Sorry about the delay I'm trying to to ten things at once and only getting
7 done.
>
>1) chasConfigTable
>
>How exactly does this table work ?. I see (at least) 2 implementations.
>
>	a) The table contains only those relationships that actually exist. 
>	Rows are created/deleted by a set of chasConfigStatus.
>
>	b) The table contains all valid relationships. chasConfigStatus
>	indicates which are currently in use and which are not.
>
>Option b) makes visible all potential configurations. Using a), how 
>would a manager know if a specific slot was able to attach to a specific
>segment ?.
>
I would have the say that option a) is the correct view.  We could get into
trouble if we attempt to deal with segments for entities that are currently
disabled.

>In either case, why are chasConfigSlot, chasConfigEntity and chasConfigSegment 
>read-write and not read-only ?. Using option b), these objects are determined
>by the HW present in the chassis. Using option a), these objects are set
>implicitly when the manager creates a row by setting chasConfigStatus to 
>valid(1).
>
We have discussed this at length in the past.  The reason for read/write was
to allow for control switching backplane segments.  It is rather vendor
specific some can do this many can not.  You may want to check the archives
for more information.

>Am I missing something ?.
>
>2) Double segment attachments.
>
>Someone pointed out the problem of having one specific slot host 2
>connections to the same segment. This is a severe limitation
>on switched ethernet and on ATM. On these medias, a single entity could
>increase the bandwidth of its network connection by having multiple
>connections to the same network.
>
>This is a severe limitation. We just can't design a MIB with such an
>obvious flaw. 
>
Yes we ned to clean this up.

>3) chasConfigIndexType
> 
>Imagine a combined repeater/bridge entity that takes up one slot and
>attaches to one segment. Thus it has one entry in the chasConfigTable.
>Does chasConfigIndexType point to an interface or a repeater port in 
>this case ? It seems to me that there should be an instance of 
>chasConfigIndexType for each function defined in chasEntityFunction.
>
This has been discussed in some length as well.  I myself feel that an
entity should have a single function then the problem goes away.  Things
just seem alittle more nature that way.  However I guess the view taken
is that this would call out the bridge.

>4) chasConfigIndexValue
>
>If the entity in question is a repeater with multiple ports per
>segment (fairly typical I guess), which port instance does
>chasConfigIndexValue reference ?.
>
I don't think it makes a difference.  All the ports are on the same segment.
>
>
>	Niels Ole Brunsgaard
>	Cray Networks A/S
>	Copenhagen, Denmark.