Subject: Re: Event declarations

From: "Khosravi, Hormuzd M" <[email-masked]>
Date: Thu, 10 Feb 2005 22:38:41 -0800

Hi Joel,

I am glad you started working on this aspect, this is definitely needed
by the protocol. In general the model that you have proposed below for
reporting events seems reasonable to me. On the specifics on the LFB
definition, I would defer this to the Model team for now since I haven't
been following the latest updates being made to the Model draft. I guess
it would depend on the general design philosophy for the LFBs.

Hope this helps,

regards
Hormuzd 

-----Original Message-----
From: Forwarding and Control Element Separation
[mailto:[email-masked]] On Behalf Of Joel M. Halpern
Sent: Thursday, February 10, 2005 12:16 PM
To: [email-masked]
Subject: [FORCES] Event declarations

I am working on updating the model draft.
As part of that, I am trying to figure out where / how "events" should
be 
declared.

The general idea is that the model will have event declarations, which
also 
create a boolean variable.  When the variable is True, the event is
sent.
I also assume that events will have a path to identify the event being 
signalled, and the event message will include an LFB instance 
identifier.  (The simplest model for achieving that I can see is that we

have an "EVENT-REPORT" Operation, which carries path-data and content
data 
for each event being reported.)

So now we turn to the model and ask the question "where should events be

declared, and how should the content be declared?"

One way to do it is that each information declaration (structure, array,

and LFB) caninclude its own event statement.  That statement would
include 
a description of what the event means, and a declaration of the fields 
included in the data reported with the event.
This provides a nice simple consistent place to declare events.  The
syntax 
would be clean.

But, it assumes that every LFB that wants to use a given type definition
is 
going to want to be able to provide the same events.  Also, it would
mean 
that the information reported by an event would have to come from that
one 
structure.  Both these restrictions feel problematic to me.

The other alternative is to create an events section of the LFB
declaration.
This would then need to somehow describe for each event what condition
it 
is triggered by, and what information is sent.  The complication comes
in 
when trying to declare evens triggered by entries in tables.  It is easy
to 
have an LFB level event triggered by too many bad packets.  But suppose
one 
has a port table, and the event is port down.  Clearly, the event should
be 
tied to the individual port.  And clearly the reported elements should
come 
from the corresponding failed element of the table.  And maybe from some

parallel tables.
Hence, I start ending up with something in the LFB declaration that
looks like:
    <event name=portfail, eventid = 700, varID = 17>
         <indexvariable> idx </indexvariable>
         <trigger> portstatus[idx} </trigger>
         <pathaugment> idx </pathaugment>
         <description> when status field becomes "down" <description>
         <report> portstatus[idx}.status, portinfo[idx].identity
</report>
     </event>
So that you can have one or more index variables to use in referring to
events.
you can indicate which ones are to appear in the event path and in what
order
The trigger clause may be just documentation?
And the report clause, using the index variables, indicates what is to
be 
reported.
And this would also declare a boolean array, with variable ID 17, to use
to 
indicate which of these events are to be generated.

Is this a reasonable approach, or am I totally confused?
Yours,
Joel