RE: FW: 64 bit counters in MPLS MIBs

["C. M. Heard" <heard@pobox.com>]

On Mon, 6 Jan 2003, Harrington, David wrote:

> While I recognize the overhead caused by supporting 64-bit values on
> devices without native 64-bit support, I think it is something of a red
> herring. If the amount of traffic crossing an interface will exceed the
> one-hour guideline, and the hardware/software being used is incapable of
> supporting emulation of 64-bit Counters, then the designers of the
> product should take a closer look at their designs.

Thank you. That was my point exactly. You said it much better than I did.

> If there is any likelihood that an interface may exceed the one-hour
> guideline, then Counter64s are called for. This would exempt a managed
> object designed to support an interface that cannot possibly exceed the
> one-hour guideline, such as the byte count for a 1M Ethernet interface.

Agreed.  And that's what the IF-MIB (RFC 2863) does, although it makes
the 32/64 bit selection the basis of ifSpeed and ifHighSpeed, and also
requires that 32-bit counters be present whenever their 64-bit are
needed.

> For mib objects supporting interfaces where the speed is not known at
> mib-design-time, then it should be assumed that at some point, it will
> be applied to an interface that qualifies for the one-hour guideline,
> and thus they should use Counter64s.

Either that, or face the possibility that at some future date you
may need to extend the MIB module in the manner that was done when
the RFC 1573 version of the IF-MIB was built from the old MIB-II
Interfaces Group from RFC 1213.


On Mon, 6 Jan 2003, Wijnen, Bert (Bert) wrote:
> > -----Original Message-----
> > From: Glenn Waters [mailto:gww@nortelnetworks.com]
> > Sent: maandag 6 januari 2003 21:56
> > To: Mreview (E-mail)
> > Subject: RE: FW: 64 bit counters in MPLS MIBs
> > 
> > 
> > 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.
> 
> But I believe that that is what RFC2863 (IF-MIB) does, no?
> And that seems to be one that everyone needs to implement
> on virtually every IP-capable device. Oh well. So much for
> that then.

It isn't _quite_ that bad.  Actually, the IF-MIB compliance
statements seem to me to be very well-designed, and they
won't cause you to suffer from that that particular brand of
yuckiness.

What happens is this:  every interface is required to implement
the ifGeneralInformationGroup, which as the name implies contains
some general stuff.  Among that stuff if ifType and ifSpeed.
From ifType you can in principle determine whether the interface
is bit-oriented (e.g., DS1, DS3, SONET/SDH, etc.), fixed-length
(includes character oriented interfaces like RS-232 or cell-
riented interfaces like ATM), or packet-oriented (e.g., Ethernet).
Bit-oriented interfaces are not required to maintain any IF-MIB
counters (although there are frequently other counters in the
media-specific MIB that will be maintained).  Fixed-length
interfaces are required to maintain octet counters.  Packet-
oriented interfaces are required to maintain octet counters and
packet counters.  Then, depending on its speed, a particular
interface may be required to maintain only 32-bit octet counters
(ifFixedLengthGroup), both 32-bit and 64-bit octet counters
(ifHCFixedLengthGroup), 32-bit octet and packet counters
(ifPacketGroup), 32- and 64-bit octet counters and 32-bit
packet counters (ifHCPacketGroup), or 32- and 64-bit octet
and packet counters (ifVHCPacketGroup).  Here is the breakdown:

   ifType ---> |                      |                  |
===============|     Fixed Length     |  Packet Oriented |
 ifSpeed (bps) |                      |                  |
---------------+----------------------+------------------+
   20,000,000  |  ifFixedLengthGroup  |  ifPacketGroup   |
     or less   |                      |                  |
---------------+----------------------+------------------+
 >  20,000,000 | ifHCFixedLengthGroup | ifHCPacketGroup  |
<= 650,000,000 |                      |                  |
---------------+----------------------+------------------+
   more than   | ifHCFixedLengthGroup | ifHCPacketGroup  |
  650,000,000  |                      |                  |

So, for every ifType that your NMS supports, you will know
which counters to poll.  You don't have to do a trail poll
and be told noSuch.  Furthermore, an SNMPv1 manager can
always get the 32-bit counters even from a high speed
interface;  by definition, they always return the lower
32 bits of their 64-bit counterparts, and they are often
useful even though they violate the 1-hour rule.

This isn't ideal, but it seems to be a reasonable compromise
between the desirability from the device's perspective of
only having to support 32-bit counters on slow interfaces
(which tend to be more numerous and have less associated
computing power than their high-speed counterparts) and
the desirability from the NMS's perspective of having
everything uniform.  And it does not leave SNMPv1 management
apps completely out in the cold.

Getting back to the original topic, if the MPLS folk wanted
to do something like the IF-MIB where 32 and 64 bit counter
objects are defined in the MIB and which ones you implement
are tied to something like ifSpeed, then I think they are on
solid ground. But if they want to put something like "implement
the C64s if you have enough processing horsepower, do the C32s
otherwise" in the compliance statements then I think pushing
back on them is quite in order.

//cmh