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

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: ippm-admin@ietf.org [mailto:ippm-admin@ietf.org]On 
> Behalf Of STEPHAN Emile FTRD/DAC/LAN
> Sent: 13 November, 2003 8:37 PM
> To: Andy Bierman; Matthew J Zekauskas; ippm@ietf.org
> 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:matt@internet2.edu] 
> Envoyé : jeudi 13 novembre 2003 17:23
> À : ippm@ietf.org
> 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 
> <abierman@cisco.com> 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
> ippm@ietf.org 
> https://www1.ietf.org/mailman/listinfo/ippm
> 
> _______________________________________________
> ippm mailing list
> ippm@ietf.org 
> https://www1.ietf.org/mailman/listinfo/ippm
> 

_______________________________________________
ippm mailing list
ippm@ietf.org 
https://www1.ietf.org/mailman/listinfo/ippm