From bbsefynehdho@wx88.net Thu Apr 7 14:08:04 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA21437; Thu, 7 Apr 2005 14:08:01 -0400 (EDT) Date: Thu, 7 Apr 2005 14:08:01 -0400 (EDT) Received: from gen92-4-82-235-10-136.fbx.proxad.net ([82.235.10.136]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1DJbYk-0004wz-AE; Thu, 07 Apr 2005 14:16:56 -0400 Received: from duty.eaglesnest.net ([152.163.142.184]) by mobility.australianmalls.com (Sun Java System Messaging Server 6.1 HotFix 0.01 (built Aug 21 2004)) with SMTP id <0ICD00HGMY1D01Q0@mobility.australianmalls.com> for edu-team@ietf.org (ORCPT edu-team@ietf.org); Thu, 07 Apr 2005 16:07:51 -0300 (IST) Received: (qmail 84299 invoked from network); Fri, 08 Apr 2005 00:58:51 +0600 Received: from unknown (HELO cupboard.dora.com) (202.106.184.200) by server-1.allotted-63.eaglesnest.net with SMTP; Thu, 07 Apr 2005 23:05:51 +0400 Received: by cupboard with Internet Mail Service (5.5.8752.16) id ; Thu, 07 Apr 2005 23:01:51 +0400 Date: Thu, 07 Apr 2005 13:07:51 -0600 From: Otis Pope Subject: Cheap Medicines To: References: In-Reply-To: Message-ID: <309248426412.JPN37178@foothill.net>cupboard.australianmalls.com> Message-ID: <309248426412.JPN37178@foothill.net> MIME-version: 1.0 Content-Type: multipart/alternative; boundary="----_001_5900_82C98VP9.94CB2669" X-Mailer: Ximian Evolution 1.4.5 (1.4.5-7) X-Spam-Score: 4.7 (++++) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a This is a multi-part message in MIME format. ------_001_5900_82C98VP9.94CB2669 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7Bit Hi, You can buy the most wanted medications from our site. we sell ViCODiN(179 $),VALiUM(169 $) and ViAGRA(199 $) at a very reasonable price. we ship worldwide and no prescription is needed. http://www.grx-meds.com/scripts/default.asp?idaff=110 Cheapest Online Pharmacy ------_001_5900_82C98VP9.94CB2669 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: 7Bit Hi,
You can buy the most wanted medications from our site.
we sell ViCODiN(179 $),VALiUM(169 $) and ViAGRA(199 $) at a very reasonable price.
we ship worldwide and no prescription is needed.
Cheapest Online Pharmacy ------_001_5900_82C98VP9.94CB2669-- From owner-forces@PEACH.EASE.LSOFT.COM Wed Apr 13 03:15:29 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA01816 for ; Wed, 13 Apr 2005 03:15:29 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DLcFh-0006NV-FL for forces-archive@IETF.ORG; Wed, 13 Apr 2005 03:25:34 -0400 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <18.0100FCDC@cherry.ease.lsoft.com>; Wed, 13 Apr 2005 3:15:22 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 66307023 for FORCES@PEACH.EASE.LSOFT.COM; Wed, 13 Apr 2005 03:15:21 -0400 Received: from 209.119.0.34 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Wed, 13 Apr 2005 03:15:21 -0500 Received: from PEACH.EASE.LSOFT.COM (209.119.1.45) by grape.ease.lsoft.com (LSMTP for OpenVMS v1.1b) with SMTP id <6.00564F70@grape.ease.lsoft.com>; Wed, 13 Apr 2005 3:15:21 -0400 Message-ID: Date: Wed, 13 Apr 2005 03:15:21 -0400 Reply-To: Dong Ligang Sender: Forwarding and Control Element Separation From: Dong Ligang Subject: Some hints for modifying ForCES Specification To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5 1) [Page 14] Remove the definition of ACID, as ACID is a well known concept. In this ForCES Specification, we did not provide new information about the definition of ACID. 2) The Length field of Common Header[Page 22] is in DWORDS while the length field of messages is in bytes (e.g., Association Setup Message [Page 36]. They are inconsistent. 3) [Page 25] "OPER-TLV : = 1*PATH-DATA-TLV" and "DATA := DATARAW-TLV / RESULT-TLV / 1*PATH-DATA-TLV". Since we can express multiple PATH-DATA-TLV in OPER-TLV, we do not need multiple PATH-DATA-TLV in DATA. In other words, I think "flat path data" expression is simpler than "nesting" expression in example 18 of the appendix. 4) [Page 25] "PATH := flags IDcount IDs [SELECTOR]". According to the examples in appendix, I guess that flags is either F_SELKEY, FIND-EMPTY, or 0. An alias should be provided for "flag=0". 5) [Page 14] We need to express "Transactional all-or-none", "Any-of-N independent operations", and "go-to-N loose transaction" in the common header. 6) We need to define the data in the Association Setup Response Message. For example, Result 0 the setup msg was successful. 1 the setup msg is rejected by the CE 2 the CE cannot read the setup msg because of wrong message format. 7)[Page 56] The operations in "6.10 Operation Summary" conflict with the former introduction from Section 6.4 to Section 6.9. 8) Remove redundant figures, e.g., Figure 24. 9) It is difficult to distinguish the attribute& capability between FE protocol LFB and FE LFB (or called FE object LFB). Why not combine the FE protocol LFB and FE LFB? 10) I suggest remove the concept of "FE protocol LFB" and "FE LFB". LFB is "logical function block", that means a basic and single function. However in fact, "FE protocol LFB" and "FE LFB" contain many functions. 11) In Appendix D, we should provide realistic use cases or examples. 12) We need to define PDU, OID, etc. 13) CE LFB should be removed. 14) In "6.5.1 Config Message", "get" operation cannot be used for config message. 15) Should Association Setup Response Message should contain some or all capability&topology info. of FE? 16) How to use "Throttle flag"? 17)[Page 57] "When the FE is ready to start forwarding data traffic, it sends a FE UP Event message to the CE. The CE responds with a FE ACTIVATE State Maintenance message to ask the FE to go active and start forwarding data traffic." Individual Up Event message is unnecessary, as Association Setup Message and Heartbeat Message can implicitly suggest this FE is "Up". Besides, Individual Down Event message can be replaced by Association Teardown Message. 18) [Page 20] "Command (8 bits)" should be changed to "Message Type (8 bits)" 19) Give more explanation about MIID table [Page 33] 20) Others, e.g., the lowercase or uppercase, spell of words, should be fixed. From owner-forces@PEACH.EASE.LSOFT.COM Wed Apr 13 07:04:32 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA14881 for ; Wed, 13 Apr 2005 07:04:32 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DLfpR-0003Gw-BC for forces-archive@IETF.ORG; Wed, 13 Apr 2005 07:14:41 -0400 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <4.0101010B@cherry.ease.lsoft.com>; Wed, 13 Apr 2005 7:04:33 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 66350287 for FORCES@PEACH.EASE.LSOFT.COM; Wed, 13 Apr 2005 07:04:00 -0400 Received: from 208.184.15.238 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Wed, 13 Apr 2005 07:04:00 -0500 Received: from [69.170.19.163] (HELO JMHLap3.stevecrocker.com) by EXECDSL.COM (CommuniGate Pro SMTP 3.3) with ESMTP id 9917456; Wed, 13 Apr 2005 07:03:59 -0400 X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Approved-By: "Joel M. Halpern" Message-ID: <6.2.1.2.0.20050413070211.02f31e18@localhost> Date: Wed, 13 Apr 2005 07:03:56 -0400 Reply-To: "Joel M. Halpern" Sender: Forwarding and Control Element Separation From: "Joel M. Halpern" Subject: Re: Some hints for modifying ForCES Specification Comments: To: Dong Ligang To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: Precedence: list X-Spam-Score: 0.1 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Thank you for taking a careful look at the ForCES protocol specification. With regard to this specific suggestion, the nested multiplicity is deliberate. It is true that any path-data representable this way can be represented with just a top level repetition. However, if paths get long, the ability to share the common subexpression and refer to multiple items within that sub-expression was deemed useful by the design teams and the working group. Yours, Joel M. Halpern At 03:15 AM 4/13/2005, Dong Ligang wrote: > 3) [Page 25] "OPER-TLV : = 1*PATH-DATA-TLV" and "DATA := DATARAW-TLV / >RESULT-TLV / 1*PATH-DATA-TLV". Since we can express multiple PATH-DATA-TLV >in OPER-TLV, we do not need multiple PATH-DATA-TLV in DATA. In other words, >I think "flat path data" expression is simpler than "nesting" expression in >example 18 of the appendix. From owner-forces@PEACH.EASE.LSOFT.COM Wed Apr 13 07:44:15 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA17380 for ; Wed, 13 Apr 2005 07:44:15 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DLgRq-0004FX-Hv for forces-archive@IETF.ORG; Wed, 13 Apr 2005 07:54:22 -0400 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <16.0101016B@cherry.ease.lsoft.com>; Wed, 13 Apr 2005 7:44:15 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 66352538 for FORCES@PEACH.EASE.LSOFT.COM; Wed, 13 Apr 2005 07:44:13 -0400 Received: from 208.184.15.238 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Wed, 13 Apr 2005 07:44:13 -0500 Received: from [69.170.19.163] (HELO JMHLap3.stevecrocker.com) by EXECDSL.COM (CommuniGate Pro SMTP 3.3) with ESMTP id 9917952 for FORCES@PEACH.EASE.LSOFT.COM; Wed, 13 Apr 2005 07:44:12 -0400 X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Approved-By: "Joel M. Halpern" Message-ID: <6.2.1.2.0.20050413074255.02ee5e70@localhost> Date: Wed, 13 Apr 2005 07:44:08 -0400 Reply-To: "Joel M. Halpern" Sender: Forwarding and Control Element Separation From: "Joel M. Halpern" Subject: An approach to modeling ForCES events To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list X-Spam-Score: 0.1 (/) X-Scan-Signature: 5ebbf074524e58e662bc8209a6235027 Below is a proposal for event modeling, including defining the paths for registering and reporting events in the protocol. Here is a sample XML for event declaration in an LFB Class definition, followed by some description and question. Assume that the LFB include a foo and bar elements. foo is an array whose contents are a structure with fields baz, caz, daz where daz is in turn an array of uint32. oddity is an array indexed by the same idex as the daz entires. I have not defined any specific semantics for the objects because it would take a lot of text. These are simply examples of things which can change, and which teh CE wants to know about. bar report if bar changes bar foo.$1.baz 75 report if any baz in foo gets above 75 foo.$1.baz foo.$1.caz foo.$1.daz.$2 3 foo.$1.daz.$2 foo.$1.caz oddity.$2.state oddity bar This declares that paths within this LFB that start with 7 reference events, and paths that start with 8 are for the boolean variables that represent registration state for the events. Paths starting with 7 will appear only in notifications. Q: I could have used a single path starting point, and simply had different meanings for its use in SET / GET (where it would reference the boolean variable) and in NOTIFICATIONS (where it would mean the event itself and the associated reporting type. I thought this was a bad idea. Each even then has an ID which is concatenated with the base paths to start building the notification and registration paths. For event 1 (changes to bar) the paths are simply 7.1 for the notification and 8.1 for registering. Events 2 and 3 are events about array elements inside the LFB. Thus the path to a specific event is the base, the eventid, and the subscript. So a specific occurrence (say in the fourth daz entry in the second foo entry) of event 3 would be reported with the path 7.3.2.4. Q: We have been asked to support registering for events on a whole table. Currently, set 8.3.2 would be setting teh table of boolean variables. However, it is not legal to directly create or delete entries in this table (Since it mirrors the foo[]daz table structure.) So we could declare that a reference to the entire array is in this case a reference to a single boolean that covers the array. It seems useful to have that. But allowing that will seriously complicate the type determination logic. Each event includes a target variable (with subscripts if the target is in an array.) The subscripts are named so they can be referenced in the reports clause. The subscripts themselves will appear in the event notification. Each event then includes a condition. I have not tried to enumerate all the conditions yet, but some of them are shown above. Q: Should we directly put the different condition tags, as I have done above, or should we use: value The target variable can be an array, rather than its entries. In that case, the change trigger would mean the deletion or creation of any entry. (We will probably have separate deletion and creation triggers as well.) In that case, the event path will include the subscript of the entry being created or deleted. the in the reports will cause a scalar to be included indicating what event has occurred. (This is legal with any report, but is likely most useful with arrays.) The reports element indicates what information to send along with the notification. It can select any elements from the LFB Class. It can use any of the subscripts in the trigger path. Essentially, it defines the data type and contents for the data portion of the notification TLV. One additional question that occurred to me later is, if a change is made by the CE, and the CE is registered for an event triggered by the change, should the notification be generated? Should we have a flag in the SET request to suppress such notifications? My first reaction is that it should be generated even for changes by the CE, but I am not sure. Is this sufficiently ugly to prompt someone to do a better job? Thank you, Joel From owner-forces@PEACH.EASE.LSOFT.COM Wed Apr 13 10:13:20 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA29216 for ; Wed, 13 Apr 2005 10:13:20 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DLim9-0008Nw-7K for forces-archive@IETF.ORG; Wed, 13 Apr 2005 10:23:29 -0400 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <10.010104A4@cherry.ease.lsoft.com>; Wed, 13 Apr 2005 10:13:20 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 66377328 for FORCES@PEACH.EASE.LSOFT.COM; Wed, 13 Apr 2005 10:13:18 -0400 Received: from 208.2.156.7 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Wed, 13 Apr 2005 10:13:18 -0500 Received: from [10.0.0.9] ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2005041307140781:16026 ; Wed, 13 Apr 2005 07:14:07 -0700 References: <6.2.1.2.0.20050413074255.02ee5e70@localhost> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 X-MIMETrack: Itemize by SMTP Server on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 04/13/2005 07:14:08 AM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 04/13/2005 07:14:09 AM, Serialize complete at 04/13/2005 07:14:09 AM Content-Transfer-Encoding: 7bit Content-Type: text/plain Approved-By: Jamal Hadi Salim Message-ID: <1113401595.1084.119.camel@jzny.localdomain> Date: Wed, 13 Apr 2005 10:13:15 -0400 Reply-To: hadi@znyx.com Sender: Forwarding and Control Element Separation From: Jamal Hadi Salim Organization: Znyx Networks Subject: Re: An approach to modeling ForCES events To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <6.2.1.2.0.20050413074255.02ee5e70@localhost> Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: a743e34ab8eb08259de9a7307caed594 Content-Transfer-Encoding: 7bit Joel, Good - lets have some activity on the list; hopefully this discussion doesnt turn out into you and I batting a ball at each other(trying to guilt other people ;-> We can make good progress if people understand whats being said now as opposed to spending many hours later rehashing the same things again) I have a small variation to your approach further below. It wouldnt be fun otherwise ;-> On Wed, 2005-04-13 at 07:44, Joel M. Halpern wrote: > Assume that the LFB include a foo and bar elements. foo is an array > whose contents are a structure with fields baz, caz, daz where daz > is in turn an array of uint32. > oddity is an array indexed by the same idex as the daz entires. > Does oddity make sense the way you described it? If i read correctly, there will be many daz "tables" but only one oddity. > I have not defined any specific semantics for the objects because it would > take a lot of text. These are simply examples of things which can change, > and which teh CE wants to know about. > Didnt quiet follow: Are you talking about registration? Or how things will be laid out in the LFB text? > > > bar > > report if bar changes > > bar > > > I am assuming the target is going to be a path syntax i.e you just have it above for illustratation purposes. > > foo.$1.baz > 75 > report if any baz in foo gets above 75 > > foo.$1.baz > foo.$1.caz > > > > > foo.$1.daz.$2 > 3 > > foo.$1.daz.$2 > foo.$1.caz > oddity.$2.state > > > > oddity > > > > bar > > > > I think you have all the needed constructs above. Good stuff. The triggers that cause events as you have them right now may not be universal; example fallsbelow or exceeds makes sense only if you have counters. I think this can be revisted later, but let me just digress a little: I may also be interested in getting a synchronous event ("send me bar every 30 seconds") or even more interesting async ones perhaps driven by some packet arrival like "notify me about bar when you receive ICMPs from Joel". I am not sure the second one fits well, but certainly the first one does. Also additional semantics like "let me know if it changes X times" which could be viewed as a superset of where X=1 > This declares that paths within this LFB that start with 7 reference > events, and paths that start with 8 are for the boolean variables that > represent registration state for the events. Paths starting with 7 will > appear only in notifications. > > Q: I could have used a single path starting point, and simply had different > meanings for its use in SET / GET (where it would reference the boolean > variable) and in NOTIFICATIONS (where it would mean the event itself and > the associated reporting type. I thought this was a bad idea. > I think your approach of the subscription being a different scope than notification is better. Related: The event subscribe/unsubscribe are essentially SETs. GET "all events" or "all event to do with foo" doesnt exist at the moment. > Each even then has an ID which is concatenated with the base paths to start > building the notification and registration paths. For event 1 (changes to > bar) the paths are simply 7.1 for the notification and 8.1 for registering. Makes sense. > Events 2 and 3 are events about array elements inside the LFB. Thus the > path to a specific event is the base, the eventid, and the subscript. So a > specific occurrence (say in the fourth daz entry in the second foo entry) > of event 3 would be reported with the path 7.3.2.4 Q. How does an FE LFB say "I can support foo.$1.daz.$2" as a event target? If you decide to describe it in english in some text - does that limit things? Or do we let the CE register and have the FE reject when it cant do it. Heres where i think i should mention the variation i have over what you present, the other way to do this is to say: If i subscribe to event path 8.X foo it would mean I am interested in anything that happens in foo. If i subscribe to target foo.$1.baz then i am interested in column baz of table foo. If i subscribe to target bar then i am only interested in that scalar. In other words theres a hierachical connotation to event targets. i.e if i say target "foo" then that implies "foo.$1.baz" and "foo.$1.caz" and "foo.$1.daz.$2" The only issue with above is conflict resolution which is resolvable. The construct still is the one that defines the verbosity of what gets reported back. In other words, even on the you could have different syntatic sugar; verbosity levels are: 3) "tell me what exactly changed". The notify will have to give you the path and new target values. 2) "tell me the path of what changed" as well under event id 30. 1) "dont bother telling me what exactly changed - all i need to know is event 3 happened" > Q: We have been asked to support registering for events on a whole > table. Currently, set 8.3.2 would be setting teh table of boolean > variables. Refer to my comments above. > However, it is not legal to directly create or delete entries > in this table (Since it mirrors the foo[]daz table structure.) So we could > declare that a reference to the entire array is in this case a reference to > a single boolean that covers the array. It seems useful to have that. But > allowing that will seriously complicate the type determination logic. > Seems like it will be ok to subscribe/unsubscribe though. In other words if i subscribe for event 3 - that is something that will exist in the FEs LFB state information i.e i can query it; if i unsubscribe then i cant query for that event. > Each event includes a target variable (with subscripts if the target is in > an array.) The subscripts are named so they can be referenced in the > reports clause. The subscripts themselves will appear in the event > notification. > Each event then includes a condition. I have not tried to enumerate all > the conditions yet, but some of them are shown above. The conditions are essentially triggers for the events - I think we can probably say there exist only a handful of those. > Q: Should we directly put the different condition tags, as I have done > above, or should we use: > > > > value > > > The target variable can be an array, rather than its entries. In that > case, the change trigger would mean the deletion or creation of any > entry. (We will probably have separate deletion and creation triggers as > well.) In that case, the event path will include the subscript of the > entry being created or deleted. the in the reports will > cause a scalar to be included indicating what event has occurred. (This is > legal with any report, but is likely most useful with arrays.) > > The reports element indicates what information to send along with the > notification. It can select any elements from the LFB Class. It can use > any of the subscripts in the trigger path. Essentially, it defines the > data type and contents for the data portion of the notification TLV. > > One additional question that occurred to me later is, if a change is made > by the CE, and the CE is registered for an event triggered by the > change, should the notification be generated? Should we have a flag in > the SET request to suppress such notifications? My first reaction is that > it should be generated even for changes by the CE, but I am not sure. > > Is this sufficiently ugly to prompt someone to do a better job? > Look at my comments on more genericity of subscription; I think the constructs needed are all there in what you define. Hopefully the other folks in the protocol and model would chip in as well in this discussion. cheers, jamal From owner-forces@PEACH.EASE.LSOFT.COM Wed Apr 13 10:29:03 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA01022 for ; Wed, 13 Apr 2005 10:29:02 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DLj1L-0000K4-S3 for forces-archive@IETF.ORG; Wed, 13 Apr 2005 10:39:12 -0400 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <6.0101044F@cherry.ease.lsoft.com>; Wed, 13 Apr 2005 10:29:02 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 66378706 for FORCES@PEACH.EASE.LSOFT.COM; Wed, 13 Apr 2005 10:29:02 -0400 Received: from 208.184.15.238 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Wed, 13 Apr 2005 10:29:02 -0500 Received: from [64.254.114.114] (HELO JMHLap3.stevecrocker.com) by EXECDSL.COM (CommuniGate Pro SMTP 3.3) with ESMTP id 9919771 for FORCES@PEACH.EASE.LSOFT.COM; Wed, 13 Apr 2005 10:29:00 -0400 X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 References: <6.2.1.2.0.20050413074255.02ee5e70@localhost> <1113401595.1084.119.camel@jzny.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Approved-By: "Joel M. Halpern" Message-ID: <6.2.1.2.0.20050413102440.02d49790@localhost> Date: Wed, 13 Apr 2005 10:28:55 -0400 Reply-To: "Joel M. Halpern" Sender: Forwarding and Control Element Separation From: "Joel M. Halpern" Subject: Re: An approach to modeling ForCES events To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <1113401595.1084.119.camel@jzny.localdomain> Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 I considered an approach like the one you suggest below. It may be the right answer. I have some concerns, lfollowing the coied portion of your comment. At 10:13 AM 4/13/2005, Jamal Hadi Salim wrote: >Heres where i think i should mention the variation i have over what you >present, the other way to do this is to say: > >If i subscribe to event path 8.X foo it would mean I am >interested in anything that happens in foo. >If i subscribe to target foo.$1.baz then i am interested in column baz >of table foo. >If i subscribe to target bar then i am only interested in that scalar. > >In other words theres a hierachical connotation to event targets. i.e >if i say target "foo" then that implies "foo.$1.baz" and >"foo.$1.caz" and "foo.$1.daz.$2" >The only issue with above is conflict resolution which is resolvable. > >The construct still is the one that defines the verbosity of >what gets reported back. >In other words, even on the you could have different syntatic >sugar; verbosity levels are: >3) "tell me what exactly changed". >The notify will have to give you the path and new target values. >2) "tell me the path of what changed" as well under event id 30. >1) "dont bother telling me what exactly changed - all i need to know is >event 3 happened" Given a table with fields a, b, and c, it does not seem obvious to me that being interested in all changes to fields anywhere in the table implies any likelihood of the CE being interested in notification of changes to b or c. As a simple example, the "a" field might be status, which the CE needs to know about changes to, while the "b" and "c" fields are statistical (change all the time, but the CE will get the fields when he needs the value.) Also, it does not seem that being interested in creation and deletion of entries in the table means that the CE is interested in notifications of changes to field values of existing elements. (Again, the existence entries may reflect interfaces or signaling events, while the contents may be statistical.) Yours, Joel From owner-forces@PEACH.EASE.LSOFT.COM Wed Apr 13 10:36:15 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA01680 for ; Wed, 13 Apr 2005 10:36:15 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DLj8K-0000XI-5I for forces-archive@IETF.ORG; Wed, 13 Apr 2005 10:46:25 -0400 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <9.01010324@cherry.ease.lsoft.com>; Wed, 13 Apr 2005 10:36:15 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 66380285 for FORCES@PEACH.EASE.LSOFT.COM; Wed, 13 Apr 2005 10:36:14 -0400 Received: from 208.184.15.238 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Wed, 13 Apr 2005 10:36:14 -0500 Received: from [64.254.114.114] (HELO JMHLap3.stevecrocker.com) by EXECDSL.COM (CommuniGate Pro SMTP 3.3) with ESMTP id 9919922 for FORCES@PEACH.EASE.LSOFT.COM; Wed, 13 Apr 2005 10:36:12 -0400 X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 References: <6.2.1.2.0.20050413074255.02ee5e70@localhost> <1113401595.1084.119.camel@jzny.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Approved-By: "Joel M. Halpern" Message-ID: <6.2.1.2.0.20050413102917.02d49aa8@localhost> Date: Wed, 13 Apr 2005 10:36:07 -0400 Reply-To: "Joel M. Halpern" Sender: Forwarding and Control Element Separation From: "Joel M. Halpern" Subject: Re: An approach to modeling ForCES events To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <1113401595.1084.119.camel@jzny.localdomain> Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe A couple of comments in line. Yours, Joel At 10:13 AM 4/13/2005, Jamal Hadi Salim wrote: >On Wed, 2005-04-13 at 07:44, Joel M. Halpern wrote: > > Assume that the LFB include a foo and bar elements. foo is an array > > whose contents are a structure with fields baz, caz, daz where daz > > is in turn an array of uint32. > > oddity is an array indexed by the same idex as the daz entires. > > > >Does oddity make sense the way you described it? If i read correctly, >there will be many daz "tables" but only one oddity. This construction of interacting tables is not common, but it can occur. The oddity table might be a table of DSCPs. The foo table might be a microflow (4-tuple) table which can include traffic with differing DSCPs. One can imagine other cases. I included this mainly to show that the indexing is not confined to the table where the event is detected. > > I have not defined any specific semantics for the objects because it would > > take a lot of text. These are simply examples of things which can change, > > and which teh CE wants to know about. > > > >Didnt quiet follow: >Are you talking about registration? Or how things will be laid out in >the LFB text? I hope we can craft a better example for the model document, so that folks will know how to write event sections for their LFB class definitions. > > > > > > bar > > > > report if bar changes > > > > bar > > > > > > > >I am assuming the target is going to be a path syntax i.e you just have >it above for illustratation purposes. My current thinking is that the LFB class definition event declaration can use field names (like bar) and field name sequences (p-struct.p-field-struct.q-field) with array subscript indications (the dollar sign variables) rather than using the numeric values of the path. (The first field by definition must be a top level element of the LFB inside which this event declaration appears.) After all, this path appears in the class definition. Humans will find the field names easier to deal with than the numbers. And the XML parser can figure out what field is being referred to using either syntax. This applies to both the declaration of the field that is triggering the event, and the declarations of fields to be reported in the event notification. Thanks, Joel From owner-forces@PEACH.EASE.LSOFT.COM Wed Apr 13 11:16:04 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04798 for ; Wed, 13 Apr 2005 11:16:04 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DLjkq-0001cM-RJ for forces-archive@IETF.ORG; Wed, 13 Apr 2005 11:26:15 -0400 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <14.0101038B@cherry.ease.lsoft.com>; Wed, 13 Apr 2005 11:16:03 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 66382876 for FORCES@PEACH.EASE.LSOFT.COM; Wed, 13 Apr 2005 11:16:00 -0400 Received: from 208.2.156.7 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Wed, 13 Apr 2005 11:16:00 -0500 Received: from [10.0.0.9] ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2005041308164891:16129 ; Wed, 13 Apr 2005 08:16:48 -0700 References: <6.2.1.2.0.20050413074255.02ee5e70@localhost> <1113401595.1084.119.camel@jzny.localdomain> <6.2.1.2.0.20050413102440.02d49790@localhost> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 X-MIMETrack: Itemize by SMTP Server on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 04/13/2005 08:16:49 AM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 04/13/2005 08:16:50 AM, Serialize complete at 04/13/2005 08:16:50 AM Content-Transfer-Encoding: 7bit Content-Type: text/plain Approved-By: Jamal Hadi Salim Message-ID: <1113405356.1076.191.camel@jzny.localdomain> Date: Wed, 13 Apr 2005 11:15:56 -0400 Reply-To: hadi@znyx.com Sender: Forwarding and Control Element Separation From: Jamal Hadi Salim Organization: Znyx Networks Subject: Re: An approach to modeling ForCES events To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <6.2.1.2.0.20050413102440.02d49790@localhost> Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c Content-Transfer-Encoding: 7bit On Wed, 2005-04-13 at 10:28, Joel M. Halpern wrote: > Given a table with fields a, b, and c, it does not seem obvious to me that > being interested in all changes to fields anywhere in the table implies any > likelihood of the CE being interested in notification of changes to b or c. Agreed. It may make sense to have ability to have multiple targets specified such as specifying interest only in changes to a and c: foo.$1.a foo.$1.c maybe a & or || relationship to the two as well (dont wanna complicate this) > As a simple example, the "a" field might be status, which the CE needs to > know about changes to, while the "b" and "c" fields are statistical (change > all the time, but the CE will get the fields when he needs the value.) I think the granularity is what matters. As an example, I would be interested in a stateful classifier table whenever it adds a new entry to its tracking table or it deletes an existing entry for whatever reason to be the trigger for notification. But it still does make sense for me to be interested in the statistics of a specific entry when the received packets exceed a threshold for example. This is a conflict resolution problem. Three solutions: 1) You could say in simple terms that the more fine grained event subscribed to is should be used as a trigger in case of conflict. i.e if i subsribe to changes in table foo and foo.$1.a then foo.$1.a is used in case its the one that changes. 2) You could also be explicit from CE and give the events priorities so the FE knows which one to use a s a trigger in case of conflicts. 3) Or you could say just send "event ID 10: something happened to table foo" in addition to "event ID 500: receive packet count stats on foo.1 exceeded 75" > Also, it does not seem that being interested in creation and deletion of > entries in the table means that the CE is interested in notifications of > changes to field values of existing elements. (Again, the existence entries > may reflect interfaces or signaling events, while the contents may be > statistical.) > The delienation of from seems to solve this already, no? BTW, I am looking at the construct you have (we should discuss the wire format at some point) - and i think you have all the verbosity levels: You could send to the CE the event without the . You could also send the event with which contains the new values etc. Again, I dont want to complicate things on this first stage. The end goal should be to reduce the amount of info to be sent on the wire (read: info to be processed by CE) if possible and being very specific on what nodes change. The later part we achieve already from what you posted. I think the only difference you and i have at the moment is the hierachy implications and conflict resolution is something that needs to be resolved regardless. cheers, jamal From owner-forces@PEACH.EASE.LSOFT.COM Wed Apr 13 11:26:01 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05781 for ; Wed, 13 Apr 2005 11:26:01 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DLjuV-0001qX-NY for forces-archive@IETF.ORG; Wed, 13 Apr 2005 11:36:11 -0400 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <5.01010453@cherry.ease.lsoft.com>; Wed, 13 Apr 2005 11:26:02 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 66383471 for FORCES@PEACH.EASE.LSOFT.COM; Wed, 13 Apr 2005 11:26:01 -0400 Received: from 208.2.156.7 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Wed, 13 Apr 2005 11:26:01 -0500 Received: from [10.0.0.9] ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2005041308265034:16148 ; Wed, 13 Apr 2005 08:26:50 -0700 References: <6.2.1.2.0.20050413074255.02ee5e70@localhost> <1113401595.1084.119.camel@jzny.localdomain> <6.2.1.2.0.20050413102917.02d49aa8@localhost> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 X-MIMETrack: Itemize by SMTP Server on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 04/13/2005 08:26:50 AM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 04/13/2005 08:26:51 AM, Serialize complete at 04/13/2005 08:26:51 AM Content-Transfer-Encoding: 7bit Content-Type: text/plain Approved-By: Jamal Hadi Salim Message-ID: <1113405958.1084.196.camel@jzny.localdomain> Date: Wed, 13 Apr 2005 11:25:58 -0400 Reply-To: hadi@znyx.com Sender: Forwarding and Control Element Separation From: Jamal Hadi Salim Organization: Znyx Networks Subject: Re: An approach to modeling ForCES events Comments: To: "Joel M. Halpern" To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <6.2.1.2.0.20050413102917.02d49aa8@localhost> Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Content-Transfer-Encoding: 7bit On Wed, 2005-04-13 at 10:36, Joel M. Halpern wrote: > My current thinking is that the LFB class definition event declaration can > use field names (like bar) and field name sequences > (p-struct.p-field-struct.q-field) with array subscript indications (the > dollar sign variables) rather than using the numeric values of the path. > (The first field by definition must be a top level element of the LFB > inside which this event declaration appears.) After all, this path appears > in the class definition. Humans will find the field names easier to deal > with than the numbers. And the XML parser can figure out what field is > being referred to using either syntax. This applies to both the > declaration of the field that is triggering the event, and the declarations > of fields to be reported in the event notification. > Ok, makes sense. At some point we should correlate with a wire format (thats the angle i was coming from). cheers, jamal From owner-forces@PEACH.EASE.LSOFT.COM Wed Apr 13 12:13:13 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA09709 for ; Wed, 13 Apr 2005 12:13:12 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DLkeA-0003EV-QY for forces-archive@IETF.ORG; Wed, 13 Apr 2005 12:23:24 -0400 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <9.0101053E@cherry.ease.lsoft.com>; Wed, 13 Apr 2005 12:13:12 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 66384825 for FORCES@PEACH.EASE.LSOFT.COM; Wed, 13 Apr 2005 12:13:11 -0400 Received: from 208.184.15.238 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Wed, 13 Apr 2005 12:13:11 -0500 Received: from [64.254.114.114] (HELO JMHLap3.stevecrocker.com) by EXECDSL.COM (CommuniGate Pro SMTP 3.3) with ESMTP id 9920978 for FORCES@PEACH.EASE.LSOFT.COM; Wed, 13 Apr 2005 12:13:09 -0400 X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 References: <6.2.1.2.0.20050413074255.02ee5e70@localhost> <1113401595.1084.119.camel@jzny.localdomain> <6.2.1.2.0.20050413102917.02d49aa8@localhost> <1113405958.1084.196.camel@jzny.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Approved-By: "Joel M. Halpern" Message-ID: <6.2.1.2.0.20050413121029.02d46920@localhost> Date: Wed, 13 Apr 2005 12:13:03 -0400 Reply-To: "Joel M. Halpern" Sender: Forwarding and Control Element Separation From: "Joel M. Halpern" Subject: Re: An approach to modeling ForCES events To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <1113405958.1084.196.camel@jzny.localdomain> Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 The on-the-wire format to report an event is, I think, quite simple. OP-TLV, code = notification path-data-tlv path = flags, length = 2, path = notification base | event id data = encoded format of fields defined in the reports clause of the event Thus, the actual paths to the trigger and the report fields do not even need to appear in the notification, since they are implied by the notification ID. Yours, Joel At 11:25 AM 4/13/2005, Jamal Hadi Salim wrote: >On Wed, 2005-04-13 at 10:36, Joel M. Halpern wrote: > > > My current thinking is that the LFB class definition event declaration can > > use field names (like bar) and field name sequences > > (p-struct.p-field-struct.q-field) with array subscript indications (the > > dollar sign variables) rather than using the numeric values of the path. > > (The first field by definition must be a top level element of the LFB > > inside which this event declaration appears.) After all, this path > appears > > in the class definition. Humans will find the field names easier to deal > > with than the numbers. And the XML parser can figure out what field is > > being referred to using either syntax. This applies to both the > > declaration of the field that is triggering the event, and the > declarations > > of fields to be reported in the event notification. > > > >Ok, makes sense. At some point we should correlate with a wire format >(thats the angle i was coming from). > >cheers, >jamal From owner-forces@PEACH.EASE.LSOFT.COM Wed Apr 13 12:33:59 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11573 for ; Wed, 13 Apr 2005 12:33:59 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DLkyH-0003sm-Uu for forces-archive@IETF.ORG; Wed, 13 Apr 2005 12:44:11 -0400 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <14.010105B7@cherry.ease.lsoft.com>; Wed, 13 Apr 2005 12:33:59 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 66386561 for FORCES@PEACH.EASE.LSOFT.COM; Wed, 13 Apr 2005 12:33:58 -0400 Received: from 208.184.15.238 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Wed, 13 Apr 2005 12:33:58 -0500 Received: from [64.254.114.114] (HELO JMHLap3.stevecrocker.com) by EXECDSL.COM (CommuniGate Pro SMTP 3.3) with ESMTP id 9921128 for FORCES@PEACH.EASE.LSOFT.COM; Wed, 13 Apr 2005 12:33:57 -0400 X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 References: <6.2.1.2.0.20050413074255.02ee5e70@localhost> <1113401595.1084.119.camel@jzny.localdomain> <6.2.1.2.0.20050413102917.02d49aa8@localhost> <1113405958.1084.196.camel@jzny.localdomain> <6.2.1.2.0.20050413121029.02d46920@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Approved-By: "Joel M. Halpern" Message-ID: <6.2.1.2.0.20050413123222.02c1da08@localhost> Date: Wed, 13 Apr 2005 12:33:54 -0400 Reply-To: "Joel M. Halpern" Sender: Forwarding and Control Element Separation From: "Joel M. Halpern" Subject: Re: An approach to modeling ForCES events To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <6.2.1.2.0.20050413121029.02d46920@localhost> Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 One case I forgot to mention. At 12:13 PM 4/13/2005, Joel M. Halpern wrote: >The on-the-wire format to report an event is, I think, quite simple. > >OP-TLV, code = notification > path-data-tlv > path = flags, length = 2, path = notification base | event id > data = encoded format of fields defined in the reports clause > of the event If the event is triggered by an entry in a table, then the path is longer, with the relevant subscripts added to the path. So if foo.2.bar.3 triggered event ID 6, with event base ID of 11, then the path would be length = 4, IDs = 11, 6, 2, 3 >Thus, the actual paths to the trigger and the report fields do not even >need to appear in the notification, since they are implied by the >notification ID. > >Yours, >Joel From owner-forces@PEACH.EASE.LSOFT.COM Thu Apr 14 20:22:40 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA14797 for ; Thu, 14 Apr 2005 20:22:40 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DMElf-0002y4-8E for forces-archive@IETF.ORG; Thu, 14 Apr 2005 20:33:07 -0400 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <10.01014307@cherry.ease.lsoft.com>; Thu, 14 Apr 2005 20:22:37 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 66611878 for FORCES@PEACH.EASE.LSOFT.COM; Thu, 14 Apr 2005 20:22:35 -0400 Received: from 134.134.136.18 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Thu, 14 Apr 2005 20:22:35 -0400 Received: from orsfmr100.jf.intel.com (orsfmr100.jf.intel.com [10.7.209.16]) by orsfmr004.jf.intel.com (8.12.10/8.12.10/d: major-outer.mc,v 1.1 2004/09/17 17:50:56 root Exp $) with ESMTP id j3F0MZdm013061; Fri, 15 Apr 2005 00:22:35 GMT Received: from orsmsxvs040.jf.intel.com (orsmsxvs040.jf.intel.com [192.168.65.206]) by orsfmr100.jf.intel.com (8.12.10/8.12.10/d: major-inner.mc,v 1.2 2004/09/17 18:05:01 root Exp $) with SMTP id j3F0MVEJ009896; Fri, 15 Apr 2005 00:22:35 GMT Received: from orsmsx331.amr.corp.intel.com ([192.168.65.56]) by orsmsxvs040.jf.intel.com (SAVSMTP 3.1.7.47) with SMTP id M2005041417223413187 ; Thu, 14 Apr 2005 17:22:34 -0700 Received: from orsmsx408.amr.corp.intel.com ([192.168.65.52]) by orsmsx331.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 14 Apr 2005 17:22:34 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Thread-Topic: An approach to modeling ForCES events Thread-Index: AcVAMvYT1nOZIS9qTmyaBhJ/kl9pdABHR7Xw X-OriginalArrivalTime: 15 Apr 2005 00:22:34.0744 (UTC) FILETIME=[38960780:01C54151] X-Scanned-By: MIMEDefang 2.44 Approved-By: "Deleganes, Ellen M" Message-ID: <468F3FDA28AA87429AD807992E22D07E04EE06FB@orsmsx408> Date: Thu, 14 Apr 2005 17:25:00 -0700 Reply-To: "Deleganes, Ellen M" Sender: Forwarding and Control Element Separation From: "Deleganes, Ellen M" Subject: Re: An approach to modeling ForCES events Comments: To: hadi@znyx.com To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: 515708a075ffdf0a79d1c83b601e2afd Content-Transfer-Encoding: quoted-printable 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 or 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.=20 Regards, Ellen -----Original Message----- From: Forwarding and Control Element Separation [mailto:FORCES@PEACH.EASE.LSOFT.COM] On Behalf Of Jamal Hadi Salim Sent: Wednesday, April 13, 2005 7:13 AM To: FORCES@PEACH.EASE.LSOFT.COM Subject: Re: An approach to modeling ForCES events Joel, Good - lets have some activity on the list; hopefully this discussion doesnt turn out into you and I batting a ball at each other(trying to guilt other people ;-> We can make good progress if people understand whats being said now as opposed to spending many hours later rehashing the same things again) I have a small variation to your approach further below. It wouldnt be fun otherwise ;-> On Wed, 2005-04-13 at 07:44, Joel M. Halpern wrote: > Assume that the LFB include a foo and bar elements. foo is an array=20 > whose contents are a structure with fields baz, caz, daz where daz=20 > is in turn an array of uint32. > oddity is an array indexed by the same idex as the daz entires. >=20 Does oddity make sense the way you described it? If i read correctly,=20 there will be many daz "tables" but only one oddity. > I have not defined any specific semantics for the objects because it would=20 > take a lot of text. These are simply examples of things which can change,=20 > and which teh CE wants to know about. >=20 Didnt quiet follow: Are you talking about registration? Or how things will be laid out in the LFB text?=20 > > > bar > > report if bar changes > > bar > > > I am assuming the target is going to be a path syntax i.e you just have it above for illustratation purposes. > > foo.$1.baz > 75 > report if any baz in foo gets above 75 > > foo.$1.baz > foo.$1.caz > > > > > foo.$1.daz.$2 > 3 > > foo.$1.daz.$2 > foo.$1.caz > oddity.$2.state > > > > oddity > > > > bar > > > >=20 I think you have all the needed constructs above. Good stuff. The triggers that cause events as you have them right now may not be universal; example fallsbelow or exceeds makes sense only if you have counters. I think this can be revisted later, but let me just digress a little: I may also be interested in getting a synchronous event ("send me=20 bar every 30 seconds") or even more interesting async ones perhaps driven by some packet arrival like "notify me about bar when you receive ICMPs from Joel". I am not sure the second one fits well, but certainly the first one does.=20 Also additional semantics like "let me know if it changes X times" which could be viewed as a superset of where X=3D1 > This declares that paths within this LFB that start with 7 reference=20 > events, and paths that start with 8 are for the boolean variables that > represent registration state for the events. Paths starting with 7 will=20 > appear only in notifications. > > Q: I could have used a single path starting point, and simply had different=20 > meanings for its use in SET / GET (where it would reference the boolean=20 > variable) and in NOTIFICATIONS (where it would mean the event itself and=20 > the associated reporting type. I thought this was a bad idea. >=20 I think your approach of the subscription being a different scope than notification is better. Related: The event subscribe/unsubscribe are essentially SETs. GET "all events" or "all event to do with foo" doesnt exist at the moment. > Each even then has an ID which is concatenated with the base paths to start=20 > building the notification and registration paths. For event 1 (changes to=20 > bar) the paths are simply 7.1 for the notification and 8.1 for registering. Makes sense. > Events 2 and 3 are events about array elements inside the LFB. Thus the=20 > path to a specific event is the base, the eventid, and the subscript. So a=20 > specific occurrence (say in the fourth daz entry in the second foo entry)=20 > of event 3 would be reported with the path 7.3.2.4 Q. How does an FE LFB say "I can support foo.$1.daz.$2" as a event target? If you decide to describe it in english in some text - does that limit things? Or do we let the CE register and have the FE reject when it cant do it. Heres where i think i should mention the variation i have over what you present, the other way to do this is to say: If i subscribe to event path 8.X foo it would mean I am interested in anything that happens in foo.=20 If i subscribe to target foo.$1.baz then i am interested in column baz of table foo. If i subscribe to target bar then i am only interested in that scalar. In other words theres a hierachical connotation to event targets. i.e if i say target "foo" then that implies "foo.$1.baz" and "foo.$1.caz" and "foo.$1.daz.$2" The only issue with above is conflict resolution which is resolvable. The construct still is the one that defines the verbosity of what gets reported back. In other words, even on the you could have different syntatic sugar; verbosity levels are: 3) "tell me what exactly changed". The notify will have to give you the path and new target values. 2) "tell me the path of what changed" as well under event id 30. 1) "dont bother telling me what exactly changed - all i need to know is event 3 happened" > Q: We have been asked to support registering for events on a whole=20 > table. Currently, set 8.3.2 would be setting teh table of boolean=20 > variables.=20 Refer to my comments above. > However, it is not legal to directly create or delete entries=20 > in this table (Since it mirrors the foo[]daz table structure.) So we could=20 > declare that a reference to the entire array is in this case a reference to=20 > a single boolean that covers the array. It seems useful to have that. But=20 > allowing that will seriously complicate the type determination logic. >=20 Seems like it will be ok to subscribe/unsubscribe though. In other words if i subscribe for event 3 - that is something that will exist in the FEs LFB state information i.e i can query it; if i unsubscribe then i cant query for that event. > Each event includes a target variable (with subscripts if the target is in=20 > an array.) The subscripts are named so they can be referenced in the=20 > reports clause. The subscripts themselves will appear in the event=20 > notification. > Each event then includes a condition. I have not tried to enumerate all=20 > the conditions yet, but some of them are shown above. The conditions are essentially triggers for the events - I think we can probably say there exist only a handful of those. > Q: Should we directly put the different condition tags, as I have done > above, or should we use: > > > > value > >=20 > The target variable can be an array, rather than its entries. In that > case, the change trigger would mean the deletion or creation of any=20 > entry. (We will probably have separate deletion and creation triggers as=20 > well.) In that case, the event path will include the subscript of the > entry being created or deleted. the in the reports will=20 > cause a scalar to be included indicating what event has occurred. (This is=20 > legal with any report, but is likely most useful with arrays.) >=20 > The reports element indicates what information to send along with the=20 > notification. It can select any elements from the LFB Class. It can use=20 > any of the subscripts in the trigger path. Essentially, it defines the=20 > data type and contents for the data portion of the notification TLV. >=20 > One additional question that occurred to me later is, if a change is made=20 > by the CE, and the CE is registered for an event triggered by the=20 > change, should the notification be generated? Should we have a flag in=20 > the SET request to suppress such notifications? My first reaction is that=20 > it should be generated even for changes by the CE, but I am not sure. >=20 > Is this sufficiently ugly to prompt someone to do a better job? >=20 Look at my comments on more genericity of subscription; I think the constructs needed are all there in what you define. Hopefully the other folks in the protocol and model would chip in as well in this discussion. cheers, jamal From owner-forces@PEACH.EASE.LSOFT.COM Fri Apr 15 10:19:41 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04246 for ; Fri, 15 Apr 2005 10:19:41 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DMRpl-0008DY-OS for forces-archive@IETF.ORG; Fri, 15 Apr 2005 10:30:16 -0400 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <21.0101503C@cherry.ease.lsoft.com>; Fri, 15 Apr 2005 10:19:39 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 66707804 for FORCES@PEACH.EASE.LSOFT.COM; Fri, 15 Apr 2005 10:19:35 -0400 Received: from 208.2.156.7 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Fri, 15 Apr 2005 10:19:35 -0400 Received: from [10.0.0.229] ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2005041507202200:18588 ; Fri, 15 Apr 2005 07:20:22 -0700 References: <468F3FDA28AA87429AD807992E22D07E04EE06FB@orsmsx408> Mime-Version: 1.0 X-Mailer: Evolution 2.2.1.1 X-MIMETrack: Itemize by SMTP Server on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 04/15/2005 07:20:22 AM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 04/15/2005 07:20:25 AM, Serialize complete at 04/15/2005 07:20:25 AM Content-Transfer-Encoding: 7bit Content-Type: text/plain Approved-By: Jamal Hadi Salim Message-ID: <1113574771.7608.12.camel@localhost.localdomain> Date: Fri, 15 Apr 2005 10:19:31 -0400 Reply-To: hadi@znyx.com Sender: Forwarding and Control Element Separation From: Jamal Hadi Salim Organization: ZNYX Networks Subject: Re: An approach to modeling ForCES events Comments: To: "Deleganes, Ellen M" To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <468F3FDA28AA87429AD807992E22D07E04EE06FB@orsmsx408> Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Content-Transfer-Encoding: 7bit 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 > or 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 owner-forces@PEACH.EASE.LSOFT.COM Fri Apr 15 10:48:33 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06545 for ; Fri, 15 Apr 2005 10:48:33 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DMSHj-0000ru-Sm for forces-archive@IETF.ORG; Fri, 15 Apr 2005 10:59:08 -0400 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <18.01014F75@cherry.ease.lsoft.com>; Fri, 15 Apr 2005 10:48:33 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 66710554 for FORCES@PEACH.EASE.LSOFT.COM; Fri, 15 Apr 2005 10:48:32 -0400 Received: from 208.184.15.238 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Fri, 15 Apr 2005 10:48:32 -0400 Received: from [64.254.114.114] (HELO JMHLap3.stevecrocker.com) by EXECDSL.COM (CommuniGate Pro SMTP 3.3) with ESMTP id 9945724 for FORCES@PEACH.EASE.LSOFT.COM; Fri, 15 Apr 2005 10:48:31 -0400 X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 References: <468F3FDA28AA87429AD807992E22D07E04EE06FB@orsmsx408> <1113574771.7608.12.camel@localhost.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Approved-By: "Joel M. Halpern" Message-ID: <6.2.1.2.0.20050415104106.02c7d690@localhost> Date: Fri, 15 Apr 2005 10:48:28 -0400 Reply-To: "Joel M. Halpern" Sender: Forwarding and Control Element Separation From: "Joel M. Halpern" Subject: Re: An approach to modeling ForCES events To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <1113574771.7608.12.camel@localhost.localdomain> Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Yes, one of the tasks in writing the event section of the model document will be to put together a list of ALL the triggers we want to support, what model information they need, and the exact semantics. I was just showing some samples so as to indicate the approach. For example, I did not show a case with a configurable threshold, whether the alarm condition might be foo.$1.threshold I am trying to find out if this approach, with explicitly listed events, the mechanism for subscript handling, the ability to register for changes to a table itself, and separately some way to register for all occurrences of an element related event in a table (which I have not figured out) is what we want. Frankly, I am really hoping someone will come up with something with this expressive power but a better syntax / structure, because I am not really happy with what I have suggested. Things like the $1 (or worse foo.$1.bar.$2.zang.$3.quibble) are not what I would really like. But since you need to report the index of the event, and you may need to pick elements out of parallel tables with related indexing for reporting with the event, I can not currently see any way around this. Yours, Joel At 10:19 AM 4/15/2005, Jamal Hadi Salim wrote: >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 > > or 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 owner-forces@PEACH.EASE.LSOFT.COM Fri Apr 15 10:51:58 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06818 for ; Fri, 15 Apr 2005 10:51:58 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DMSL3-00012W-Lg for forces-archive@IETF.ORG; Fri, 15 Apr 2005 11:02:34 -0400 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <13.01015095@cherry.ease.lsoft.com>; Fri, 15 Apr 2005 10:51:59 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 66710836 for FORCES@PEACH.EASE.LSOFT.COM; Fri, 15 Apr 2005 10:51:58 -0400 Received: from 134.134.136.17 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Fri, 15 Apr 2005 10:51:57 -0400 Received: from orsfmr101.jf.intel.com (orsfmr101.jf.intel.com [10.7.209.17]) by orsfmr003.jf.intel.com (8.12.10/8.12.10/d: major-outer.mc,v 1.1 2004/09/17 17:50:56 root Exp $) with ESMTP id j3FEpvk8005094; Fri, 15 Apr 2005 14:51:57 GMT Received: from orsmsxvs041.jf.intel.com (orsmsxvs041.jf.intel.com [192.168.65.54]) by orsfmr101.jf.intel.com (8.12.10/8.12.10/d: major-inner.mc,v 1.2 2004/09/17 18:05:01 root Exp $) with SMTP id j3FEpiUC026669; Fri, 15 Apr 2005 14:51:57 GMT Received: from orsmsx332.amr.corp.intel.com ([192.168.65.60]) by orsmsxvs041.jf.intel.com (SAVSMTP 3.1.7.47) with SMTP id M2005041507500503145 ; Fri, 15 Apr 2005 07:50:05 -0700 Received: from orsmsx408.amr.corp.intel.com ([192.168.65.52]) by orsmsx332.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 15 Apr 2005 07:50:05 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Thread-Topic: An approach to modeling ForCES events Thread-Index: AcVBxisHLIb5RubvQiCe47IHmNVoxwABFlzw X-OriginalArrivalTime: 15 Apr 2005 14:50:05.0074 (UTC) FILETIME=[69001720:01C541CA] X-Scanned-By: MIMEDefang 2.44 Approved-By: "Deleganes, Ellen M" Message-ID: <468F3FDA28AA87429AD807992E22D07E04EE0A24@orsmsx408> Date: Fri, 15 Apr 2005 07:52:31 -0700 Reply-To: "Deleganes, Ellen M" Sender: Forwarding and Control Element Separation From: "Deleganes, Ellen M" Subject: Re: An approach to modeling ForCES events Comments: To: hadi@znyx.com To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Content-Transfer-Encoding: quoted-printable 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:FORCES@PEACH.EASE.LSOFT.COM] On Behalf Of Jamal Hadi Salim Sent: Friday, April 15, 2005 7:20 AM To: FORCES@PEACH.EASE.LSOFT.COM 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 > or 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.=20 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 owner-forces@PEACH.EASE.LSOFT.COM Fri Apr 15 14:52:38 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA01752 for ; Fri, 15 Apr 2005 14:52:37 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DMW5x-0006gf-1w for forces-archive@IETF.ORG; Fri, 15 Apr 2005 15:03:14 -0400 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <11.01015586@cherry.ease.lsoft.com>; Fri, 15 Apr 2005 14:52:35 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 66740112 for FORCES@PEACH.EASE.LSOFT.COM; Fri, 15 Apr 2005 14:52:34 -0400 Received: from 208.2.156.7 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Fri, 15 Apr 2005 14:52:33 -0400 Received: from [10.0.0.229] ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2005041511532056:18949 ; Fri, 15 Apr 2005 11:53:20 -0700 References: <468F3FDA28AA87429AD807992E22D07E04EE06FB@orsmsx408> <1113574771.7608.12.camel@localhost.localdomain> <6.2.1.2.0.20050415104106.02c7d690@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.2.1.1 X-MIMETrack: Itemize by SMTP Server on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 04/15/2005 11:53:21 AM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 04/15/2005 11:53:23 AM, Serialize complete at 04/15/2005 11:53:23 AM Content-Transfer-Encoding: 7bit Content-Type: text/plain Approved-By: Jamal Hadi Salim Message-ID: <1113591149.7608.100.camel@localhost.localdomain> Date: Fri, 15 Apr 2005 14:52:29 -0400 Reply-To: hadi@znyx.com Sender: Forwarding and Control Element Separation From: Jamal Hadi Salim Organization: ZNYX Networks Subject: Re: An approach to modeling ForCES events To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <6.2.1.2.0.20050415104106.02c7d690@localhost> Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: 22bbb45ef41b733eb2d03ee71ece8243 Content-Transfer-Encoding: 7bit On Fri, 2005-15-04 at 10:48 -0400, Joel M. Halpern wrote: > Yes, one of the tasks in writing the event section of the model document > will be to put together a list of ALL the triggers we want to support, what > model information they need, and the exact semantics. ok, nice. > I was just showing > some samples so as to indicate the approach. For example, I did not show a > case with a configurable threshold, whether the alarm condition might be > foo.$1.threshold > I think it would be better if they are listed somewhere so there is no confusion (understood that this was a quick intro you did). > I am trying to find out if this approach, with explicitly listed events, > the mechanism for subscript handling, the ability to register for changes > to a table itself, and separately some way to register for all occurrences > of an element related event in a table (which I have not figured out) is > what we want. > I didnt catch the last part on "all occurrences of an element related event in a table". But certainly explictly listing of possible events on a per LFB class is the approach taken by SNMP traps - so theres prior experience. I am however skeptical about being as restrictive as SNMP was; i.e i should be able to show interest in table foo and/or foo.$1.daz. > Frankly, I am really hoping someone will come up with something with this > expressive power but a better syntax / structure, because I am not really > happy with what I have suggested. Things like the $1 (or worse > foo.$1.bar.$2.zang.$3.quibble) are not what I would really like. But since > you need to report the index of the event, and you may need to pick > elements out of parallel tables with related indexing for reporting with > the event, I can not currently see any way around this. > How about this, lets list semantics in English and see how your approach fits and suggest how we could extend things (This also helps add text to explain the constructs you posted) For subscription purposes you would need the following: ======================================================= 1) a way to describe the specific event of interest. The explicit listing of events with registerBaseID for subscription, event IDs and for picking specific LFB-attributes is sufficient in my opinion. 2) A way to define a trigger. So far you have listed the following triggers: i) probably the most generic. Captures a change in any attribute. ii) iii) The above 2 are specific to counters of some form. Maybe we need a .. to surround each. We should add more triggers; timers for example. 3) Event report formatting. The looks good. The main issue i had is the verbosity level of reporting. I know you (Joel) have had issues with the levels of reporting in other discussions regarding the protocol. I think it's an important addition. Example of verbosity would be something along the lines of: *level0) "just tell me when the event happens - dont want any details" *level1) "tell what the value of foo.$1.bar when this event happens" 4) Ability for the FE to reject nonsense. For notification, whats needed is: ================================== Close to what you had in the wire format you posted earlier ... 1) A event ID 2) optionally (depending on whether we agree on reporting levels) a data value for that path as per subscription time construct. On Hierarchy and conflict resolution ==================================== Consider a structure such as a table which may have cells/children composed of other structures which may in turn have other structures (eventually hitting some terminal atomic element). To use your earlier example: Assume an LFB with a foo and bar elements. foo is an array whose contents are a structure with fields baz, caz, daz where daz is in turn an array of uint32. Assume the only trigger in this LFB is Here are some sample events that i may be interested in (and to which i should be allowed to subscribe to): A) change in foo.$1.daz.3 (entries in all columns of foo called daz. In particular the index 3 of daz). B) change in foo.$1.daz (entries in all columns of foo called daz) C) change in foo (everything in daz) Clearly A is a subset of B which is a subset of C. ->A solution to this is to explicitly disallow it by definition. This is what SNMP does i think (however with triggers we are already going beyond what SNMP can do). ->Another is to allow 3 events to be generated every time C happens; 2 every time B but not intersecting C happens etc. ->Another way to do it is have the FE figure it out at event generation time and only send events which are most specific (example if C happens the only C related event is triggered). -> an extension to the above: add construct which unambigously tells the FE what event to send. In the above example, C would be set to be higher priority than B (which is higher than A). Having said the above, it is clearly desirable once you have hierachies to also be able to ask for reporting thats less specific. To use the example above; if i subscribe to an event and have be table foo, then i should be able to define that returns me in level1 verbosity level what caused the event; i.e i dont wanna explicitly say "report to me the value of foo.$1.bar" Some of these thoughts are derived from our own implementation experiences and subliminal messages of what we could have done better. cheers, jamal From owner-forces@PEACH.EASE.LSOFT.COM Fri Apr 15 15:39:50 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09623 for ; Fri, 15 Apr 2005 15:39:50 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DMWpf-0001iu-Nr for forces-archive@IETF.ORG; Fri, 15 Apr 2005 15:50:28 -0400 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <15.010157D1@cherry.ease.lsoft.com>; Fri, 15 Apr 2005 15:39:50 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 66744737 for FORCES@PEACH.EASE.LSOFT.COM; Fri, 15 Apr 2005 15:39:49 -0400 Received: from 208.184.15.238 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Fri, 15 Apr 2005 15:39:41 -0400 Received: from [64.254.114.114] (HELO JMHLap3.stevecrocker.com) by EXECDSL.COM (CommuniGate Pro SMTP 3.3) with ESMTP id 9948503 for FORCES@PEACH.EASE.LSOFT.COM; Fri, 15 Apr 2005 15:39:40 -0400 X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 References: <468F3FDA28AA87429AD807992E22D07E04EE06FB@orsmsx408> <1113574771.7608.12.camel@localhost.localdomain> <6.2.1.2.0.20050415104106.02c7d690@localhost> <1113591149.7608.100.camel@localhost.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Approved-By: "Joel M. Halpern" Message-ID: <6.2.1.2.0.20050415153231.02f04bf8@localhost> Date: Fri, 15 Apr 2005 15:39:37 -0400 Reply-To: "Joel M. Halpern" Sender: Forwarding and Control Element Separation From: "Joel M. Halpern" Subject: Re: An approach to modeling ForCES events To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <1113591149.7608.100.camel@localhost.localdomain> Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Trying for text description is quite sensible at this point. Reading your note, there is an assumption I am making, that may be different than yours. I believe that the LFB definition should indicate what events an instance of that LFB class amy generate. A CE may only register for events from that set. And each event declaration includes the specific trigger for that event. So, the CE does not get to decide "I want to know if foo.$1.daz changes unless the LFB definer has already defined that as an event and assigned it an ID. Thus, the events registrations and notifications do not need to include the full path to the variable that has caused the event (although they do need to include any subscripts in the path). This also makes declaring an event that is a change (creation or deletion of entry) in the array foo natural. If I assume that event 1 is changes in foo, and event 2 are changes in the foo.$1.caz variable, then I can register for event 1 by setting registerbase.1, and I can register for each event 2 that I want to by registering for registerbase.2.subscript. What is not obvious to me is what path the CE would use to register for all occurrences of event 2, without regard to subscript. As I said in the original, using the path registerbase.2 seems inconsistent with the normal meaning for that path (the array of all the individual registrations in that table.) Yours, Joel At 02:52 PM 4/15/2005, Jamal Hadi Salim wrote: >Assume the only trigger in this LFB is >Here are some sample events that i may be interested in (and to which i >should be allowed to subscribe to): >A) change in foo.$1.daz.3 (entries in all columns of foo called daz. In >particular the index 3 of daz). >B) change in foo.$1.daz (entries in all columns of foo called daz) >C) change in foo (everything in daz) From owner-forces@PEACH.EASE.LSOFT.COM Fri Apr 15 15:41:44 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09917 for ; Fri, 15 Apr 2005 15:41:43 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DMWrV-0001zS-Cj for forces-archive@IETF.ORG; Fri, 15 Apr 2005 15:52:21 -0400 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <21.01015718@cherry.ease.lsoft.com>; Fri, 15 Apr 2005 15:41:44 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 66744819 for FORCES@PEACH.EASE.LSOFT.COM; Fri, 15 Apr 2005 15:41:43 -0400 Received: from 208.184.15.238 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Fri, 15 Apr 2005 15:41:42 -0400 Received: from [64.254.114.114] (HELO JMHLap3.stevecrocker.com) by EXECDSL.COM (CommuniGate Pro SMTP 3.3) with ESMTP id 9948517 for FORCES@PEACH.EASE.LSOFT.COM; Fri, 15 Apr 2005 15:41:42 -0400 X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 References: <468F3FDA28AA87429AD807992E22D07E04EE06FB@orsmsx408> <1113574771.7608.12.camel@localhost.localdomain> <6.2.1.2.0.20050415104106.02c7d690@localhost> <1113591149.7608.100.camel@localhost.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Approved-By: "Joel M. Halpern" Message-ID: <6.2.1.2.0.20050415153949.02f1dcb8@localhost> Date: Fri, 15 Apr 2005 15:41:37 -0400 Reply-To: "Joel M. Halpern" Sender: Forwarding and Control Element Separation From: "Joel M. Halpern" Subject: Re: An approach to modeling ForCES events To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <1113591149.7608.100.camel@localhost.localdomain> Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 I don't know if this is useful, but is easy to represent. Instead of a boolean registration variable, we use a uint8, where 0 means "do not notify", 1 means "just notify with no body", and 2 means "notify with body according to the declared report information from the LFB class definition." I assume that event notifications will be relatively rare. If so, is the savings in the report worth it? Yours, Joel M. Halpern At 02:52 PM 4/15/2005, Jamal Hadi Salim wrote: >3) Event report formatting. >The looks good. The main issue i had is the verbosity level >of reporting. I know you (Joel) have had issues with the levels of >reporting in other discussions regarding the protocol. I think it's an >important addition. >Example of verbosity would be something along the lines of: > >*level0) "just tell me when the event happens - dont want any details" >*level1) "tell what the value of foo.$1.bar when this event happens" From owner-forces@PEACH.EASE.LSOFT.COM Fri Apr 15 16:12:12 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA18000 for ; Fri, 15 Apr 2005 16:12:12 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DMXL0-0005aG-FZ for forces-archive@IETF.ORG; Fri, 15 Apr 2005 16:22:50 -0400 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <0.01015972@cherry.ease.lsoft.com>; Fri, 15 Apr 2005 16:12:12 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 66747007 for FORCES@PEACH.EASE.LSOFT.COM; Fri, 15 Apr 2005 16:12:11 -0400 Received: from 208.2.156.7 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Fri, 15 Apr 2005 16:12:11 -0400 Received: from [10.0.0.229] ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2005041513125971:19027 ; Fri, 15 Apr 2005 13:12:59 -0700 References: <468F3FDA28AA87429AD807992E22D07E04EE06FB@orsmsx408> <1113574771.7608.12.camel@localhost.localdomain> <6.2.1.2.0.20050415104106.02c7d690@localhost> <1113591149.7608.100.camel@localhost.localdomain> <6.2.1.2.0.20050415153231.02f04bf8@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.2.1.1 X-MIMETrack: Itemize by SMTP Server on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 04/15/2005 01:12:59 PM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 04/15/2005 01:13:01 PM, Serialize complete at 04/15/2005 01:13:01 PM Content-Transfer-Encoding: 7bit Content-Type: text/plain Approved-By: Jamal Hadi Salim Message-ID: <1113595929.17859.14.camel@localhost.localdomain> Date: Fri, 15 Apr 2005 16:12:09 -0400 Reply-To: hadi@znyx.com Sender: Forwarding and Control Element Separation From: Jamal Hadi Salim Organization: ZNYX Networks Subject: Re: An approach to modeling ForCES events To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <6.2.1.2.0.20050415153231.02f04bf8@localhost> Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Content-Transfer-Encoding: 7bit On Fri, 2005-15-04 at 15:39 -0400, Joel M. Halpern wrote: > Trying for text description is quite sensible at this point. > > Reading your note, there is an assumption I am making, that may be > different than yours. > > I believe that the LFB definition should indicate what events an instance > of that LFB class amy generate. A CE may only register for events from > that set. And each event declaration includes the specific trigger for > that event. > > So, the CE does not get to decide "I want to know if foo.$1.daz changes > unless the LFB definer has already defined that as an event and assigned it > an ID. > Thus, the events registrations and notifications do not need to include the > full path to the variable that has caused the event (although they do need > to include any subscripts in the path). Ok, this was one of the modes i mentioned. I have no issues with doing it this way. > This also makes declaring an event that is a change (creation or deletion > of entry) in the array foo natural. > If I assume that event 1 is changes in foo, and event 2 are changes in the > foo.$1.caz variable, then I can register for event 1 by setting > registerbase.1, and I can register for each event 2 that I want to by > registering for registerbase.2.subscript. What is not obvious to me is > what path the CE would use to register for all occurrences of event 2, > without regard to subscript. As I said in the original, using the path > registerbase.2 seems inconsistent with the normal meaning for that path > (the array of all the individual registrations in that table.) > Ok, gotcha. Maybe we need a wildcard. And the subscripts are per $x ordering. Example: registerbase.2.* == "for table foo, all indices/rows, column caz". registerbase.2.1 == "for table foo, index=1, column caz" If event target was foo.$1.caz.$2, then: registerbase.2.* == "for table foo, all indices/rows, column caz". registerbase.2.1 == "for table foo, index=1, column caz" registerbase.2.*.4 == "for table foo, all indices/rows, column caz, index=4 of caz array". registerbase.2.1.5 == "for table foo, index=1, column caz, index=5 of caz array" Of course this still means the issue on hierachy and conflicts is still there. cheers, jamal From owner-forces@PEACH.EASE.LSOFT.COM Fri Apr 15 16:30:16 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA21497 for ; Fri, 15 Apr 2005 16:30:15 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DMXcT-0007CI-Rx for forces-archive@IETF.ORG; Fri, 15 Apr 2005 16:40:54 -0400 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <14.01015768@cherry.ease.lsoft.com>; Fri, 15 Apr 2005 16:30:16 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 66748182 for FORCES@PEACH.EASE.LSOFT.COM; Fri, 15 Apr 2005 16:30:15 -0400 Received: from 134.134.136.16 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Fri, 15 Apr 2005 16:30:15 -0400 Received: from orsfmr100.jf.intel.com (orsfmr100.jf.intel.com [10.7.209.16]) by orsfmr002.jf.intel.com (8.12.10/8.12.10/d: major-outer.mc,v 1.1 2004/09/17 17:50:56 root Exp $) with ESMTP id j3FKUAf8026683; Fri, 15 Apr 2005 20:30:10 GMT Received: from orsmsxvs040.jf.intel.com (orsmsxvs040.jf.intel.com [192.168.65.206]) by orsfmr100.jf.intel.com (8.12.10/8.12.10/d: major-inner.mc,v 1.2 2004/09/17 18:05:01 root Exp $) with SMTP id j3FKU8aD018411; Fri, 15 Apr 2005 20:30:10 GMT Received: from orsmsx331.amr.corp.intel.com ([192.168.65.56]) by orsmsxvs040.jf.intel.com (SAVSMTP 3.1.7.47) with SMTP id M2005041513300923366 ; Fri, 15 Apr 2005 13:30:09 -0700 Received: from orsmsx408.amr.corp.intel.com ([192.168.65.52]) by orsmsx331.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 15 Apr 2005 13:30:09 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Thread-Topic: An approach to modeling ForCES events Thread-Index: AcVB8y6QukAbiXYgQ4G3uIxxbsvMcAABkbnQ X-OriginalArrivalTime: 15 Apr 2005 20:30:09.0752 (UTC) FILETIME=[EB22DD80:01C541F9] X-Scanned-By: MIMEDefang 2.44 Approved-By: "Deleganes, Ellen M" Message-ID: <468F3FDA28AA87429AD807992E22D07E04F18EB4@orsmsx408> Date: Fri, 15 Apr 2005 13:32:36 -0700 Reply-To: "Deleganes, Ellen M" Sender: Forwarding and Control Element Separation From: "Deleganes, Ellen M" Subject: Re: An approach to modeling ForCES events Comments: To: "Joel M. Halpern" To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Content-Transfer-Encoding: quoted-printable I think it is valuable to have two levels of verbosity in reporting, where some mechanism exists to be able to select on a per event type basis. I think it depends on what the event is on whether you want more report information or not. For events that happen more frequently, maybe all you want are the notifications. In the case where you are generating events due to a counter exceeding (perhaps indicating some kind of bad behavior) then you probably do want more detailed information. Regards, Ellen -----Original Message----- From: Forwarding and Control Element Separation [mailto:FORCES@PEACH.EASE.LSOFT.COM] On Behalf Of Joel M. Halpern Sent: Friday, April 15, 2005 12:42 PM To: FORCES@PEACH.EASE.LSOFT.COM Subject: Re: An approach to modeling ForCES events I don't know if this is useful, but is easy to represent. Instead of a=20 boolean registration variable, we use a uint8, where 0 means "do not=20 notify", 1 means "just notify with no body", and 2 means "notify with body=20 according to the declared report information from the LFB class definition." I assume that event notifications will be relatively rare. If so, is the=20 savings in the report worth it? Yours, Joel M. Halpern At 02:52 PM 4/15/2005, Jamal Hadi Salim wrote: >3) Event report formatting. >The looks good. The main issue i had is the verbosity level >of reporting. I know you (Joel) have had issues with the levels of >reporting in other discussions regarding the protocol. I think it's an >important addition. >Example of verbosity would be something along the lines of: > >*level0) "just tell me when the event happens - dont want any details" >*level1) "tell what the value of foo.$1.bar when this event happens" From owner-forces@PEACH.EASE.LSOFT.COM Fri Apr 15 16:44:10 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA23063 for ; Fri, 15 Apr 2005 16:44:10 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DMXpw-000891-An for forces-archive@IETF.ORG; Fri, 15 Apr 2005 16:54:48 -0400 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <17.0101595F@cherry.ease.lsoft.com>; Fri, 15 Apr 2005 16:44:10 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 66749297 for FORCES@PEACH.EASE.LSOFT.COM; Fri, 15 Apr 2005 16:44:09 -0400 Received: from 208.184.15.238 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Fri, 15 Apr 2005 16:44:09 -0400 Received: from [64.254.114.114] (HELO JMHLap3.stevecrocker.com) by EXECDSL.COM (CommuniGate Pro SMTP 3.3) with ESMTP id 9949035 for FORCES@PEACH.EASE.LSOFT.COM; Fri, 15 Apr 2005 16:44:09 -0400 X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 References: <468F3FDA28AA87429AD807992E22D07E04F18EB4@orsmsx408> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Approved-By: "Joel M. Halpern" Message-ID: <6.2.1.2.0.20050415164145.02f068c0@localhost> Date: Fri, 15 Apr 2005 16:43:45 -0400 Reply-To: "Joel M. Halpern" Sender: Forwarding and Control Element Separation From: "Joel M. Halpern" Subject: Re: An approach to modeling ForCES events To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <468F3FDA28AA87429AD807992E22D07E04F18EB4@orsmsx408> Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 For each event, the event definition includes the indication as to what information is to be reported. The question is whether, for a given event, in some situations that the CE can determine when it registers, it will want the full information and in some circumstances (that it can determine at registration time) it will want only the indication of the event occurring. if the CE at registration can meaningfully make that distinction, then having different registration levels is useful. Yours, Joel At 04:32 PM 4/15/2005, Deleganes, Ellen M wrote: >I think it is valuable to have two levels of verbosity in reporting, >where some mechanism exists to be able to select on a per event type >basis. I think it depends on what the event is on whether you want more >report information or not. For events that happen more frequently, maybe >all you want are the notifications. In the case where you are generating >events due to a counter exceeding (perhaps indicating some kind of bad >behavior) then you probably do want more detailed information. > >Regards, >Ellen > > >-----Original Message----- >From: Forwarding and Control Element Separation >[mailto:FORCES@PEACH.EASE.LSOFT.COM] On Behalf Of Joel M. Halpern >Sent: Friday, April 15, 2005 12:42 PM >To: FORCES@PEACH.EASE.LSOFT.COM >Subject: Re: An approach to modeling ForCES events > >I don't know if this is useful, but is easy to represent. Instead of a >boolean registration variable, we use a uint8, where 0 means "do not >notify", 1 means "just notify with no body", and 2 means "notify with >body >according to the declared report information from the LFB class >definition." > >I assume that event notifications will be relatively rare. If so, is >the >savings in the report worth it? > >Yours, >Joel M. Halpern > >At 02:52 PM 4/15/2005, Jamal Hadi Salim wrote: > >3) Event report formatting. > >The looks good. The main issue i had is the verbosity level > >of reporting. I know you (Joel) have had issues with the levels of > >reporting in other discussions regarding the protocol. I think it's an > >important addition. > >Example of verbosity would be something along the lines of: > > > >*level0) "just tell me when the event happens - dont want any details" > >*level1) "tell what the value of foo.$1.bar when this event happens" From owner-forces@PEACH.EASE.LSOFT.COM Fri Apr 15 17:27:48 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA27794 for ; Fri, 15 Apr 2005 17:27:48 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DMYWA-0002Ur-6p for forces-archive@IETF.ORG; Fri, 15 Apr 2005 17:38:27 -0400 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <11.0101596D@cherry.ease.lsoft.com>; Fri, 15 Apr 2005 17:27:48 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 66751840 for FORCES@PEACH.EASE.LSOFT.COM; Fri, 15 Apr 2005 17:27:47 -0400 Received: from 208.2.156.7 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Fri, 15 Apr 2005 17:27:47 -0400 Received: from [10.0.0.229] ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2005041514283453:19114 ; Fri, 15 Apr 2005 14:28:34 -0700 References: <468F3FDA28AA87429AD807992E22D07E04F18EB4@orsmsx408> <6.2.1.2.0.20050415164145.02f068c0@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.2.1.1 X-MIMETrack: Itemize by SMTP Server on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 04/15/2005 02:28:34 PM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 04/15/2005 02:28:36 PM, Serialize complete at 04/15/2005 02:28:36 PM Content-Transfer-Encoding: 7bit Content-Type: text/plain Approved-By: Jamal Hadi Salim Message-ID: <1113600464.17859.30.camel@localhost.localdomain> Date: Fri, 15 Apr 2005 17:27:44 -0400 Reply-To: hadi@znyx.com Sender: Forwarding and Control Element Separation From: Jamal Hadi Salim Organization: ZNYX Networks Subject: Re: An approach to modeling ForCES events To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <6.2.1.2.0.20050415164145.02f068c0@localhost> Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 Content-Transfer-Encoding: 7bit If it is going to be too complex to change at runtime, then perhaps we should stick with the knowledge that the CE needs to know at registration time the details of verbosity needed. Another thought that popped into my head when i was reading Ellens email; in addition to events that happen more frequently requiring more less verbosity - theres the case of what the event type is: Edge Triggered vs Level Triggered. As an example, I may want a situation where FE generates an empty event with specific event ID (say ID X). From that moment on, the FE doesnt generate any new ID X events until the CE either acknowledges the event or reads/writes some attribute. In between CE being notified and the CE reactivating the event again on the FE, a substantial amount of work may need to be done and arrival of new events does not add any new information or takes unnecessary resources. Thoughts? cheers, jamal On Fri, 2005-15-04 at 16:43 -0400, Joel M. Halpern wrote: > For each event, the event definition includes the indication as to what > information is to be reported. > The question is whether, for a given event, in some situations that the CE > can determine when it registers, it will want the full information and in > some circumstances (that it can determine at registration time) it will > want only the indication of the event occurring. > if the CE at registration can meaningfully make that distinction, then > having different registration levels is useful. > > Yours, > Joel > > At 04:32 PM 4/15/2005, Deleganes, Ellen M wrote: > >I think it is valuable to have two levels of verbosity in reporting, > >where some mechanism exists to be able to select on a per event type > >basis. I think it depends on what the event is on whether you want more > >report information or not. For events that happen more frequently, maybe > >all you want are the notifications. In the case where you are generating > >events due to a counter exceeding (perhaps indicating some kind of bad > >behavior) then you probably do want more detailed information. > > > >Regards, > >Ellen > > > > > >-----Original Message----- > >From: Forwarding and Control Element Separation > >[mailto:FORCES@PEACH.EASE.LSOFT.COM] On Behalf Of Joel M. Halpern > >Sent: Friday, April 15, 2005 12:42 PM > >To: FORCES@PEACH.EASE.LSOFT.COM > >Subject: Re: An approach to modeling ForCES events > > > >I don't know if this is useful, but is easy to represent. Instead of a > >boolean registration variable, we use a uint8, where 0 means "do not > >notify", 1 means "just notify with no body", and 2 means "notify with > >body > >according to the declared report information from the LFB class > >definition." > > > >I assume that event notifications will be relatively rare. If so, is > >the > >savings in the report worth it? > > > >Yours, > >Joel M. Halpern > > > >At 02:52 PM 4/15/2005, Jamal Hadi Salim wrote: > > >3) Event report formatting. > > >The looks good. The main issue i had is the verbosity level > > >of reporting. I know you (Joel) have had issues with the levels of > > >reporting in other discussions regarding the protocol. I think it's an > > >important addition. > > >Example of verbosity would be something along the lines of: > > > > > >*level0) "just tell me when the event happens - dont want any details" > > >*level1) "tell what the value of foo.$1.bar when this event happens" From owner-forces@PEACH.EASE.LSOFT.COM Fri Apr 15 19:07:12 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA08237 for ; Fri, 15 Apr 2005 19:07:12 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DMa4O-0007sc-QB for forces-archive@IETF.ORG; Fri, 15 Apr 2005 19:17:53 -0400 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <9.01015AD7@cherry.ease.lsoft.com>; Fri, 15 Apr 2005 19:07:13 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 66758204 for FORCES@PEACH.EASE.LSOFT.COM; Fri, 15 Apr 2005 19:07:12 -0400 Received: from 208.184.15.238 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Fri, 15 Apr 2005 19:07:11 -0400 Received: from [69.170.19.163] (HELO JMHLap3.stevecrocker.com) by EXECDSL.COM (CommuniGate Pro SMTP 3.3) with ESMTP id 9949717 for FORCES@PEACH.EASE.LSOFT.COM; Fri, 15 Apr 2005 19:07:11 -0400 X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 References: <468F3FDA28AA87429AD807992E22D07E04F18EB4@orsmsx408> <6.2.1.2.0.20050415164145.02f068c0@localhost> <1113600464.17859.30.camel@localhost.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Approved-By: "Joel M. Halpern" Message-ID: <6.2.1.2.0.20050415190227.02d9fa38@localhost> Date: Fri, 15 Apr 2005 19:07:10 -0400 Reply-To: "Joel M. Halpern" Sender: Forwarding and Control Element Separation From: "Joel M. Halpern" Subject: Re: An approach to modeling ForCES events To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <1113600464.17859.30.camel@localhost.localdomain> Precedence: list X-Spam-Score: 0.1 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 My inclination is that all events should be edge triggered. There is no reason for the FE to retransmit an event notification, since the ForCES protocol is reliable. If we want to allow for notification of exiting the condition, that would be a separate event, with a different trigger condition on the same variable. It might use the same level, or hysteresis can be obtained by using a lower level in the reverse direction. Yours, Joel PS: Does anyone else in the working group care? At 05:27 PM 4/15/2005, you wrote: >Subject: Re: An approach to modeling ForCES events >To: FORCES@PEACH.EASE.LSOFT.COM > >If it is going to be too complex to change at runtime, then perhaps >we should stick with the knowledge that the CE needs to know at >registration time the details of verbosity needed. > >Another thought that popped into my head when i was reading Ellens >email; in addition to events that happen more frequently requiring more >less verbosity - theres the case of what the event type is: >Edge Triggered vs Level Triggered. >As an example, I may want a situation where FE generates an empty event >with specific event ID (say ID X). From that moment on, the FE doesnt >generate any new ID X events until the CE either acknowledges the event >or reads/writes some attribute. In between CE being notified and the CE >reactivating the event again on the FE, a substantial amount of work may >need to be done and arrival of new events does not add any new >information or takes unnecessary resources. > >Thoughts? > >cheers, >jamal From owner-forces@PEACH.EASE.LSOFT.COM Mon Apr 18 07:31:24 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA09182 for ; Mon, 18 Apr 2005 07:31:24 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DNUeA-0007At-IL for forces-archive@IETF.ORG; Mon, 18 Apr 2005 07:42:35 -0400 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <13.01019485@cherry.ease.lsoft.com>; Mon, 18 Apr 2005 7:23:43 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 67036178 for FORCES@PEACH.EASE.LSOFT.COM; Mon, 18 Apr 2005 07:23:42 -0400 Received: from 208.2.156.7 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Mon, 18 Apr 2005 07:23:42 -0400 Received: from localhost.localdomain ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2005041804242711:20588 ; Mon, 18 Apr 2005 04:24:27 -0700 References: <468F3FDA28AA87429AD807992E22D07E04F18EB4@orsmsx408> <6.2.1.2.0.20050415164145.02f068c0@localhost> <1113600464.17859.30.camel@localhost.localdomain> <6.2.1.2.0.20050415190227.02d9fa38@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.2.1.1 X-MIMETrack: Itemize by SMTP Server on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 04/18/2005 04:24:27 AM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 04/18/2005 04:24:29 AM, Serialize complete at 04/18/2005 04:24:29 AM Content-Transfer-Encoding: 7bit Content-Type: text/plain Approved-By: Jamal Hadi Salim Message-ID: <1113823417.7419.53.camel@localhost.localdomain> Date: Mon, 18 Apr 2005 07:23:37 -0400 Reply-To: hadi@znyx.com Sender: Forwarding and Control Element Separation From: Jamal Hadi Salim Organization: ZNYX Networks Subject: Re: An approach to modeling ForCES events To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <6.2.1.2.0.20050415190227.02d9fa38@localhost> Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Content-Transfer-Encoding: 7bit The edge/level triggering is not a reliability mechanism. Rather it is a classical event optimization scheme to reduce/defer work. Many papers have been written on the topic (including one coauthored by yours truly). Heres one example use: If the FE receives event triggers of some type at huge bursts, then it may be useful (depending on available resources) for the CE to just get one notification and no more per burst. Once the CE is done working on the causes of the even a ok-to-send-more-events signal is sent to the FE. Typically such a mechanism is part of the event mechanism if it is available. However, if the consensus is not to have this built in, fine with me. like you point out - i can find some way to do it in our implementation. cheers, jamal On Fri, 2005-15-04 at 19:07 -0400, Joel M. Halpern wrote: > My inclination is that all events should be edge triggered. There is no > reason for the FE to retransmit an event notification, since the ForCES > protocol is reliable. If we want to allow for notification of exiting the > condition, that would be a separate event, with a different trigger > condition on the same variable. It might use the same level, or hysteresis > can be obtained by using a lower level in the reverse direction. > > Yours, > Joel > > PS: Does anyone else in the working group care? > > At 05:27 PM 4/15/2005, you wrote: > >Subject: Re: An approach to modeling ForCES events > >To: FORCES@PEACH.EASE.LSOFT.COM > > > >If it is going to be too complex to change at runtime, then perhaps > >we should stick with the knowledge that the CE needs to know at > >registration time the details of verbosity needed. > > > >Another thought that popped into my head when i was reading Ellens > >email; in addition to events that happen more frequently requiring more > >less verbosity - theres the case of what the event type is: > >Edge Triggered vs Level Triggered. > >As an example, I may want a situation where FE generates an empty event > >with specific event ID (say ID X). From that moment on, the FE doesnt > >generate any new ID X events until the CE either acknowledges the event > >or reads/writes some attribute. In between CE being notified and the CE > >reactivating the event again on the FE, a substantial amount of work may > >need to be done and arrival of new events does not add any new > >information or takes unnecessary resources. > > > >Thoughts? > > > >cheers, > >jamal From owner-forces@PEACH.EASE.LSOFT.COM Tue Apr 19 00:40:26 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA12421 for ; Tue, 19 Apr 2005 00:40:26 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DNki7-0003GF-HC for forces-archive@IETF.ORG; Tue, 19 Apr 2005 00:51:48 -0400 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <10.0101ABF0@cherry.ease.lsoft.com>; Tue, 19 Apr 2005 0:40:23 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 67141614 for FORCES@PEACH.EASE.LSOFT.COM; Tue, 19 Apr 2005 00:40:22 -0400 Received: from 134.134.136.16 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Tue, 19 Apr 2005 00:40:21 -0400 Received: from orsfmr100.jf.intel.com (orsfmr100.jf.intel.com [10.7.209.16]) by orsfmr002.jf.intel.com (8.12.10/8.12.10/d: major-outer.mc,v 1.1 2004/09/17 17:50:56 root Exp $) with ESMTP id j3J4eLuI004163; Tue, 19 Apr 2005 04:40:21 GMT Received: from orsmsxvs040.jf.intel.com (orsmsxvs040.jf.intel.com [192.168.65.206]) by orsfmr100.jf.intel.com (8.12.10/8.12.10/d: major-inner.mc,v 1.2 2004/09/17 18:05:01 root Exp $) with SMTP id j3J4eK0R007774; Tue, 19 Apr 2005 04:40:20 GMT Received: from orsmsx332.amr.corp.intel.com ([192.168.65.60]) by orsmsxvs040.jf.intel.com (SAVSMTP 3.1.7.47) with SMTP id M2005041821402003219 ; Mon, 18 Apr 2005 21:40:20 -0700 Received: from orsmsx408.amr.corp.intel.com ([192.168.65.52]) by orsmsx332.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 18 Apr 2005 21:40:20 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Thread-Topic: An approach to modeling ForCES events Thread-Index: AcVECYH5WiZ3aIITSfmsQwhgpXCtVgAjVtTA X-OriginalArrivalTime: 19 Apr 2005 04:40:20.0645 (UTC) FILETIME=[E4A23D50:01C54499] X-Scanned-By: MIMEDefang 2.44 Approved-By: "Deleganes, Ellen M" Message-ID: <468F3FDA28AA87429AD807992E22D07E04F5F8CA@orsmsx408> Date: Mon, 18 Apr 2005 21:42:47 -0700 Reply-To: "Deleganes, Ellen M" Sender: Forwarding and Control Element Separation From: "Deleganes, Ellen M" Subject: Re: An approach to modeling ForCES events Comments: To: hadi@znyx.com To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: b5d20af10c334b36874c0264b10f59f1 Content-Transfer-Encoding: quoted-printable 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.) What happens if the FE runs out of space to buffer events? 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. 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. Regards, Ellen -----Original Message----- From: Forwarding and Control Element Separation [mailto:FORCES@PEACH.EASE.LSOFT.COM] On Behalf Of Jamal Hadi Salim Sent: Monday, April 18, 2005 4:24 AM To: FORCES@PEACH.EASE.LSOFT.COM Subject: Re: An approach to modeling ForCES events The edge/level triggering is not a reliability mechanism. Rather it is a classical event optimization scheme to reduce/defer work. Many papers have been written on the topic (including one coauthored by yours truly). Heres one example use:=20 If the FE receives event triggers of some type at huge bursts, then it may be useful (depending on available resources) for the CE to just get one notification and no more per burst. Once the CE is done working on the causes of the even a ok-to-send-more-events signal is sent to the FE.=20 Typically such a mechanism is part of the event mechanism if it is available. However, if the consensus is not to have this built in, fine with me. like you point out - i can find some way to do it in our implementation.=20 cheers, jamal On Fri, 2005-15-04 at 19:07 -0400, Joel M. Halpern wrote: > My inclination is that all events should be edge triggered. There is no=20 > reason for the FE to retransmit an event notification, since the ForCES=20 > protocol is reliable. If we want to allow for notification of exiting the=20 > condition, that would be a separate event, with a different trigger=20 > condition on the same variable. It might use the same level, or hysteresis=20 > can be obtained by using a lower level in the reverse direction. >=20 > Yours, > Joel >=20 > PS: Does anyone else in the working group care? >=20 > At 05:27 PM 4/15/2005, you wrote: > >Subject: Re: An approach to modeling ForCES events > >To: FORCES@PEACH.EASE.LSOFT.COM > > > >If it is going to be too complex to change at runtime, then perhaps > >we should stick with the knowledge that the CE needs to know at > >registration time the details of verbosity needed. > > > >Another thought that popped into my head when i was reading Ellens > >email; in addition to events that happen more frequently requiring more > >less verbosity - theres the case of what the event type is: > >Edge Triggered vs Level Triggered. > >As an example, I may want a situation where FE generates an empty event > >with specific event ID (say ID X). From that moment on, the FE doesnt > >generate any new ID X events until the CE either acknowledges the event > >or reads/writes some attribute. In between CE being notified and the CE > >reactivating the event again on the FE, a substantial amount of work may > >need to be done and arrival of new events does not add any new > >information or takes unnecessary resources. > > > >Thoughts? > > > >cheers, > >jamal From owner-forces@PEACH.EASE.LSOFT.COM Tue Apr 19 06:53:25 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA27662 for ; Tue, 19 Apr 2005 06:53:25 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DNqX8-0000bf-13 for forces-archive@IETF.ORG; Tue, 19 Apr 2005 07:04:51 -0400 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <3.0101AE41@cherry.ease.lsoft.com>; Tue, 19 Apr 2005 6:53:21 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 67184301 for FORCES@PEACH.EASE.LSOFT.COM; Tue, 19 Apr 2005 06:53:20 -0400 Received: from 208.2.156.7 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Tue, 19 Apr 2005 06:53:20 -0400 Received: from localhost.localdomain ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2005041903540444:21938 ; Tue, 19 Apr 2005 03:54:04 -0700 References: <468F3FDA28AA87429AD807992E22D07E04F5F8CA@orsmsx408> Mime-Version: 1.0 X-Mailer: Evolution 2.2.1.1 X-MIMETrack: Itemize by SMTP Server on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 04/19/2005 03:54:05 AM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 04/19/2005 03:54:07 AM, Serialize complete at 04/19/2005 03:54:07 AM Content-Transfer-Encoding: 7bit Content-Type: text/plain Approved-By: Jamal Hadi Salim Message-ID: <1113907996.7309.70.camel@localhost.localdomain> Date: Tue, 19 Apr 2005 06:53:16 -0400 Reply-To: hadi@znyx.com Sender: Forwarding and Control Element Separation From: Jamal Hadi Salim Organization: ZNYX Networks Subject: Re: An approach to modeling ForCES events To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <468F3FDA28AA87429AD807992E22D07E04F5F8CA@orsmsx408> Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: b5d20af10c334b36874c0264b10f59f1 Content-Transfer-Encoding: 7bit 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 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. From owner-forces@PEACH.EASE.LSOFT.COM Tue Apr 19 16:36:09 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA24629 for ; Tue, 19 Apr 2005 16:36:08 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DNzd8-0007KG-My for forces-archive@IETF.ORG; Tue, 19 Apr 2005 16:47:39 -0400 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <15.0101BF02@cherry.ease.lsoft.com>; Tue, 19 Apr 2005 16:36:00 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 67247041 for FORCES@PEACH.EASE.LSOFT.COM; Tue, 19 Apr 2005 16:35:59 -0400 Received: from 134.134.136.19 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Tue, 19 Apr 2005 16:35:57 -0400 Received: from orsfmr101.jf.intel.com (orsfmr101.jf.intel.com [10.7.209.17]) by orsfmr005.jf.intel.com (8.12.10/8.12.10/d: major-outer.mc,v 1.1 2004/09/17 17:50:56 root Exp $) with ESMTP id j3JKZuHb031812 for ; Tue, 19 Apr 2005 20:35:56 GMT Received: from orsmsxvs041.jf.intel.com (orsmsxvs041.jf.intel.com [192.168.65.54]) by orsfmr101.jf.intel.com (8.12.10/8.12.10/d: major-inner.mc,v 1.2 2004/09/17 18:05:01 root Exp $) with SMTP id j3JKZupD023795 for ; Tue, 19 Apr 2005 20:35:56 GMT Received: from orsmsx332.amr.corp.intel.com ([192.168.65.60]) by orsmsxvs041.jf.intel.com (SAVSMTP 3.1.7.47) with SMTP id M2005041913355615827 for ; Tue, 19 Apr 2005 13:35:56 -0700 Received: from orsmsx410.amr.corp.intel.com ([192.168.65.64]) by orsmsx332.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 19 Apr 2005 13:35:55 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C5451F.4BA42CCA" Thread-Topic: An approach to modeling ForCES events Thread-Index: AcVEzgRK2lmgm6AGR9a6K9BNrS9tvwAUHR2A X-OriginalArrivalTime: 19 Apr 2005 20:35:55.0996 (UTC) FILETIME=[632A81C0:01C5451F] X-Scanned-By: MIMEDefang 2.44 Approved-By: "Chawla, Shuchi" Message-ID: <85514027246E4643A1B0780EC0F6F458025B5EDA@orsmsx410> Date: Tue, 19 Apr 2005 13:35:15 -0700 Reply-To: "Chawla, Shuchi" Sender: Forwarding and Control Element Separation From: "Chawla, Shuchi" Subject: Re: An approach to modeling ForCES events To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list X-Spam-Score: 0.2 (/) X-Scan-Signature: 97901e96c4dacf0263335ebc3a004b57 This is a multi-part message in MIME format. ------_=_NextPart_001_01C5451F.4BA42CCA Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable 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.=20 - 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? Regards, Shuchi -----Original Message----- From: Forwarding and Control Element Separation [mailto:FORCES@PEACH.EASE.LSOFT.COM] On Behalf Of Jamal Hadi Salim Sent: Tuesday, April 19, 2005 3:53 AM To: FORCES@PEACH.EASE.LSOFT.COM Subject: Re: An approach to modeling ForCES events 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: =20 1) nothing needs to be buffered because the state is part of the attribute you are already maintaining at the FE. This applies to as the trigger. Events just dont get generated at the FE anymore in the period those events are turned off for the target.=20 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. =20 > What happens if the FE runs out of space to buffer events?=20 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. >=20 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.=20 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).=20 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).=20 =20 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. ------_=_NextPart_001_01C5451F.4BA42CCA Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable RE: An approach to modeling ForCES events

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?

