Re: The future

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

Microsoft Mail v3.0 IPM.Microsoft Mail.Note
From: Wilson, Peter
To:  Moran, Paul
     Woodruff, Paul
     IETF-Chassis MIB
Subject:  Re:  The future
Date: 1992-12-17 12:01
Priority: 
Fixed Font: 0001
Message ID: 7CCB12A5
Conversation ID: 7CCB12A5

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

First -
I apologise for the length of this message.

>> I do have a couple of concerns I wanted to bring up.  First I'm not sure 
we
>> want to delete the concept of the segment that an entity is connected to.
>> I feel that we can view segment as either backplane segment or backbone,
>> rib etc in a more general sense.  I feel the information is useful
>> to have in this MIB.
>
>I totaly agree with this view, the segment table and the configuration 
table
>are most helpful specially when trying to use the chassis MIB to describe a
>"logical" chassis rather then the traditional one.

I don't think I removed the ability of the MIB to model the concept of a 
'segment'. I really just wanted to simplify the relationships between 
'things' in the chassis. Instead of treating a segment as a seperate thing I 
asked the question 'why is a segment different from a component of anything 
else? It is simply a component that _may_ be needed to construct a 
particular entity in some architectures. For example a chassis has a 
backplane that contains three 802.3 'segments'. Another architecture may use 
a central repeater builder card. Every repeater card connects to every 
repeater builder. The concept of segment is confusing in this instance. The 
repeater entity is important. In a logical chassis what is the analogy to a 
segment? I can't really think of one and if I could I think I'd be hard 
pressed to explain why it isn't a component of some module.

Example: The chassis contains two cards. Each card contains 12 ports. Each 
port is a component of the card it is on. Any port can connect to any 
'segment' Suppose all odd ports are on segment 1, all even ports on segment 
2. In my model

phyLocationTable
locationType    Location     Contents
Backplane       1            'Standard Backplane'
ModularSlot     1            '12 Port Switchable Card'
ModularSlot     2            '12 Port Switchable Card'

entityTable
Index     Type
14        Repeater	; Index chosen for example
20        Repeater

componentTable
location     index       Type       Assignment
Backplane.1     1        802.3      Entity 14
Backplane.1     2        802.3      Entity 20
Backplane.1     3        802.3      Entity 0    ; Not currently used
ModularSlot.1   1        802.3      Entity 14
ModularSlot.1   2        802.3      Entity 20
ModularSlot.1   3        802.3      Entity 14
ModularSlot.1   4        802.3      Entity 20
...
ModularSlot.2  12        802.3      Entity 20

The old MIB couldn't actually represent this model because the 3-way 
relationship was between module, entity and segment.Assume this were 
enhanced to be 4-way between module, sub-module, entity and segment. The 
equivalent tables in the old MIB would then be:

phyTable
Slot            Contents
1            '12 Port Switchable Card'
2            '12 Port Switchable Card'

entityTable
Index     Type
14        Repeater	; Index chosen for example so as not to be same as
20        Repeater      ; segment index.

segmentTable
Index     Type
1         802.3
2         802.3
3         802.3

mappingTable
module  subindex  entity   segment
1        1         14        1
1        2         20        2
1        3         14        1
1        4         20        2
...
2       12         20        2

Now this is a complex and doesn't store any information about things 
currently unused, for example segment 2. Neither can one simply change the 
connection of one component of one module from one segment to another. To do 
this one needs to delete the old row and create a new row.

A Common Example
 ----------------
Much more than common than chassis where any port can be dynamically 
switched to any repeater is the case where all ports on a card can be 
switched to a repeater. ie all ports on card 2 on repeater 3.

phyLocationTable
locationType    Location     Contents
Backplane       1            'Standard Backplane'
ModularSlot     1            '12 Port Repeater Card'
ModularSlot     2            '12 Port Repeater Card'

entityTable
Index     Type
14        Repeater	; Index chosen for example
20        Repeater

componentTable
location     index       Type       Assignment
Backplane.1     1        802.3      Entity 14
Backplane.1     2        802.3      Entity 20
Backplane.1     3        802.3      Entity 0    ; Not currently used
ModularSlot.1   1        802.3      Entity 14
ModularSlot.2   2        802.3      Entity 20

ie, each card has only one distinct component that represents all 12 ports. 
The table is still simple and the relationships/potential relationships 
clear.

>> The other concern I have is that Pete treats the backplane as a module.
>> I question if this is the correct view for us to take?  I could go either
>> way I just want to get other views.
>
> Again in the traditional chassis the backplane was quite simple and did 
not have any
> "features" and for example contained all the segments in the chassis.
> In a "logical" chassis the backplane may be also a "logical" one and as 
such may have
> segments which are connected internally and externally. therefor I find it
> logically to treat the backplane as a module. It is my belive that it
> is better to put in the effort so the backplane can be treated as a module 
and let
> those who want to use it to be able to, and those who don't will not, 
rather then
> having those who want to treat the backplane as a module not be able to do 
so.


Thanks for the comments. One thing to note from the examples above, having a 
fixed backplane with a couple of 802.3 components does not really involve 
greater complexity from the simple agent because we've reduced complexity in 
the mapping table and removed the segment table altogether. Also the model 
is easier to understand so is likely to have fewer interoperability 
problems.

My main point is that segments still exist but they are components of some 
module.

Pete