dsx0BundleTable issues
Gary Hanson <gary@kentrox.com> Tue, 16 June 1998 18:58 UTC
Delivery-Date: Tue, 16 Jun 1998 14:58:03 -0400
Return-Path: gary@kentrox.com
Received: from cnri.reston.va.us (ns.cnri.reston.va.us [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id OAA29444 for <ietf-archive@ietf.org>; Tue, 16 Jun 1998 14:58:02 -0400 (EDT)
Received: from frogger.cisco.com (frogger.cisco.com [171.69.30.57]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id PAA10205 for <ietf-archive@cnri.reston.va.us>; Tue, 16 Jun 1998 15:00:24 -0400 (EDT)
Received: from hubbub.cisco.com (mailgate-sj-1.cisco.com [198.92.30.31]) by frogger.cisco.com (8.8.5-Cisco.2-SunOS.5.5.1.sun4/8.6.5) with ESMTP id LAA14013 for <extdom.trunk-mib@aliashost.cisco.com>; Tue, 16 Jun 1998 11:50:53 -0700 (PDT)
Received: from proxy1.cisco.com (proxy1.cisco.com [192.31.7.88]) by hubbub.cisco.com (8.8.4-Cisco.1/CISCO.GATE.1.1) with ESMTP id LAA01558 for <trunk-mib@external.cisco.com>; Tue, 16 Jun 1998 11:50:52 -0700 (PDT)
Received: (from smap@localhost) by proxy1.cisco.com (8.8.7/8.8.5) id LAA20679 for <trunk-mib@external.cisco.com>; Tue, 16 Jun 1998 11:50:49 -0700 (PDT)
Received: from kentrox.kentrox.com(192.228.59.2) by proxy1.cisco.com via smap (V2.0) id xma020667; Tue, 16 Jun 98 18:50:44 GMT
X-SMAP-Received-From: outside
Received: from kentrox.com ([146.71.112.126]) by kentrox.kentrox.com (8.9.0/8.9.0) with SMTP id LAA03030 for <trunk-mib@external.cisco.com>; Tue, 16 Jun 1998 11:46:57 -0700 (PDT)
Received: from localhost by kentrox.com (4.1/SMI-4.1_KTX1.1) id AA23972; Tue, 16 Jun 98 11:46:56 PDT
Date: Tue, 16 Jun 1998 11:46:55 -0700
From: Gary Hanson <gary@kentrox.com>
X-Sender: gary@skeeter
Reply-To: Gary Hanson <gary@kentrox.com>
To: trunk-mib@external.cisco.com
Subject: dsx0BundleTable issues
Message-Id: <Pine.SUN.3.96.980616101409.23771B-100000@skeeter>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset="US-ASCII"
Hi all, We've recently identified a few areas where the DS0BUNDLE-MIB is less convenient to use than we would have liked. I thought I would share this implementation experience with the WG to get it on the record. I want to stress that this feedback does NOT indicate a belief that the DS0BUNDLE-MIB needs to be fixed relative to these points at this time (prior to release as part of a Proposed Standard), but that it may be desirable to consider these points at the next opportunity to revise the MIB. 1. There is no convenient way to locate the dsx0BundleTable entry that corresponds to a given ds0Bundle interface. If a manager wishes to delete a ds0Bundle, it must potentially walk through the dsx0BundleIfIndex attribute column looking for the matching entry. A helpful solution would be to add a new table that provides a mapping from ds0Bundle ifIndex values to the corresponding dsx0BundleIndex values for the entries in the dsx0BundleTable. 2. The TestAndIncr SYNTAX of the dsx0BundleNextIndex object seems cumbersome when compared with similar objects in other MIBs (e.g., the atmVpCrossConnectIndexNext object in the ATM-MIB). If used as recommended, the dsx0BundleNextIndex object requires a GET followed by a SET prior to each attempt to create an entry in the dsx0BundleTable, whereas atmVpCrossConnectIndexNext and similar index-dispensing objects require just a GET prior to each attempt to create an entry in their corresponding tables. The TestAndIncr approach thus requires a total of 3 consecutive SNMP operations to create a new table entry, whereas the other approach only requires 2 consecutive SNMP operations. In addition, for a management application to be robust, it needs to be prepared to run into theoretical cases where the dsx0BundleNextIndex value wraps (or is randomly set during agent initialization) and then the management application runs into a potentially long sequence of dispensed values that are found to be already in use. In this case, the need for 3 instead of 2 consecutive operations becomes more painful, perhaps to the point that the management application punts and decides to just avoid using dsx0BundleNextIndex and tries randomly using index values in an effort to more quickly find unused entries. If the goal is to facilitate the dispensing of a usable index value for the dsx0BundleNextIndex, it would be helpful to define an object that works more like atmVpCrossConnectIndexNext does, which intelligently provides only a value that is already NOT in use, or provides a special value to indicate that ALL entries ARE in use. Since 0 is unfortunately a legal index value for the dsx0BundleIndex, presumably a value like -1 would have to be used to indicate that no more table entries are available. Regards, Gary ______ | /// | TM Gary Hanson gary@kentrox.com | ADC|Kentrox 14375 NW Science Park Dr. 503-641-3321 (FAX) |______| Portland, Oregon 97229 800-733-5511 x6333
- dsx0BundleTable issues Gary Hanson