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

[Andy Bierman <[e-mail]>]

At 07:45 AM 12/4/2003, STEPHAN Emile FTRD/DAC/LAN wrote:
>Dear All,

I think Implementation A and B make sense for this MIB.
Filtering and notification can be done with a different MIB,
such as the ALARM-MIB under development in the DISMAN WG.
High level (EMS) features such as email or SMS notification can
be left for future work or not standardized.

It seems to me that the WG wants this MIB to be drastically
simplified before it will be considered further.  To me, that
means remove all objects that are not needed for Implementation 
A and B described below.

Andy


>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