RE: Chassis MIB comments

[Manu Kaycee <[e-mail]>]

Pete,

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

I'm sure Chris will address you comments, so I'll save specific object-related
details for later.  Let's address and sort out some of the larger issues.

> 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:

It still is rather complex, but most of us agree in that it could be
simplified.
 
> 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'.

In this example, per the mib semantics, you are remapping a module between
entities, and doing so by remapping all of its applicable resources.  A
modified chasLogResourceTable, as Chis suggests, would also provide the same.
Admittedly, since resources are being bound to entities, such a control
should be via the chasLogResourceTable, instead.

> 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?

Depends on the number of entities to which a resource is mapped.

> Can the number of assignments be increased dynamically, ie row 
> creation in the resource table as well as the entity table?

We may want to keep in mind that these apply regardless of whether the
mapping of entities to resources is many-to-one, or one-to-one.

 
> 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.

We all agree that a chassis MIB would be most useful.  To keep the discussion
on track and in perspective, let me state again that some of us are
concerned about the existing mapping model; which does not mean that a chassis
MIB is useless...far from it.  As you state, we want to be able to provide
access methods for each individual logical device.  Bridges and routers, for
example, are logical devices: "brouters" are two or more logical devices that
overlap spatially.  More below...

> Manu suggests that modelling a bridge and router as seperate entities is a 
> requirement.

Not quite, but I'll go along.  More below...

> 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.

In the first case (separate bridge and router boxes), there is no spatial
overlap and, therefore, separate resources.  In the second case (single box),
there is spatial overlap and, therefore, shared resources.  Now one may
call it a "brouter".  But this "brouter" performs separate relay functions:
bridging and routing.

As you yourself indicate above, "I think the requirement on the chassis
MIB ends at identifying those devices that would otherwise be free
standing."  Doen't this mean that, though they may overlap spatially, they
are separate, and should be identified as such?


mjk