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

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Fri, 14 Nov 2003 21:21:46 +0200

Emile,

I think that the IPPM MIB document would benefit from a framework section explaining in more details the concepts that you and Matt are describing in your mails - what are the targets where the MIB is expected to run, how you define the relationship between the entities that you call proxy, Surveyor, NMS, etc. 

Regards,

Dan

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On 
> Behalf Of STEPHAN Emile FTRD/DAC/LAN
> Sent: 13 November, 2003 8:37 PM
> To: Andy Bierman; Matthew J Zekauskas; [email-masked]
> Subject: RE : [ippm] comments on draft-ietf-ippm-reporting-mib-04.txt
> 
> 
> 
> Dear Matt and Andy,
> 
> The input I received from Matt was to focus on the 
> implemtation of the MIB as an proxy rather than an agent 
> embedded in each probe.
> 
> When the IPPM MIB is implemeted as a proxy it is an 
> application on the top of the measurement system that makes a 
> first level of aggregation for NMS and that provides a SNMP 
> interface to the measurement system.
>  
> Collecting results take a lot of place either in Surveyor the 
> IPPM MIB, in the RMON MIB or in a IPFIX collector. The rule 
> of the IPPM MIB is to make an initial consolidation of the 
> result to avoid to flood NMS application with unrelevant information.
> 
> FTRD has implemented the proxy on the top of an industrial 
> measurement system. I can make a live demo of it during the 
> meeting or after.
> 
> Best Regards
> Emile
> 
> 
> -----Message d'origine-----
> De : Matthew J Zekauskas [mailto:[email-masked]] 
> Envoyé : jeudi 13 novembre 2003 17:23
> À : [email-masked]
> Cc : Matt Zekauskas
> Objet : Re: [ippm] comments on draft-ietf-ippm-reporting-mib-04.txt
> 
> 
> 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.
> 
> --Matt
> 
> --On Thursday, November 13, 2003 8:02 AM -0800 Andy Bierman 
> <[email-masked]> 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
> [email-masked] 
> https://www1.ietf.org/mailman/listinfo/ippm
> 
> _______________________________________________
> ippm mailing list
> [email-masked] 
> https://www1.ietf.org/mailman/listinfo/ippm
> 

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

---

From: "Henk Uijterwaal (RIPE-NCC)" <[email-masked]>
Date: Wed, 19 Nov 2003 13:31:06 +0100 (CET)

Dan,

> I think that the IPPM MIB document would benefit from a framework
> section explaining in more details the concepts that you and Matt are
> describing in your mails - what are the targets where the MIB is
> expected to run, how you define the relationship between the entities
> that you call proxy, Surveyor, NMS, etc.

Wait a second: Surveyor is only one of the implementations of the
One-way-delay and one-way-loss metrics, there are more implementations.

Henk

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

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

---

From: "Henk Uijterwaal (RIPE-NCC)" <[email-masked]>
Date: Wed, 19 Nov 2003 13:31:06 +0100 (CET)

Dan,

Henk