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
