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

["STEPHAN Emile FTRD/DAC/LAN" <[e-mail]>]

Dear All,

The IPPM MIB is designed as the reporting interface for a set of points of measure colocated (an embedded SNMP agent) or distributed (an IPPM proxy).

The workflow of the reporting is simple:

    test packet arrival  
         |
         V
    network metrics computation ----> ippmHistoryTable
	owd,ploss,ipdv...
         |
         V
   Aggregated metrics computation --> ippmHistoryTable
 	min,max,avgt,%... of owd,ploss,ipdv...
         |
         V
     filtering ---------------------> ippmReportTable 
 

The aggregation permits to produce results over well known period of time (e.g.: every 5 minutes, per hour...). Reporting raw singletons have a big limitation: If you increase the test packets rate you increase the volume of information to report too. The aggregation permits to solve this scalability issue: The volume of information to report does not increase with the test packets rate.

3 main implementations are possible:

Implementation A:

The IPPM MIB stores only network measure results:

    test packet arrival  
         |
         V
    network metrics computation --> ippmHistoryTable 
	owd,ploss,ipdv...

Implementation B:
The IPPM MIB does not store network measure results but store a first level of aggregation compatible with both measurement needs and management plane bottlenecks:

    test packet arrival  
         |
         V
    network metrics computation
	owd,ploss,ipdv...
         |
         V
   Aggregated metrics computation --> ippmHistoryTable 
 	min,max,avgt,%... of owd,ploss,ipdv...

Implementation C:
The IPPM MIB computes different level of aggregation and filters the imformation to report:

    test packet arrival  
         |
         V
    network metrics computation
	owd,ploss,ipdv...
         |
         V
   Aggregated metrics computation --> ippmHistoryTable
 	min,max,avgt,%... of owd,ploss,ipdv...
         |
         V
     filtering ---------------------> ippmReportTable

To sum up, A) and B) are suitable for embedded agent, and B) and C) are compatible with proxy mode: An  IPPM Proxy is an separate application. Regarding the B) in proxy mode, the first level of aggregation is performed by the probe.

Hope that helps,

Regards
Emile

-----Message d'origine-----
De : Henk Uijterwaal (RIPE-NCC) [mailto:[e-mail]] 
Envoyé : mercredi 19 novembre 2003 14:01
À : Matthew J Zekauskas
Cc : [e-mail]
Objet : Re: [ippm] comments on draft-ietf-ippm-reporting-mib-04.txt


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

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