RE: [Fwd: Re: [RMONMIB] I-D ACTION:draft-ietf-rmonmib-raqmon-pdu- 08.txt]

["Romascanu, Dan \(Dan\)" <dromasca@avaya.com>]

> -----Original Message-----
> From: owner-mreview@ops.ietf.org 
> [mailto:owner-mreview@ops.ietf.org]On Behalf Of David B Harrington
> Sent: 15 January, 2005 12:09 AM
> To: 'Andy Bierman'; 'Randy Presuhn'
> Cc: 'Mreview (E-mail)'
> Subject: RE: [Fwd: Re: [RMONMIB] I-D 
> ACTION:draft-ietf-rmonmib-raqmon-pdu- 08.txt]
> 
> 
>  
> 
> > -----Original Message-----
> > <soapbox>
> > Why does it seem like every couple years the RMON WG pushes
> > the SNMP envelope, and keeps running into "CLR roadblocks"?
> > The standards are supposed to serve users, not the other
> > way around.  It seems to me that any effort spent
> > devising detailed rules around SMI usage (to prevent users
> > from "hurting themselves") is totally pointless, especially
> > in the absence of any real evidence of a problem to solve.
> > Here's a litmus test: What operational problems are being
> > solved by preventing somebody from defining a table of
> > accessible-for-notify objects?  Can't think of any?  Then 
> > lose the CLR!
> > </soapbox>
> 
> Overall, I really hate discussion about CLRs atop CLRs atop CLRs. I
> feel like we're navel gazing rather than doing something productive to
> make SNMP a more useable protocol for operators.
> 
> However...
> 
> I have a concern over whether tables full of accessible-for-notify
> objects obscures the fundamental trap-directed-polling philosophy of
> SNMP.
> I think doing this is bad practice.
> 
> I do not like what the RAQMON MIB does; it should send a simple single
> notification to the manager saying it has some information for the
> manager, and then let the manager poll for the rest of the data. Dan's
> argument is that the devices are very limited and sending the
> notification is simple; Marshall's Simple Book seems to disagree that
> an event-driven approach is simple. The reason SNMP is used for RAQMON
> is because it is already on the device. Well, if it's on the device
> already, it probably supports polling already, so using the polling
> approach should not be detrimental. If the goal is real-time reporting
> of events, I don't feel comfortable that using SNMP this way is a wise
> choice.
> 

Let us read the RAQMON framework carefully. RAQMON is using SNMP as one of the options of transporting reports to collectors, and not to management applications. A few collectors are exposing the RAQMON MIB to applications, reflecting sessions from many low-resourced data source devices each. A certain amount of lost monitoring PDUs is acceptable. The main issue here is scalability - polling hundreds or thousands of devices like IP phones does not scale and keeping the state of the monitoring information in the end devices imposes an unnecessary burden on these devices. This is not event-driven management, just a usage of SNMP in a simple manner that does not seem to break anything in the existing SNMP framework. I agree with Andy here, I am afraid that we would be over careful by not allowing applications willing to live with the "best effort" nature of SNMP notifications to use an existing and well understood standard. 

Regards,

Dan

>