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

At 12:25 AM 1/16/2005, Romascanu, Dan \(Dan\) wrote:
>Andy,
>
>See in line. 
>
>Regards,
>
>Dan
>
>
>
>> -----Original Message-----
>> From: [email protected] 
>> [mailto:[email protected]]On Behalf Of Andy Bierman
>> Sent: 15 January, 2005 8: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.
>
>Are not we setting the threshold too high? Why require confirmation from three potential implementers? Even in order to advance a standard from Proposed to Draft only two interoperable implementations are required. 

okay -- then I'd like to hear from 2 potential implementors.
(note that 2 potential != 2 actual).


>I also doubt that the people following this list can make firm commitments about implementation plans. Even speaking for myself I have good reasons to believe that my employer intents to implement all the options in the RAQMON standard, but I am not authorized to make firm product plans commitments.

I'm not asking for firm commitments.
I have only heard about problems with the SNMP transport,
and how nobody will implement it because they don't need 
SNMP for anything else, and they already have a TCP/IP stack.
It adds significant mandatory complexity to the collector.

I want to avoid a scenario where people dismiss RAQMON (in favor
of proprietary or other approaches) because it has so much extra 
baggage they don't need and don't want to implement.  Do you
really think vendors are going to implement SNMP-transport in
their collector if none of their own (or foreseeable) products
plan to use it? What RDSs are they even going to test against?

> 
>> 
>> 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.
>> 
>
>We do not propose to implement an SNMP notification sender only. We are talking about a full SNMP implementation ('agent'), we just propose that the reporting objects are only 'accessible-for-notify' in order to allow keeping the state in the RDSs beyond the emission of the notifications. 

This is a notification sender.  It is not a full agent.
See the thread on event driven polling as well. 




>> 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.  
>
>Are we bending because of a CLR over CLR discussion? Even this discussion seems to converge towards relaxing the text in the MIB Review Guidelines by replacing the famous 'i.e.' by a 'e.g.' - this being where this whole thread started. 

No.  See Juergen's objections to this transport.  
I have heard several times from at least one RAQMON author
that nobody will implement the SNMP-transport in the RDS and we
were only doing it to make the "SNMP people" feel happy.
Look at the list above.  Are you dismissing these technical arguments?  
Do you believe the SNMP transport is viable and will be used instead 
of the TCP transport?  If so, why?


>The SNMP notifications mapping was the result of the discussions at IETF56, including the bar-BOF in San Francisco (hard to forget, we were watching the start of the Iraq war on the TV). The intent was to avoid RDSs that already have SNMP on them to use SNMP, instead of supporting the new RAQMON protocol. That's how we got eventually to the current proposal, where a RDS MUST support either the TCP or SNMP transport, while the collectors MUST support both.

I know the history.  The SNMP transport was an optimization
to get around the development of a new protocol, under the assumption
that it will be easier and faster to get to RFC publication this way.
Well, now we have a bloated, inefficient, sub-optimal standard
because of it.  We didn't save any time either, so let's just
decide on the technical merits.  


>Defining the objects as a table rather than group of scalars was chosen because the indices of the table define the reporting session, and possible extensions to RAQMON can be defined easily as extensions of the table. 
>
>> 
>> 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.  
>
>I am respectfully declaring myself out of this consensus proposal, but as editor will gracefully obey to the decision of the WG. I want to wrap-up this work, it took too long time already. 
>
>> 
>> 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?
>
>I am not sure that I understand your question. The address in the index reflects the Receiver Address (RA) field in the PDU. Every MIB object corresponds to a RAQMON PDU field, the MIB being the mapping of the PDU. Can you be more specific on what you see as not being correctly and clearly mapped? 

The TCP PDU parameters and SNMP Notification parameters are not the
same and it is not explained well how they exactly correlate.


>> 
>> 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?
>
>Yes, we can do this and it would be more efficient indeed. The potential problem is that when somebody will define an extension in the future, the indexation may not be unique in the case of multiple sub-sessions running in parallel. By keeping the current indexation it is clear by examining a notification to what session / sub-session the reporting information relates.  
>
>> 
>> >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

Andy