Subject: Re: An approach to modeling ForCES events

From: "Deleganes, Ellen M" <[email-masked]>
Date: Fri, 15 Apr 2005 07:52:31 -0700

In that case, it is my opinion that it is worth trying to enumerate
other triggers that are not universal either, but most people think
would be useful. That way, we can have more confidence the protocol and
the model can handle the most common cases.

Regards,
Ellen

-----Original Message-----
From: Forwarding and Control Element Separation
[mailto:[email-masked]] On Behalf Of Jamal Hadi Salim
Sent: Friday, April 15, 2005 7:20 AM
To: [email-masked]
Subject: Re: An approach to modeling ForCES events

On Thu, 2005-14-04 at 17:25 -0700, Deleganes, Ellen M wrote:
> I didn't quite follow what point you were making in the comment about
> some of the event triggers may not be universal. I agree that the
> <fallsbelow> or <exceeds> triggers only makes sense for some types of
> fields, namely counters. The triggers seem useful in some cases, so I
> hope you weren't suggesting to eliminate those triggers altogether. 

What i am suggesting is if we go and add triggers such as these which
deal only with specific cases we might as well enumerate more. Example i
gave was a synchronous trigger such as timers for example etc.
A table or any attribute manipulation is another. A packet arrival thats
interesting could also be used as a trigger. Note all these are not
universal either.

cheers,
jamal

---

From: "Chawla, Shuchi" <[email-masked]>
Date: Tue, 19 Apr 2005 15:58:22 -0700

Joel,

Thanks -- I understand the points you have made.  I was intending the
specs to be used more as guides/references for the type of information
that may be required for events and alarms etc.

Wrt. the reporting of events and alarms, I agree that we would be
defining what is required to be communicated by the FE to the CE.  I
didn't mean to imply the notifications to external entities.  I outlined
some general requirements that may impact the information that needs to
be conveyed by the FE to the CE.

Regards,
Shuchi

-----Original Message-----
From: Forwarding and Control Element Separation
[mailto:[email-masked]] On Behalf Of Joel M. Halpern
Sent: Tuesday, April 19, 2005 1:57 PM
To: [email-masked]
Subject: Re: An approach to modeling ForCES events

You have some good points here.
Two things to keep in mind:
1) We are focused more on integrating into the IETF/ SNMP management
world 
view, while paying attention to the useful input from ITU.
2) This particular problem is not about the reporting of events and
alarms 
to external entities.  it is not even about reporting SNMP traps or 
notifications.  Rather, it is about how the FE will give the CE enough 
information that it can generate appropriate indications (variables,
traps, 
notifications, alarms, etc) to the external OA&M environment.

Yours,
Joel M. Halpern

At 04:35 PM 4/19/2005, Chawla, Shuchi wrote:

>I haven't been following the entire thread on event modeling in detail,

>but here are some of my thoughts - some of them are on the general
aspects 
>of event and alarm reporting.  So, it is a slight digression from the 
>conversation, but hopefully, still relevant.
>
>There are some ITU-T specs for data networks/communication systems that

