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