Subject: (FRNETMIB) FR SLA MIB - Issue 2 - Free the Freerunning Counts!

From: "Rehbehn, Kenneth" <[email-masked]>
Date: Tue, 2 May 2000 16:27:15 -0400

> > 2) The frsldPvcDataTable is a table of free-running counters.  This
> > means
> > that the time period for the min, max, and average variables in the
> > frsldPvcDataTable would be infinite, making these values
> > meaningless.
> > What's the point?
> 
> The min, max and avg values in the data table were discussed in
> Washington.  I pointed the same thing out there, and this correction
> was acceptable at the time.  From the meeting minutes:
> 
>      Rob pointed out an error in the document on
>      frsldPvcDataDelayMin/Max/Avg.  The reference is to the
>      free-running table and this should have relevance only to the
>      free running world. This will be corrected.
> 
> Further, I showed this change again in Adelaide.  We can either alter
> the text to state how the object  decay should be handled or add a
> variable to show the life span of the value.  This would bring up
> implementation issues as to whether to use a sliding window or a
> polled window.  I don't feel comfortable removing the values in that
> they are needed if the implementation chooses not to do any sampling.
> What would you prefer?

If Min/Max/Avg don't make sense in a table of free running counts then they
should be removed.  Don't add complexity by adding concepts such as object
decay or life span.  Eliminate the objects.

If an implementation chooses not to do any sampling then the implementation
can live with the choice.  It is simple enough to use frsldSmplCtrlTable to
structure a longish period of time which will be able to snag the
Min/Max/Avg.  Don't overload the free running counts to do this.

Staring at this makes me wonder - why do we even need free running counters?
This MIB should be restricted to the historical record as delimited by the
interval boundaries.  The MIB seems to be both a source of raw material for
some manager that then "cooks" the data for reporting AND a source of
"cooked" data for a manager to report.  Pick one approach and stick with it!
I recommend the "cooked" data approach as found in the sample tables.  How
these tables get created is an implementation specific issue.

In conclusion, remove the table free running counters.

Focus the MIB on reporting SLA results - not the mechanism for building the
results.
X-Info: To unsubscribe, email [email-masked]' with
X-Info: 'unsubscribe frnetmib' in the body of the message.