Re: Chassis MIB comments

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

I will reply to this because I think I understand what they are asking
for and agree with it.  If I'm incorrect I'm sure I will be corrected.

Some deleted

>
>Originally there was only one table, effectively 'chasPhyResourceEntry'. The 
>index on this table enabled querries such as 'tell me all the resources on 
>module X'. At the IETF in Columbus concern was expressed that an entity to 
>resource mapping could only be performed by scanning each row of the 
>resource table and comparing the entity number. It was decided that adding a 
>seperate 'logical' resource table so 'tell me all the resource currently 
>assigned to entity Y' could be optimised. The information in the two tables 
>is basically the same, we are simply getting the agent to provide two 
>seperate views.
>
I got a different view from this:
	I think they wanted 1 table that identifies resources perhaps
	a better name would be chasResourceTable.  This would be similar
	to the MIB that I published to the list shortly after the IETF.

	Then Chris proposes the many:many mapping table.  This may not
	be so much a logical resource table but a configuration table.

This is all just semantics.

>Do have have a particular concern with the indices on the two tables?
>
>>2.  If the chasLogResourceTable consisted of 4 indices:
>>    chasLogResourceEntityIndex, chasLogResourceModuleTypeIndex,
>>    chasLogResourceModuleLocation and chasLogResourceResourceIndex,
>>    the table would provide a many-to-many mapping for
>>    resource/module/entity mapping.
>
>For simplicity I think its best to keep the relationship from resource to 
>entity one to one (or many resources to a single entity). Many of the 
>problems with the old proposal was the complex relationships between 
>modules, segments and entities. A couple of problems with the many to many 
>relationship:
>
I'm not convinced that this many:many mapping is that much more complicated.

>1) It is necessary for this MIB to support the dynamic configuration of 
>resources between entities. For example I can through management move a card 
>from one repeater to another. Such a feature is available in products now so 
>the MIB must handle it. The current proposal allows the entity assignment 
>column in chasPhyResourceTable to be writable. Change the assignment and the 
>resource 'moves'. Now in a many to many mapping a resource can map to more 
>than one entity. This means at least that your proposed change to the phy 
>table requires a some assignment 'instance'. Then the question is how many 
>assignments? Can the number of assignments be increased dynamically, ie row 
>creation in the resource table as well as the entity table?
>
I'm not sure why they have precluded moving a repeater from one card to
another.  Granted now it requires building a new conceptual row in the
configuration table as opposed to your system of just setting an object
but this is not a major hit in my book.

>2) Why do we need a chassis MIB? In a later mail someone suggests that the 
>'brouter' model defeats the object of the chassis MIB. Why? The reasons we 
>need a chassis MIB are ...... fold. Firstly to provide a physical inventory 
>of a generic chassis. Secondly the chassis is a container of what would 
>otherwise be seperate physical devices, that is entities. I think the 
>requirement on the chassis MIB ends at identifying those devices that would 
>otherwise be free standing. Thirdly to provide the access method for each 
>logical device.
>
If I understand the last part of this correctly then it would seem that
the chasPhyLocationTable, chasModuleTable and chasEntityTable where the
entity table contains a object that defines which module the entity resides on.
This would be the easiest model we have yet had.  It would be an answer
for a part of our needs.  Perhaps the entire resource idea can be scrapped.
Is this waht you are implying with the last part of the above statement?

>Manu suggests that modelling a bridge and router as seperate entities is a 
>requirement. Compare the chassis with the physical analogy. Either there 
>will be seperate bridge and router boxes on the network or there will be a 
>single box performing both a bridging and routing function. In the first 
>case the chassis map requires resources of bridge ports, bridge relay, 
>router ports and router relay. In the latter case there are 'network' ports 
>and a brouter relay. Both can be mapped using the existing model with a many 
>resource-to-one-entity relationship.
>
The one thing I never liked about the brouter component was that it forced the
bridge and router into a single MIB view.  The view table mentioned below 
would help here but I'm not sure it is the full answer.  We still don't allow
the ability to disable the router and not the bridge as would be allowed by
chasEntityAdminStatus if the two were different entities.  Now we have
just such a beast in house.  The bridge and the router may use the same
interfaces however there are instances where I would like to disable the
bridge and not the router the chassis MIB can allow for this functionality.
It does however require the many to many mapping.

>>3.  If the access profile information was removed from the
>>    chasLogResourceTable into a view table, it would allow more than 1
>>    view to be defined for each mapping.
>
>Yes. I think the whole access part of the MIB has to be rethought. From some 
>other comments recently it may even be better to have an SNMPv2 view table 
>and an SNMPv1 table where only the table appropriate to the protocol is 
>provided.
>
>Pete

This multiple view problem came up before on the list.  I propose one of
the following solutions to fix this problem:

1 view table defined as follows:
	INDEX (EntityID, ViewIndex)
	Table to contain IPaddress, community string, context

The second option would be two tables as follows
	SNMPAccessTable
	INDEX (entityID, viewIndex)
	Table contains IPaddress, community string

	SNMPv2AccessTable
	INDEX (entityID, viewIndex)
	Table contains SNMPv2 context (the context should be sufficient to
		determine how to communicate with the entity).

This second option is what Pete suggested above.  Does anybody else have
any suggestions on the view problem?

/David Arneson