[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [IPFIX] Fwd: I-D ACTION:draft-ietf-ipfix-export-per-sctp-stream-04.txt
Hi Benoit, all,
I've also got a few comments on the draft ipfix-export-per-sctp-
stream-04:
2.3. Limitations:
"This method requires multiple SCTP streams in the association between
the Exporting and Collecting Process, ideally one per Template."
No - if we had only one Template in the association, we would not need
multiple SCTP streams.
3.1.1. IPFIX Protocol Specifications Limitation:
"Note that a workaround allowed by the IPFIX specifications [RFC5101]
is to use only one Template Record per SCTP Transport Session, at the
cost of multiplying the number of SCTP Transport Sessions when
multiple Template Records are required."
This paragraph sounds a little misplaced, as it already mentions the
performance impact. After reading it, I was wondering what other
method would be proposed in this draft.
4.2. Template Management:
"Any Data Sets associated with a Template Record MUST be sent on the
same SCTP stream on which the Template Record was sent."
According to rfc5101, an Options Template Record is a Template Record.
Later in the same section you specify: "When the Options Template and
associated Data Records are sent in different SCTP streams, [...]".
Isn't this a contradiction, or am I missing something here?
4.5. The Collecting Process's Side:
"3. A Data Record is received unreliably although it is expected to be
sent reliably (due to a previously received Data Record associated
with the Data Record Reliability Options Template)."
Is it possible for the receiving side of a SCTP connection to
determine which SCTP messages were sent unreliably? I did not find any
indication of that in rfc3758. The receiving side only knows if
complete messages or fragments are skipped.
4.5. The Collecting Process's Side:
"In the case where the Exporting Process does not support the [...]"
This paragraph is a duplicate.
6. Examples:
In Figure 3, you seem to use the Options Reliability Template 257
(defined in Figure 1) that was received in another stream. A small
remark would be good which indicates, that all streams belong to the
same SCTP association.
Thanks,
Tobi
--
Dipl.-Inf. Tobias Limmer
Chair for Computer Networks and Communication Systems
Universität Erlangen-Nürnberg
Martensstr. 3, D-91058 Erlangen, Germany
Phone: +49-9131-8527931 Fax: +49-9131-8527409
eMail: limmer .at. informatik.uni-erlangen.de
URL: http://www7.informatik.uni-erlangen.de/~limmer