Subject: [Bridge-mib] (no subject)

From: [email-masked] (Alex Ruzin)
Date: Mon, 5 Nov 2001 14:00:40 +0200

Dear Ladies & Gentlemen,

First let me introduce myself.
I am responsible for SNMP and, occasionally, for Spanning Tree in
my company. I had implemented Spanning Tree 802.1d and a Bridge
MIB RFC1493. Now I've finished the first step of implementation
of Rapid Spanning Tree 802.1w (it is under alpha testing now). This
implementation, among other, supports a possibility to create one STP
instance per VLAN (I know, it is not 802.1s compatible, it will be
a next step).

In a parallel way I am designing our private MIB for SNMP support
for these features. In this message I am attaching it: may be ( and I
will consider it as a great honor for myself) some ideas from it
will be useful for you in your work under  draft-ietf-bridge-rstpmib-00.txt

Would you like to send your comments and remarks, I'll accept them
with great gratitude.

The attached files are:
RSTP.mib - the MIB draft
rstp.txt  the brief structure of MIB, as it is presented by snmptranslate
utility of NET-SNMP.

Now please allow me to make some comments.
 .
1. For many reasons it is convenient to have a possibility to configure
    an device for operation after nearest reset. For STP this possibility
has a
   special importance, while a non-atomic setting of parameters
   may follow drastic and unwanted changes in the network.
   So, the configuration that will be applied after nearest reset we call
    'NVRAM-configuration'. The configuration
    of the *operating now* device is called 'RUN configuration'.
    For this concept reflection we use an TEXTUAL-CONVENTION named
    "StorageType". All writeble tables are indexed with an object of this
type.
    Sure, the alternative is to organize two separate tables: one for run
and
    one for NVRAM. I have to point, that our old MIBs have been organized in
    such way.

2. For the same reason all objects are separated onto writeble and
readable-only
    tables. Sure (and it is a purpose), the latter type of tables are not
indexed with
   object of StorageType type. More of that, we consider such division as a
   method to make a MIB more understandable by network managers.

3. We inserted in the MIB so called rstpMSTiCfgTable as a preparation for
    MSTP support. Now it allows us to support RSTP instances per VLAN.

4. In RFC1493 the dot1dTpFdbTable is indexed only by dot1dTpFdbAddress.
    It doesn't  allow to support 802.1q tagged properties of the Bridge
 may be
    I missed the new bridge MIB editions) . Our rstpMacTable
    is indexed by both rstpMacAddr and  rstpMacVid (the latter one may be
equal
    to 0 in the untagged case)

Thank you for your tolerance & patience.
I look forward to working with you in the cooperation, while as far as I see
private MIBs
design is the evil, and we have to avoid it as strong as possible.

Best regards, Alex Rozin
============
Optical Access Ltd.
P.O. Box 114
Yokneam 20692, ISRAEL
Home  : http://www.opticalaccess.com