Regards,

Shuchi

-----Original Message-----
From: Forwarding and Control Element Separation [mailto:FORCES@PEACH.EASE.LSOF= T.COM] On Behalf Of Jamal Hadi Salim
Sent: Tuesday, April 19, 2005 3:53 AM
To: FORCES@PEACH.EASE.LSOFT.COM
Subject: Re: An approach to modeling ForCES events

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.

------_=_NextPart_001_01C5451F.4BA42CCA-- From owner-forces@PEACH.EASE.LSOFT.COM Tue Apr 19 16:57:16 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA26399 for ; Tue, 19 Apr 2005 16:57:16 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DNzxT-0007vY-6b for forces-archive@IETF.ORG; Tue, 19 Apr 2005 17:08:47 -0400 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <6.0101BF74@cherry.ease.lsoft.com>; Tue, 19 Apr 2005 16:57:05 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 67249294 for FORCES@PEACH.EASE.LSOFT.COM; Tue, 19 Apr 2005 16:57:04 -0400 Received: from 208.184.15.238 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Tue, 19 Apr 2005 16:57:04 -0400 Received: from [64.254.114.114] (HELO JMHLap3.stevecrocker.com) by EXECDSL.COM (CommuniGate Pro SMTP 3.3) with ESMTP id 9991372 for FORCES@PEACH.EASE.LSOFT.COM; Tue, 19 Apr 2005 16:56:59 -0400 X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 References: <85514027246E4643A1B0780EC0F6F458025B5EDA@orsmsx410> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: quoted-printable Approved-By: "Joel M. Halpern" Message-ID: <6.2.1.2.0.20050419165450.02c5bca8@localhost> Date: Tue, 19 Apr 2005 16:56:51 -0400 Reply-To: "Joel M. Halpern" Sender: Forwarding and Control Element Separation From: "Joel M. Halpern" Subject: Re: An approach to modeling ForCES events To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <85514027246E4643A1B0780EC0F6F458025B5EDA@orsmsx410> Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: a0ecb232550b38fd41a3cf6a312fbabc Content-Transfer-Encoding: quoted-printable 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= =20 view, while paying attention to the useful input from ITU. 2) This particular problem is not about the reporting of events and alarms= =20 to external entities. it is not even about reporting SNMP traps or=20 notifications. Rather, it is about how the FE will give the CE enough=20 information that it can generate appropriate indications (variables, traps,= =20 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=92t been following the entire thread on event modeling in detail,= =20 >but here are some of my thoughts =96 some of them are on the general= aspects=20 >of event and alarm reporting. So, it is a slight digression from the=20 >conversation, but hopefully, still relevant. > >There are some ITU-T specs for data networks/communication systems that=20 >specify the alarm and event reporting functions/requirements. It=92s been= a=20 >long time since I=92ve looked at these specs. and I don=92t currently have= =20 >access to them, but I think it would be worth it to scan through them to=20 >see the type of functionality that such systems should support, and what=20 >might be considered overkill. The two that I saw on the ITU site are:=20 >ITU-T X.733 and ITU-T X.734 (I assume these were the ones I had looked at= =20 >in the past, but I don=92t remember for sure!). > >- There should be support for both events and alarms, since they=20 >have differences. If events are thresholded, and they exceed their=20 >threshold, it may lead to an alarm condition. Alarms may be generated and= =20 >cleared. Events do not have a concept of a =93clear=94. An attribute= change=20 >on some object may be classified as an event. A Loss of Signal on a=20 >physical interface would classify as an alarm. An alarm should be=20 >generated when the condition is detected (after the appropriate=20 >integration time), and then a =93clear=94 generated when the condition= clears. > >- From what I remember, these specs. classify alarms into different= =20 >classes (equipment, QoS etc.). Each alarm has a default severity (which=20 >is not modifiable) and perceived severity (which is modifiable). The=20 >support for perceived severity arises from the fact that what may be=20 >considered a =93major=94 condition on some network element in a certain=20 >network, may be considered =93minor=94 in some other network element based= on=20 >its function and topology in the network etc. Alarms define probable cause= =20 >and proposed repair information (among other information, which I don=92t= =20 >remember). > >- In certain cases, it is possible that a large number of=20 >events/alarms get generated since a condition on object X could lead to a= =20 >different condition on objects associated with X, and so on. If the FE is= =20 >not doing event correlation and root cause analysis, it might land up=20 >sending all of these events to the CE, and it can result in event=20 >flooding. As an example, if an FE is associated with a large number of=20 >channelized interfaces, each configured to provide a service, if the=20 >physical interface experiences a loss of signal, all channelized=20 >interfaces will also have an alarm, as will the services associated with=20 >the channelized interfaces. Depending on the alarm detection mechanisms=20 >and alarm integration times, it is possible that the root cause alarm is=20 >detected after the alarm conditions that result from it. > >- In my opinion, if we can avoid support for deferred events, we=20 >should. If there is an issue with the CE not being able to keep up with=20 >the events from the FE, maybe the severity of the condition (or some other= =20 >threshold) can be used as a filter to determine what to send to the CE. I= =20 >agree that packets that need processing by the CE do need to get sent by=20 >the FE to the CE. I wasn=92t viewing these as =93events=94 however. If we= have=20 >the concept of a =93data=94 versus a =93control=94 channel, these packets= would be=20 >considered for transmission over the data channel, whereas events/alarms=20 >would be reported over the control channel (I may have misunderstood what= =20 >was being stated). > >- Thresholds being used as triggers for events/alarms are definitely= =20 >a good thing to support in my opinion. In large systems, where the number= =20 >of objects being managed and monitored is significant, thresholds provide= =20 >a mechanism to support manageability of such system without overwhelming=20 >the CE and running out of space on the event/alarm logs that are=20 >maintained in persistent storage. > >- I think event subscription/registration should only be possible on= =20 >events explicitly defined by an LFB. It seems it would be rather complex= =20 >to express the =93situations=94 under which to use different verbosity= levels=20 >for the different event types. Are there specific use cases that require= =20 >this flexibility? Else, it would seem reasonable to limit this to=20 >registration time. I assume multiple entities on the CE can register for= =20 >the same event from an FE. What if one registers with a high verbosity=20 >level, and one with a low verbosity level? Would the FE now have to send= =20 >2 separate events with the different levels of verbosity, or is it the=20 >intent that the FE always send all the info., and an =93event subsystem=94= on=20 >the CE will do the filtering for the different registrations? If so, have= =20 >we gained that much with this support for different verbosity levels? Is= =20 >this case valid? > >Regards, > >Shuchi > >-----Original Message----- >From: Forwarding and Control Element Separation=20 >[mailto:FORCES@PEACH.EASE.LSOFT.COM]=20 >On Behalf Of Jamal Hadi Salim >Sent: Tuesday, April 19, 2005 3:53 AM >To: FORCES@PEACH.EASE.LSOFT.COM >Subject: Re: An approach to modeling ForCES events > >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 > > 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. From owner-forces@PEACH.EASE.LSOFT.COM Tue Apr 19 19:00:58 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA05391 for ; Tue, 19 Apr 2005 19:00:58 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DO1tN-0003Dm-U9 for forces-archive@IETF.ORG; Tue, 19 Apr 2005 19:12:30 -0400 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <11.0101C097@cherry.ease.lsoft.com>; Tue, 19 Apr 2005 19:00:59 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 67258800 for FORCES@PEACH.EASE.LSOFT.COM; Tue, 19 Apr 2005 19:00:58 -0400 Received: from 134.134.136.19 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Tue, 19 Apr 2005 19:00:54 -0400 Received: from orsfmr100.jf.intel.com (orsfmr100.jf.intel.com [10.7.209.16]) by orsfmr005.jf.intel.com (8.12.10/8.12.10/d: major-outer.mc,v 1.1 2004/09/17 17:50:56 root Exp $) with ESMTP id j3JN0mHb011092; Tue, 19 Apr 2005 23:00:48 GMT Received: from orsmsxvs040.jf.intel.com (orsmsxvs040.jf.intel.com [192.168.65.206]) by orsfmr100.jf.intel.com (8.12.10/8.12.10/d: major-inner.mc,v 1.2 2004/09/17 18:05:01 root Exp $) with SMTP id j3JMvW1N011065; Tue, 19 Apr 2005 23:00:45 GMT Received: from orsmsx331.amr.corp.intel.com ([192.168.65.56]) by orsmsxvs040.jf.intel.com (SAVSMTP 3.1.7.47) with SMTP id M2005041915591320681 ; Tue, 19 Apr 2005 15:59:16 -0700 Received: from orsmsx410.amr.corp.intel.com ([192.168.65.64]) by orsmsx331.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 19 Apr 2005 15:58:42 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Thread-Topic: An approach to modeling ForCES events Thread-Index: AcVFImBI7nyLEaiwRdm9uPFvdHYiMQABzNOg X-OriginalArrivalTime: 19 Apr 2005 22:58:42.0395 (UTC) FILETIME=[552342B0:01C54533] X-Scanned-By: MIMEDefang 2.44 Approved-By: "Chawla, Shuchi" Message-ID: <85514027246E4643A1B0780EC0F6F458025B61D2@orsmsx410> Date: Tue, 19 Apr 2005 15:58:22 -0700 Reply-To: "Chawla, Shuchi" Sender: Forwarding and Control Element Separation From: "Chawla, Shuchi" Subject: Re: An approach to modeling ForCES events Comments: To: "Joel M. Halpern" To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: 872695ea777a517bf5717e5acc69f8be Content-Transfer-Encoding: quoted-printable 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:FORCES@PEACH.EASE.LSOFT.COM] On Behalf Of Joel M. Halpern Sent: Tuesday, April 19, 2005 1:57 PM To: FORCES@PEACH.EASE.LSOFT.COM 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=20 view, while paying attention to the useful input from ITU. 2) This particular problem is not about the reporting of events and alarms=20 to external entities. it is not even about reporting SNMP traps or=20 notifications. Rather, it is about how the FE will give the CE enough=20 information that it can generate appropriate indications (variables, traps,=20 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=20 >of event and alarm reporting. So, it is a slight digression from the=20 >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=20 >long time since I've looked at these specs. and I don't currently have=20 >access to them, but I think it would be worth it to scan through them to=20 >see the type of functionality that such systems should support, and what=20 >might be considered overkill. The two that I saw on the ITU site are:=20 >ITU-T X.733 and ITU-T X.734 (I assume these were the ones I had looked at=20 >in the past, but I don't remember for sure!). > >- There should be support for both events and alarms, since they=20 >have differences. If events are thresholded, and they exceed their=20 >threshold, it may lead to an alarm condition. Alarms may be generated and=20 >cleared. Events do not have a concept of a "clear". An attribute change=20 >on some object may be classified as an event. A Loss of Signal on a=20 >physical interface would classify as an alarm. An alarm should be=20 >generated when the condition is detected (after the appropriate=20 >integration time), and then a "clear" generated when the condition clears. > >- From what I remember, these specs. classify alarms into different=20 >classes (equipment, QoS etc.). Each alarm has a default severity (which=20 >is not modifiable) and perceived severity (which is modifiable). The=20 >support for perceived severity arises from the fact that what may be=20 >considered a "major" condition on some network element in a certain=20 >network, may be considered "minor" in some other network element based on=20 >its function and topology in the network etc. Alarms define probable cause=20 >and proposed repair information (among other information, which I don't >remember). > >- In certain cases, it is possible that a large number of=20 >events/alarms get generated since a condition on object X could lead to a=20 >different condition on objects associated with X, and so on. If the FE is=20 >not doing event correlation and root cause analysis, it might land up=20 >sending all of these events to the CE, and it can result in event=20 >flooding. As an example, if an FE is associated with a large number of >channelized interfaces, each configured to provide a service, if the=20 >physical interface experiences a loss of signal, all channelized=20 >interfaces will also have an alarm, as will the services associated with=20 >the channelized interfaces. Depending on the alarm detection mechanisms=20 >and alarm integration times, it is possible that the root cause alarm is=20 >detected after the alarm conditions that result from it. > >- In my opinion, if we can avoid support for deferred events, we=20 >should. If there is an issue with the CE not being able to keep up with=20 >the events from the FE, maybe the severity of the condition (or some other=20 >threshold) can be used as a filter to determine what to send to the CE. I=20 >agree that packets that need processing by the CE do need to get sent by=20 >the FE to the CE. I wasn't viewing these as "events" however. If we have=20 >the concept of a "data" versus a "control" channel, these packets would be=20 >considered for transmission over the data channel, whereas events/alarms=20 >would be reported over the control channel (I may have misunderstood what=20 >was being stated). > >- Thresholds being used as triggers for events/alarms are definitely=20 >a good thing to support in my opinion. In large systems, where the number=20 >of objects being managed and monitored is significant, thresholds provide=20 >a mechanism to support manageability of such system without overwhelming=20 >the CE and running out of space on the event/alarm logs that are=20 >maintained in persistent storage. > >- I think event subscription/registration should only be possible on=20 >events explicitly defined by an LFB. It seems it would be rather complex=20 >to express the "situations" under which to use different verbosity levels=20 >for the different event types. Are there specific use cases that require=20 >this flexibility? Else, it would seem reasonable to limit this to=20 >registration time. I assume multiple entities on the CE can register for=20 >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=20 >2 separate events with the different levels of verbosity, or is it the=20 >intent that the FE always send all the info., and an "event subsystem" on=20 >the CE will do the filtering for the different registrations? If so, have=20 >we gained that much with this support for different verbosity levels? Is=20 >this case valid? > >Regards, > >Shuchi > >-----Original Message----- >From: Forwarding and Control Element Separation=20 >[mailto:FORCES@PEACH.EASE.LSOFT.COM ]=20 >On Behalf Of Jamal Hadi Salim >Sent: Tuesday, April 19, 2005 3:53 AM >To: FORCES@PEACH.EASE.LSOFT.COM >Subject: Re: An approach to modeling ForCES events > >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 > > 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. From owner-forces@PEACH.EASE.LSOFT.COM Wed Apr 20 08:36:58 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA03608 for ; Wed, 20 Apr 2005 08:36:58 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DOEd8-000150-VK for forces-archive@IETF.ORG; Wed, 20 Apr 2005 08:48:35 -0400 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <3.0101CD5F@cherry.ease.lsoft.com>; Wed, 20 Apr 2005 8:36:57 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 67339382 for FORCES@PEACH.EASE.LSOFT.COM; Wed, 20 Apr 2005 08:36:56 -0400 Received: from 208.2.156.7 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Wed, 20 Apr 2005 08:36:55 -0400 Received: from localhost.localdomain ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2005042005373953:23308 ; Wed, 20 Apr 2005 05:37:39 -0700 References: <85514027246E4643A1B0780EC0F6F458025B5EDA@orsmsx410> Mime-Version: 1.0 X-Mailer: Evolution 2.2.1.1 X-MIMETrack: Itemize by SMTP Server on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 04/20/2005 05:37:40 AM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 04/20/2005 05:37:41 AM, Serialize complete at 04/20/2005 05:37:41 AM Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Approved-By: Jamal Hadi Salim Message-ID: <1114000612.7567.91.camel@localhost.localdomain> Date: Wed, 20 Apr 2005 08:36:52 -0400 Reply-To: hadi@znyx.com Sender: Forwarding and Control Element Separation From: Jamal Hadi Salim Organization: ZNYX Networks Subject: Re: An approach to modeling ForCES events To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <85514027246E4643A1B0780EC0F6F458025B5EDA@orsmsx410> Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: 225414c974e0d6437992164e91287a51 Content-Transfer-Encoding: quoted-printable Shuchi, On Tue, 2005-19-04 at 13:35 -0700, Chawla, Shuchi wrote: [..] > - 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. >=20 The alarm management is an NE level/layer detail (derived from the happenings in the FE(s) and maybe in the CE no doubt). You seem to agree on this after looking at your last response;=20 [As an example - I would expect no changes whatsoever in the way system root cause analysis or fault management schemes would work just because of how we do events between CE-FE. To the Forces level CE, the link going down is just another event and to the alarm management relating one or more NE that may end up being a high priority fault that need to be repaired; forces will send any "repair" messages without needing to understand the high level details etc etc].=20 You do bring an interesting example though with the channelized intefaces in relation to the hierachies of possible events. If the CE is told that the physical interface went down; isnt that sufficient as a detail to mean all the logical interfaces also went down? i.e would this still mean that the FE sends events for all channelized interfaces as well? Refer to my views on earlier email on desire to have hierachical semantics to avoid ambiguities (but now based on your example also to avoid unnecessary events). Likewise if a table is flushed it should be sufficient to indicate that all entries have been deleted without sending events for every row. > - In my opinion, if we can avoid support for deferred events, we > should. =20 You may be refering to what i said: I used the word "defered" but didnt intend for it to mean defering events rather it is to defer processing of events. What i said is: If you register to receive events you typically do so=20 in order to process them - otherwise you dont register for them;=20 i.e, when you receive notification of an event at the CE, you create work to process it. In other words, such a notification is a work-scheduling signal (this would not be necessarily true if you just received an event you had no interest in). Typically, the work is scheduled to run immediately. If you allow edge vs level triggering of events then you could use that scheduling signal to _defer_ the work (and not the event). So the desired support is for the two kinds of triggers. In one scheme the event trigger stays disabled (after sending a event to the CE) until re-enabled explicitly by the CE and in the second case it is always enabled. This is very easy to add to the definition of the event; brute force: it becomes an XML-level-attribute at definition time although my preference would be it gets set at runtime and therefore is a boolean within the definition of the event. A registration to the event could be used to reenable it every time. Again like i said earlier - I know we will do this in our implementation (based on some of experiences in implementation thus far); it would be nice if Forces supported it, however if consensus is not to then we will keep it proprietary. I do hope consensus is derived from people understanding what i am proposing though. =20 > 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. All these are attempts to help offload the CE and reduce abuse of resources (bandwidth and CPU in this case). Same with event-trigger type being edge vs level. > I agree that packets that need processing by the CE do need to get > sent by the FE to the CE. I wasn=E2=80=99t viewing these as =E2=80=9Ceve= nts=E2=80=9D however. > If we have the concept of a =E2=80=9Cdata=E2=80=9D versus a =E2=80=9Ccont= rol=E2=80=9D 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). >=20 But these are not intentionaly redirected packets (such as OSPF for example). They are "units of work" for some event that needs to be processed at the CE. Example are ones to be exception handled in particular; i am not so sure these belong to the data channel.=20 The other " units of work" are packets built as a result of other packets arriving at the FE(sic);->. I gave the example of an IPSEC ACQuire being sent to the CE as a result of a missing security association in the FE. > - 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. >=20 I agree - an optimization to offload the CE. Nota Bene the same logic reasoning is used for the event-trigger-type ;-> > - I think event subscription/registration should only be > possible on events explicitly defined by an LFB. This is agreed on. > It seems it would be rather complex to express the =E2=80=9Csituations= =E2=80=9D > under which to use different verbosity levels for the different event > types. Are there specific use cases that require this flexibility?=20 Optimization is a good enough reason in my opinion. > Else, it would seem reasonable to limit this to registration time. Verbosity - I dont agree that should be at registration time; it is trivial to add to both the model and protocol that it is done at=20 run time.=20 > 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 =E2=80=9Cevent subsy= stem=E2=80=9D > on the CE will do the filtering for the different registrations? =20 Good point to bring up: Upto this point ive thought of the CE as only registering once per event.=20 On the systems i have used this scheme on, the highest verbosity level is sent in such a case and it would be up to the CE to discriminate. i.e any intelligence will have to be embedded at the CE. > If so, have we gained that much with this support for different > verbosity levels? Is this case valid? I think the case is valid - whether we have gained much will depend on the implementation. Clearly it is a win over the case where you send two events and they are all verbose for two different registrations (I assume this to be the case if you didnt have a level differentiator). Ok, that was long ;-> Blame it on coffee. I didnt proof read it so i may be repeating myself in a few places. Dont disappear now. =20 cheers, jamal From owner-forces@PEACH.EASE.LSOFT.COM Wed Apr 20 11:17:04 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18859 for ; Wed, 20 Apr 2005 11:17:04 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DOH87-00068j-4S for forces-archive@IETF.ORG; Wed, 20 Apr 2005 11:28:43 -0400 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <8.0101D6E2@cherry.ease.lsoft.com>; Wed, 20 Apr 2005 11:17:04 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 67361464 for FORCES@PEACH.EASE.LSOFT.COM; Wed, 20 Apr 2005 11:17:03 -0400 Received: from 62.241.163.6 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Wed, 20 Apr 2005 11:17:03 -0400 Received: from pc6 (1Cust68.tnt10.lnd4.gbr.da.uu.net [62.188.139.68]) by astro.systems.pipex.net (Postfix) with SMTP id 06DE3E0003AB; Wed, 20 Apr 2005 16:17:00 +0100 (BST) References: <85514027246E4643A1B0780EC0F6F458025B5EDA@orsmsx410> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Approved-By: Tom Petch Message-ID: <036201c545b3$1e4184c0$0601a8c0@pc6> Date: Wed, 20 Apr 2005 14:31:50 +0200 Reply-To: Tom Petch Sender: Forwarding and Control Element Separation From: Tom Petch Subject: Re: An approach to modeling ForCES events Comments: To: "Chawla, Shuchi" To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list X-Spam-Score: 0.1 (/) X-Scan-Signature: 14582b0692e7f70ce7111d04db3781c8 Content-Transfer-Encoding: 7bit As an aside, X.733, X.736 and M.3100 were used by the Disman WG in the creation of the Alarm MIB, RFC 3877, and the ITU events and alarms are listed there. As Joel points out, the internal alarms between FE and CE are likely to be different in kind but the Alarm MIB provides a useful checklist of what the ITU-T were thinking in 1992. If and when there is a list of alarms for this work, then I see a case for reusing the same technical terms for the same alarms. The name/number mappings are registered with IANA (as an SNMP Textual Convention). Tom Petch ----- Original Message ----- From: "Chawla, Shuchi" To: Sent: Tuesday, April 19, 2005 10:35 PM Subject: Re: An approach to modeling ForCES events 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? Regards, Shuchi From owner-forces@PEACH.EASE.LSOFT.COM Thu Apr 21 08:29:55 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA20864 for ; Thu, 21 Apr 2005 08:29:55 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DOb05-00050p-2F for forces-archive@IETF.ORG; Thu, 21 Apr 2005 08:41:45 -0400 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <12.0101EF5F@cherry.ease.lsoft.com>; Thu, 21 Apr 2005 8:29:53 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 67484031 for FORCES@PEACH.EASE.LSOFT.COM; Thu, 21 Apr 2005 08:29:52 -0400 Received: from 208.2.156.7 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Thu, 21 Apr 2005 08:29:52 -0400 Received: from localhost.localdomain ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2005042105303576:24640 ; Thu, 21 Apr 2005 05:30:35 -0700 References: <85514027246E4643A1B0780EC0F6F458025B5EDA@orsmsx410> <1114000612.7567.91.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.2.1.1 X-MIMETrack: Itemize by SMTP Server on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 04/21/2005 05:30:36 AM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 04/21/2005 05:30:37 AM, Serialize complete at 04/21/2005 05:30:37 AM Content-Transfer-Encoding: 7bit Content-Type: text/plain Approved-By: Jamal Hadi Salim Message-ID: <1114086588.16559.34.camel@localhost.localdomain> Date: Thu, 21 Apr 2005 08:29:48 -0400 Reply-To: hadi@znyx.com Sender: Forwarding and Control Element Separation From: Jamal Hadi Salim Organization: ZNYX Networks Subject: Re: An approach to modeling ForCES events To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <1114000612.7567.91.camel@localhost.localdomain> Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Content-Transfer-Encoding: 7bit On Wed, 2005-20-04 at 08:36 -0400, Jamal Hadi Salim wrote: > So the desired support is for the two kinds of triggers. > In one scheme the event trigger stays disabled (after sending a event to > the CE) until re-enabled explicitly by the CE and in the second case > it is always enabled. > This is very easy to add to the definition of the event; brute force: it > becomes an XML-level-attribute at definition time although my preference > would be it gets set at runtime and therefore is a boolean within the > definition of the event. A registration to the event could be used to > reenable it every time. After chewing on this some more: I think perhaps using terms like edge vs level triggering may mud what i am trying to say. So perhaps a more descriptive term is event-mode (because event-type is taken). This is analogous to what is used in timers. When you register for a timer you typically could select a one-shot or continuous mode timer. In one-shot mode, the timer runs once and you have to reenable it if you need it again. In continous mode, it runs periodically, forever unless you explicitly stop it. To apply this to event registration - when you register for events, you set a flag to select one-shot mode. Otherwise continous mode is assumed. Does this make more sense? cheers, jamal From owner-forces@PEACH.EASE.LSOFT.COM Thu Apr 21 09:43:00 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA00297 for ; Thu, 21 Apr 2005 09:43:00 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DOc8o-0007um-3a for forces-archive@IETF.ORG; Thu, 21 Apr 2005 09:54:50 -0400 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <0.0101F20F@cherry.ease.lsoft.com>; Thu, 21 Apr 2005 9:42:59 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 67489178 for FORCES@PEACH.EASE.LSOFT.COM; Thu, 21 Apr 2005 09:42:58 -0400 Received: from 208.184.15.238 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Thu, 21 Apr 2005 09:42:58 -0400 Received: from [64.254.114.114] (HELO JMHLap3.stevecrocker.com) by EXECDSL.COM (CommuniGate Pro SMTP 3.3) with ESMTP id 10010929 for FORCES@PEACH.EASE.LSOFT.COM; Thu, 21 Apr 2005 09:42:57 -0400 X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 References: <85514027246E4643A1B0780EC0F6F458025B5EDA@orsmsx410> <1114000612.7567.91.camel@localhost.localdomain> <1114086588.16559.34.camel@localhost.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Approved-By: "Joel M. Halpern" Message-ID: <6.2.1.2.0.20050421093811.02c839b0@localhost> Date: Thu, 21 Apr 2005 09:42:53 -0400 Reply-To: "Joel M. Halpern" Sender: Forwarding and Control Element Separation From: "Joel M. Halpern" Subject: Re: An approach to modeling ForCES events To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <1114086588.16559.34.camel@localhost.localdomain> Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa That (one shot vs continuous) makes somewhat more sense. I am having trouble building a mental model of when a CE would need one-shot notifications. Essentially, this would reflect some situation where the CE needed to know the first time something happened, but not later times? I can see how we would support this. I am just trying to figure out if it is a complication worth having. Can you give some examples of one-shot event registrations (for events that themselves happen more than once. The registration mode doesn't matter if the event only occurs once.) Yours, Joel At 08:29 AM 4/21/2005, Jamal Hadi Salim wrote: >On Wed, 2005-20-04 at 08:36 -0400, Jamal Hadi Salim wrote: > > > So the desired support is for the two kinds of triggers. > > In one scheme the event trigger stays disabled (after sending a event to > > the CE) until re-enabled explicitly by the CE and in the second case > > it is always enabled. > > This is very easy to add to the definition of the event; brute force: it > > becomes an XML-level-attribute at definition time although my preference > > would be it gets set at runtime and therefore is a boolean within the > > definition of the event. A registration to the event could be used to > > reenable it every time. > > >After chewing on this some more: >I think perhaps using terms like edge vs level triggering may mud what i >am trying to say. So perhaps a more descriptive term is event-mode >(because event-type is taken). >This is analogous to what is used in timers. When you register for >a timer you typically could select a one-shot or continuous mode timer. >In one-shot mode, the timer runs once and you have to reenable it if you >need it again. >In continous mode, it runs periodically, forever unless you explicitly >stop it. > >To apply this to event registration - when you register for events, you >set a flag to select one-shot mode. Otherwise continous mode is assumed. >Does this make more sense? > >cheers, >jamal From owner-forces@PEACH.EASE.LSOFT.COM Thu Apr 21 11:33:46 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09643 for ; Thu, 21 Apr 2005 11:33:46 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DOds2-0002SG-Cu for forces-archive@IETF.ORG; Thu, 21 Apr 2005 11:45:39 -0400 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <17.0101F345@cherry.ease.lsoft.com>; Thu, 21 Apr 2005 11:33:46 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 67501510 for FORCES@PEACH.EASE.LSOFT.COM; Thu, 21 Apr 2005 11:33:38 -0400 Received: from 134.134.136.18 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Thu, 21 Apr 2005 11:33:38 -0400 Received: from orsfmr101.jf.intel.com (orsfmr101.jf.intel.com [10.7.209.17]) by orsfmr004.jf.intel.com (8.12.10/8.12.10/d: major-outer.mc,v 1.1 2004/09/17 17:50:56 root Exp $) with ESMTP id j3LFXaWa010515 for ; Thu, 21 Apr 2005 15:33:36 GMT Received: from orsmsxvs041.jf.intel.com (orsmsxvs041.jf.intel.com [192.168.65.54]) by orsfmr101.jf.intel.com (8.12.10/8.12.10/d: major-inner.mc,v 1.2 2004/09/17 18:05:01 root Exp $) with SMTP id j3LFXYll020337 for ; Thu, 21 Apr 2005 15:33:36 GMT Received: from orsmsx331.amr.corp.intel.com ([192.168.65.56]) by orsmsxvs041.jf.intel.com (SAVSMTP 3.1.7.47) with SMTP id M2005042108333612561 for ; Thu, 21 Apr 2005 08:33:36 -0700 Received: from orsmsx410.amr.corp.intel.com ([192.168.65.64]) by orsmsx331.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 21 Apr 2005 08:33:36 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Thread-Topic: An approach to modeling ForCES events Thread-Index: AcVFpaaywJd5JwM5TTu7SaBc3ZsFiAA3joPQ X-OriginalArrivalTime: 21 Apr 2005 15:33:36.0542 (UTC) FILETIME=[7C08FBE0:01C54687] X-Scanned-By: MIMEDefang 2.44 Approved-By: "Chawla, Shuchi" Message-ID: <85514027246E4643A1B0780EC0F6F458025E2FB9@orsmsx410> Date: Thu, 21 Apr 2005 08:33:35 -0700 Reply-To: "Chawla, Shuchi" Sender: Forwarding and Control Element Separation From: "Chawla, Shuchi" Subject: Re: An approach to modeling ForCES events To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: d9238570526f12788af3d33c67f37625 Content-Transfer-Encoding: quoted-printable Jamal, Comments inline... Regards, Shuchi -----Original Message----- From: Forwarding and Control Element Separation [mailto:FORCES@PEACH.EASE.LSOFT.COM] On Behalf Of Jamal Hadi Salim Sent: Wednesday, April 20, 2005 5:37 AM To: FORCES@PEACH.EASE.LSOFT.COM Subject: Re: An approach to modeling ForCES events Shuchi, On Tue, 2005-19-04 at 13:35 -0700, Chawla, Shuchi wrote: [..] > - 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. >=20 The alarm management is an NE level/layer detail (derived from the happenings in the FE(s) and maybe in the CE no doubt). You seem to agree on this after looking at your last response;=20 [As an example - I would expect no changes whatsoever in the way system root cause analysis or fault management schemes would work just because of how we do events between CE-FE. To the Forces level CE, the link going down is just another event and to the alarm management relating one or more NE that may end up being a high priority fault that need to be repaired; forces will send any "repair" messages without needing to understand the high level details etc etc].=20 [Shuchi] I believe both cases are possible -- alarms directly generated (and cleared) by the FE with the CE acting more as a pass-through or the FE just generating events, and some entity on the CE doing the needful to convert these to alarms to be sent to some NMS. In a system I had worked on, the former model was followed. However, my assumption is that there are some events/alarms from the FE that are also going to be used by the CE on the basis of which it will take some specific action. I think there are going to be events/alarms that are of critical nature and those that are more informative. Minimally, it seems there should probably be some mechanism to prioritize the critical ones from the FE to the CE so that they don't get held up behind a burst of informative events. Maybe this is where message priorities get used, I suppose. This would be especially true of events related to faults or loss of signal type events etc. where there is a need to failover to a standby entity. You do bring an interesting example though with the channelized intefaces in relation to the hierachies of possible events. If the CE is told that the physical interface went down; isnt that sufficient as a detail to mean all the logical interfaces also went down? i.e would this still mean that the FE sends events for all channelized interfaces as well? Refer to my views on earlier email on desire to have hierachical semantics to avoid ambiguities (but now based on your example also to avoid unnecessary events). Likewise if a table is flushed it should be sufficient to indicate that all entries have been deleted without sending events for every row. [Shuchi] If the FE did detect that the physical interface went down prior to the channelized interfaces going down, then it is possible for the FE to correlate the problem on the channelized interfaces to that of the physical interface and hence only send the event for the physical interface. However, it is possible based on alarm integration times and how the detection is implemented, that one or more logical interfaces is detected to be down prior to the physical interface being detected. It's up to the implementation on the FE to then maybe check the physical interface status prior to sending up these logical interface events. There can be several levels in this hierarchy of interfaces, so there's no guarantee how this might be implemented within an FE.=20 > - In my opinion, if we can avoid support for deferred events, we > should. =20 You may be refering to what i said: I used the word "defered" but didnt intend for it to mean defering events rather it is to defer processing of events. What i said is: If you register to receive events you typically do so=20 in order to process them - otherwise you dont register for them;=20 i.e, when you receive notification of an event at the CE, you create work to process it. In other words, such a notification is a work-scheduling signal (this would not be necessarily true if you just received an event you had no interest in). Typically, the work is scheduled to run immediately. If you allow edge vs level triggering of events then you could use that scheduling signal to _defer_ the work (and not the event). [Shuchi] My mistake -- I had misunderstood the reference to "deferred". So the desired support is for the two kinds of triggers. In one scheme the event trigger stays disabled (after sending a event to the CE) until re-enabled explicitly by the CE and in the second case it is always enabled. This is very easy to add to the definition of the event; brute force: it becomes an XML-level-attribute at definition time although my preference would be it gets set at runtime and therefore is a boolean within the definition of the event. A registration to the event could be used to reenable it every time. [Shuchi] Isn't registration for an event a "one-time" thing? I'm unclear about a registration being used to reenable it every time... Again like i said earlier - I know we will do this in our implementation (based on some of experiences in implementation thus far); it would be nice if Forces supported it, however if consensus is not to then we will keep it proprietary. I do hope consensus is derived from people understanding what i am proposing though. =20 > 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. All these are attempts to help offload the CE and reduce abuse of resources (bandwidth and CPU in this case). Same with event-trigger type being edge vs level. > 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). >=20 But these are not intentionaly redirected packets (such as OSPF for example). They are "units of work" for some event that needs to be processed at the CE. Example are ones to be exception handled in particular; i am not so sure these belong to the data channel.=20 The other " units of work" are packets built as a result of other packets arriving at the FE(sic);->. I gave the example of an IPSEC ACQuire being sent to the CE as a result of a missing security association in the FE. [Shuchi] Would you consider these to be "events" or just other "control messages" (such as those from the CE to the FE)? > - 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. >=20 I agree - an optimization to offload the CE. Nota Bene the same logic reasoning is used for the event-trigger-type ;-> > - I think event subscription/registration should only be > possible on events explicitly defined by an LFB. This is agreed on. > 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?=20 Optimization is a good enough reason in my opinion. [Shuchi] Do you have any specific examples of this? I'm still no too sure how exactly this would be specified and used. > Else, it would seem reasonable to limit this to registration time. Verbosity - I dont agree that should be at registration time; it is trivial to add to both the model and protocol that it is done at=20 run time.=20 > 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? =20 Good point to bring up: Upto this point ive thought of the CE as only registering once per event.=20 On the systems i have used this scheme on, the highest verbosity level is sent in such a case and it would be up to the CE to discriminate. i.e any intelligence will have to be embedded at the CE. > If so, have we gained that much with this support for different > verbosity levels? Is this case valid? I think the case is valid - whether we have gained much will depend on the implementation. Clearly it is a win over the case where you send two events and they are all verbose for two different registrations (I assume this to be the case if you didnt have a level differentiator). Ok, that was long ;-> Blame it on coffee. I didnt proof read it so i may be repeating myself in a few places. Dont disappear now. =20 cheers, jamal From upib@unionplanters.com Tue Apr 26 03:01:20 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA07371; Tue, 26 Apr 2005 03:01:20 -0400 (EDT) Message-Id: <200504260701.DAA07371@ietf.org> Received: from [80.97.189.107] (helo=UnionPlanters.com) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1DQKGl-0003RA-OT; Tue, 26 Apr 2005 03:14:09 -0400 From: "Union Planters" Subject: UPInternet Banking - Personal Security Alert! Date: Sat, 23 Apr 2005 21:41:22 -0700 MIME-Version: 1.0 Content-Type: text/html; charset="Windows-1251" Content-Transfer-Encoding: 7bit X-Priority: 1 X-MSMail-Priority: High X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Spam-Score: 9.9 (+++++++++) X-Spam-Flag: YES X-Scan-Signature: d16ce744298aacf98517bc7c108bd198 Content-Transfer-Encoding: 7bit Dear Union Planters Customer
 
     

   Dear Union Planters Customer,

   In order to maintain the safety and integrity of our Union Planters
   community, we have issued the following warning.
   It came to our attention that your account may be suspected of fraud.
   We ask our users with exposed accounts to confirm their identity with
   Union Planters every once in a while, in order to upkeep the safety
   of our environment.
   If the submitted information will fail to match our records for three
   times, your account will be suspended until further notice.
   If you will fail to confirm your identity within the next 48 hours,
   your account will be suspended until further notice.

   Please follow the link below and confirm your account information:
   https://upib.unionplanters.com/upib/

   This instruction has been sent to all bank customers and is obligatory to fallow.

   Thank you,

   Customer Support Service

 
  Union Planters Bank Service Member FDIC
 
