Bert, let's see if I understand. You are saying model both 32 and 64 bit and use the appropriate ones on the interfaces that have the "appropriate" speeds so that wrapping does not occur too frequent. Further, when the low speed interface is queried for a 64 bit counter you would get no such object (and similarly for the high speed interface and the 32 bit counter). From a management station perspective I could live with that but - YUCK.
There is a little wrench that is thrown into this specific scenario. With MPLS you don't know which interface a path will use so you don't know which object to model until the path is setup. That seems painful.
Do I not understand all this or are we all speaking the same language?
Cheers, /gww
> -----Original Message-----
> From: C. M. Heard [mailto:heard@pobox.com]
> Sent: Monday, January 06, 2003 15:23
> To: Mreview (E-mail)
> Subject: RE: FW: 64 bit counters in MPLS MIBs
>
> On Mon, 6 Jan 2003, Wijnen, Bert (Bert) wrote:
> > Well, if you define a MIB module, then sometimes you define
> > Counters that for some implementations can exceed 32 bits
> > in less then an hour, but for other implementations (on slower
> > devices) they would only exceed 32bits in say 3 hours.
> >
> > Or some devices may have both highspeed and lowspeed ifaces,
> > and the first ones are implemented on cards taht have 64bit
> > registers with those counts, while the slow speed ifaces
> > only have 32bit registers. So in that scenario, it could be
> > OK (or so I (still) think).
>
> I agree with all of that. But for the scenario set forth above,
> the MIB module's compliance statement would presumably say that
> HC counters are required for highspeed ifaces, while
> LC counters are required for lowspeed ifaces. The criterion
> would be the speed of the interface, not whether the processors
> have native 64-bit arithmetic. The latter reason is what Tom
> Nadeau cited in the message that you forwarded (or at least
> that was what I understood).
>
> //cmh
>
>