Rptr MIB Edits - Issue 8

John Flick <johnf@hprnljf.rose.hp.com> Thu, 08 May 1997 01:10 UTC

Received: from cnri by ietf.org id aa13483; 7 May 97 21:10 EDT
Received: from palrel1.hp.com by CNRI.Reston.VA.US id aa25146; 7 May 97 21:10 EDT
Received: from hprnd.rose.hp.com (daemon@hprnd.rose.hp.com [15.29.43.139]) by palrel1.hp.com with ESMTP (8.7.5/8.7.3) id SAA28447; Wed, 7 May 1997 18:04:50 -0700 (PDT)
Received: from hprnljf.rose.hp.com by hprnd.rose.hp.com with ESMTP (1.37.109.20/15.5+ECS 3.3) id AA008633481; Wed, 7 May 1997 18:04:41 -0700
Received: from localhost (johnf@localhost [127.0.0.1]) by hprnljf.rose.hp.com with SMTP (8.7.5/8.7.3) id SAA27877; Wed, 7 May 1997 18:05:14 -0700 (PDT)
Message-Id: <199705080105.SAA27877@hprnljf.rose.hp.com>
X-Authentication-Warning: hprnljf.rose.hp.com: Host johnf@localhost [127.0.0.1] didn't use HELO protocol
To: vgmib@hprnd.rose.hp.com
Cc: maria@xedia.com
Subject: Rptr MIB Edits - Issue 8
Date: Wed, 07 May 1997 18:05:14 -0700
From: John Flick <johnf@hprnljf.rose.hp.com>

>    There is still some debate in the SNMP community about the
>"proper" way to represent a Counter64 as two Counter32s (such that the
>MIB can be implemented by a V1 agent/manager with no loss of
>precision). As far as I can tell, there has been no general agreement
>(across working groups) about the best way to do this. (There has been
>discussion in the RMON working group in particular about this.) It
>would be best if every MIB used the same scheme. The argument against
>the low/high Counter32 scheme used in the vgmib is that the two
>counters do not follow the definition of counter behavior from RFC1902:
>
>   The Counter32 type represents a non-negative integer which
>   monotonically increases until it reaches a maximum value of 2^32-1
>   (4294967295 decimal), when it wraps around and starts increasing
>   again from zero.
>
>Instead, it has been proposed that one Counter32 count the underlying
>event and the second Counter32 count the number of times the first one
>wraps. Personally, I do not think it is a big issue if the counters
>are implemented as indicated (it is a "formality/legalese" thing and
>the current mechanism seems to me to be easier to implement in some
>cases). 

Addressing this issue would mean renaming some counters, and updating
the DESCRIPTIONS of the affected counters.  The following counters
would be renamed:

    vgRptrMonL32TotalReadableOctets   => vgRptrMonTotalReadableOctets
    vgRptrMonU32TotalReadableOctets   => vgRptrMonReadableOctetRollovers
    vgRptrPortL32ReadableOctets       => vgRptrPortReadableOctets
    vgRptrPortU32ReadableOctets       => vgRptrPortReadOctetRollovers
    vgRptrPortL32UnreadableOctets     => vgRptrPortUnreadableOctets
    vgRptrPortU32UnreadableOctets     => vgRptrPortUnreadOctetRollovers
    vgRptrPortL32HighPriorityOctets   => vgRptrPortHighPriorityOctets
    vgRptrPortU32HighPriorityOctets   => vgRptrPortHighPriOctetRollovers
    vgRptrPortL32NormPriorityOctets   => vgRptrPortNormPriorityOctets
    vgRptrPortU32NormPriorityOctets   => vgRptrPortNormPriOctetRollovers

I had to resort to some cheesy abbreviations in the names of the rollover
counters to keep the counter names from getting absurdly long.
Here are the updated definitions of the PortReadableOctets triplet of
counters, showing an example of the way the DESCRIPTIONS would be
updated for all of the affected counters:

       vgRptrPortReadableOctets OBJECT-TYPE
           SYNTAX     Counter32
           MAX-ACCESS read-only
           STATUS     current
           DESCRIPTION
                   "This object is a count of the number of octets
                   contained in good frames that have been received
                   on this port.  This counter is incremented by
                   OctetCount for each frame received on this port
                   which has been determined to be a readable frame
                   (i.e. each frame counted by
                   vgRptrPortReadableFrames).

                   Note that this counter can roll over very
                   quickly.  A management station is advised to
                   also poll the vgRptrPortReadOctetRollovers
                   object, or to use the 64-bit counter defined by
                   vgRptrPortHCReadableOctets instead of the two
                   32-bit counters.

                   This two-counter mechanism is provided for those
                   network management protocols that do not support
                   64-bit counters (e.g. SNMPv1).  Note that
                   retrieval of these two counters in the same PDU
                   is NOT guaranteed to be atomic.

                   This counter may experience a discontinuity when
                   the value of the corresponding instance of 
                   vgRptrPortLastChange changes."
           REFERENCE
                   "IEEE Standard 802.12-1995, 13.2.4.5.1,
                   aReadableOctetsReceived."
           ::= { vgRptrMonPortEntry 2 }

       vgRptrPortReadOctetRollovers OBJECT-TYPE
           SYNTAX     Counter32
           MAX-ACCESS read-only
           STATUS     current
           DESCRIPTION
                   "This object is a count of the number of times
                   that the associated instance of the
                   vgRptrPortReadableOctets counter has rolled over.

                   This two-counter mechanism is provided for those
                   network management protocols that do not support
                   64-bit counters (e.g. SNMPv1).  Note that
                   retrieval of these two counters in the same PDU
                   is NOT guaranteed to be atomic.

                   This counter may experience a discontinuity when
                   the value of the corresponding instance of 
                   vgRptrPortLastChange changes."
           REFERENCE
                   "IEEE Standard 802.12-1995, 13.2.4.5.1,
                   aReadableOctetsReceived."
           ::= { vgRptrMonPortEntry 3 }

       vgRptrPortHCReadableOctets OBJECT-TYPE
           SYNTAX     Counter64
           MAX-ACCESS read-only
           STATUS     current
           DESCRIPTION
                   "This object is a count of the number of octets
                   contained in good frames that have been received
                   on this port.  This counter is incremented by
                   OctetCount for each frame received on this port
                   which has been determined to be a readable frame
                   (i.e. each frame counted by
                   vgRptrPortReadableFrames).

                   This counter is a 64 bit version of
                   vgRptrPortReadableOctets.  It should be used by
                   Network Management protocols which support 64 bit
                   counters (e.g. SNMPv2).

                   This counter may experience a discontinuity when
                   the value of the corresponding instance of 
                   vgRptrPortLastChange changes."
           REFERENCE
                   "IEEE Standard 802.12-1995, 13.2.4.5.1,
                   aReadableOctetsReceived."
           ::= { vgRptrMonPortEntry 4 }



Let me know what you think.

Thanks,
John