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

OK. I just wanted to be sure I understood whether this was possible or
not.

dbh 

> -----Original Message-----
> From: [email protected] 
> [mailto:[email protected]] On Behalf Of Golovinsky, Eugene
> Sent: Tuesday, January 18, 2005 10:48 AM
> To: '[email protected]'; [email protected]
> Subject: RE: [RMONMIB] 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
> 
> _______________________________________________
> RMONMIB mailing list
> [email protected]
> https://www1.ietf.org/mailman/listinfo/rmonmib
>