
Message-Id: <9609161255.AA29816@freewheel.bgs.com>
To: if-mib@mda.vndad.tek.com
Subject: Re: Beeman_Doug: RE: ifCounterDisconTime 
In-Reply-To: kzm's message of Sun, 15 Sep 1996 20:15:58 -0700.
Sender: if-mib-owner@vndad.tek.com
Precedence: bulk

Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Mon, 16 Sep 1996 08:55:00 -0400
From: Chris Chiotasso <chris@bgs.com>


Keith,

The way you describe the current situation is the way it's supposed to work.  
In practice, when a card is hot swapped, sysUpTime is generally not reset so 
the NMS already has to handle the case where the counters don't follow the 
rule.  If the discontinuityTimer is added, the NMS could add the logic to deal 
with this as new releases went out and the existing implementations would work 
as they do now.  (I didn't say they were right, just unchanged from what they 
are now:)

The discontinuity timeStamp was chosen over a new ticking clock because thats 
what the definition of Counter32 in RFC1902 suggests.  The real issue was 
whether to change the OIDs for the ifTable's counter objects or not. 

At this point, things work whether the ifTable counter OIDs change or not.  We 
can handle it either way and for us a speedy solution to this would be much 
more advantageous than retaining the current counter OIDs as they are.  I 
would not oppose changing the OIDs if that's what others want.

Chris 

 >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>

 > There's been at least one mis-communication on this topic.  One of the
 > reasons that I sided with the minority who opposed this change in Montreal
 > was because of the potential confusion.
 > 
 > 1. The current situation:
 > 
 >   Counters are relative, which means that an NM application must retrieve
 >   a counter's value at two different times, T1 and T2, and difference the
 >   two retrieved values to determine how many occurrences there were in the
 >   time interval (T1,T2).  When an agent reboots, it forgets what values its
 >   counters had, and so, there is an unknown relationship between the values
 >   collected at T1 and T2 if a reboot occurred in the interval (T1,T2).  An
 >   NM application can detect when this happens by retrieving and remembering
 >   the value of sysUptime: if the sysUpTime value at T2 is not (T2-T1)
 >   greater than its value at T1, then a reboot occurred.  In a reboot
 >   occurred, then differencing the values retrieved at T1 and T2 will
 >   result in a value which bears no relation to reality, i.e., no value
 >   can be determined for that interval.
 > 
 > 2. The situation as the majority in Montral proposed:
 > 
 >   The proposal is that counter discontinuities are allowed at other
 >   times, i.e., at times when the value of sysUpTime does not revert to 0.
 >   Values which bear no relation to reality will now also occur at times
 >   other than at reboots.
 > 
 >   a. If a TimeStamp object is added, then its value will have to be
 >   retrieved in addition to sysUpTime; and, in addition to comparing the
 >   new sysUpTime value with the (remembered) value of sysUpTime at T1,
 >   the retrieved value of this new TimeStamp must also be compared to
 >   the remembered value of sysUpTime.  If this new TimeStamps's value is
 >   greater, then the interval is treated as if a reboot had occurred.
 > 
 >   b. If a "ticking-clock" object is added (i.e., an object whose value is
 >   the number of ticks since the last counter discontinuity, then the current
 >   algorithm (see 1. above) can be used except that this new object must be
 >   retrieved *instead* of sysUpTime.
 >  
 > Given the above, then assuming that this proposal goes ahead, then:
 > 
 >  - already-fielded NM applications must be modify in order to work
 >    correctly.  (They will only work as they do now if they're already
 >    broken :-).
 > 
 >  - NM application developers might prefer the ticking-clock object (see b.
 >    above) since it is more efficient in terms of extra objects, and is a
 >    smaller change from the existing algorithm.
 > 
 > Keith.
 >  
 > > As an application developer I don't see this change as a problem.  The way
      I 
 > > understand the proposed change, sysUpTime is still the main timer used to 
 > > evaluate the counters.  A new object will be added to say at what sysUpTim
     e 
 > > this entry has reset.  Anything already fielded will still work as it does
      
 > > now.  Nothing breaks.  New releases can use the new discontinuity object t
     o 
 > > improve the way the counters are managed.
 > > 
 > > Chris 
 > > 
 > >  >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
 > > 
 > >  > hello Beeman_Doug
 > >  > 
 > >  > > This looks fine. However, I would hope the agent resets all counters 
     in th
 > >      e 
 > >  > > affected row.
 > >  > 
 > >  > One of the difficult issues that we confront here
 > >  > is getting some confidence that management station
 > >  > applications writers accept this change, since
 > >  > one effect of such a new object is to change the way
 > >  > that counters should be read...
 > >  > 
 > >  > So I'll ask you, as I hope to ask whenever it seems fruitful,
 > >  > can you speak to whether this is fine from the point of view
 > >  > of writing/maintaining manager applications?
 > >  > 
 > >  > 
 > >  > 
 > >  > Ted Brunner			Video and Networking Division
 > >  > 				Tektronix
 > >  > 				MS 50-490
 > >  > ted.brunner@tek.com		14150 SW Karl Braun
 > >  > 503.627.1317			Beaverton OR 97005	
 > >  > 		
 > > 
 > > 
 >