Re: MIDCOM MIB suggestions for addressing the notification requirements

Hi Rohan,

we are coming slightly back to this during the MIDCOM session.

Thanks,

  Martin

--On Mittwoch, 28. Juli 2004 16:34 Uhr -0700 Rohan Mahy <[email protected]> 
wrote:

| Hi,
|
| When working on the requirements for MIDCOM, I observed that the
| notification requirement always seemed slightly misplaced.  Many of the
| motivations for notification had to do with monitoring or traditional
| network management of some kind which was orthogonal to the core open and
| close pinholes and bindings functionality in the semantics document.
| What really convinced me that the notification function was separate was
| when I started to imagine all the other things that might want to be
| decoupled from the core MIDCOM protocol and still find out about
| MIDCOM-related notifications.
|
| To that end, I propose that we allow the MIDCOM notification to be
| decoupled from the core MIDCOM MIB, and that we reuse an existing MIB to
| facilitate the notifications.  Specifically, we can use the Event MIB
| (RFC 2981) to set notifications for interesting events that occur with
| other MIB variables.
|
| For example, the simplest use of the Event MIB would monitor the
| Application Management MIB (RFC 2564) to receive notifications if the
| middlebox controller application terminates unexpectedly or is going down
| for maintenance.
|
| In another example, the Event MIB would monitor the Meter MIB (RFC 2720--
| which provides a MIB for the real-time traffic of individual network
| flows) to see if certain flows exceed a threshold (or when the traffic
| flow drops to zero for a period of time).
|
| Finally, the Event MIB could monitor the the Host Resources MIB (RFC
| 1514) to watch for CPU  or memory consumption thresholds.
|
| All of this type of monitoring is much closer to the traditional uses of
| SNMP than the rest of the MIB, and so is much more likely to be useful by
| other more traditional SNMP monitoring applications.  It would be a shame
| to reinvent a MIDCOM-specific notification mechanism, when a more general
| one is already in use that is likely to be more appropriate for many of
| its consumers.
|
| thanks,
| -rohan
|
|
| _______________________________________________
| midcom mailing list
| [email protected]
| https://www1.ietf.org/mailman/listinfo/midcom
|