ietf
[Top] [All Lists]

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

2010-03-24 16:05:05
Dan,

OK, I'll do that!

Regards, Benoit.
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