Re: MIDCOM MIB suggestions for addressing the notification requirements

Rohan,

Thank you reviewing the MIB module!

If I understand correctly, you suggest removing the three notification objects
from the MIB and not requiring the MIB implementation itself to take care about
notifying the MIDCIM clients about policy state changes.

I have three comments on this suggestion.

  - The effort of implementing the three notifications (including the
    mechanism of sending them) is quite low.

  - The lifetime as it is currently defined is the REMAINING lifetime
    of the policy decreasing its value continuously.  When a MIDCOM client
    writes to this object it jumps to a higher or lower value and then
    continues to decrease continuously.  The MIDCOM MIB implementation
    detects these write actions and sends notifications to the observing
    MIDCOM clients.
    If you want to detect all lifetime changes reliably with the Event MIB
    you need the Event MIB implementation to frequently poll the lifetimes of
    all policy rules and to configure two events (jumps up and jumps down)
    per policy rule.  This appears to be a waste of resources, because the
    polling interval needs to be rather short compared to many other monitoring
    tasks.  Also, configuring this in the Event MIB is more complex than
    configuring the policy rule itself.

  - The midcomGroupEvent cannot be detected by the Event MIB.  It is generated
    by the MIDCOM MIB implementation when the MIDCOM client uses the
    midcomGroupLifetime object as a shortcut to writing the lifetime of all
    member rules.  An Event MIB implementation would detect a lifetime change
    in all member rules and send a notification per member.  Only the
    MIDCOM MIB implementation knows that the change was caused by writing
    to midcomGroupLifetime and can generate a single midcomGroupEvent instead
    of a midcomRuleEvent per member rule.

Therefore, I doubt that at the bottom line we would achieve an
improvement by delegating the notification task to the Event MIB.

Thanks,

    Juergen
-- 
Juergen Quittek        [email protected]       Tel: +49 6221 90511-15
NEC Europe Ltd.,       Network Laboratories        Fax: +49 6221 90511-55
Kurfuersten-Anlage 36, 69115 Heidelberg, Germany   http://www.netlab.nec.de



--On 28.07.2004 16:34 h -0700 Rohan Mahy 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