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

David,

>From a logical architecture point of view the answer is NO according to the RAQMON framework. 

RDSs send RAQMON PDUs (currently defined to run over TCP transport or as SNMP notifications) to RRCs. There are many RDSs and a few RRCs. RRCs perform data aggregation, history, etc. and present the information in the RAQMON MIB module to NMSs.

It can happen that a certain host runs co-resident RRC and NMS. This can be even a recommended configuration in your small configuration case. Still the information goes logically from RDSs to the RRC in that host. 

Is this what you were asking? 

Regards,

Dan



> -----Original Message-----
> From: [email protected] 
> [mailto:[email protected]]On Behalf Of David B Harrington
> Sent: 18 January, 2005 6:14 PM
> To: Siddiqui, Anwar A (Anwar); [email protected]
> Subject: RE: [RMONMIB] Begin WG Last Call: 
> draft-ietf-rmonmib-raqmon-pdu-09
> 
> 
> So the answer to my question is Yes, it is possible to send the data
> directly to an NMS.
> 
> If the operator wanted the functionality typically provided by a
> collector, the NMS would also need to provide the functionality of a
> RAQMON collector.
> 
> OK. I just wanted to be sure I understood whether the RAQMON SNMP
> notification could be sent directly to an NMS or not, or whether
> something actually prevented that from being done.
> 
> Question answered. Thank you,
> 
> dbh 
> 
> > -----Original Message-----
> > From: [email protected] 
> > [mailto:[email protected]] On Behalf Of Siddiqui, 
> > Anwar A (Anwar)
> > Sent: Tuesday, January 18, 2005 10:45 AM
> > To: [email protected]; [email protected]
> > Subject: RE: [RMONMIB] Begin WG Last Call: 
> > draft-ietf-rmonmib-raqmon-pdu-09
> > 
> > 
> > There will always be RRC (what you call collector) for RDSs in the
> > architecture. Logical entities like RRCs will have TCP interface and
> > SNMP interface to gather info from RDSs and performs following
> > functions:
> > 
> > a. Collectors provide scaling like you describe and provides an
> > engineering solution to avoid fan in problems
> > b. Collectors aggregate information over a session and can 
> > portray that
> > as historical data
> > c. Collectors performs averaging, min/max type functions 
> > d. various kinds of NMS applications (e.g. IT Troubleshooting 
> > help Desk
> > Ticket system vs. Enterprise SLA Application vs. Average Monthly
> > Performance ) can use the same data in RRC provided by the RDS to
> > perform different kinds of tasks.
> > 
> > In summary, if RDSs started to PDUs (i.e. RAW data) to the NMS
> > applications directly, some of these functions will disappear.
> > 
> > Anwar
> > 
> > -----Original Message-----
> > From: [email protected] [mailto:[email protected]] On
> > Behalf Of David B Harrington
> > Sent: Tuesday, January 18, 2005 10: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
> > 
> 
> 
> 
> _______________________________________________
> RMONMIB mailing list
> [email protected]
> https://www1.ietf.org/mailman/listinfo/rmonmib
>