Subject: RE: re-review of Notify Log MIB

From: Randy Presuhn <[email-masked]>
Date: Mon, 20 Dec 1999 15:39:19 -0800 (PST)

Hi -

> Date: Mon, 20 Dec 1999 14:46:50 -0800
> To: Randy Presuhn <[email-masked]>, [email-masked]
> From: Ramanathan Kavasseri <[email-masked]>
> Subject: RE: re-review of Notify Log MIB
> List-Id: IETF disman Working Group mailing list <[email-masked]>
...
> Assuming we permit wraps, how will you differentiate an old
> entry from a new one? 

I outlined an algorithm on this list on December 14:

| The current draft permits two different, implementation-specific
| behaviours on wrap.  Which of these is implemented will affect
| how a management application goes about finding "all log records
| that have been added since I last checked".
|
| I think an algorithm that would tolerate both would need to:
|     -  remember the index from the last walk of the table
|     -  if the index for the retrieved entry hits the max,
|        start over at the top of the table
|     -  check the nlmLogDateAndTime (if implemented) for each entry 
|        to make sure it is greater than or equal to that from the last
|        table walk
|     -  terminate after nlmConfigLogEntryLimit iterations
|
| The nlmLogTime column cannot be used as a termination condition
| if the log is potentially persistant, thus the need for the last
| termination condition.

Note that if we assume that log persistance is unlikely in
systems that don't support DateAndTime, we don't have to
worry about the unsuitability of TimeStamps for determining
entry age across reboots, and could thus reasonably employ
nlmLogTime for the termination heuristic in systems that lack
DateAndTime (and, the heuristic assumes, log entry persistance)

>                       What if the log wraps, and at the same time,
> the agent resets - perhaps it's far-fetched, but it's a valid scenario.

Log entries have no defined persistance.  It's certainly
not realistic to expect persistance from a system that can't
do DateAndTime.  Personally, I think the TimeStamp is bogus
and should be removed, and we should only use DateAndTime.
However, that wasn't the consensus.

> As was pointed out above, if the MIB
> or the agent gets reset, you'll still need to deal with notification
> log loss. 

That's a separate problem, was not one of our requirements, and
we really shouldn't be adding it to our scope now.

> I would like to see the "MUST be flushed" text, with the rider that
> we resolve the issue when we get implementation feedback the
> next time around. A solution (which is ugly, and will likely
> get shot to bits, but I'll throw it out anyway) is to perhaps
> have a "history table" that holds the entries that were
> flushed at wrap time...There should be a timelimit
> after which entries in this table will be aged out. This way,
> we get the "flushed entries" behaviour, while trying to minimize
> any possible notification loss. I still consider it ugly
> to try any sort of los-prevention as the purpose of the MIB is
> not to "guarantee" that logs will remain until read.

This is changing the requirements from those of a log to those
of a disseminator.  This may be worth discussing, but not in
the context of resolving the reviewer's comments.

> Besides, I wonder how long the engine will need to run to generate
> that amount of logs...BTW, please note that I'm suggesting this abysmal
> solution (or anything else) be reserved till implementation feedback,
> so we can get *some* information on this and other possible
> issues with the MIB...

To satisfy the reviewer, we need to get rid of the ambiguity,
one way or another.

Sharon has argued that the "no flush on wrap" solution makes
more operational sense.  The only cases where it would be a
problem is systems that don't support DateAndTime that have
persistant log storage (pretty improbable) and stay up enough
to have logged more than 2^32-1 notifications.  Even then,
a heuristic could use the existance of a (probably huge) gap
in the indexes in addition to the TimeStamp to determine when
a walk has gone from new stuff into old stuff.

> >Since there is a strong objection to "must flush", would there
> >be any objections to resolving the IESG reviewer comment by
> >deleting the words "and may flush existing entries" from the
> >DESCRIPTION of nlmLogIndex?
> 
> 
> If we don't say "must flush", we'll then need to modify the DESCRIPTION for
> nlmLogIndex to describe the intended behaviour at wrap-time...

It already says it wraps.  We have other words on limiting
the number of entries.  I believe all we need do is delete
the "must flush" phrase.

> And we'll need to note that a "get-next" of the last index read
> will not necessarily result in a new log entry - how useful is that?

That's already true, and will be true for any approach where the
index can wrap or be reset or re-used.  Avoiding this would
require going to something like a DateAndTime + unique id.

> If there is still strong objection to a "flushing entries" scenario, then I'll
> remove the "and may flush existing entries" text, but I'd like to know
> what the intended behaviour should be at that point.
...

Just what it says.  The index wraps.  The descriptions of
nlmConfigLogEntryLimit, nlmConfigGlobalAgeOut, and, of course,
nlmLogEntry spell out all the rest.  In other words, index
wrap would of itself be of no consequence whatsoever to the
entry removal policy.

We actually end up with a net simplification.

 ------------------------------------------------------------------------
 Randy Presuhn           [email-masked]       http://www.bmc.com/
 Voice: +1 408 546-1006  BMC Software, Inc.  1-3141  2141 N. First Street
 Fax:   +1 408 965-0359  San Jose, California 95131  USA
 ------------------------------------------------------------------------
 Any relationship between my opinions and BMC's should be coincidental.
 ------------------------------------------------------------------------

---

From: Ramanathan Kavasseri <[email-masked]>
Date: Mon, 20 Dec 1999 16:31:06 -0800

>DateAndTime (and, the heuristic assumes, log entry persistance)

ok.

>we really shouldn't be adding it to our scope now.

Ahh, I meant to add "and we shouldn't be adding it to our scope now"...
:-)

>the context of resolving the reviewer's comments.

Again, I meant to say doing any such modification would be undesirable
at this stage, as such loss-prevention was not one of the original requirements of the MIB. I seem to be leaving out the all important phrase "should
not be changing requirements at this stage" consistently...

>a walk has gone from new stuff into old stuff.

"heuristic" is a good term to use for this, since I can see corner
cases like sysUpTime resetting after an index wrap that need
to be accounted for.
But that again is up to the network management system to factor
into its heuristic, and not the problem of the notif-log-mib
(certainly not at this stage).

I see why you dislike TimeStamps... :-)

>the number of entries.  I believe all we need do is delete

ok.

>require going to something like a DateAndTime + unique id.

ok. It's a price to pay for the wrapping - I can live with that.

>We actually end up with a net simplification.

Ok. :-)
Will make the necessary edits.

Ram