Subject: Events revisted

From: Jamal Hadi Salim <[email-masked]>
Date: Wed, 22 Dec 2004 11:20:32 -0500

Does anyone see events as anything else other than change of state of
attributes?
Looking at the port LFB definition,  I am definetely interested in more
than just admin/operational attribute changes.
We could add a class definition for events, but the more i think about
it the more i think that we should just flag the data definitions with
"event-capable" flag. Thoughts?

cheers,
jamal

---

From: "Joel M. Halpern" <[email-masked]>
Date: Wed, 22 Dec 2004 11:29:18 -0500

If we use management protocols as exemplars, events are often thresholded 
changes in attributes.  ~If there are more than 5 line errors in 10 
seconds, generate the alarm~ kinds of things.  While all of the parameters 
are attributes, it is not really accurate to say that any one variable is 
"event-capable".

Also, explicitly defining the events can allow us to define what 
information should be sent with the events.  This can help the CE quickly 
do the right thing.

Yours,
Joel

---

From: Jamal Hadi Salim <[email-masked]>
Date: Wed, 22 Dec 2004 11:41:36 -0500

> information should be sent with the events.  This can help the CE quickly 

Good point. So I take it we need a class definition for events.

Next step:
Take a set of ports in a table in which say i am interested in 1/2 of
the attributes per port type: Do you need a corresponding event table
that has paths to those attributes? 
How do you define thresholds?

cheers,
jamal

---

From: "Joel M. Halpern" <[email-masked]>
Date: Wed, 22 Dec 2004 13:59:12 -0500

The schema for defining an LFB will have to include provision for 
describing the events the LFB can generate.  Then the LFB declaration will 
have to include the events that LFB can generate, and the IDs used to 
registor for those events.

Yours,
Joel

---

From: Jamal Hadi Salim <[email-masked]>
Date: Wed, 22 Dec 2004 14:30:33 -0500

> registor for those events.

Most likey something along this sample:

--
  <LFBClassDefs>
   <LFBClassDef>
.
.
      <Events>
        <Event access="read-only">
          <name>EventPortTable</name>
          <id>3</id>
          <synopsis>table of Events one row per Port</synopsis>
          <typeRef>porteventdesc</typeRef>
        </Event>
      </Events>
.
.
    </LFBClassDef>
  </LFBClassDefs>

-----

Registration would have to explicitly mention path (to ID 3 means
everything in the sample table). Events generation will also have paths
+ optionally data included. Thoughts?

cheers,
jamal

---

From: "Joel M. Halpern" <[email-masked]>
Date: Wed, 22 Dec 2004 14:46:11 -0500

Looks like a good start.

A couple of questions:
What does access mean?
I would expect the event to include a list of variables from the to be 
included in the event notification?  Is there some other thing the TypeRef 
is to reference?
I presume that the trigger conditions are described in English 
prose.  Thresholds would be LFB variables defined in the main part of the 
LFB Class definition?

Thanks,
Joel

---

From: Jamal Hadi Salim <[email-masked]>
Date: Wed, 22 Dec 2004 15:33:25 -0500

> What does access mean?

ACL - a hint to show CE cant update those variables. Maybe this is not
so reflective if you are going to set notification thresholds.

> included in the event notification? 

Any port attribute whose state could change, or some set threshold
crossed resulting in an event would be listed in that porteventdesc.
 
For subscription purposes you would need the following:
a) a path 
b) Perhaps a way to define a threshold. A threahold could be as simple
as a MTU change regardless of the value and like you described earlier
"error count exceeded 10"
c) a verbosity level (revisits our old discussion here;->)
i) "let me know when the threshold gets crossed" vs ii)"let me know
when the threshold gets crossed and what value it crossed to"

For notification:
a) A path
b) optionally a data value for that path as per registration.

>  Is there some other thing the TypeRef 
> is to reference?

Refer to my comment above. I dont wanna complicate things; but the
eventdescp path reference maybe just an alias that refers to the local
attribute.
For thresholds maybe we could learn something from RMON gauges.

cheers,
jamal

---

From: "Joel M. Halpern" <[email-masked]>
Date: Wed, 22 Dec 2004 15:39:23 -0500

Given that there is only one CE in charge of the FE (we don't have the SNMP 
multi-manager problem) it seems that the threshold can just be an attribute 
of the LFB.

I would really like the event definition to indicate which variables should 
be sent.  I don't think that "all variables of the triggering LFB" is a 
useful definition. But the CE needs to know what to expect, and how to 
parse it.

Yours,
Joel

---

From: Jamal Hadi Salim <[email-masked]>
Date: Wed, 22 Dec 2004 16:42:30 -0500

> multi-manager problem) it seems that the threshold can just be an attribute 

Is this because we can set its values from the management side? 

> useful definition. But the CE needs to know what to expect, and how to 

Parse error.
The porteventdesc (a datatypedef specific to the port LFB) constitutes 
attributes upon whose state/threshold changes an event is triggered.
Example the MTU attribute to the port would fit such a definition. In
the worst case _all_ attributes of an LFB could generate events. In such
a case the "all" variables applies and will therefore _all_ be listed.  
Paste me some xml if ia m missing something maybe then it will become
clear.

cheers,
jamal

---

From: "Joel M. Halpern" <[email-masked]>
Date: Wed, 22 Dec 2004 17:47:04 -0500

The question of variables for the notification may be simply a matter of my 
misreading the description.
I would expect to see a list of variables from the LFB Class that has the 
event notification.
A typeRef is a declaration of the type of something, not a reference to 
other attributes.
The type of the content of the notification will be the synthetic struct 
built from the sequence of the types of the referenced attributes.  There 
is an interesting syntactic issue of how we say "the subscript from the 
table element that went over threshold, and these attributes from that 
table element."  I am sure we can work this out.  This really only affects 
the XML, not the on-the-wire protocol.

Yours,
Joel

---

From: Jamal Hadi Salim <[email-masked]>
Date: Thu, 23 Dec 2004 07:57:03 -0500

> A typeRef is a declaration of the type of something, not a reference to 

You need to define the list and where to store the associated
parameters. Example of associated parameters: thresholds and paths to
the subscrisable events (which i dont think equate to paths to
attributes they represent).
You need some descripion per event-capable attribute. In the case of the
port LFB, the list is per port and we have a table of such ports.
Indidual ports in the table maybe of different type within one FE
(ethernet, POS,etc) and may not have exactly the same subscrisable
events. The difference in subscrisable events applies even to ports of
the same type (such as ethernet). To summarize, what i meant by a 
porteventdesc (a datatypedef), would look like:

{
  ifindex of targeted port,
  name maybe,
  MTU: 
	ID = x, 
	optional,
	Path of value being targeted (maybe unnecessary),
	real threshold description here;	   	
  Admin state:
	ID = Y,
	..
	..
  ..
  ..
} port event desriptor type

Later define a table of these that corresponds to the table of ports
(hence the typeref).
Are we saying the same thing?

> the XML, not the on-the-wire protocol.

Send the XML ;-> some variant of flags on the path-data seems to me like
will suffice.

cheers,
jamal