From shivendra.kumar@fnc.fujitsu.com Mon Feb 7 16:04:01 2000 Received: from sj-mailhub-3.cisco.com (sj-mailhub-3.cisco.com [171.68.224.215]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA21750 for ; Mon, 7 Feb 2000 16:03:59 -0500 (EST) Received: from proxy3.cisco.com (proxy3.cisco.com [192.31.7.90]) by sj-mailhub-3.cisco.com (8.9.1a/8.9.1) with SMTP id MAA18656 for ; Mon, 7 Feb 2000 12:44:21 -0800 (PST) Received: from miranda.tx.fnc.fujitsu.com (miranda.tx.fnc.fujitsu.com [167.254.254.199]) by proxy3.cisco.com with SMTP (MailShield v1.5); Mon, 07 Feb 2000 12:18:15 -0800 Received: from tdd1053.tx.fnc.fujitsu.com (tdd1053.tddeng00.fnts.com [167.254.126.25]) by miranda.tx.fnc.fujitsu.com (8.9.3+Sun/8.9.3) with ESMTP id OAA04295; Mon, 7 Feb 2000 14:13:36 -0600 (CST) Received: from fnc.fujitsu.com (localhost [127.0.0.1]) by tdd1053.tx.fnc.fujitsu.com (8.8.8+Sun/8.8.8) with ESMTP id OAA25460; Mon, 7 Feb 2000 14:13:35 -0600 (CST) Sender: shikumar@fnc.fujitsu.com Message-ID: <389F276F.4CDA0D2B@fnc.fujitsu.com> Date: Mon, 07 Feb 2000 14:13:35 -0600 From: Shivendra Kumar X-Mailer: Mozilla 4.61 [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: bridge-mib@external.cisco.com CC: "Gera, Sanjay" , "Bhatnagar, Mohit" Subject: question on bridge mib rfc 1493 Content-Type: multipart/alternative; boundary="------------6AFEE6B3B577EF92F5F77D9E" X-SMTP-HELO: miranda.tx.fnc.fujitsu.com X-SMTP-MAIL-FROM: shivendra.kumar@fnc.fujitsu.com X-SMAP-Received-From: outside X-SMTP-PEER-INFO: miranda.tx.fnc.fujitsu.com [167.254.254.199] --------------6AFEE6B3B577EF92F5F77D9E Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit 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@ - shivendra.kumar@fnc.fujitsu.com ****************************************************************************** --------------6AFEE6B3B577EF92F5F77D9E Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit 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@ - shivendra.kumar@fnc.fujitsu.com
******************************************************************************
  --------------6AFEE6B3B577EF92F5F77D9E-- From slavitch@loran.com Mon Feb 7 16:40:37 2000 Received: from sj-mailhub-2.cisco.com (sj-mailhub-2.cisco.com [171.69.43.88]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA22483 for ; Mon, 7 Feb 2000 16:40:37 -0500 (EST) Received: from proxy1.cisco.com (proxy1.cisco.com [192.31.7.88]) by sj-mailhub-2.cisco.com (8.9.1a/8.9.1) with SMTP id NAA15038 for ; Mon, 7 Feb 2000 13:10:49 -0800 (PST) Received: from marjorie.loran.com (marjorie.loran.com [209.167.240.3]) by proxy1.cisco.com with SMTP (MailShield v1.5); Mon, 07 Feb 2000 13:08:06 -0800 Received: (qmail 32232 invoked by uid 2); 7 Feb 2000 16:03:33 -0500 Received: from kubrick.ottawa.loran.com (HELO loran.com) (172.17.2.139) by marjorie.loran.com with SMTP; 7 Feb 2000 16:03:33 -0500 Message-ID: <389F327D.1E117908@loran.com> Date: Mon, 07 Feb 2000 16:00:45 -0500 From: Michael Slavitch X-Mailer: Mozilla 4.7 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Shivendra Kumar CC: bridge-mib@external.cisco.com, "Gera, Sanjay" , "Bhatnagar, Mohit" , bridge-mib@external.cisco.com Subject: Re: question on bridge mib rfc 1493 References: <389F276F.4CDA0D2B@fnc.fujitsu.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-SMTP-HELO: marjorie.loran.com X-SMTP-MAIL-FROM: slavitch@loran.com X-SMAP-Received-From: outside X-SMTP-PEER-INFO: marjorie.loran.com [209.167.240.3] Content-Transfer-Encoding: 7bit > 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. 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 klingle@cisco.com Mon Feb 7 17:05:45 2000 Received: from sj-mailhub-3.cisco.com (sj-mailhub-3.cisco.com [171.68.224.215]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22930 for ; Mon, 7 Feb 2000 17:05:44 -0500 (EST) Received: from claret.cisco.com (claret.cisco.com [161.44.2.33]) by sj-mailhub-3.cisco.com (8.9.1a/8.9.1) with ESMTP id NAA20386 for ; Mon, 7 Feb 2000 13:42:02 -0800 (PST) Received: from cisco.com (klingle-ultra.cisco.com [161.44.53.27]) by claret.cisco.com (8.8.4-Cisco.1/8.6.5) with ESMTP id QAA29049; Mon, 7 Feb 2000 16:20:59 -0500 (EST) Sender: klingle@cisco.com Message-ID: <389F3729.F874B574@cisco.com> Date: Mon, 07 Feb 2000 16:20:41 -0500 From: Kevin Lingle X-Mailer: Mozilla 4.51C-CISCOENG [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Shivendra Kumar CC: bridge-mib@external.cisco.com, "Gera, Sanjay" , "Bhatnagar, Mohit" Subject: Re: question on bridge mib rfc 1493 References: <389F276F.4CDA0D2B@fnc.fujitsu.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit 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: > 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@ - shivendra.kumar@fnc.fujitsu.com > ****************************************************************************** > > -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= 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@fnc.fujitsu.com Mon Feb 7 17:15:23 2000 Received: from sj-mailhub-3.cisco.com (sj-mailhub-3.cisco.com [171.68.224.215]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA23104 for ; Mon, 7 Feb 2000 17:15:21 -0500 (EST) Received: from proxy1.cisco.com (proxy1.cisco.com [192.31.7.88]) by sj-mailhub-3.cisco.com (8.9.1a/8.9.1) with SMTP id NAA27371 for ; Mon, 7 Feb 2000 13:53:13 -0800 (PST) Received: from miranda.tx.fnc.fujitsu.com (miranda.tx.fnc.fujitsu.com [167.254.254.199]) by proxy1.cisco.com with SMTP (MailShield v1.5); Mon, 07 Feb 2000 13:33:39 -0800 Received: from tdd1053.tx.fnc.fujitsu.com (tdd1053.tddeng00.fnts.com [167.254.126.25]) by miranda.tx.fnc.fujitsu.com (8.9.3+Sun/8.9.3) with ESMTP id PAA08482; Mon, 7 Feb 2000 15:22:35 -0600 (CST) Received: from fnc.fujitsu.com (localhost [127.0.0.1]) by tdd1053.tx.fnc.fujitsu.com (8.8.8+Sun/8.8.8) with ESMTP id PAA25561; Mon, 7 Feb 2000 15:22:35 -0600 (CST) Sender: shikumar@fnc.fujitsu.com Message-ID: <389F379A.148875C9@fnc.fujitsu.com> Date: Mon, 07 Feb 2000 15:22:34 -0600 From: Shivendra Kumar X-Mailer: Mozilla 4.61 [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Michael Slavitch CC: bridge-mib@external.cisco.com, "Gera, Sanjay" , "Bhatnagar, Mohit" Subject: Re: question on bridge mib rfc 1493 References: <389F276F.4CDA0D2B@fnc.fujitsu.com> <389F327D.1E117908@loran.com> Content-Type: multipart/alternative; boundary="------------D0BA5EFCFE840163E04FD253" X-SMTP-HELO: miranda.tx.fnc.fujitsu.com X-SMTP-MAIL-FROM: shivendra.kumar@fnc.fujitsu.com X-SMAP-Received-From: outside X-SMTP-PEER-INFO: miranda.tx.fnc.fujitsu.com [167.254.254.199] --------------D0BA5EFCFE840163E04FD253 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit 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 Michael Slavitch wrote: > > 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. > > 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. -- ***************************************************************************** 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@ - shivendra.kumar@fnc.fujitsu.com ****************************************************************************** --------------D0BA5EFCFE840163E04FD253 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit 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
 

Michael Slavitch wrote:

>  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.

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.

-- 

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

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@ - shivendra.kumar@fnc.fujitsu.com
******************************************************************************
  --------------D0BA5EFCFE840163E04FD253-- From shivendra.kumar@fnc.fujitsu.com Mon Feb 7 17:22:50 2000 Received: from kickme.cisco.com (kickme.cisco.com [198.92.30.42]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA23280 for ; Mon, 7 Feb 2000 17:22:48 -0500 (EST) Received: from proxy2.cisco.com (proxy2.cisco.com [192.31.7.89]) by kickme.cisco.com (8.9.1a/8.9.1) with SMTP id NAA01489 for ; Mon, 7 Feb 2000 13:31:24 -0800 (PST) Received: from miranda.tx.fnc.fujitsu.com (miranda.tx.fnc.fujitsu.com [167.254.254.199]) by proxy2.cisco.com with SMTP (MailShield v1.5); Mon, 07 Feb 2000 13:43:48 -0800 Received: from tdd1053.tx.fnc.fujitsu.com (tdd1053.tddeng00.fnts.com [167.254.126.25]) by miranda.tx.fnc.fujitsu.com (8.9.3+Sun/8.9.3) with ESMTP id PAA08862; Mon, 7 Feb 2000 15:28:10 -0600 (CST) Received: from fnc.fujitsu.com (localhost [127.0.0.1]) by tdd1053.tx.fnc.fujitsu.com (8.8.8+Sun/8.8.8) with ESMTP id PAA25566; Mon, 7 Feb 2000 15:28:09 -0600 (CST) Sender: shikumar@fnc.fujitsu.com Message-ID: <389F38E9.C4D23E4A@fnc.fujitsu.com> Date: Mon, 07 Feb 2000 15:28:09 -0600 From: Shivendra Kumar X-Mailer: Mozilla 4.61 [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Kevin Lingle CC: bridge-mib@external.cisco.com, "Gera, Sanjay" , "Bhatnagar, Mohit" , randy@psg.com, entmib@cisco.com Subject: Re: question on bridge mib rfc 1493 References: <389F276F.4CDA0D2B@fnc.fujitsu.com> <389F3729.F874B574@cisco.com> Content-Type: multipart/alternative; boundary="------------F8AF815477B7446861FFDE0F" X-SMTP-HELO: miranda.tx.fnc.fujitsu.com X-SMTP-MAIL-FROM: shivendra.kumar@fnc.fujitsu.com X-SMAP-Received-From: outside X-SMTP-PEER-INFO: miranda.tx.fnc.fujitsu.com [167.254.254.199] --------------F8AF815477B7446861FFDE0F Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit 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@ - shivendra.kumar@fnc.fujitsu.com > > ****************************************************************************** > > > > > > -- > =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= > 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 hello(off) - 001-972-4794889 hello(res) - 001-972-5300122 mail@ - shivendra.kumar@fnc.fujitsu.com ****************************************************************************** --------------F8AF815477B7446861FFDE0F Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit 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@ - shivendra.kumar@fnc.fujitsu.com
> ******************************************************************************
>
>

--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
 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
hello(off) - 001-972-4794889                    hello(res) - 001-972-5300122
mail@ - shivendra.kumar@fnc.fujitsu.com
******************************************************************************
  --------------F8AF815477B7446861FFDE0F-- From klingle@cisco.com Mon Feb 7 18:00:13 2000 Received: from sj-mailhub-2.cisco.com (sj-mailhub-2.cisco.com [171.69.43.88]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA23779 for ; Mon, 7 Feb 2000 18:00:13 -0500 (EST) Received: from claret.cisco.com (claret.cisco.com [161.44.2.33]) by sj-mailhub-2.cisco.com (8.9.1a/8.9.1) with ESMTP id OAA02530 for ; Mon, 7 Feb 2000 14:27:42 -0800 (PST) Received: from cisco.com (klingle-ultra.cisco.com [161.44.53.27]) by claret.cisco.com (8.8.4-Cisco.1/8.6.5) with ESMTP id RAA03566; Mon, 7 Feb 2000 17:23:41 -0500 (EST) Sender: klingle@cisco.com Message-ID: <389F45DA.2B52384F@cisco.com> Date: Mon, 07 Feb 2000 17:23:22 -0500 From: Kevin Lingle X-Mailer: Mozilla 4.51C-CISCOENG [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Shivendra Kumar CC: bridge-mib@external.cisco.com, "Gera, Sanjay" , "Bhatnagar, Mohit" , randy@psg.com, entmib@cisco.com Subject: Re: question on bridge mib rfc 1493 References: <389F276F.4CDA0D2B@fnc.fujitsu.com> <389F3729.F874B574@cisco.com> <389F38E9.C4D23E4A@fnc.fujitsu.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Shivendra Kumar wrote: > > 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? 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 > > > > > > 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@ - shivendra.kumar@fnc.fujitsu.com > > > ****************************************************************************** > > > > > > > > > > -- > > =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= > > 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 > hello(off) - 001-972-4794889 hello(res) - 001-972-5300122 > mail@ - shivendra.kumar@fnc.fujitsu.com > ****************************************************************************** > > -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= 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 Graeme_Mckerrell@eur.3com.com Tue Feb 8 04:09:40 2000 Received: from kickme.cisco.com (kickme.cisco.com [198.92.30.42]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA12752 for ; Tue, 8 Feb 2000 04:09:40 -0500 (EST) Received: from proxy1.cisco.com (proxy1.cisco.com [192.31.7.88]) by kickme.cisco.com (8.9.1a/8.9.1) with SMTP id AAA29685 for ; Tue, 8 Feb 2000 00:25:20 -0800 (PST) Received: from columba.eur.3com.com (columba.eur.3com.com [161.71.169.13]) by proxy1.cisco.com with SMTP (MailShield v1.5); Tue, 08 Feb 2000 00:35:42 -0800 Received: from toucana.eur.3com.com (eurelay.eur.3com.com [140.204.220.50]) by columba.eur.3com.com (8.9.3/8.9.3) with ESMTP id IAA27763; Tue, 8 Feb 2000 08:22:52 GMT Received: from notesmta.eur.3com.com (eurmta1.EUR.3Com.COM [140.204.220.206]) by toucana.eur.3com.com (8.9.3/8.9.3) with SMTP id IAA21933; Tue, 8 Feb 2000 08:20:47 GMT Received: by notesmta.eur.3com.com(Lotus SMTP MTA v4.6.3 (733.2 10-16-1998)) id 8025687F.002F809F ; Tue, 8 Feb 2000 08:38:51 +0000 X-Lotus-FromDomain: 3COM From: "Graeme Mckerrell" To: Shivendra Kumar cc: bridge-mib@external.cisco.com, "Gera, Sanjay" , "Bhatnagar, Mohit" Message-ID: <8025687F.002F7EC9.00@notesmta.eur.3com.com> Date: Tue, 8 Feb 2000 08:28:18 +0000 Subject: Re: question on bridge mib rfc 1493 Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline X-SMTP-HELO: columba.eur.3com.com X-SMTP-MAIL-FROM: Graeme_Mckerrell@eur.3com.com X-SMAP-Received-From: outside X-SMTP-PEER-INFO: columba.eur.3com.com [161.71.169.13] A question for you shivendra. Your mentioned that collapsing bridge/slot/port into a single index was tedious and difficult. Do your ports appear in the interface table, if so what indexing scheme do you use there? There are plenty of standard MIBs e.g. RMON, which require an interface index to operate, are you having to take this same approach on all such MIBS? In my opinion the encoding format you described is actually quite straight forward. Simply because the resultant number when written in decimal is not easy to decode, does't mean that within the context of an application this is difficult. The SNMP requests themselves are encoded in a far more convoluted manner! A good application will abstract away any of this "complexity" from the user. Regards Graeme McKerrell From klingle@cisco.com Tue Feb 8 10:30:09 2000 Received: from kickme.cisco.com (kickme.cisco.com [198.92.30.42]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA27144 for ; Tue, 8 Feb 2000 10:30:08 -0500 (EST) Received: from claret.cisco.com (claret.cisco.com [161.44.2.33]) by kickme.cisco.com (8.9.1a/8.9.1) with ESMTP id GAA01817 for ; Tue, 8 Feb 2000 06:44:50 -0800 (PST) Received: from cisco.com (klingle-ultra.cisco.com [161.44.53.27]) by claret.cisco.com (8.8.4-Cisco.1/8.6.5) with ESMTP id JAA14725; Tue, 8 Feb 2000 09:52:27 -0500 (EST) Sender: klingle@cisco.com Message-ID: <38A02D99.4BDBC63D@cisco.com> Date: Tue, 08 Feb 2000 09:52:09 -0500 From: Kevin Lingle X-Mailer: Mozilla 4.51C-CISCOENG [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Graeme Mckerrell CC: Shivendra Kumar , bridge-mib@external.cisco.com, "Gera, Sanjay" , "Bhatnagar, Mohit" Subject: Re: question on bridge mib rfc 1493 References: <8025687F.002F7EC9.00@notesmta.eur.3com.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Good points Graeme! Graeme Mckerrell wrote: > > A question for you shivendra. Your mentioned that collapsing bridge/slot/port > into a single index was tedious and difficult. Do your ports appear in the > interface table, if so what indexing scheme do you use there? There are plenty > of standard MIBs e.g. RMON, which require an interface index to operate, are you > having to take this same approach on all such MIBS? Note also that the bridge mib itself provides a mapping of bridge port number to ifIndex via dot1dBasePortIfIndex. So there is a built-in mapping from any arbitrarily encoded dot1dBasePort (bridge port) number back to some real physical interface. Presuming the interface is in ifTable (I sure hope it is... if not there are larger problems here ;) kevin > > In my opinion the encoding format you described is actually quite straight > forward. Simply because the resultant number when written in decimal is not easy > to decode, does't mean that within the context of an application this is > difficult. The SNMP requests themselves are encoded in a far more convoluted > manner! A good application will abstract away any of this "complexity" from the > user. > > Regards > Graeme McKerrell -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= 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 anil@cabletron.com Tue Feb 8 11:12:32 2000 Received: from sj-mailhub-2.cisco.com (sj-mailhub-2.cisco.com [171.69.43.88]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA29641 for ; Tue, 8 Feb 2000 11:12:30 -0500 (EST) Received: from proxy1.cisco.com (proxy1.cisco.com [192.31.7.88]) by sj-mailhub-2.cisco.com (8.9.1a/8.9.1) with SMTP id HAA21782 for ; Tue, 8 Feb 2000 07:38:22 -0800 (PST) Received: from ctron-dnm.ctron.com (ctron-dnm.cabletron.com [12.25.1.120]) by proxy1.cisco.com with SMTP (MailShield v1.5); Tue, 08 Feb 2000 07:35:22 -0800 Received: (from uucp@localhost) by ctron-dnm.ctron.com (8.8.7/8.8.7) id KAA27367; Tue, 8 Feb 2000 10:26:16 -0500 (EST) Received: from unknown(134.141.72.253) by ctron-dnm.ctron.com via smap (4.1) id xma027330; Tue, 8 Feb 00 10:25:39 -0500 Received: from ctron-exc2.ctron.com (ctron-exc2 [134.141.3.241]) by olympus.ctron.com (8.8.7/8.8.7) with ESMTP id KAA14383; Tue, 8 Feb 2000 10:22:04 -0500 (EST) Received: by ctron-exc2.ctron.com with Internet Mail Service (5.5.2448.0) id ; Tue, 8 Feb 2000 10:22:03 -0500 Message-ID: From: "Rijhsinghani, Anil" To: Kevin Lingle , "'Shivendra Kumar'" Cc: bridge-mib@external.cisco.com Subject: RE: question on bridge mib rfc 1493 Date: Tue, 8 Feb 2000 10:22:24 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="ISO-8859-1" X-SMTP-HELO: ctron-dnm.ctron.com X-SMTP-MAIL-FROM: anil@cabletron.com X-SMAP-Received-From: outside X-SMTP-PEER-INFO: ctron-dnm.cabletron.com [12.25.1.120] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id LAA29641 > ---------- > From: Shivendra Kumar[SMTP:shivendra.kumar@fnc.fujitsu.com] > Sent: Monday, February 07, 2000 4:28 PM > To: Kevin Lingle > Cc: bridge-mib@external.cisco.com; Gera, Sanjay; Bhatnagar, Mohit; > randy@psg.com; entmib@cisco.com > 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@ - shivendra.kumar@fnc.fujitsu.com > > > ************************************************************************** > **** > > > > > > -- > > =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= >  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 dromasca@lucent.com Wed Feb 9 10:24:03 2000 Received: from sj-mailhub-2.cisco.com (sj-mailhub-2.cisco.com [171.69.43.88]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA07993 for ; Wed, 9 Feb 2000 10:24:02 -0500 (EST) Received: from proxy2.cisco.com (proxy2.cisco.com [192.31.7.89]) by sj-mailhub-2.cisco.com (8.9.1a/8.9.1) with SMTP id FAA12510 for ; Wed, 9 Feb 2000 05:51:02 -0800 (PST) Received: from itc-eml2.ta.israel.madge.com (at.lannet.com [194.90.94.231]) by proxy2.cisco.com with SMTP (MailShield v1.5); Wed, 09 Feb 2000 05:50:33 -0800 Received: by ITC-EML2 with Internet Mail Service (5.5.2650.21) id ; Wed, 9 Feb 2000 15:42:57 +0200 Message-ID: <15F58915DF84D311AC7D0090279AA614127E2B@ITC-EML2> From: Dan Romascanu To: "'Kevin Lingle'" , Shivendra Kumar Cc: bridge-mib@external.cisco.com, "Gera, Sanjay" , "Bhatnagar, Mohit" , randy@psg.com, entmib@cisco.com Subject: RE: question on bridge mib rfc 1493 Date: Wed, 9 Feb 2000 15:42:57 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain X-SMTP-HELO: itc-eml2.ta.israel.madge.com X-SMTP-MAIL-FROM: dromasca@lucent.com X-SMAP-Received-From: outside X-SMTP-PEER-INFO: at.lannet.com [194.90.94.231] > 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 funn ;) > [Dan] SMON MIB is a Proposed Standard - RFC 2613. However, I am not sure that you will find the answer for your problem there The Entity MIB would certainly help. You define the bridge(s) as entries in entPhysicalTable, define ports and modules as entries in entLogicalTable. entPhysicalContainsTable defines the hierarchy of the physical objects. Using the entLPMappingtable in the Entity MIB for mapping logical to physical entities, and the dot1dbasePortTable in RFC 1493 to map bridge ports to ifIndex, you actually get the whole picture. Now, you just need to find the management application that is smart enough to look into all these tables, or write it by yourself :-) Changing indexing of a 'standard' table certainly rips the standard label from the implementation. You cannot claim conformance with 1493, and will not interoperate with an 1493 management application, but only with your own proprietary application. Regards, Dan From kzm@cisco.com Wed Feb 9 12:52:17 2000 Received: from kickme.cisco.com (kickme.cisco.com [198.92.30.42]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12912 for ; Wed, 9 Feb 2000 12:52:14 -0500 (EST) Received: from foxhound.cisco.com (foxhound.cisco.com [171.69.192.161]) by kickme.cisco.com (8.9.1a/8.9.1) with ESMTP id JAA25596 for ; Wed, 9 Feb 2000 09:04:38 -0800 (PST) Received: (from kzm@localhost) by foxhound.cisco.com (8.8.8/2.5.1/Cisco List Logging/8.8.8) id JAA18518; Wed, 9 Feb 2000 09:13:52 -0800 (PST) From: Keith McCloghrie Message-Id: <200002091713.JAA18518@foxhound.cisco.com> Subject: Re: question on bridge mib rfc 1493 To: dromasca@lucent.com (Dan Romascanu) Date: Wed, 9 Feb 2000 09:13:52 -0800 (PST) Cc: klingle@cisco.com ('Kevin Lingle'), shivendra.kumar@fnc.fujitsu.com (Shivendra Kumar), bridge-mib@external.cisco.com, sanjay.gera@fnc.fujitsu.com (Gera Sanjay), mohit.bhatnagar@fnc.fujitsu.com (Bhatnagar Mohit), randy@psg.com, entmib@cisco.com In-Reply-To: <15F58915DF84D311AC7D0090279AA614127E2B@ITC-EML2> from "Dan Romascanu" at Feb 09, 2000 03:42:57 PM X-Mailer: ELM [version 2.5 PL1] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit > 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. From dromasca@lucent.com Thu Feb 10 01:53:50 2000 Received: from sj-mailhub-3.cisco.com (sj-mailhub-3.cisco.com [171.68.224.215]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA08062 for ; Thu, 10 Feb 2000 01:53:49 -0500 (EST) Received: from proxy2.cisco.com (proxy2.cisco.com [192.31.7.89]) by sj-mailhub-3.cisco.com (8.9.1a/8.9.1) with SMTP id WAA07164 for ; Wed, 9 Feb 2000 22:40:13 -0800 (PST) Received: from itc-eml2.ta.israel.madge.com (at.lannet.com [194.90.94.231]) by proxy2.cisco.com with SMTP (MailShield v1.5); Wed, 09 Feb 2000 22:23:02 -0800 Received: by ITC-EML2 with Internet Mail Service (5.5.2650.21) id ; Thu, 10 Feb 2000 08:15:32 +0200 Message-ID: <15F58915DF84D311AC7D0090279AA614127E39@ITC-EML2> From: Dan Romascanu To: "'Keith McCloghrie'" , dromasca@lucent.com Cc: klingle@cisco.com, shivendra.kumar@fnc.fujitsu.com, bridge-mib@external.cisco.com, sanjay.gera@fnc.fujitsu.com, mohit.bhatnagar@fnc.fujitsu.com, randy@psg.com, entmib@cisco.com Subject: RE: question on bridge mib rfc 1493 Date: Thu, 10 Feb 2000 08:15:30 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain X-SMTP-HELO: itc-eml2.ta.israel.madge.com X-SMTP-MAIL-FROM: dromasca@lucent.com X-SMAP-Received-From: outside X-SMTP-PEER-INFO: at.lannet.com [194.90.94.231] 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:kzm@cisco.com] > Sent: Wed February 09 2000 19:14 > To: dromasca@lucent.com > Cc: klingle@cisco.com; shivendra.kumar@fnc.fujitsu.com; > bridge-mib@external.cisco.com; sanjay.gera@fnc.fujitsu.com; > mohit.bhatnagar@fnc.fujitsu.com; randy@psg.com; entmib@cisco.com > Subject: Re: question on bridge mib rfc 1493 > > > 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. From sunnyindu@mail.com Sat Feb 26 03:27:18 2000 Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA11651 for ; Sat, 26 Feb 2000 03:27:17 -0500 (EST) Received: from proxy2.cisco.com (proxy2.cisco.com [192.31.7.89]) by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with SMTP id XAA25313 for ; Fri, 25 Feb 2000 23:51:02 -0800 (PST) Received: from fcs.firstclasssolutions.net (fcs.firstclasssolutions.net [206.114.196.2]) by proxy2.cisco.com with SMTP (MailShield v1.5); Fri, 25 Feb 2000 23:54:05 -0800 Received: from oemcomputer (ppp209.firstclasssolutions.net [206.114.196.209]) by fcs.firstclasssolutions.net (8.8.5/8.8.5) with SMTP id BAA05940 for ; Sat, 26 Feb 2000 01:50:24 -0600 (CST) Message-Id: <200002260750.BAA05940@fcs.firstclasssolutions.net> From: "AUCTIONS_Supply_Outlet" To: "" Date: Sat, 26 Feb 2000 01:47:48 -0800 Subject: Do You Own Sell on AUCTIONS? On the INTERNET? Reply-To: sunnyindu@mail.com Organization: We Cater to AUCTIONEERS! MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Priority: 3 X-SMTP-HELO: fcs.firstclasssolutions.net X-SMTP-MAIL-FROM: sunnyindu@mail.com X-SMAP-Received-From: outside X-SMTP-PEER-INFO: fcs.firstclasssolutions.net [206.114.196.2] Content-Transfer-Encoding: 7bit >Subject: Do You Own Sell on AUCTIONS? On the INTERNET? Hi! My name is Shawn and we are a wholesale distributors of Off Lease/Refurbished laptops. We cater to AUCTIONEERS, independently owned and operated Computer Stores and Computer Repair shops. We specialize in buying Quantities of Factory Over Stocks Products and Off Lease Products. All our product is A-Grade, good quality and is backed with 100% money back guarantee! There is a great need for these quality laptops at good price in today's market situation and if you may be interested to take advantage of opportunity and talk to us or look at our list (Prices/specs) > PLEASE CLICK AT THE FOLLOWING LINK TO REQUEST MORE INFORMATION. Click below for more info! http://www.webhostcorp.com/members/angela423/contact.html >=> >====== Unsubscribe Link === http://www.webhostcorp.com/members/angela423/remove.html ============================