RE: FW: 64 bit counters in MPLS MIBs

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

Andy answers me...

> At 06:07 PM 1/6/2003 +0100, Wijnen, Bert (Bert) wrote:
> >I had suggested to MPLS MIB people that at places
> >where they use parallel 64 and 32 bit counter (the
> >32-bit values fo those systems that do not support 
> >64bit), that it might be better to use just 64 bit
> >and forget the 32 bit counters.
> >
> >This is what I am getting back. Any opinions/input
> >or comments?
> 
> As Mike pointed out, the real issue is the expected rollover time
> for the counter, not just the SNMPv1 vs. SNMPv2C issue that
> Dave mentioned.
> 
> Remember the '1 hour rule'?  Remember the many discussions 
> that led to the text in RFC 1573, sec. 3.2.6?  Remember that
> we don't have Unsigned64 or Integer64 because some people
> objected on the grounds a reasonable '1 hour rule' could
> not be written for these types?
> 
> Well, we still have the '1 hour rule' in effect, and therefore
> it would be inappropriate to tell the MPLS MIB people they
> should remove their 32 bit counters.  The correct design
> depends on the possible instances of the counter. For many
> counters, this is to have both 32-bit and 64-bit counters 
> and use conformance statements to specify which versions need 
> to be implemented.  The 64-bit versions are named with an HC
> in the descriptor (by convention).
> 

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.
- regular LC counters for things that do not roll over within
  an hour.

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 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.)

I do not like the RFC1573 that much where they are all optional
groups. It is then pretty difficult for a NMS (I think) to
figure out which device does what or which table entries do
have the HC counters, which ones have both HC and LC counters,
and which have just LC counters.

For the second group (the counter that do not roll over
in less than an hour) I have been telling people that it is
OK with me if they already have 64bit counters and if the WG
decides that therefor they rather make all counters 64bit.
Also, if they roll over in say 2 hours... it is quite possible
that a few years from now they roll over much faster.
Specifically if the intended devices-to-be-managed have native
64bit arithmetic anyway, then I see no problem making all 
counters of the type Counter64.

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.


> This does not mean I supported the '1 hour rule', then or now.
> The rule for Unsigned64 is so bloody obvious it's not
> surprising we missed it: "I need to model a quantity that is 
> greater than 2^^32." End of rule.
> 
that is another gripe (which I fully understand) but not part
of this discussion I think/hope.

Bert