Subject: question on bridge mib rfc 1493

From: Shivendra Kumar <[email-masked]>
Date: Mon, 07 Feb 2000 14:13:35 -0600

Hi friends,

 This is Shivendra , working for  a project Flash600 for Fujitsu Network
communications.
  We are having LAN bridging functionality in this product and we are
supporting rfc 1493 with some modifications.
   One of the fundamental things we want to change in this MIB is the
indexing mechanism.
  For example , let's consider dot1dBasePortTable . This table is
indexed by dot1dBasePortIfIndex which is specified as an Integer.
 Case 1.  Now, for our implementation  BridgePortIfIndex will be
composed of three fields:
  slot# - Slot No. on the equipment in  which the LAN card sits
  bridge# - The bridge no. on the lan card to which this port is
associated
  port# - The port no. on the bridge

  This makes the  BridgePortIfIndex  encoding difficult , eg. say
Integer is 4bytes value, so we encode one byte  each for  above three
field and leave one byte unused.

  We want to change the Indexing mechanism to use three separate indexes
each of type Integer and named as
Case  2. BaseBridgeSlotNumber,
  BasebridgeBridgeNumber,
  and BaseBridgePortNumber.

  The benefit of indexing like this is ease of usage. Let's see a case
when using
  slot# = 1
  bridge# = 1
  Port# =1

so we say ,
get  dot1dBasePortMtuExceededDiscards.1.1.1

whereas in earlier case( case 1) we have to calculate
  -------------------------------------------------------
  | 00000000|00000001|00000001 |00000001|  = 65793
-----------------------------------------------------------
  <------------------ 4 bytes -------------------------->
And, after doing the above tedious calculation we reach the index value
as 65793 and then say
get  dot1dBasePortMtuExceededDiscards.65793
So , obviously this indexing mechanism is complex.
We want to change this and use Case 2 (described earlier) which is
simpler.

We are adding this m,ib as proprietary mib but still want to conform
with the accepted standards.
Will it be an acceptable change to do as per standards. Your
inputs/experienecs are welcome.

regards,
Shivendra

--

*****************************************************************************

Shivendra Kumar
Fujitsu Network Communications Inc.             2901, Beltline Drive
2801 Telecome Parkway,                          Apt# 119,
Richardson,                                     Garland,
Texas 75082                                     Texas 75044
hello(off) - 001-972-4794889                    hello(res) - 001-972-5300122
mail@ - [email-masked]
******************************************************************************

---

From: Michael Slavitch <[email-masked]>
Date: Mon, 07 Feb 2000 16:00:45 -0500

>  This is Shivendra , working for  a project Flash600 for Fujitsu
> Network communications.

No you are not. Please, follow the standard. Do not place it in a
private
MIB.  If it's not 1493 it's not 1493.

Behavior like this makes any form of network management very difficult.

---

From: Kevin Lingle <[email-masked]>
Date: Mon, 07 Feb 2000 16:20:41 -0500

Shivendra,

You can't do what you've described in case #2 because
the objects in the mib aren't defined to be indexed
this way.  You can't simply alter indexing schemes for
a standard mib any more than you can change anything
else about the objects in a standard mib and remain
compliant.

Why do you need to encode this containment hierarchy in 
the bridge port number anyway?

Kevin
Shivendra Kumar wrote:
> 
> Hi friends,
> 
>  This is Shivendra , working for  a project Flash600 for Fujitsu Network communications.
>   We are having LAN bridging functionality in this product and we are supporting rfc 1493 with some modifications.
>    One of the fundamental things we want to change in this MIB is the indexing mechanism.
>   For example , let's consider dot1dBasePortTable . This table is indexed by dot1dBasePortIfIndex which is specified as an Integer.
>  Case 1.  Now, for our implementation  BridgePortIfIndex will be composed of three fields:
>   bridge# - The bridge no. on the lan card to which this port is associated
>   This makes the  BridgePortIfIndex  encoding difficult , eg. say Integer is 4bytes value, so we encode one byte  each for  above three  field and leave one byte unused.
> 
>   We want to change the Indexing mechanism to use three separate indexes each of type Integer and named as
>   The benefit of indexing like this is ease of usage. Let's see a case when using
>   slot# = 1
>   bridge# = 1
>   Port# =1
> 
> so we say ,
> And, after doing the above tedious calculation we reach the index value as 65793 and then say
> We want to change this and use Case 2 (described earlier) which is simpler.
> 
> We are adding this m,ib as proprietary mib but still want to conform with the accepted standards.
> Will it be an acceptable change to do as per standards. Your inputs/experienecs are welcome.
> 
> regards,
> Shivendra
> 
> --
> 

-- 
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
 Kevin R. Lingle       919.392.2029
 checkout: http://wwwin-eng.cisco.com/Eng/IOS/SNMP_WWW/mib-police.html
 Sometimes I think I understand everything, then I regain consciousness.
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=

---

From: Shivendra Kumar <[email-masked]>
Date: Mon, 07 Feb 2000 15:22:34 -0600

Hi Michael,
  As per our layer 2 implementation, we have to support some MIB objects
for Ethernet frames over ATM and SONET modes. Thes MIB objects don't
figure in rfc 1493 or rfc 2674 which are for the bridge.
So, anyway we are forced to modify this MIB and add our own tables to it.
  We are placing this MIB in entreprise section already( proprietary MIBs
)
So, the question is , If we adapt a MIB into proprietary MIB , Is it a
fair thing to say that we can change the indexing mechanism?
And, Do the standards allow changing of Indexing mechanisms?

regards,
Shivendra

--

Shivendra Kumar

---

From: Shivendra Kumar <[email-masked]>
Date: Mon, 07 Feb 2000 15:28:09 -0600

> else about the objects in a standard mib and remain

But, we are already deriving our private MIB from the standard MIB rfc 1493.
som the standard Oids for these objects can't be used. It will be our proprietary Oids , so why not have indexing a simpler way.
Folks from MIB entities group : Do u have any comments on changing the indexing mechanism?

> the bridge port number anyway?

Yes , we need to. because , we may have multiple bridges ( logical closed user groups on a card ) on a lan card and then we can have such multiple lan cards.

--

Shivendra Kumar

---

From: Kevin Lingle <[email-masked]>
Date: Mon, 07 Feb 2000 17:23:22 -0500

> Folks from MIB entities group : Do u have any comments on changing the indexing mechanism?

Well, if it is truely a private MIB then you can do what you want.
I hope you are changing all of the object descriptors accordingly
so that there is not confusing you private MIB w/ the standard
MIB.  Not a required thing, but certainly prudent IMHO.

Have you looked at some of the more recent workn in the
SMON MIB??  I don't know too much about it as I never
followed the work too closely.  I just wonder if they may
have done something to address containment issues better
than the original bridge mib. If I were you, I'd browse
the IETF I-Ds to find out where SMON mib status sits today
and investigate that mib for any "modern" bridging function ;)

kevin