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

[lester@netscout.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 agree with this.  Why should a change in the MIB force some agent
implementations to upgrade to SNMPv2C.
This is not only a drastic change but downright ridiculous.  Some home
grown stacks may not be easy to make the  upgrade.  Specially when we
already have previous draft implementations.

Andy wrote:

>I think we need to take steps to reduce MIB complexity, improve MIB
readability,
>and encourage adoption of the most current network management standards.
That's
>the detailed rationale for getting rid of the "overflow" counters.

How can  dropping a 32-bit overflow counter can make the MIB any less
complex.   In fact keeping the base 32-bit
counter and having a 64-bit counter together will make it more complex.  If
you want to make the MIB  more readable then drop
both the 32-bit counters and just keep one 64-bit counter.  That way the
agent implementations are forced to use SNMPv2C
with  64-bit counters and the management stations will have to deal with
one counter.

Lester D'Souza
NetScout Systems, Inc.
lester@netscout.com








abierman@cisco.com on 10/02/2000 01:03:42 PM

To:   IZilbers@avaya.com
cc:   lstabile@concord.com, rmonmib@ietf.org, mibs@ops.ietf.org (bcc:
      Lester D'Souza/NetScout)
Subject:  Re: [RMONMIB] comments on draft-ietf-rmonmib-dsmon-mib-02.txt




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

_______________________________________________
RMONMIB mailing list
RMONMIB@ietf.org
http://www.ietf.org/mailman/listinfo/rmonmib