Re: FC Management MIB - proposed changes

[Keith McCloghrie <kzm@cisco.com>]

> Use Counter64 only if necessary. Counter32 would be the
> preferred solution.

Right.  The SMI (RFC 2578) says:

   A requirement on "standard" MIB modules is that the Counter64 type
   may be used only if the information being modeled would wrap in less
   than one hour if the Counter32 type was used instead. 

> -There are no Counter64s in FC standards that we need in the MIB

A Counter32 which counts octets at 1Gbs can wrap in about 34 seconds !!

If we assume the minimum packet size is approx 50 bytes (e.g., RFC 2625
says that an FC frame containing an ARP packet is 52 bytes long), then
a Counter32 which counts packets at 1Gbs can wrap in 28 minutes.
Thus, every counter which can increment at a sustained rate of at
least one increment per packet needs to be a Counter64.

Note that it's common that instrumentation (e.g., hardware) doesn't
keep 64-bit counters; in such cases, the SNMP agent needs to maintain
the Counter64 variable by polling the instrumentation at whatever rate
is necessary to avoid loss of information.

> -Some existing tools have problems with Counter64 and Unsigned64

Such tools should have been upgraded to support SNMPv2c/SNMPv3 long ago.

> -No Gauge64 in SMIv2
 
See RFC 2856.

> > I assume you mean the inadequate security of SNMPv1 and SNMPv2c,
> > i.e., nobody perceives that SNMPv3 is insecure, right ??
> Yes, SNMPv3 is secure, but not that many implementations.

Actually, there are lots of implementations.  I believe the issue is
how many customers feel security is important enough to deploy SNMPv3,
and in today's climate, I suspect that number is rising.

Keith.