On Thu, Apr 10, 2014 at 8:39 AM, Linda Dunbar <[email protected]> wrote: > Scott, et al, > > > > Your draft listed comprehensive requirement on what data you need to pull > out of a router. > > > > The Section 3 (Use Cases) , I was hoping to see some use cases on how those > collected data are used. But Section 3 only listed bunch of data that you > need. So Section 3 is really the “Requirement” (instead of use cases). > > > > Do you have any examples showing how those data are used? Concrete examples > can greatly help router vendors to prioritize the information to be pulled > when there is resource contention. Even though the primary objective is > “Collecting large data sets with high frequency with minimal impact to > device’s CPU”, very often “large set & high frequency” do need CPU cycles.
Hi Linda, Thanks for the comments. The draft as such needs to be re-organized along the lines you suggest, which I hope to start this quarter. > > > > Both Syslog and IPFIX were intended to export data from devices. What are > the limitation of those schemes? I think many of the limitations of the original syslog RFC3164 are addressed in RFC5424, but I'm also not aware of strong support for 5424 in the industry. If that is not the case I'd be happy to learn otherwise. IPFIX was mentioned in the draft as an example of how the operations of existing data export models that work very well with their specific datasets could be improved by adding a framework that supports pub/sub subscriptions in front of them. Particularly if a vendor already supports a specific format like IPFIX. Again I'm sure this concept could benefit from a re-write, which we will look into. Thanks, Scott > > > > Thanks, Linda Dunbar > > _______________________________________________ i2rs mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2rs
