RE: FW: 64 bit counters in MPLS MIBs

[Andy Bierman <abierman@cisco.com>]

At 08:29 PM 1/6/2003 +0100, Wijnen, Bert (Bert) wrote:
>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...

agreed


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

agreed -- we did this with the DSMON MIB if I recall correctly.


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

this is a problem for all optional or conditionally mandatory
groups.  The Capabilities MIB in the SMIng WG in meant to address
this problem.


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

The problem is MIB objects which can be applied to fast
or slow interfaces (e.g. RMON), sometimes on the same device.
Our conformance info sections are useless in this case.
The NMS must simply poll both the HC and LC counters
for every possible instance and see what the agent returns.


>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 is the ongoing debate about forcing a migration
to SNMPv3 vs. providing pragmatic solutions for existing
environments.  I don't think standards writers should be
ignoring practical application of their work, but I also
don't care too much about SNMPv1-only environments.
The upgrade to SNMPv2C is not that difficult.



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

no, although we *still* don't have these data types 13 years later...


>Bert 

Andy