Subject: Event classes

From: Balazs Lengyel <[email-masked]>
Date: Thu, 25 May 2006 18:12:03 +0200

I wrote an alternative version of chapter 3.5 Event classes to include some comments from 
the list.

----------------------------------------------------------------------------------------
3.5  Event Classes

    Notifications can be classified into a number of event classes.  Each
    event class identifies a set of event notifications which
    - share similar content
    - are generated from similar events
    - expect similar handling on the manager/agent side
    - are used for similar purpose

    The initial set of event classes are configuration, state, rpc-reply,
    maintenance, heartbeat, fault. Netconf defines a set of standard
    event classes but allows a netconf server to use other vendor specific
    event classes if the proposed event or it's usage can not fit the
    standard classes.

    All events shall carry the following data: detailed event type,
    event class timestamp, sequence number of the notification
    and are free to carry additional data.

    For each class the following is included:
    - definition, including triggering events
    - expected handling
    - expected data, additional data is allowed
    - examples
    - why do we need the event class

    A configuration event, alternatively known as an inventory
    event, is used to indicate that hardware, software, or a
    service has been added/changed/removed.
    - As configuration notifications could potentially carry huge
    amounts of data it is expected that netconf clients will use
    filtering to reduce their number and possibly their data content.
    - The notification might carry the changed data itself or rather
    some kind of pointer to the changed part of the configuration.
    It is discouraged to include big amounts of configuration data
    in the notification or to simply repeat the content of the
    netconf operation that triggered the notification
    - Examples: HW board removed, SW module loaded, DNS server reconfigured.
    - As multiple independent sources can configure a netconf server
    node, netconf clients need to be aware of configuration operations
    issued by other clients and events like physical HW removal.

    A state event indicates a change from one state to another, where a
    state is a condition or stage in the existence of a managed entity.
    If the state can indicate some kind of fault e.g. link failed the
    notification shall be sent as a fault notification. The state
    event is not a direct result of a
    configuration operation but rather a result of a network event a
    node internal event or an indirect result of a configuration event
    - No special handling.
    - The  notification shall identify the object who's state changed
    and the new state.
    - Examples: Operational state of an interface has changed to up.
    - Internal states of a node are important for supervision purposes
    and also effect how a node can be configured.

    A maintenance event signals the beginning, process or end of an
    action generated by a manual or automated  maintenance action.
    If the maintenance event is a direct result of a
    configuration management operation on this Netconf session then
    an rpc-reply notification should be used.
    - no special handling
    - Expected data: description of the maintenance process, the stage the process
    has reached, the manual action, automatic process that triggered
    the notification
    - Examples: automatic backup completed
    - Network management needs to know about the success or failure
    of certain maintenance operations that were not triggered by the
    event receiving management entity.

    An rpc-reply event is triggered by a specific Netconf operation
    that sends back multiple response messages. The first message
    indicates the unsuccessful/successful starting of an operation
    that might take a longer time to complete. Succeeding messages
    return further results.
    - The netconf server and the management application should be
    able to link the event with the triggering operation.
    - Expected data: Reference to the triggering operation including
    session-Id and message-id, sequence number
    - Examples: end result of a long running operation, successive
    results of a ping test
    - Some operation can take a longer time to complete or produce
    multiple results in which case both an initial and one or more
    late result are needed

    A heart beat event is sent periodically to enable testing that the
    communications channel is still functional.
    - On reception the liveliness of the channel is confirmed, after
    this the notification is simply discarded not even logged.
    - Expected data: sequence number

    A fault notification is generated when a fault condition occurs.
    Depending on the severity of the fault the notification might be
    considered an alarm or a warning.
    - This notification represent an undesirable situation. It is
    expected that a manager will sooner or later take action to rectify
    the fault. The agent shall try to send the fault notification without
    any delay or buffering.
    - The fault notification should carry the following data: severity,
    event source, probable cause, specific problem, additional information
    - Examples: communications alarm, environmental alarm,
    equipment alarm, processing error alarm, quality of service alarm, or
    a threshold crossing event. See RFC3877 and RFC2819 for more
    information.
    - fault notifications are not the main aim of this configuration protocol,
    however they are included as faults have a relevance for
    configuration management.

----------------------------------------------------------------------------------------

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/netconf/>

---

From: Andy Bierman <[email-masked]>
Date: Fri, 26 May 2006 09:30:40 -0700

Balazs Lengyel wrote:
> I wrote an alternative version of chapter 3.5 Event classes to include 
> some comments from the list.

I appreciate it.
I think it is important that the classifications
do not overlap, and the document provides clear guidelines
for selecting a classification.

Where do threshold-crossed events belong?
I think they are part of 'state events'.
It should be clear a change in state in an
embedded NM application (like RMON or ALARM-MIB)
is included in this group.

Andy

---

From: Balazs Lengyel <[email-masked]>
Date: Mon, 29 May 2006 10:34:01 +0200

Hello,
State is a good choice but there is a more general issue hidden here.

State events can also represent a fault. E.g. For threshold-crossing: memory-usage more 
then 20% is just a state event. Memory usage more then 99.9% is a critical fault/alarm as 
at this point we can easily have a crash. Where do we put such events? Shall we
- allow such events to jump from state to fault depending on the seriousness of the situation
- allow some notifications to belong to more then one event class
- leave it to the application developer
regards Balazs

-- 
Balazs Lengyel                       Ericsson Hungary Ltd.
TSP System Manager
ECN: 831 7320                        Fax: +36 1 4377792
Tel: +36-1-437-7320     email: [email-masked]