[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [RMONMIB] comments on draft-ietf-rmonmib-dsmon-mib-02.txt
- To: <firstname.lastname@example.org>,<email@example.com>
- Subject: RE: [RMONMIB] comments on draft-ietf-rmonmib-dsmon-mib-02.txt
- From: "David T. Perkins" <firstname.lastname@example.org>
- Date: Tue, 03 Oct 2000 13:01:01 -0700
- Delivery-date: Tue, 03 Oct 2000 12:59:22 -0700
- Envelope-to: email@example.com
I do not know what is meant by "64-bit implementations".
My belief is that a backwards compatable approach TO THE SNMPv1
PROTOCOL has to be adopted that allows new data types (such as
the 64-bit counter, 64-bit signed and unsigned integers) to be
added. And there is already a solution. This solution has been
in use for several years in the UC-DAVIS SNMP agent.
The solution is to add the new data types to the SMI, and define
the "transport mapping" so that "old" SMI data types
encoded as "straight" BER, and new (to SNMPv1) data type
values encoded first into BER and that is used as the value for
an encoding of OPAQUE data type. This is all explained on the
The result is that agents can continue to be written in SNMPv1
(no major upgrade). Only a very small and localized updated is
(I believe in the UC-DAVIS code, it was less than 20 lines of C
Only the purests get upset with this proposal. It really works!
/david t. perkins
At 10:26 AM 10/03/2000 -0400, Carter Bullard wrote:
There will be an eventual need for overflow counters
with 64 bit implementations. Its just a matter of time,
as it was with 32 bit implementations.
Is the consensus that there will not be overflow counter
support in 64 bit implementations?
300 E. 56th Street, Suite 17A
New York, New York 10022
Phone +1 212 813-9426
Fax +1 212 813-9426
From: firstname.lastname@example.org [mailto:email@example.com]On Behalf Of
Sent: Tuesday, October 03, 2000 9:30 AM
To: firstname.lastname@example.org; email@example.com
Subject: RE: [RMONMIB] comments on draft-ietf-rmonmib-dsmon-mib-02.txt
> Hi Andy,
> I agree with Ofer Goren that it is not a simple compile switch to support
> SNMPv2C/v3 for the majority of implementations.
> But I would go a bit further and suggest that you should continue to support the
> overflow counters in new MIBs. If you don't, then I believe they will be
> defined in proprietary MIBs by the majority of vendors that cannot easily
> support SNMPv2C/v3. This will make it more difficult for the NMS people
> It is true that there are a few SNMPv2C/v3 implementations out there that could
> be used as a replacement for the many SNMPv1 implementations that are out there.
> However I would find it difficult to justify the cost of purchasing a third
> party SNMPv2C/v3 implementation and porting it into an existing product. Even
> taking a 'free' implementation requires significant development effort to port,
> adapting it to interface to an existing product, or adapting the rest of the
> software to the new SNMP interface. Why should I have to divert resources to
> this work when I could implement new features instead, where the end-user will
> see as a more direct benefit.
> If you have an agent and NMS that both support SNMPv2C/v3, then you always have
> the option of not implementing the overflow counters in your agent. The MIB
> compliance statements can make it clear that it is required to implement either
> the 64-bit counters or the 32-bit overflow counters, but it is not required to
> implement both.
> We have an existing solution to the 64-bit counters that works well with
> existing equipment. Let's not break it.
This is essentially saying that no one ever has to move up to 64
bits. If agent vendors and WGs continue to supply overflow counters,
there is no incentive to upgrade. The RFCs are clear that 64 bits is
the proper form for high-capacity measurements. If everyone wants
dual-32 instead, why not just amend SNMPv1 and other standards to add
overflow counter conventions, and deprecate 64 bits?
By continuing to add overflow counters, we are just increasing the
hodgepodge, and are not improving mibs toward standards. I agree with
Andy that we should drop them. I think dsmon is as good a place to
start as any.
Concord Communications, Inc.
600 Nickerson Road
Marlborough, MA 01752
RMONMIB mailing list