'Chassis MIB' WG Reactivation

[Dan Romascanu <[e-mail]>]

Hello,

Bob Millen's message came just in time to remind us that 1993
is (almost) over and together with it the moratorium period 
concerning opening of new WGs in the Network Management Area.

Bob states correctly that there is an accute need of defining
a standard method for the management of compound devices. On
my opinion the time elapsed since the activity in the Chassis
MIB WG was interrupted only enhanced the need. We should learn
from the mistakes of the past (the list is long, we did not 
limit and define a clear-enough scope, key people were involved
in too many parallel activities,...), take the good things (we
had many well articulated technical proposals, so that a new 
activity needs not be begun from zero) and rectivate this
activity. We might even change the name to something else if
'Chassis MIB' arrises traumatic memories to anyone.

We have a problem which needs and can be soved. Let's 
approach it.

A Happy New Year to everybody

[e-mail]
Dan Romascanu, LANNET Data Communications Ltd., 
Tel Aviv, ISRAEL, Voice: 972-3-645-8414


==============================================================================

FORWARDED MESSAGE


We have two network management requirements associated with on-going
development of our product line.  It is my suspicion that a number of
developers of managed network products have similar requirements.

>From a very limited review of the proxy conventions described in the SNMPv2
"Administrative Model" document (RFC1445) it appears that both of our
requirements might be met by these provisions.  One of our requirements might
also be met by the Chassis MIB.  We're not especially familiar with the Chassis
MIB either, but our impression is that, at least so far, it is not attracting
a wide following.

Requirement 1:  Standard Management of 'Foreign' Device
=======================================================
This is the standard requirement of managing non-SNMP devices with an SNMP
Management Station.  A little of our history might help motivate my question.

We currently have an SNMPv1 proxy to our pre-SNMP network products.  In our
analysis of our options when we designed this proxy we seemed to have two basic
choices.

  1)  We could play games with the community string on SNMP requests.  While
      there were suggestions about this in the IETF community, there was no
      agreed upon approach.

      We wanted an approach that would allow the various high runner Management
      Stations to manage our proxied devices without our having to write
      special management applications for each Management Station package that
      our customer might want to use.  We found there was no widely adhered to
      standard proxy approach.

  2)  The only approach that occurred to us which solved this problem was to
      have our proxy look like an IP router to the network manager.  Our proxy
      makes the network manager 'think' that it is a router with all of the
      proxied devices on a different IP network number than the management
      station.

      There were several problems with this approach.  It was a hassle getting
      our proxy to the point where the network manager really believed that our
      proxy was a properly functioning IP router.  Most of our initial
      difficulties were associated with our learning curve.  But along the way
      we discovered some bugs in the primary network management package we use.
      (We use HP's Network Node Manager [NNM], which is part of HP's OpenView
      Unix package.)

      With this approach one must 'make up' an IP address and MAC address for
      each proxied device so that the network manager can deal with it in a
      standard way.  For our first proxy requirement this wasn't too onerous.
      We were able to map our device's proprietary address in a one-to-one way
      to an IP address.  Also NNM seems to be happy with MAC addresses of
      zero.

      We haven't had much experience with other management stations and this
      proxy.  I suspect that we would have to do some tweaks in many cases to
      get things to work as successfully as they currently are with NNM.

We now have a new requirement where the number of proxied devices is such that
the above approach won't work.  There is no clean mapping of our proprietary
device addresses to IP addresses.  We don't want that many bogus IP addresses
floating around even if we could come up with such a mapping.

So I guess the bottom line question relative to our standard proxy requirement
boils down to the following.  Does SNMPv2 provide a complete enough
documentation of a standard proxy approach so that any proxy created according
to spec can plug and play with any Network Manager that supports the spec.

I have two main concerns here.  My sense is that the SNMPv2 proxy details
aren't quite complete enough for this.  I also have no sense that proxy writers
and network manager writers are diligently working to have their products plug
and play in this fashion.

Requirement 2:  Standard Management of 'Compound' Devices
=========================================================
This requirement is more along the lines of what I understand the Chassis MIB
to be aimed at.  Again, an example will motivate what we need.

One of the devices in our product line is a mutliport Bridge.  We refer to it
as our Ethernet Bridge Card (EBC).  (A crude representation follows.)

                            FDDI Ring
           _____________________________
          /                             \
         /                               \
         \                               /
          \_____________________________/
                       |
                       |
                       |1
                 ______|_______
                |              |
                |     FDDI     | Ethernet
                |      MIB     | Bridge
          5_____|              | Card (EBC)
                |              |
          6_____|              |
                |    Bridge    |
          7_____|     MIB      |
                |              |
          8_____|              |
                |              |
                | 2    3    4  |
                |______________|
                |____|____|____| <-- 3 Repeaters

                                 (Each Repeater has
                                  8 10BaseT ports and
                                  one AUI connection)

The EBC bridges eight (8) segments.  Segments 5 through 8 are proprietary to
Intecom.  They allow wide area bridging through the switching fabric of our
integrated voice and data PBX (private branch exchange).

The 'compound' nature of our device is that it is a bridge and also three hubs.
When we looked at options to manage this device we were disappointed to find
that the Repeater MIB only supports a single repeater.  When we complained to
the Repeater MIB mailing list we were told that the Chassis MIB was the
solution to our problem.

It doesn't seem to us that the Chassis MIB directly fits our problem.  We don't
have a chassis.  Also it seems that the Chassis MIB isn't being taken seriously
by very many developers.  (Is this an incorrect impression on our part?)

To get around the problem we created additions to our private MIB patterned
after the repeater MIB.  Now our single EBC agent can provide management
information for the bridge (via the standard Bridge MIB) and the three
repeaters (via our proprietary MIB).  We have written special 'card view'
management applications that allow us to provide convenient monitoring of the
information available from our private MIB, but we would prefer a more standard
approach.

Thus, we have been lead to wonder if some kind of standard SNMPv2 proxy
approach might be the answer.  As an example, the agent in the EBC could make
each repeater appear to be a proxied device.  Each proxied repeater would
support "it's own" standard Repeater MIB.

If all writers of compound device agents and writers of management stations
had a standard approach to follow in this area, across the board 'plug and
play' management of compound devices might happen.  How likely is that to
happen with the current SNMPv2 proxy specification?  Is there another more
likely approach?  Is the Chassis MIB not all that dead?

HP OpenView Direction
=====================
My immediate hope in the responses that I get from this message is to come up
with an understanding of a standards oriented strategy that addresses both of
these requirements.  Before we apply development effort in that direction I
hope to get a feeling that HP plans to go in a similar direction in providing
standard management in these two different situations.

Thanks in advance for any help you can provide.

Bob Millen
Intecom Inc.
Liberty Plaza II
5057 Keller Springs Road
Dallas, Texas  75248

Internet:  [e-mail]

PHONE:     [phone]
FAX:       [phone]