ietf
[Top] [All Lists]

RE: Gen-ART LC/Telechat review of draft-ietf-ipfix-export-per-sctp-stream-06

2010-03-24 15:37:43
Benoit,
 
Do you plan to issue a revised ID that will allow Russ to clear his
DISCUSS?
 
Thanks and Regards,
 
Dan
 


________________________________

        From: Ben Campbell [mailto:ben(_at_)estacado(_dot_)net] 
        Sent: Wednesday, March 24, 2010 10:27 PM
        To: Benoit Claise
        Cc: paitken(_at_)cisco(_dot_)com; andrjohn(_at_)cisco(_dot_)com; 
muenz(_at_)net(_dot_)in(_dot_)tum(_dot_)de;
General Area Review Team; Romascanu, Dan (Dan); quittek(_at_)neclab(_dot_)eu;
IETF-Discussion list; Russ Housley
        Subject: Re: Gen-ART LC/Telechat review of
draft-ietf-ipfix-export-per-sctp-stream-06
        
        
        Benoit and I just had an offline discussion that helped me
understand things a little better. That discussion, and this email
resolve my issues, (pending the actual revised draft.)

        Specific comments inline:

        Thanks!

        Ben.

        On Mar 18, 2010, at 3:31 AM, Benoit Claise wrote:


                Dear Ben,
                
                Thanks for your detailed review.
                Sorry about the delay, we've been a little bit busy with
IETF deadlines recently ;-) 

                        I have been selected as the General Area Review
Team (Gen-ART)
                        reviewer for this draft (for background on
Gen-ART, please see
        
http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html).
                        
                        Please wait for direction from your document
shepherd
                        or AD before posting a new version of the draft.
                        
                        Document:
draft-ietf-ipfix-export-per-sctp-stream-06
                        Reviewer: Ben Campbell
                        Review Date: 1 March 2010
                        IESG Telechat date: 4 March 2010
                        
                        Summary: This document is almost ready for
publication as a proposed standard, but there is an open issue that
should be considered first.
                        
                        
                        Major issues:
                        
                        -- section 4.5, general:
                        
                        I am confused as to  how the collector
determines the exporter supports this extension. If I understand
correctly (and it's probable that I do not, since this is my first real
exposure to IPFix), the collector basically has to infer exporter
support from the behavior of the exporter. But then the second paragraph
after the numbered list (i.e. 2 paragraphs after item 4) says:
                        
                         "In the case where the Exporting Process does
not support the 
                                per-SCTP-stream extension, then the
first Data Record received 
                                by the Collecting Process will disable
the extension for the 
                                specific Exporter on the Collecting
side."
                        
                        This seems to conflict. Why would the collector
need to worry about items 1-4 if it can categorically determine exporter
support from the first data record?
                        
                        In general, though, I think that having the
collector infer support is not the right way to do this. It would be far
better to explicitly signal support, if that is at all possible in
IPFix. Otherwise, it seems like the collector has to watch every record
for violations of 1-4, and make fairly complex decisions on a per-record
basis.
                          

                We clarified the text in section 4.5 as follows
                Note that 
                    - the paragraphs 1, 2, 3, 7, 8, 9, 10, and 11 are
unchanged, but copied for completeness
                    - we mainly rearranged the order so that it provides
a more logical reading.
                
                

                Collecting Processes must operate slightly contrary to
[RFC5101] in order to realize the full benefits of per-stream export.
However, the specification in this section contains a mechanism which
allows per-stream-capable Collecting Processes to selectively enable
per-stream export, in order to ensure interoperability of
per-stream-capable Collecting Processes with Exporting Processes which
do not implement per-stream export.

                

                As specified in [RFC5101], the Collecting Process SHOULD
listen for a new association request from the Exporting Process.  The
Exporting Process will request a number of SCTP streams to use for
export.

                

                A Collecting Process SHOULD support the procedure for
the addition of an SCTP stream [SCTP-RESET].

                

                In IPFIX, there is no explicit notification of the
Exporting Process's capabilities.  There is also no return channel for
the Collecting Process to communicate its capabilities. 
                
                The dataRecordsReliability Options Template is expected,
but cannot be guaranteed, to only originate from a per-SCTP-stream
compliant Exporting Process.  In the case where the Exporting Process
uses the per-SCTP-stream extension, the first Data Record received by
the Collecting Process is associated with the Data Records Reliability
Options Template.   If the first Data Record is associated with any
other (Options) Template, the Collecting Process MUST disable the
extension for the specific Exporter on the Collecting side.

                
                

                The Collecting Process MUST check that the Exporter is
compliant with the specifications in this document.  For example,
nothing prevents an implementation that does not meet the specification
of the per-SCTP-stream extension from sending a Template that looks like
a dataRecordsReliability Options Template.  Therefore, a Collecting
Process MUST detect if the Exporter fails to meet the specification
fully.  If any of the conditions below is met, the Exporting Process
does not properly use the per-SCTP-stream extension.  In this case, the
Collecting Process MUST disable the per-SCTP-stream extension for the
given Exporter and report an error message:

                

                1. A Data Record is received before the appropriate Data
