Hi, Maybe it won't be that hard to automatically setup filters for common use-cases. E.g., if the 'inject' operation had parameters like 'notify-when-ready' and 'notify-if-bounced', then the server can send those notifications (just to that client) if the "inject" fails or gets deleted later, for the specific data entry.
Andy On Thu, Aug 15, 2013 at 7:39 AM, Alia Atlas <[email protected]> wrote: > Hi Andy, > > I meant that the traceability and syslog aspects are a 2nd order problem. > > I agree very strongly that notifications are a primary concern. That's how > clients learn > about network changes, changes affecting their state, etc. I believe that > we need a > sophisticated mechanism to filter and send just the relevant events to the > specific client. > Sending all notifications to all clients would be bad in terms of scaling > and security. > > I don't have a fixed number for the notifications per second. I'm curious > if others have thought > about it? > > Alia > > > > On Thu, Aug 15, 2013 at 10:31 AM, Andy Bierman <[email protected]> wrote: >> >> Hi, >> >> We are going to run into several long-unsolved NM problems >> like "standardized log files". (Knowing that adding such a huge >> task to the charter would be a mistake is the difference between >> boiling an ocean or just a lake. ;-) >> >> Notifications may not be a 2nd order problem because the >> WG punted on the "I2RS broker" role. Now it is up to >> each I2RS Client to know that the RIB state it injected >> got replaced by a higher priority client, or know a higher >> priority entry was deleted and now maybe it can try again. >> >> IMO, the notification mechanism will need to be quite >> sophisticated to filter just the events relevant to a specific client. >> More likely all clients will each get all notifications, creating >> N fire-hoses of 'add' and 'delete' events. >> >> At the BoF, the metric "5000 updates a second" was mentioned >> as the answer to the question "what is fast-path?" How many >> notifications per second are reasonable for I2RS? >> >> >> Andy >> >> On Thu, Aug 15, 2013 at 7:10 AM, Alia Atlas <[email protected]> wrote: >> > Juergen, >> > >> > Thanks for the useful information. I agree that a focus on traceability >> > is >> > not an initial primary goal, but Joe's point that syslog isn't >> > vendor-agnostic is a good one too. I'm not sure that I see a network >> > application doing automated troubleshooting and recovery - >> > but perhaps I'm insufficiently optimistic. >> > >> > Alia >> > >> > >> > On Thu, Aug 15, 2013 at 3:06 AM, Juergen Schoenwaelder >> > <[email protected]> wrote: >> >> >> >> On Wed, Aug 14, 2013 at 05:46:30PM -0400, Joe Marcus Clarke wrote: >> >> > On 8/14/13 5:35 PM, Alia Atlas wrote: >> >> > > I can see having it in a file for displaying or sending - but >> >> > > actually >> >> > > having the I2RS agent crawl through it to report the data back??? >> >> > >> >> > A file/buffer is fine, but will lead to vendor-specific ways of >> >> > getting >> >> > at the data. As I read the architecture concerning information >> >> > collection, I thought this might be very useful information for a >> >> > Client >> >> > to collect from the Agent. >> >> > >> >> > I know Joel disagrees in favor of syslog. I think syslog is okay, >> >> > but >> >> > only if you're receiving messages since the beginning of time (i.e., >> >> > before a problem is identified). While I very well may be off base >> >> > here, having the a record of what Clients did what on a particular >> >> > Agent >> >> > in a vendor-agnostic way as information to be collected via I2RS >> >> > seemed >> >> > reasonable. >> >> >> >> Just for your information: RFC 5277 defines a NETCONF extension for >> >> notification delivery which supports the playback of event streams. >> >> This essentially allows implementations to buffer notifications (which >> >> might be syslog messages) for a certain time (or a certain volume) and >> >> one can request a replay of the notifications from a given start time >> >> until a certain stop time, optionally applying a filter to it. >> >> >> >> For debugging purposes, such a mechanism (buffering and selected and >> >> filtered playback) seems a reasonable solution that is also relatively >> >> easy to implement. If, however, complete accountability tracking is >> >> the goal, then you need to stream all notifications to an external >> >> server and you probably also need something like SYSLOG signatures >> >> (RFC 5848) to be able to prove that the notification log is complete >> >> etc. >> >> >> >> Personally, I think i2rs is likely better off with postponing work on >> >> event notification logging until the primary goals of i2rs have been >> >> met. For early implementors, protocols like SYSLOG likely are good >> >> enough. >> >> >> >> /js >> >> >> >> -- >> >> Juergen Schoenwaelder Jacobs University Bremen gGmbH >> >> Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany >> >> Fax: +49 421 200 3103 <http://www.jacobs-university.de/> >> > >> > >> > >> > _______________________________________________ >> > i2rs mailing list >> > [email protected] >> > https://www.ietf.org/mailman/listinfo/i2rs >> > > > _______________________________________________ i2rs mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2rs
