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

[Dan Romascanu <dromasca@avaya.com>]

There is an Arabian nights story dealing with this issue...

The rollover of a 64 bits counter happens after 1.84 e+19 bits = 1.84 e+9
seconds on a fully loaded 10 Gbps link =~ 58 years.

I think that we have consensus that we should not worry. 

Regards,

Dan



> -----Original Message-----
> From:	Carter Bullard [SMTP:carter@qosient.com]
> Sent:	Tue October 03 2000 16:27
> To:	rmonmib@ietf.org; mibs@ops.ietf.org
> Subject:	RE: [RMONMIB] comments on
> draft-ietf-rmonmib-dsmon-mib-02.txt
> 
> Gentle People, 
> 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? 
> 
> Carter 
> 
> Carter Bullard 
> QoSient, LLC 
> 300 E. 56th Street, Suite 17A 
> New York, New York  10022 
> 
> carter@qosient.com 
> Phone +1 212 813-9426 
> Fax   +1 212 813-9426 
> 
> 
> -----Original Message----- 
> From: rmonmib-admin@ietf.org [ <mailto:rmonmib-admin@ietf.org>]On Behalf
> Of 
> Larry Stabile 
> Sent: Tuesday, October 03, 2000 9:30 AM 
> To: rmonmib@ietf.org; mibs@ops.ietf.org 
> Subject: RE: [RMONMIB] comments on draft-ietf-rmonmib-dsmon-mib-02.txt 
> 
> 
> 
> Les Bell: 
> 
> > 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
> 
> > everywhere. 
> > 
> > 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. 
> 
>  - Larry 
> 
> -------------- 
> 
> Larry Stabile 
> Concord Communications, Inc. 
> 600 Nickerson Road 
> Marlborough, MA 01752 
> lstabile@concord.com 
> 508-303-4246 
> 
> _______________________________________________ 
> RMONMIB mailing list 
> RMONMIB@ietf.org 
> <http://www.ietf.org/mailman/listinfo/rmonmib> 
>