Hey Dan,
Hmmmmm, I remember when ethernet was really fast.
Actually I remember when 2400 baud was fast :o)
I can buy a 2 Tbps fiber link, supporting IP, today.
And that number should be around 40 - 100 Tbps by
Q3-Q4 next year.
At 100 Tbps, a 64 bit counter will roll over
in 2.1350398 days. Do 50 hour turnover times
justify rollover counters? I think so.
At just 10 Tbps, which is already being done on
vendors benches, no problem, you get turnover in
under a month. Isn't 21 days a turnover time frame
that would justify a rollover counter?
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: Dan Romascanu [mailto:dromasca@avaya.com]
Sent: Tuesday, October 03, 2000 10:46 AM
To: Carter Bullard; rmonmib@ietf.org; mibs@ops.ietf.org
Subject: RE: [RMONMIB] comments on draft-ietf-rmonmib-dsmon-mib-02.txt
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>
>