Record associated with the Data Records Reliability Options Template has
been received on the same SCTP stream (see section 4.1). 
                
                2. A Data Record associated with a Data Record
Reliability 
                Options Template is received on an SCTP stream for a
(non-Options) Template that was defined on a different SCTP stream.

                

                3. Loss of Data Records is detected within a stream
where there has not been received a Data Record associated with the Data
Record Reliability Options Template indicating unreliable transmission
for any template.

                
                4. A message is received with the SCTP U(nordered) flag
set to 1, (i.e., the message was sent unordered) even if it is processed
in order.

                

                Note that it is not an error to receive a Data Record
reliably if that Data Record is associated with a Template whose Data
Records are expected to be sent unreliably.
                


                Continuing below the paragraphs are unchanged
                

                
                   The Collecting Process MUST accept other non-scope
Information Elements in the Data Record Reliability Options Template.
                

                
                


        This helps quite a bit, and I think it addresses my concern.
It's now clearer to me that the Options Template triggers the assumption
that the extension is being used, and the other heuristics are tests
that allow you to fall back if the extension is not being used
"properly". While a binary signal of some sort would be nice, I yield to
the work groups expertise in the area.


                   ...
                

                        Minor issues:
                        
                        -- section 4.2, 3rd paragraph from end, starting
with "When an Options Template..."
                        
                        I'm confused by this paragraph. Would exporters
using this extension ever send the options template and associated data
records in different streams?
                          

                Actually, there is nothing in RFC5101 that mandates that
(Options) Template and associated Data Records must be sent in the same
SCTP stream. 


        Okay.


                        Nits/editorial comments:
                        
                        -- section 4.1, description of
dataRecordsReliability:
                        
                        I find the first sentence hard to parse.
                          

                OLD:
                
                        dataRecordsReliability
                     
                           Description:
                                The reliability of the export of Data
Records, within
                                this SCTP stream, for the element(s) in
the Options
                                Template scope, usually a templateID. A
value of 'true'
                                means that the Exporting Process MUST
send any Data
                                Records associated with the element(s)
reliably within
                                this SCTP stream.  A value of 'false'
means that the
                                Exporting Process MAY send any Data
Records associated
                                with the element(s) unreliably within
this SCTP stream.
                NEW
                

                dataRecordsReliability

                

                   Description:

                The export reliability of Data Records, within this SCTP
stream, for the element(s) in the Options Template scope.  A typical
example of element for which the export reliability must be reported is
the templateID, as a specified in the Data Record Reliability  Options
Template.  A value of 'true' means that the Exporting Process MUST send
any Data Records associated with the element(s) reliably within this
SCTP stream.  A value of 'false' means that the Exporting Process MAY
send any Data Records associated with the element(s) unreliably within
this SCTP stream.


        That helps, thanks.


                


                        -- section 4.2, first paragraph" "...exporting
processes should follow..."
                        
                        (Note that an identical comment applies to the
first paragraph of several of the specification sections.)
                        
                        It would be best to avoid the word "should" in
this context. Even though we all know a lower case should is not
normative, it's still enough to confuse a reader into interpreting as a
normative SHOULD, which is actually weaker than the real requirement.
That is, I don't think you mean to say that, in order to take advantage
of this extension and implementation SHOULD follow this specification. 
                          


                Actually, this should be a "MUST"
                OLD
                
                To take advantage of per-stream export, Exporting
Processes should follow the specification in this section in addition to
Section 8, Template Management, of [RFC5101].
                
                NEW
                
                To take advantage of per-stream export, Exporting
Processes MUST follow the specification in this section in addition to
Section 8, Template Management, of [RFC5101].
                
                We have corrected the other first paragraph of several
of the specification sections 


        Okay, I think that solves it.



                        -- section 4.3, paragraph 3:
                        
                        pedantic nit - I think you mean all IPFIX
messages in a single stream MUST be sent in order--not that all messages
have to be in a single stream, right? The current wording is (slightly)
ambiguous on that point.
                          

                Not pedantic, you're actually right.
                
                OLD:
                All IPFIX Messages MUST be sent in order within an SCTP
stream.
                
                NEW:
                
                All IPFIX Messages in an SCTP stream MUST be sent in
order.
                


        Okay.


                        -- section 4.3, last paragraph:
                        
                        Why mention the alternative if it is not
feasible in production?
                          

                OLD:
                
                        An alternative, which is not practical in
                        operational networks, is to restart the SCTP
association with an
                        increased number of SCTP streams.
                NEW
                
                An alternative, which may result in the loss of Flow
Records (for example, due to lack of buffering on the Exporter), is to
restart the SCTP association with an increased number of SCTP streams
                


        Okay.


                        --Examples, figure 3:
                        
                        Is Data 257 a typo?
                          

                Good catch.
                
                

                        -- idnits has some warnings. Please check before
publication.
                          

                The warnings are about: License, copyright year, and
outdated references.
                I'll correct these. Not sure whether I should publish a
new draft version. Anyway, I have all those changes above in my private
copy of the draft.
                
                


        You should coordinate that with the draft shepherd (and AD
advisor).



                Please let us know if this clarifies the situation.
                
                Regards, Benoit.
                


_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf