One more go at the many-to-many mapping

{3COM/PDD/PeteW} Wed, 07 July 1993 18:30 UTC

Received: from by IETF.CNRI.Reston.VA.US id aa10251; 7 Jul 93 14:30 EDT
Received: from CS.UTK.EDU by IETF.CNRI.Reston.VA.US id aa10247; 7 Jul 93 14:30 EDT
Received: from localhost by CS.UTK.EDU with SMTP (5.61+IDA+UTK-930125/2.8s-UTK) id AA13100; Wed, 7 Jul 93 14:02:54 -0400
X-Resent-To: chassismib@CS.UTK.EDU ; Wed, 7 Jul 1993 14:02:53 EDT
Errors-To: owner-chassismib@CS.UTK.EDU
Received: from gatekeeper.3Com.COM by CS.UTK.EDU with SMTP (5.61+IDA+UTK-930125/2.8s-UTK) id AA13090; Wed, 7 Jul 93 14:02:50 -0400
Received: from gw.3Com.COM by gatekeeper.3Com.COM with SMTP id AA22355 (5.65c/IDA-1.4.4-910725 for <>); Wed, 7 Jul 1993 11:02:47 -0700
Received: by gw.3Com.COM id AA06918 (5.65c/IDA-1.4.4 for; Wed, 7 Jul 1993 11:02:46 -0700
Date: Wed, 7 Jul 93 18:59 PDT
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: {3COM/PDD/PeteW}
Subject: One more go at the many-to-many mapping
Message-Id: <930707.110126@3Mail.3Com.COM>
Msg-Date: 1993-07-07
Msg-Time: 18:56

Microsoft Mail v3.0 IPM.Microsoft Mail.Note
From: Wilson, Peter
To:  Chassis MIB
Subject:  One more go at the many-to-many mapping (resource/entity)
Date: 1993-07-07 18:52
Fixed Font: 0001
Message ID: 8AFF2C93
Conversation ID: 8AFF2C93


I want one last attempt to persuade everyone that the many-to-many maping is 
NOT required before I have a go at merging the many-to-many MIB with the 
configuration requirements that it does not currently meet :-)

The sticking point seems really to be the bridge/router card so I'll use 
this for illustration purposes. Some assumptions:

 - The chassis MIB only provides configuration reporting and chassis type 
configuration control
  (ie moving a port to a different repeater).
 - This means ALL bridge or router control is provided by the MIB for that 
kind of device, NOT the
  chassis MIB.
 - As an example a bridge/router card comprises:
	- A bridge element with its own MIB.
	- A router element with its own MIB.
	- 2 bridge ports through which bridge traffic is forwarded
	- 2 router ports through which router traffic is forwarded
	- 2 physical _repeater_ ports onto backplane Ethernets. The
	  internal bridge and router ports share these ports for traffic.
	- The chassis MIB allows the _physical_ ports
	  to be switched to one of 3 ethernet segments.
 - The bridge/router ports are unimportant as far as the chassis MIB is 
concerned, they are entirely
  encapsulated in the specific MIB.

Now in this situation the resource table contains the following entries for 
this card:

Resource 1:	Repeater Port
Resource 2:	Repeater Port
Resource 3:	Bridge Relay
Resource 4:	Router Engine

The entities that exist in this chassis are:
Entity 1:	Repeater, backplane 1
Entity 2:	Repeater, backplane 2
Entity 3:	Repeater, backplane 3
Entity 4:	Bridge
Entity 5:	Router

Now when the bridge/router card is connected to ethernet backplanes 1 and 2, 
the resource to entity mapping is as follows:

Resource 1:	Repeater Port		Entity 1
Resource 2:	Repeater Port		Entity 2
Resource 3:	Bridge Relay		Bridge
Resource 4:	Router Engine		Router

This information allows the view of each entity to be obtained and so the 
system can be managed.

There are a couple of important features of this example which should be 
1. Resource to Entity mapping is one to one!
2. Allows a simple way of switching one of the ports to one of the 
3. Does not use a 'brouter' entity.

One question raised at the Columbus meeting was:
	'I don't no to which repeater port bridge interface 1 is connected'

This was discussed at considerable length and the conclusion was that while 
this is useful information:
a)	By analogy this information would not be available in
	a MIB if the repeaters and bridges were not in a chassis.
b)	This is a general network topology issue that cannot be answered
	by the chassis MIB.
c)	It wasn't worth complicating the proposal by overloading these
	tables with topology information. If this to be covered by this
	MIB then a sensible place is to create a seperate MIB group
	with a topology table.

A lot of the many to many map seems to be trying to answer this last point, 
and everything just gets too complicated. Leave the existing tables alone 
and deal with the topology elsewhere.

eg a 'interconnection link' table:
		thing-X, interface 1	'connects to'	thing-Y

It is actually possible to generate such a table that is generic enough not 
to be restricted to a chassis and so could help the general topology 
problem! I'll try to put together a fairly simple example MIB section you 
may like to think about.

The simple mappings _can_ be used to describe any chassis configuration 
provided the tables are not overloaded with too many different concepts. 
Keep the basic tables one-to-one (resource-entity) and one-to-one (resource 
to module). If you want to map the interconnection of logical devices in 
your chassis then a different MIB group should be proposed. Remember ISO try 
to have one solution that does everything! If we try to we'll never 

I would like to propose that the simpler version of the MIB be presented to 
the IETF as a draft standard and that if people want additional information 
we can add that information in a later version as seperate groups.