[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)



I think I posted a long long time ago an idea that
I first heard from Geoff Carpenter (then at IBM Watson
Research). The idea is:

  - managed device sends a heartbeat every x interval
  - heartbeat includes latest sequence number of notification 
    entries in a log file (basically a MIB accessible file)
  - manager can determine from that 
    - we're still in touch with the managed device
    - if it has all the latest notification information
    - if not, it can go pick up the missing information

I think that is a neat idea... but we are diverging I guess.
This probably belongs more in disman WG

Bert 

> -----Original Message-----
> From: David T. Perkins [mailto:dperkins@dsperkins.com]
> Sent: Friday, November 02, 2001 6:40 PM
> To: Randy Presuhn
> Cc: bwijnen@lucent.com; saperia@jdscons.com; snmpconf@snmp.com;
> schishol@nortelnetworks.com
> Subject: RE: BCP and Notifications (was: snmpconf FW: MIBs for events
> and notification logging)
> 
> 
> HI,
> 
> 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.lu
> cent.com>
> > > From: "Wijnen, Bert (Bert)" <bwijnen@lucent.com>
> > > 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
> 
> Regards,
> /david t. perkins
>