RE: FW: 64 bit counters in MPLS MIBs

["Wijnen, Bert (Bert)" <bwijnen@lucent.com>]

> On Mon, 6 Jan 2003, Wijnen, Bert (Bert) wrote:
> > So I saw in their MIB modules:
> > - HC (counter64) counters with LC counters (counter32) for 
> >   SNMPv1 access or devices that do not have native 64bit
> >   arithmenthic.
> 
> I think providing LC counters _for this reason_ is a bad idea,
> if the HC bit counters are needed in the first place.  It's
> just giving license to implement something inadequate.  Note
> that the "solution" cannot achieve its intended purpose
> unless the LC counters figure as an _alternative_ to the HC
> counters, not as an optional-to-implement supplement to them.
> 
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).

> > - regular LC counters for things that do not roll over within
> >   an hour.
> 
> That, of course, is OK.
> 
> > Now... for the first set, I have been giving advice lately that
> > with me it is OK if the WG decides that they just do HC counters
> > and do not provide LC counters. If they want to provide them,
> > then fine... but it just adds objects and complexity in 
> > compliance statements and for management apps. And worse,
> > you can never get rid of them...
> 
> I'd say it's not OK (given the stated reason).  Providing
> alternative means to do the same thing is BAD for
> interoperability.  Providing alternatives that don't work
> properly is even worse.
> 
See above

> > (I like DBH suggestion to add them but make then deprecated
> > right away... that way old systems can still do it if they
> > want, but it is not needed.)
> 
> For SNMPv1 compatibility, maybe.  But in this case you
> don't make the 32-bit counters an _alternative_ to the
> 64-bit counters, you make them an optional-to-implement
> _supplement_.  (And if you want the alternative to work
> correctly, for each a 32-bit "event" counter you would
> have a corresponding 32-bit "rollover" counter.)
> 
Aha... OK subtle wording (for me at least). The word supplement
is indeed better.

> > I know that such is a bit harsh on SNMPv1 management apps,
> > but then, I believe that specifically on the NMS side
> > it is time by now to move over to SNMPv3.
> 
> Yep.  Presumably that's why SNMPv3 is Standard and SNMPv1
> is Historic.
> 
Finally ;-) We still need to drink some beer/wine/softdrinks
or such to that at the next IETF... let us not forget!

Bert
> //cmh
> 
>