ietf
[Top] [All Lists]

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

2010-03-24 15:29:18
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