Subject: RE: question on bridge mib rfc 1493

From: "Rijhsinghani, Anil" <[email-masked]>
Date: Tue, 8 Feb 2000 10:22:24 -0500

> ----------
> From: 	Shivendra Kumar[SMTP:[email-masked]]
> Sent: 	Monday, February 07, 2000 4:28 PM
> To: 	Kevin Lingle
> Cc: 	[email-masked]; Gera, Sanjay; Bhatnagar, Mohit;
> [email-masked]; [email-masked]
> Subject: 	Re: question on bridge mib rfc 1493
> 
> Kevin Lingle wrote: 
> 
> 	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. 
> 	 
> 
> 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? 
>   
> 
> 	  
> 	Why do you need to encode this containment hierarchy in 
> 	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. 
> 
> 	  
> 
> 	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: 
> 	>   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] 
> 	>
> **************************************************************************
> **** 
> 	> 
> 	> 
> 
> 	-- 
> 	
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= 
> 	 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. 
> 	
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> 
> -- 
> 
> **************************************************************************
> ***
> 
> Shivendra Kumar 
> Fujitsu Network Communications Inc.             2901, Beltline Drive
> 2801 Telecome Parkway,                          Apt# 119,
> Richardson,                                     Garland,
> Texas 75082                                     Texas 75044
The bridge port numbers map into the interface numbers
via dot1dBasePortIfIndex.  So, assuming that you implement
MIB-II or ifTable, you are doing the same kind of things with those
indexes, which in turn means you are probably not compliant
here either.  If this is true, then you are effectively not
compliant to SNMP, although you can certainly
do any kind of indexing in your proprietary MIBs.  The problem
is that the purpose of standard MIBs is to make all vendors
implement the same objects in the same tree using the same
indexing, thus enabling interoperability and common apps.

What I would suggest, along the lines of others recommendations,
is that you implement the interfaces MIB per the standard,
perhaps using the single integer indexing containing all
your information (let an application map it into your physical
topology), and for the purposes of 1493 or 2674 use port
numbering from 1 to number of ports, using dot1dBasePortIfIndex
to map into the ifIndex.

Regards,
Anil

---

From: Dan Romascanu <[email-masked]>
Date: Thu, 10 Feb 2000 08:15:30 +0200

Keith,

Thanks, you are right. I mistakenly swapped Physical and Logical in my
explanation. The correct phrase is:

'The Entity MIB would certainly help.  You define the bridge(s) as entries
in entLogicalTable, define ports and modules as entries in
entPhysicalTable.'

Regards,

Dan

> -----Original Message-----
> From:	Keith McCloghrie [SMTP:[email-masked]]
> Sent:	Wed February 09 2000 19:14
> To:	[email-masked]
> Cc:	[email-masked]; [email-masked];
> [email-masked]; [email-masked];
> [email-masked]; [email-masked]; [email-masked]
> > 	The Entity MIB would certainly help.  You define the bridge(s) as
> > entries in entPhysicalTable, define ports and modules as entries in
> > entLogicalTable.
> 
> To prevent people from getting confused, I note that you have a typo in
> the above.  Each physical entity (the chassis, each module, each port)
> is represented as an entry in the entPhysicalTable.  An entry in the
> entLogicalTable represents a "logical entity" as represented by a
> SNMPv3 context, e.g., a logical bridge which performs the bridging
> function for a single VLAN.
> 
> Keith.