>specify the alarm and event reporting functions/requirements.  It's
been a 
>long time since I've looked at these specs. and I don't currently have 
>access to them, but I think it would be worth it to scan through them
to 
>see the type of functionality that such systems should support, and
what 
>might be considered overkill.  The two that I saw on the ITU site are: 
>ITU-T X.733 and ITU-T X.734 (I assume these were the ones I had looked
at 
>in the past, but I don't remember for sure!).
>
>-       There should be support for both events and alarms, since they 
>have differences.  If events are thresholded, and they exceed their 
>threshold, it may lead to an alarm condition.  Alarms may be generated
and 
>cleared.  Events do not have a concept of a "clear".  An attribute
change 
>on some object may be classified as an event.  A Loss of Signal on a 
>physical interface would classify as an alarm.  An alarm should be 
>generated when the condition is detected (after the appropriate 
>integration time), and then a "clear" generated when the condition
clears.
>
>-       From what I remember, these specs. classify alarms into
different 
>classes (equipment, QoS etc.).  Each alarm has a default severity
(which 
>is not modifiable) and perceived severity (which is modifiable).  The 
>support for perceived severity arises from the fact that what may be 
>considered a "major" condition on some network element in a certain 
>network, may be considered "minor" in some other network element based
on 
>its function and topology in the network etc. Alarms define probable
cause 
>and proposed repair information (among other information, which I don't

>remember).
>
>-       In certain cases, it is possible that a large number of 
>events/alarms get generated since a condition on object X could lead to
a 
>different condition on objects associated with X, and so on.  If the FE
is 
>not doing event correlation and root cause analysis, it might land up 
>sending all of these events to the CE, and it can result in event 
>flooding.  As an example, if an FE is associated with a large number of

>channelized interfaces, each configured to provide a service, if the 
>physical interface experiences a loss of signal, all channelized 
>interfaces will also have an alarm, as will the services associated
with 
>the channelized interfaces.  Depending on the alarm detection
mechanisms 
>and alarm integration times, it is possible that the root cause alarm
is 
>detected after the alarm conditions that result from it.
>
>-       In my opinion, if we can avoid support for deferred events, we 
>should.  If there is an issue with the CE not being able to keep up
with 
>the events from the FE, maybe the severity of the condition (or some
other 
>threshold) can be used as a filter to determine what to send to the CE.
I 
>agree that packets that need processing by the CE do need to get sent
by 
>the FE to the CE.  I wasn't viewing these as "events" however.  If we
have 
>the concept of a "data" versus a "control" channel, these packets would
be 
>considered for transmission over the data channel, whereas
events/alarms 
>would be reported over the control channel (I may have misunderstood
what 
>was being stated).
>
>-       Thresholds being used as triggers for events/alarms are
definitely 
>a good thing to support in my opinion.  In large systems, where the
number 
>of objects being managed and monitored is significant, thresholds
provide 
>a mechanism to support manageability of such system without
overwhelming 
>the CE and running out of space on the event/alarm logs that are 
>maintained in persistent storage.
>
>-       I think event subscription/registration should only be possible
on 
>events explicitly defined by an LFB.  It seems it would be rather
complex 
>to express the "situations" under which to use different verbosity
levels 
>for the different event types.  Are there specific use cases that
require 
>this flexibility?  Else, it would seem reasonable to limit this to 
>registration time.  I assume multiple entities on the CE can register
for 
>the same event from an FE.  What if one registers with a high verbosity

>level, and one with a low verbosity level?  Would the FE now have to
send 
>2 separate events with the different levels of verbosity, or is it the 
>intent that the FE always send all the info., and an "event subsystem"
on 
>the CE will do the filtering for the different registrations?  If so,
have 
>we gained that much with this support for different verbosity levels?
Is 
>this case valid?
>Shuchi
>[<mailto:[email-masked]>mailto:[email-masked]
] 
>On Behalf Of Jamal Hadi Salim
>Sent: Tuesday, April 19, 2005 3:53 AM
>On Mon, 2005-18-04 at 21:42 -0700, Deleganes, Ellen M wrote:
>
> > Deferring events seems more difficult for the FE than just turning
them
>
> > on and off because in order to defer sending events to the CE, the
FE
>
> > would have to maintain state and possibly buffer the events. (I'm
>
> > assuming that if the CE doesn't want notifications that the FE
doesn't
>
> > have to keep them around.)
>
>There are two scenarios:
>
>
>
>1) nothing needs to be buffered because the state is part of the
>
>attribute you are already maintaining at the FE. This applies to
>
><change> as the trigger.
>
>Events just dont get generated at the FE anymore in the period those
>
>events are turned off for the target.
>
>As an example for a simple implementation approach: if the event of
>
>interest was attribute X of LFB Y changing, then every time attribute X
>
>is changed localy within an FE, the FE will send an event to the CE if
>
>the send-event-flag-for-attribute-X is true. If this flag is turned off
>
>no such event is generated (but the local state of attribute X is still
>
>updated). So in this case, the first event generated would alert the CE
>
>and turn itself off until the CE sets back the boolean to process
again.
>
>Note turning off events for attribute X does not equate to turning off
>
>all events at the FE.
>
>2) Buffering needed.
>
>The "units of work" need to be transported to the CE - without the "
>
>unit of work" the CE cant process the event. As an example of such
>
>things would be packets that need to be transported to the CE for
>
>further resolution.  Another example would be queries built as a result
>
>of packets arriving at the FE (eg a IPSEC security association acquire
>
>message whose resolution happens at the CE). Overall such units of work
>
>need to be buffered.
>
>
>
> >  What happens if the FE runs out of space to buffer events?
>
>So you are talking about case #2. I would say simple FIFO schemes would
>
>do. Overrun of the FIFO should be flagged.
>
> > Seems complex to deal with in the first place and the
>
> > error cases are even worse. I would hope events don't come in "huge
>
> > bursts" but are relatively rare and we don't need to build into the
>
> > model or the protocol the extra complexity to defer events.
>
> >
>
>What do you mean by error cases? Lost messages? There are several ways
>
>to deal with that issue.
>
>To digress a little:
>
>I think the threshold triggers we are trying to build in are equally as
>
>complex as this issue and serve the same purpose.
>
>The only real value the thresholds provide is offloading the CE by
>
>providing ability to deffer the CE work scheduling point (which is
>
>exactly what the edge/level triggering does).
>
>In other words, the thresholds dont reduce the work that the FE has to
>
>do. It still has to constantly poll to check the stats in place of the
>
>CE doing that work. Note: i am not arguing against the threshold
>
>triggering - just pointing out the similarities because you brought up
>
>the point of complexity (I still think its a good necessary evil).
>
> > If there is a case where one cause generates a burst of events, it
may
>
> > be reasonable to provide a mechanism to allow the CE to request only
the
>
> > first event in the burst. Do you happen to have a scenario where a
large
>
> > burst of events would occur? The only realistic scenario I can think
of
>
> > is when the CE is controlling a large number of FEs and they all
want to
>
> > send events at once. But this isn't the scenario outlined.
>
>The general class of problems is: more events coming into the CE than
>
>the CE can handle within reasonable time. Essentially, like the
>
>threshold triggering, it is an optimization. More importantly, its a
>
>classical event-processing scaling mechanism. Assuming in the worst
case
>
>your CE cant keep up with the rate at which events are generated from
>
>the FEs, then the CE will end up thrashing. The ability to selectively
>
>defer events processing helps the CE not to thrash.
>
>I hadnt thought of the example you provided above - but its a
reasonable
>
>one.
>
>The examples i can think of require processing of something in the
>
>CE to update state at the FE[1]. These could be "stateful" classifiers
>
>at the FE which require that the CE make the state update decision or
>
>IDSes etc. The specific problem i am faced with at the moment is IPSEC
>
>ACQuires being issued at the FE to the CE (assuming IKE runs at the
>
>CE).
>
>
>
>cheers,
>
>jamal
>
>[1] We have spent many electrons in the past arguing about this very
>
>issue. i.e whether the full processing of such things should happen at
>
>the FE instead of being sent to the CE. I dont wanna go there with this
>
>thread - Assume this is a legit way as well and let the benchmarks
>
>decide which of the two approaches is better.