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
- Rptr MIB Edits - Issue 8 John Flick