SBXQEHURNWSXESBLSOQMOLMHCDQURLNJISHNHU From owner-forces@PEACH.EASE.LSOFT.COM Thu Apr 28 08:46:20 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA10911 for ; Thu, 28 Apr 2005 08:46:19 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DR8cE-0000g6-8H for forces-archive@IETF.ORG; Thu, 28 Apr 2005 08:59:38 -0400 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <1.010295B7@cherry.ease.lsoft.com>; Thu, 28 Apr 2005 8:46:12 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 68452041 for FORCES@PEACH.EASE.LSOFT.COM; Thu, 28 Apr 2005 08:46:11 -0400 Received: from 208.2.156.7 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Thu, 28 Apr 2005 08:46:11 -0400 Received: from localhost.localdomain ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2005042805464971:32555 ; Thu, 28 Apr 2005 05:46:49 -0700 References: <85514027246E4643A1B0780EC0F6F458025B5EDA@orsmsx410> <1114000612.7567.91.camel@localhost.localdomain> <1114086588.16559.34.camel@localhost.localdomain> <6.2.1.2.0.20050421093811.02c839b0@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.2.1.1 X-MIMETrack: Itemize by SMTP Server on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 04/28/2005 05:46:50 AM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 04/28/2005 05:46:51 AM, Serialize complete at 04/28/2005 05:46:51 AM Content-Transfer-Encoding: 7bit Content-Type: text/plain Approved-By: Jamal Hadi Salim Message-ID: <1114692368.7663.150.camel@localhost.localdomain> Date: Thu, 28 Apr 2005 08:46:08 -0400 Reply-To: hadi@znyx.com Sender: Forwarding and Control Element Separation From: Jamal Hadi Salim Organization: ZNYX Networks Subject: Re: An approach to modeling ForCES events To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <6.2.1.2.0.20050421093811.02c839b0@localhost> Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Content-Transfer-Encoding: 7bit Apologies for taking this long to respond. Too tied up. On Thu, 2005-21-04 at 09:42 -0400, Joel M. Halpern wrote: > That (one shot vs continuous) makes somewhat more sense. > > I am having trouble building a mental model of when a CE would need > one-shot notifications. Essentially, this would reflect some situation > where the CE needed to know the first time something happened, but not > later times? > Well, two things: - A one shot timer (but thats not why i proposed this). I think timers do fit in the events semantics. - The real reason I was pushing for this is the classical case where it is used - optimization. In cases where you/CE are overloaded you may wanna switch to a one-shot event mode for certain events in order to reduce the load on the CE. The one-shot event tells the CE of work that needs to be done, but lets the CE decide when to do work. Some of these schemes go to extremes from say migrating from asynchronous event notification to pure polling and back when things get better. The application of these sorts of event-modes ranges from use in servers and associated events to device drivers where interupts are the events. In other words there is " no invention" here. > I can see how we would support this. I am just trying to figure out if it > is a complication worth having. Can you give some examples of one-shot > event registrations (for events that themselves happen more than once. The > registration mode doesn't matter if the event only occurs once.) Refer to above. I dont think it imposes any complications or introduces breakages. When you register for an event, you specify mode=continous/oneshot. cheers, jamal From owner-forces@PEACH.EASE.LSOFT.COM Thu Apr 28 09:25:44 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA13686 for ; Thu, 28 Apr 2005 09:25:44 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DR9EL-0002EO-QY for forces-archive@IETF.ORG; Thu, 28 Apr 2005 09:39:04 -0400 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <8.010294F3@cherry.ease.lsoft.com>; Thu, 28 Apr 2005 9:25:42 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 68454471 for FORCES@PEACH.EASE.LSOFT.COM; Thu, 28 Apr 2005 09:25:41 -0400 Received: from 208.2.156.7 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Thu, 28 Apr 2005 09:25:41 -0400 Received: from localhost.localdomain ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2005042806261955:32600 ; Thu, 28 Apr 2005 06:26:19 -0700 References: <85514027246E4643A1B0780EC0F6F458025E2FB9@orsmsx410> Mime-Version: 1.0 X-Mailer: Evolution 2.2.1.1 X-MIMETrack: Itemize by SMTP Server on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 04/28/2005 06:26:20 AM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 04/28/2005 06:26:21 AM, Serialize complete at 04/28/2005 06:26:21 AM Content-Transfer-Encoding: 7bit Content-Type: text/plain Approved-By: Jamal Hadi Salim Message-ID: <1114694738.7663.190.camel@localhost.localdomain> Date: Thu, 28 Apr 2005 09:25:37 -0400 Reply-To: hadi@znyx.com Sender: Forwarding and Control Element Separation From: Jamal Hadi Salim Organization: ZNYX Networks Subject: Re: An approach to modeling ForCES events To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <85514027246E4643A1B0780EC0F6F458025E2FB9@orsmsx410> Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: 944ecb6e61f753561f559a497458fb4f Content-Transfer-Encoding: 7bit Hello Shuchi, I asked you not to disappear, so to set an example i am back ;-> On Thu, 2005-21-04 at 08:33 -0700, Chawla, Shuchi wrote: > [Shuchi] I believe both cases are possible -- alarms directly generated > (and cleared) by the FE with the CE acting more as a pass-through or the > FE just generating events, and some entity on the CE doing the needful > to convert these to alarms to be sent to some NMS. In a system I had > worked on, the former model was followed. However, my assumption is > that there are some events/alarms from the FE that are also going to be > used by the CE on the basis of which it will take some specific action. Agreed, although the scope of their interpretations is different. > I think there are going to be events/alarms that are of critical nature > and those that are more informative. Minimally, it seems there should > probably be some mechanism to prioritize the critical ones from the FE > to the CE so that they don't get held up behind a burst of informative > events. Maybe this is where message priorities get used, I suppose. > This would be especially true of events related to faults or loss of > signal type events etc. where there is a need to failover to a standby > entity. > nod on prioritization. BTW, this is a good example of scope. The Forces scope for recovery and failover to a standby is restricted within an NE. As an example, at the forces NE level, a link failure or FE failure would mean a failover within the NE (to another link/FE depending on policy). An alarm system looking at the same issue would have a broader scope of failing over to a different NE altogether. > [Shuchi] If the FE did detect that the physical interface went down > prior to the channelized interfaces going down, then it is possible for > the FE to correlate the problem on the channelized interfaces to that of > the physical interface and hence only send the event for the physical > interface. However, it is possible based on alarm integration times and > how the detection is implemented, that one or more logical interfaces is > detected to be down prior to the physical interface being detected. > It's up to the implementation on the FE to then maybe check the physical > interface status prior to sending up these logical interface events. > There can be several levels in this hierarchy of interfaces, so there's > no guarantee how this might be implemented within an FE. > Agreed - maybe that was a bad example. I wanted to demonstrate that if you could have hierachical events, that it would make sense to send less event notifications by only sending the "top of hierachy event". As an example, assume the physical went down - then you only want to mention that to the CE and not the other 100 channels. The CE should be able to deduce. > [Shuchi] Isn't registration for an event a "one-time" thing? I'm > unclear about a registration being used to reenable it every time... > Theres nothing that says event registration/deregistration cant happen multiple times at runtime. Infact not allowing that maybe counterproductive. > > But these are not intentionaly redirected packets (such as OSPF for > example). > They are "units of work" for some event that needs to be processed at > the CE. Example are ones to be exception handled in particular; i am not > so sure these belong to the data channel. > The other " units of work" are packets built as a result of other > packets arriving at the FE(sic);->. I gave the example of an IPSEC > ACQuire being sent to the CE as a result of a missing security > association in the FE. > > [Shuchi] Would you consider these to be "events" or just other "control > messages" (such as those from the CE to the FE)? > Depends on the implementation i think - and I dont wanna be biased (and believe we should cover both to be usable). Lets take the example of the Acquire event in the case of IPSEC. Its essentially a table lookup failure of an arriving packet. Typically, such a lookup generates an Acquire event to the key manager. What gets sent to the key manager is not a packet but rather a description of some important things in the packet as well as some metadata. The result of the acquire is a table update on the FE. A different scheme maybe to send the packet in its entirety to the CE. The former would fit as an "event" and the later is closer to "control". > Optimization is a good enough reason in my opinion. > > [Shuchi] Do you have any specific examples of this? I'm still no too > sure how exactly this would be specified and used. > Refer to my email to Joel. I really dont need to have to list a specific LFB that would benefit from this - its a classical scheme when you talk events. I am not inventing anything new here. cheers, jamal From owner-forces@PEACH.EASE.LSOFT.COM Fri Apr 29 04:14:14 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA02963 for ; Fri, 29 Apr 2005 04:14:14 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DRQqe-0007Dt-49 for forces-archive@IETF.ORG; Fri, 29 Apr 2005 04:27:44 -0400 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <22.0102AC9A@cherry.ease.lsoft.com>; Fri, 29 Apr 2005 4:14:14 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 68557279 for FORCES@PEACH.EASE.LSOFT.COM; Fri, 29 Apr 2005 04:13:56 -0400 Received: from 194.173.20.12 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Fri, 29 Apr 2005 04:13:56 -0400 Received: from eundadmi01.pan.eu(10.100.96.64) by hhe500-02.hbg.de.pan.eu via smtp id 2833_8e5532d4_b890_11d9_9c9e_003048253456; Fri, 29 Apr 2005 11:24:58 +0200 (CEST) Received: from VPN-MRelay-01.PEL.Panasonic.de ([10.100.176.55]) by eundadmi01.pan.eu (Lotus Domino Release 6.5.2) with ESMTP id 2005042910135237-152840 ; Fri, 29 Apr 2005 10:13:52 +0200 Received: from localhost ([127.0.0.1]) by VPN-MRelay-01.PEL.Panasonic.de for forces@peach.ease.lsoft.com; Fri, 29 Apr 2005 10:15:04 +0200 MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Thread-Topic: Question on scope Thread-Index: AcVMk1FpJROaM5lVRhKI1LG1y/3cLA== Content-Transfer-Encoding: quoted-printable Content-class: urn:content-classes:message Content-Type: text/plain; charset="iso-8859-1" Approved-By: Jose Rey Message-ID: <9D277E44D6EF0942B928C6F0DE99BB31B97192@lan-ex-01.panasonic.de> Date: Fri, 29 Apr 2005 10:13:25 +0200 Reply-To: Jose Rey Sender: Forwarding and Control Element Separation From: Jose Rey Subject: Question on scope To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Content-Transfer-Encoding: quoted-printable Hi all, I am a newbie to the list. I apologize in advance if anything inappropriate = or repeated is asked. I went through the charter and over some of the drafts and I don't know yet = if I get it right. I understand that the aim is to separate control and tra= nsport, that much is clear. Additionally, some QoS functionality is impleme= nted in the forwarding entities. But, is it also planned to include more ad= vanced functionalities like transcoding, metering, intelligent packet droppi= ng (e.g., only P frames) in those FEs=3F=3F Related to that: the charter tal= ks about per-packet processing but does this processing stop at layer 4 =3F Thanks, Jos=E9 ............................................................................= .. Confidentiality Notice The information contained in this Email, and any attachments, is intended fo= r the named recipients only. It may contain confidential and/or legally priv= ileged information. If you are not the intended recipient, you must not copy= , store, distribute or take any action in reliance on it. Any views expresse= d do not necessarily reflect the views of the company. If you receive this Email by mistake, please advise the sender by using the = reply facility in your Email software and then delete it. ............................................................................= .