[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: BCP and Notifications (was: snmpconf FW: MIBs for events and notification logging)
The important point here is not reliability, by verifiability. Even
when we have logs on the managed device, that does not guarantee that
the message will get through. Networks go down sometimes for a long
periods of time. The idea is: did the message get through in some finite
period of time, and if not what is done? Debating 'reliability' is a red
herring. In the end, with reasonable retry implementations, the message
gets through enough of the time to be helpful when using
INFORMS. Discussion beyond that falls into the realm of how many angels
can dance on the head of a pin.
> Please note that getting a response back from an Inform does not
> reliably confirm that a management application has "gotten" the
> notification. There can be different implementation strategies
> of how a notification receiver is implemented and how it is
> connected to management applications and feeds them a stream
> of notifications. Many commercial products are designed so
> that a notification system is a system service that distributes
> notications to clients (which are the management applications
> running on the system, or even on another system).
> To have "reliability", the generating system MUST log each
> notification, and MUST NOT remove the log entry when it gets
> back a Response (the confirmation) to an Inform. it MUST also
> have the mechanism so that a receiver can determine if it
> has has not received notifications, and log entries of those
> notifications have been discarded from the log due to
> system events such log resource limitations, or system restart
> (when the log is not stored in persistent storage), etc.
> On Fri, 2 Nov 2001, Randy Presuhn wrote:
> > Hi -
> > > Message-ID: <2413FED0DFE6D111B3F90008C7FA61FB0DDC27FF@nl0006exch002u.nl.lucent.com>
> > > From: "Wijnen, Bert (Bert)" <firstname.lastname@example.org>
> > > Subject: RE: BCP and Notifications (was: snmpconf FW: MIBs for events and
> > > notification logging)
> > > Date: Fri, 2 Nov 2001 13:43:42 +0100
> > ...
> > > I think the possibly more important thing to focus on is that the
> > > sender of an INFORM mots probably gets a response when the
> > > notification has arrived at the destination. If not, then
> > > it can decide to retry a few times, and finally it can decide
> > > to save the information for anothe retrt later or for
> > > a manager to pickup later.
> > ...
> > This makes it possible to construct what in CMIP-land is
> > called a disseminator. Think of it as a log in which
> > entries persist only until their delivery to their final
> > destination has been confirmed. It really DOES give
> > reliable notification, even across reboots, if one needs
> > such a thing.
> It's been a few years since I've read this, but if you
> are saying that entries are not inserted in the log
> when a notification is confirmed, then I'm not sure if
> this is reliable. I'd have to look at what CMIP required
> before a notification was confirmed. And if implementations
> are a notification service that distributes notifications
> to clients without itself first logging them, before
> sending a confirmation then it is not reliable.
> One subtle difference between CMIP and SNMP is that
> responses for Informs in SNMP MUST be sent in a very
> short time or the notification generator will resend the
> Inform. This changes the implementation strategy of
> the receiver.
> > Randy Presuhn BMC Software, Inc. 1-3141
> /david t. perkins
Jon Saperia email@example.com