Re: [RMONMIB] comments on draft-ietf-rmonmib-dsmon-mib-02.txt

[Andy Bierman <abierman@cisco.com>]

Itai Zilbershtein wrote:
> 
>>..
>  >
>  >Thanks for pointing this out:
>  >
>  >1) SNMPv3 has nothing to do with this issue. Only SNMPv2C support
>  >   is needed for Counter64
>  >2) The agent is not part of the problem. Agents which need to
>  >   return 64-bit counters tend to support SNMPv2C so they can use
>  >   the Counter64 data type. All the embedded stacks have supported
>  >   SNMPv2C for years.
> 
> And yet -
> 
> Adding new capabilities to existing agents is not uncommon. Changing the
> SNMP stack (or activating an unused, untested mode) is typically a task on a
> larger scale.
> Example: RFC2613 (SMON) added support for aggregated counters (such as a
> switch interface). Typically, aggregation counters require 64bit counters,
> as the aggregated speed makes roll-overs frequent.  The 32/32 trick allows
> quick and relatively painless support of this new functionality by existing
> agents.
> >...

I disagree that upgrading an SNMP stack from SNMPv1 to SNMPv2C is a
major development undertaking, and therefore a valid reason to 
add new high-speed counter support to an agent without adding
Counter64 support.

Enabling SNMPv2C in the agent stack we use is quite trivial.
(Set a compile-time option and recompile.)  If (as 2 mgmt-vendors suggested)
there are SNMPv1 agents deployed on high-speed devices that rely on the 
32/32 pair,  then these implementations should be upgraded to SNMPv2C.
I think SNMP has a boxcar full of excess baggage, and I'm just trying to get
rid of one small bit of it.

There seems to be some consensus that all implementations should support
Counter64 instead of 2 Counter32s eventually, but not as much agreement on
the timeframe for this migration. 

Andy