Re: [ippm] comments on draft-ietf-ippm-reporting-mib-04.txt

["Henk Uijterwaal (RIPE-NCC)" <[e-mail]>]

On Thu, 13 Nov 2003, Matthew J Zekauskas wrote:

> As chair, I'd like to say that Andy's comment below is what
> I've heard informally, but no one has to-date posted to the
> list.  I'd like to ask others to read the draft, and comment
> on the complexity (or any other area) --  do you agree, or
> do you think that the current draft is on the right track.
>
> With my chair hat off, I concur with Andy's assessment below.
> What I always intended to implement with Surveyor was a simple
> scheme to export the basic data types; if there was any complex
> manipulation, it would be done by the software playing the role
> as a network management system.

Also with my chair hat off.

The way I currently see this (and the way that we've implemented this) is
something like:

                       +------+
             /-------- | User |----------------\
          Control      +------+             Control
             |                                 |
             V                                 V
         +--------+                      +----------+
         | Sender |                      | Receiver |
         +--------+                      +----------+
          |  |                             ^    |
          |  |                             |    |
          |  \--------Measurement ---------/    |
          |                                     |
          V                                     V
        +--------------------------------------------+
        |     Results                                |
        +--------------------------------------------+
              |
              V
        +------------+
        | Processing |
        +------------+
              |
              V
             User


The user requests up a measurement session by sending a control message to
both sender and receiver.  Sender and receiver set up the measurement
using a home-grown mechanism now, perhaps OWAMP-control in the future.
The measurement is done, currently with our own protocol, perhaps
OWAMP-test in the future.  Both sender and receiver record data regarding
the measurement in a file.  After the measurement is over, these files are
pulled to a central point at regular intervals. Here data is processed:
combine what sender and receiver know about a measurement, aggregate,
filter, plot and print on web pages or so, depending on what the user
wants.

The last steps are often done more than once, people tend to aggregate
over short intervals as well as long intervals, make 2 or more plots of
the same data etc.

When talking to users, the biggest issue is that the data is not available
until the file has been written.

A buffer with the data from the last X minutes would solve that.  An
application can then query the buffer and do whatever it wants to do with
the data.  This is where I see a standard format (MIB) and protocol
(SNMP) come in.

What people are not interested in, is a standard way to aggregate and
filter data.  Requirements vary a lot here: time interval, loops over the
data, format (numbers vs a plot), etc, and the one size-fits all approach
doesn't seem right.


Henk










>
> --Matt
>
> --On Thursday, November 13, 2003 8:02 AM -0800 Andy Bierman <[e-mail]> wrote:
>
> > Although a good job has been done documenting this MIB,
> > IMO it is too complex to be deployable.  The resource
> > requirements in the agent are very large.  Some of the
> > tables can get extremely large, which would lead to
> > poor SNMP performance.  The resource limitation mechanisms
> > do not align well with actual SNMP agent implementation
> > constraints.
> >
> > This MIB is way too complicated and contains too many
> > features that should be provided by an EMS or NMS.  There
> > are likely to be many implementation difficulties due to
> > undocumented (and unforeseen) interactions between features.
> > The MIB should be simplified to collect metric values
> > and provide aggregation reports which can be retrieved
> > via SNMP.  Analysis of the reports, threshold based
> > exception handling, sending email and pages to administrators,
> > etc. should be left to the application.
>
>
>
> _______________________________________________
> ippm mailing list
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/ippm
>

------------------------------------------------------------------------------
Henk Uijterwaal                             Email: [e-mail]
RIPE Network Coordination Centre            WWW: http://www.ripe.net/home/henk
P.O.Box 10096          Singel 258           Phone: [phone]
1001 EB Amsterdam      1016 AB Amsterdam    Fax: [phone]
The Netherlands        The Netherlands      Mobile: [phone]
------------------------------------------------------------------------------

That problem that we weren't having yesterday, is it better? (Big ISP NOC)

_______________________________________________
ippm mailing list
[e-mail] 
https://www1.ietf.org/mailman/listinfo/ippm