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

["David T. Perkins" <dperkins@dsperkins.com>]

HI,

Andy's hitting the target in his message.

That is, SNMP is not designed as a signalling protocol.

However, it can be used in a reporting or signalling environment
as long as it is OK if a notification (even when using informs)
is not delivered due to suppression(throttling at any place
in the path), "network packet loss", or lack of resources
on the receiver. Also, it is not the most efficient approach,
compaired to customized protocols.

On Fri, 14 Jan 2005, Andy Bierman wrote:

> At 02:09 PM 1/14/2005, David B Harrington wrote:
> > 
> >
> >> -----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 don't think so.  I also don't agree that RAQMON is somehow
> a signalling protocol.  It is a reporting mechanism, not
> signalling.  If a network device has management information
> to report, and is willing to live with the "best effort"
> nature of SNMP notifications, then why should the standard
> preclude this usage?  Allowing for manager polling
> means the agent has to store all this data to be retrieved
> arbitrarily by managers.  This is in direct conflict
> with the goals of RAQMON -- lots of simple devices that
> report into a collector.  The collector has the resources
> to be a complete SNMP agent.  Polling a collector is scalable.
> Polling 10,000 end-devices is not.
> 
> Personally, I wouldn't mind dropping the SNMP notification
> transport of RAQMON and just keep the TCP encoding.  The SNMP
> approach is quite unattractive in comparison, and so far,
> every vendor interested in RAQMON has expressed a total
> lack of interest in putting SNMP notification sender support
> in their products.
> 
> Andy
Regards,
/david t. perkins