RE: Begin WG Last Call: draft-ietf-rmonmib-raqmon-pdu- 09

Hi.

The idea is that RDS communicates with collector. Collectors are in turn
responsible for aggregating info and making it available to NMS. It is
possible that RDS can be configured to send notifications directly to NMS,
but that is not by design. One can not prevent people from doing all sorts
of things; it does not mean that these are right things to do. The same
concern, by the way, can be extended to TCP transport. Nothing prevents RDS
from communicating to something else than collector, but that would not be
RAQMON.

Cheers.
--Gene

 

 


-----Original Message-----
From: David B Harrington [mailto:[email protected]] 
Sent: Tuesday, January 18, 2005 9:18 AM
To: [email protected]
Subject: RE: [RMONMIB] Begin WG Last Call: draft-ietf-rmonmib-raqmon-pdu-09

Hi,

One of the concerns raised on the MIB Doctor's list was the issue of
scalability if multi-varbind traps are sent to an SNMP engine in
realtime from a large number of devices. My personal experience is
that this may not be scalable. I have had personal experience with a
deployment that tried to use realtime reporting of events using SNMP,
and caused a leading SNMP NMS application capable of managing tens of
thousands of devices to crash (i.e not being able to continue
operating effectively).

The main argument justifying the RAQMON approach is that these
notifications will always be sent to a collector, for whom
expectations are that collecting and aggregating these notifications
will be their primary job, and the aggregated data will be made
accessible to NMS applications. The use of multiple such collectors
would provide scalability.

Do you envision then that softphones or collaboration agents will
always use a collector? What prevents an operator from configuring a
softphone to send the notifications directly to an
SNMP-notification-receiver-aggregator (e.g. an NMS) already deployed
in the network rather than a specialized RAQMON collector? Would this
be a fairly reasonable thing to do if my network only has a small
number of softphones and already has a notification receiver
application?

David Harrington
[email protected]
MIB Doctor

> -----Original Message-----
> From: [email protected] 
> [mailto:[email protected]] On Behalf Of Siddiqui, 
> Anwar A (Anwar)
> Sent: Tuesday, January 18, 2005 9:13 AM
> To: Andy Bierman; [email protected]
> Subject: RE: [RMONMIB] Begin WG Last Call: 
> draft-ietf-rmonmib-raqmon-pdu-09
> 
> SNMP transport is an OPTIONAL FEATURE to transport RAQMON PDU. The
> motivation of that came from the fact that IT Managers tend to
manage
> Desk Top Applications environments today with SNMP and RAQMON 
> needed to
> fit into that existing environment unlike embedded devices like IP
> Phones or PDAs.
> 
> So it seemed for applications such as Softphones or Collaboration
> clients running Audio, Video, Data sharing on a PC a RDS MIB
probably
> would be very useful.
> 
> Anwar
> 
> 
> -----Original Message-----
> From: [email protected] [mailto:[email protected]] On
> Behalf Of Andy Bierman
> Sent: Saturday, January 15, 2005 1:05 PM
> To: [email protected]
> Subject: Re: [RMONMIB] Begin WG Last Call:
> draft-ietf-rmonmib-raqmon-pdu-09
> 
> At 06:14 PM 1/8/2005, Andy Bierman wrote:
> >Hi,
> 
> I want to get confirmation from at least 3 potential RAQMON 
> implementors that they plan to support the SNMP Notification 
> transport in their RDS implementation.
> 
> There are significant valid concerns that have been raised
> regarding the use of SNMP, SNMP notification sender only (w/o 
> a command responder), and UDP, for RDS to RRC communication.
> 
> It seems that the SNMP transport mapping is inferior to the 
> TCP transport mapping in every possible way:
>   - code size
>   - encoding size
>   - complexity
>   - congestion control
>   - proper use of the (transport) protocol
> 
> If nobody plans to develop an SNMP-based RDS, then we don't
> need to standardize it.  If you want to keep the SNMP Notification
> transport, then speak up during this WG Last Call.  
> 
> I have yet to hear of any plans to support this feature.  In fact,
> I have only heard objections to it.  So I am declaring the WG 
> consensus to be that the SNMP notification transport should be 
> removed from RAQMON.  
> 
> Related (but perhaps soon-to-be irrelevant) issues:
> 
> 1) I am wondering why the raqmonPeerAddrType and raqmonPeerAddr 
>    need to be in the INDEX.  This is very inefficient.
>    Why doesn't the SNMP PDU follow the TCP PDU fields?  
>    It's not clear in the document which MIB objects correspond to 
>    which BASIC PDU parameter numbers.  Not every parameter is
>    source or dest related. How is the address in the INDEX clause
>    apply to session-related parameters?
> 
> 2) Why is raqmonAppName the required parameter in every
notification?
>    This is inefficient.  Why not take raqmonRCN out of the INDEX and
> make
>    that the mandatory parameter?
> 
> >The RMONMIB WG has completed work on the Real-time Application 
> >Quality of Service Monitoring (RAQMON) Protocol Data Unit (PDU).
> >
> >The WG proposes that the I-D 'draft-ietf-rmonmib-raqmon-pdu-09.txt'

> >is the completed version of this document.  This document addresses
> >issues raised on the mailing list and also at the IETF #61 meeting.
> >
> >The WG members are strongly urged to review this document as 
> >soon as possible, and express any concerns, or identify any errors,
> >in an email to the RMONMIB WG mailing list.
> >
> >Unless there are strong objections, published on the RMONMIB 
> WG mailing
> >list by January 23, 2005, this document will be forwarded to the
OPS 
> >Area Directors for standards track consideration by the IESG.
> >
> >Please send all comments to the WG mailing list at
[email protected].
> >
> >Andy
> 
> Andy
> 
> _______________________________________________
> RMONMIB mailing list
> [email protected]
> https://www1.ietf.org/mailman/listinfo/rmonmib
> 
> 
> _______________________________________________
> RMONMIB mailing list
> [email protected]
> https://www1.ietf.org/mailman/listinfo/rmonmib
> 



_______________________________________________
RMONMIB mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/rmonmib