RE: Chassis MIB comments

[{3COM/PDD/PeteW}@pdd.3mail.3com.com]

Microsoft Mail v3.0 IPM.Microsoft Mail.Note
From: Wilson, Peter
To:  Chassis MIB
Subject:  RE: Chassis MIB comments
Date: 1993-06-11 16:10
Priority: 
Message ID: 7247F3CE
Conversation ID: 7247F3CE

------------------------------------------------------------------------------

Chris,
here are some comments on your comments:-) I've also answered some points 
raised by Manu in response to your message.

>    Should the chasPhyResourceTable provide mapping information or
>    just provide a list of all resources in the chassis?  I suggest
>    that the mapping should be done by the chasLogResourceTable and
>    that chasPhyResourceEntry be a flat list of resources as follows:
>
>              chasPhyResourceEntry  OBJECT-TYPE
>              SYNTAX  ChasPhyResourceEntry
>              ACCESS  read-only
>              STATUS  mandatory
>              DESCRIPTION
>                      "Defines a particular resource."
>              INDEX { chasPhyResIndex }
>              ::= { chasResourceTable 1 }
>
>          ChasPhyResourceEntry ::= SEQUENCE {
>              chasPhyResIndex
>                  INTEGER,
>              chasPhyResType
>                  OBJECT IDENTIFIER
>	      }
>

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.

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:

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?

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.

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.

>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