RE: FW: 64 bit counters in MPLS MIBs

["Harrington, David" <dbh@enterasys.com>]

Hi,

part 1:

While I recognize the overhead caused by supporting 64-bit values on devices without native 64-bit support, I think it is something of a red herring. If the amount of traffic crossing an interface will exceed the one-hour guideline, and the hardware/software being used is incapable of supporting emulation of 64-bit Counters, then the designers of the product should take a closer look at their designs. 

If I need to count greater than 2^32, I can use one 64-bit register or memory location and report the value in a Counter64 varbind. I can also count using two registers or two memory locations (or a combination), one for the lower half and the other for the upper half, and combine the two 32-bit values into a Counter64 varbind. 

It seems to me that the overhead of mallocing, filling in the OIDs and types and values, and then sending two Counter32 varbinds is typically greater than the overhead for mallocing one Counter64 varbind, combining two 32bit values values into the Counter64 varbind, and then sending one varbind.

part 2:

I do not believe it makes sense to select the counter size based on the deployment. If there is any likelihood that an interface may exceed the one-hour guideline, then Counter64s are called for. This would exempt a managed object designed to support an interface that cannot possibly exceed the one-hour guideline, such as the byte count for a 1M Ethernet interface.

For mib objects supporting interfaces where the speed is not known at mib-design-time, then it should be assumed that at some point, it will be applied to an interface that qualifies for the one-hour guideline, and thus they should use Counter64s.

part 3:
The only justification I can see for the dual Counter32s is to support SNMPv1-only applications. While I don't like needing to support these, the fact is there are few SNMPv3-capable applications available to date. People need to manage their networks. By insisting that mibs be designed with features not yet available in many existing applications, we would make SNMP even harder to use than it is already.

Using deprecated 32-bit counters to support SNMPv1 will help the end-users in the short term.

dbh

> -----Original Message-----
> From: Randy Presuhn [mailto:rpresuhn@dorothy.bmc.com]
> Sent: Monday, January 06, 2003 6:07 PM
> To: mreview@ops.ietf.org
> Subject: RE: FW: 64 bit counters in MPLS MIBs
> 
> 
> Hi -
> 
> > Date: Mon, 6 Jan 2003 12:22:44 -0800 (PST)
> > From: "C. M. Heard" <heard@pobox.com>
> > To: "Mreview (E-mail)" <mreview@ops.ietf.org>
> > Subject: RE: FW: 64 bit counters in MPLS MIBs
> > In-Reply-To: 
> <7D5D48D2CAA3D84C813F5B154F43B1559899DF@nl0006exch001u.nl.lucent.com>
> > Message-ID: 
> <Pine.LNX.4.10.10301061215100.26591-100000@shell4.bayarea.net>
> ...
> > I agree with all of that.  But for the scenario set forth above,
> > the MIB module's compliance statement would presumably say that
> > HC counters are required for highspeed ifaces, while
> > LC counters are required for lowspeed ifaces.
> ...
> 
> One thing really bugs me about this particular formulation:
> where RFC 2578 clause 7.1.10 is about the selection of a
> SYNTAX for OBJECT-TYPEs, this formulation goes farther and
> makes it a per-instance rule.
> 
> I think we should encourage, rather than disparage,
> implementations which support the 64-bit counters
> unconditionally.  (Assuming of course that it's architecturally
> appropriate for the object to be 64 bits in the first place.)
> I believe this would reduce the "yuck" factor Glenn mentioned.
> 
>  ------------------------------------------------------
>  Randy Presuhn          BMC Software, Inc.  SJC-1.3141
>  randy_presuhn@bmc.com  2141 North First Street
>  Tel: +1 408 546-1006   San José, California 95131  USA
>  ------------------------------------------------------
>  My opinions and BMC's are independent variables.
>  ------------------------------------------------------
> 
>