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
