RE: mapping between entities and resourc

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

Microsoft Mail v3.0 IPM.Microsoft Mail.Note
From: Wilson, Peter
To:  Chassis MIB
Cc:  Heads, Bob
     Woodruff, Paul
Subject:  RE: mapping between entities and resources..
Date: 1993-04-14 08:33
Priority: 
Fixed Font: 0001
Message ID: 3C36B0A5
Conversation ID: 3C36B0A5

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

There was quite a lot of discussion about this at the IETF. I think everyone 
agreed that that allowing a single resource to be part of a single entity 
simplifies the model considerably. I don't think this is actually a 
limitation as you suggest, merely a mis-interpretation of the model. A 
resource can be anything appropriate to a particular chassis/module. The 
example raised in the meeting was of a simple 2 port bridge between 2 
backplane Ethernets. In the model the resource of the bridge were:

	slot.mod.1	repeater port 1
	slot.mod.2	repeater port 2
	slot.mod.3	bridge

The repeater ports belong to the repeater entities, the bridge to the bridge 
entity. This extends perfectly to a bridge/router. Either the bridging and 
routing function are seperate entities or a single 'brouter' entity:

1) Seperate enities.
resources:	slot.mod.1	repeater port 1	assigned repeater 2
		slot.mod.2	repeater port 2	assigned repeater 1
		slot.mod.3	bridge		assigned bridge
		slot.mod.4	router		assigned router

entities:		repeater 1
		repeater 2
		bridge
		router

2) Single 'brouter' entity
resources:	slot.mod.1	repeater port 1	assigned repeater 2
		slot.mod.2	repeater port 2	assigned repeater 1
		slot.mod.3	brouter		assigned brouter
entities		repeater 1
		repeater 2
		brouter

Remember that the entity table provides access to the agent/context that 
actually manages that entity. In many cases the bridge and routing function 
are managed from by the same agent and so the 'brouter' entity is more 
natural. Managing the interfaces of the bridge is done throught the bridge 
agent, not the chassis MIB. Note that the concept of a bridge card having a 
logical repeater port into a backplane 'repeater' was borne out in seperate 
discussion during the repeater management meeting.

Unfortunately you missed out on some interesting discussion about what the 
model should be describing or managing. My view, for which there was a fair 
amount of support is as follows:

A chassis is a replacement for a number of discrete devices, bridges 
repeaters etc. The advantages of the chassis concept are two fold: all the 
devices are collected into a single chassis; the devices are 'logical' 
rather than hardwired and so new devices can be 'created' by redistributing 
components in the chassis. It is these two aspects of the chassis that it is 
important to manage.

The current proposal does not include 'topology' information. That is there 
is no information to indicate how the various entities in the chassis are 
interconnected. In the example above the fact that repeater ports 1 and 2 
connect to the bridge/router. This is fine. Think about the implementation 
of the same bridge and repeaters using discrete components:

                       bridge
                        |  |
                  port 1|  |port 2
               +--------+  +----------+
               |                      |
         port x|                      | port y
           repeater1             repeater 2

From a management station the topology is not known.

There was some interest in including this information in the chassis MIB but 
it was agreed that it should not be part of the module/resource/entity 
tables. Overloading these tables with extra functionality complicates the 
model un-necessarily. If this were required it would be handled by a 
seperate topology group in the MIB.

In Summary
==========
The model as discussed in Columbus can adequately describe the brouter 
device.

Everyone was tasked with going away and applying the model to their own 
devices to check for situations that can't be modelled. If you find 
something you think breaks the model then let me know and I'll try it.

I volunteered to produce a set of examples to illustrate the model. This I'm 
working on and will distribute shortly.

Apologies for the length.

Pete

>A recent note sent to the authors of the current chassis mib draft, amongst
>other things, raised the issue of mapping between entities and resources.
>It questioned the agreement reached at the recent IETF meeting, in that
>multiple entities could not be mapped to (associated with) a single 
resource.
>For example, if interfaces were a resource, and a bridge entity and a 
router
>entity resided on the same module, then the current association model did
>not support the fact that bridging and routing could occur over the same
>interface.
>
>I was not at the last IETF, but it seems to be quite a limitation, if our
>model is not able to represent a very common configuration.  I spoke with a
>co-author, who ensured me that this was the case.
>
>I suggest that we allow (as my co-author defines it, and agrees with me) a
>many-to-many mapping between resources and entities, which would include
>mapping many entities to a common resource.
>
>BTW, would this also not be required if two different entities on two
>different modules were interconnected by a common interconnect
>medium (resource)?