Subject: [i2rs] Questions to draft-swhyte-i2rs-data-collection-system-00

From: Linda Dunbar <[email-masked]>
Date: Thu, 10 Apr 2014 15:39:25 +0000

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.

Both Syslog and IPFIX were intended to export data from devices. What are the limitation of those schemes?

Thanks, Linda Dunbar

---

From: t.petch <[email-masked]>
Date: Fri, 11 Apr 2014 10:04:00 +0100

----- Original Message -----
From: "Linda Dunbar" <[email-masked]>
To: "Scott Whyte" <[email-masked]>; <[email-masked]>;
<[email-masked]>
Cc: <[email-masked]>
Sent: Thursday, April 10, 2014 4:39 PM

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.

Both Syslog and IPFIX were intended to export data from devices. What
are the limitation of those schemes?

<tp>
When anyone says 'use cases', I find myself going back to our charter,
which calls for us to work on tightly scoped key use cases, listing six.
I look at those six to see where this fits.  Um, I struggle to see the
fit with the charter.

Tom Petch

Thanks, Linda Dunbar

------------------------------------------------------------------------
--------

> _______________________________________________
> i2rs mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/i2rs
>

---

From: Scott Whyte <[email-masked]>
Date: Sat, 12 Apr 2014 11:38:48 -0700

On Thu, Apr 10, 2014 at 8:39 AM, Linda Dunbar <[email-masked]> wrote:
> 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.

> 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

---

From: Scott Whyte <[email-masked]>
Date: Sat, 12 Apr 2014 12:08:35 -0700

> I look at those six to see where this fits.  Um, I struggle to see the

Tom,
I wouldn't argue that the draft as is, is all over the place.
However, let me pose a use-case and ask the WG for guidance:

Tight coupling of interface state and control plane is broadly
supported in the industry, and greatly improves BGP convergence times
by allowing near-instantaneous reaction to a port going down instead
of having to wait for hold-down to expire.

Using I2RS and its various services I can implement BGP as an
application.  Doing so breaks this tight coupling by necessity, as the
interface affected in the data plane and the BGP application
implementing the routing system are no longer co-located.

Given the impact to control plane convergence and the wide-spread
reliance on such signalling today, it seems well placed within the
tightly scoped key use cases.  On the other hand, given that it is an
optimization based on the colocation of data and control planes in a
routing element and not purely part of the routing system, is doesn't
seem to fit in the I2RS protocol proper.

Where does this type of signalling best fit? In I2RS but not the I2RS
protcol, or a different WG (please suggest where), or in the I2RS
protocol, or something entirely different?

-Scott