Hey Bert,
For those on the list(s), RFC 2578 suggests a period
of 1 hour for counters. Given this then, the 64 bit
counter, when counting bits, will require rollover
support at 10 ^ 15.7096 bps.
I personally will be very pleased when 10 ^ 15.7096 bps
is realized and, as a commemoration to this rather amazing
event, I recommend leaving a 32-bit rollover counter
in the standard MIB definition as a data type to handle
this inevitable condition.
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: Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com]
Sent: Wednesday, October 04, 2000 4:11 AM
To: rmonmib@ietf.org; mibs@ops.ietf.org; Carter Bullard
Subject: RE: [RMONMIB] comments on draft-ietf-rmonmib-dsmon-mib-02.txt
Comment inline
> ----------
> From: Carter Bullard[SMTP:carter@qosient.com]
> Reply To: carter@qosient.com
> Sent: Wednesday, October 04, 2000 12:29 AM
> To: 'Dan Romascanu'; rmonmib@ietf.org; mibs@ops.ietf.org
> Subject: RE: [RMONMIB] comments on
> draft-ietf-rmonmib-dsmon-mib-02.txt
>
> 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.
>
I am not going to speculate if/when we would need more than 64 bit
counters, but 50 hour turnover is not a reason for rollover. See the
definition of 64-bit counters (i.e. Counter64) in RFC2578)
> 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?
>
Certainly not, see Counter64 definition
Bert