Brian,
Hi, Benoit, all,
I have a few comments on the -04 perstream draft.
In general the quality of the draft has improved greatly. I'm quite
happy with the detail in section 4.5 for guaranteeing interoperability
while still allowing CPs to get the benefits of per-stream, which was
my main issue with the previous revision. I notice too the Intended
Status is now Standards Track. I presume that this Standards Track
designation is equivalent to that of e.g. 5103 (Biflow): this is an
optional specification with specific applicability;
Exactly.
otherwise, it's still fine IMO as Informational, but then
you have to ditch all the 2119 language. I think it was the appearance
of 2119 language in an Informational draft that made the IESG suggest
Standards Track;
Exactly.
The following email was the start of this discussion, along with the
"Stream Control Transmission Protocol (SCTP) Stream Reconfiguration"
draft that became a working group document.
-------- Original Message --------
Discuss:
I have 2 relatively minor issues with the document:
1). DISCUSS DISCUSS:
Why is this document says "Intended Status: Informational"? It looks fairly normative to me.
...
see 5473 for an example of how to describe a mechanism
with specific applicability in a non-normative way. Of course, then
there's the problem with an Informative RFC contradicting a Standards
Track one (5101), necessary for the CP to realize the perstream
advantages... In any case, I'm not convinced the discussion is complete
on this point.
I agree that at this point, the situation is a little bit unclear.
I applied the discussed/proposed solution. However, the formal decision
from the WG/Chair/Area Director would be welcome.
Presuming we're talking about a restricted-applicability Standards
Track draft, the applicability of the draft is now clearer in previous
versions, but I would still suggest certain changes to the language in
order to avoid confusion on this point, as follows.
2.2 Applicability para 1
OLD: The specifications are required in cases where we must know how
many data records of a certain type...
NEW: The specifications contained in this document are applicable to
cases where application requirements include knowing how many data
records of a certain type...
[Yes, I know that required isn't a REQUIRED, but I want implementors to
be sure they don't have to do perstream if they're not splitting
templates by app; I believe the suggested text clarifies this point]
2.2 Applicability para 3
OLD: However, in order to benefit from the advantages, the Collecting
Process specified in [RFC5101] must implement some additional
specifications that this document introduces.
NEW: However, Collecting Processes may implement additional support for
per-stream export specified in this document in order to realize all
the benefits of the approach specified herein.
[Same thing. Make it clear we're not updating 5101.]
3.2.1 Transmission Order within an SCTP Stream / IPFIX Protocol
Specifications Limitation paragraph 5
DELETE: In practice, Data Records without associated (Options) template
records will most likely be discarded by the Collecting Process.
[Maybe true. Probably, even. Appropriate for an Informational draft or
an implementation report. But this comes too close to contradicting a
MAY in 5101 to be appropriate for a Standards Track draft.]
4. Specifications para 1
OLD: This section introduces improvements compared to the IPFIX
specifications in [RFC5101].
NEW: This section specifies Exporting Process and Collecting Process
behavior different from that in [RFC5101] in order to realize the
benefits of per-stream export. Note that Exporting Processes following
these Specifications will interoperate with [RFC5101]-compliant
Collecting Processes, but that Collecting Processes will have to follow
additional non-interoperable specifications to realize the full
benefits of the technique.
[The current text does not take applicability under consideration.]
4.2 Template Management para 1
OLD: This section introduces some additional specifications compared to
the Template Management section 8 in [RFC 5101]
NEW: 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].
[As for 4 above.]
4.3 SCTP para 1
OLD: This section introduces some more specific specifications compared
to the SCTP section 10.2 in [RFC 5101], in particular the "Stream"
section 10.2.4.3.
NEW: To take advantage of per-stream export, Exporting Processes should
manage SCTP streams according to the specification in this section, in
addition to Section 10.2.4.3, Stream, of [RFC5101].
[As for 4 above.]
4.4 Template Withdrawal Message para 1
OLD: This section introduces some more specific Template Withdrawal
Message-related specifications compared to [RFC 5101]
NEW: To take advantage of per-stream export, Exporting Processes should
send Template Withdrawal Messages according to the specification in
this section, in addition to Section 8, Template Management, of
[RFC5101].
[As for 4 above.]
4.5 The Collecting Process's Side para 1
OLD: This section introduces some more specific specifications to the
Collection Process compared to section 9 in [RFC5101]. However, the new
specifications are backwards compatible with RFC5101- compliant
Collecting Processes and are only needed to benefit from the advantages
offered by the per-SCTP-stream extension.
NEW: 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 for 4. Clarified that CPs need to interoperate with EPs, not "have
backward compatibility" with other CPs.]
All your new proposals above make perfect sense.
A suggestion not strictly limited to applicability:
4.1 dataRecordsReliability Information Element
[This information element is specified to only apply to Template ID
scopes. Could it not also be scoped to other things (SCTP Stream ID,
for instance) for a generalization of the approach? suggest the
following:]
OLD:
dataRecordsReliability
Description:
The Data Records reliability associated with this
Template ID. The true value means that the Data Records
are sent reliably, while the false value means that the
Data Records are not sent reliably.
NEW:
dataRecordsReliability
Description:
The Data Records reliability associated with the elements in
the Options Template scope, usually a templateID. A true value
means that the Data Records are sent reliably, while a false
value
means that the Data Records are not sent reliably.
Great suggestion.
In addition, on review I found the following editorial issues:
Subsections of 3, stylistic: The structure of this section reads a
little like a sales pitch (with the subsubsections IPFIX limitations /
perstream advantages per each subsection). Further, I don't actually
think the split into subsubsections is necessary; the text flows fine
without the headings. If you really want to keep the subsubsections,
name the 3.x.1 "IPFIX Protocol Specification Limitations" for plurality
agreement with 3.x.2.
We created this structure based on Elisa's comment
(http://www.ietf.org/mail-archive/web/ipfix/current/msg04325.html)
General Comment:
As already said during the IPFIX meeting in Philadelphia, I'd like to
see a section on the limitations of this method and a few more words on
its applicability.
While the advantages are clearly listed, it is not clear
- to which set of applications this specification is targeted (this
might be added in 2.1 Applicability),
- which limitations the method has.
I have no strong feeling about the subsubsections. We can remove the
headings.
3.2.1 Transmission Order within an SCTP Stream / IPFIX Protocol
Specifications Limitation paragraph 1
OLD: The IPFIX protocol specification foresees:
NEW: [RFC5101] specifies:
ok.
3.3.2 No Transmission Order across SCTP Streams / IPFIX Export Per SCTP
Stream Advantages, general
[This section should mention Options Templates, since 3.3.1 does.]
ok.
4.1 dataRecordsReliability
[should have an IANA NOTE pointing out that IANA should change the xxx.
They'll probably figure it out anyway but why not be helpful? :) ]
ok.
Further, I suspect you'll get a Security question asking about what
SCTP-RESET does to the SCTP-relevant bits of the 5101 security
considerations, so a paragraph exploring the potential risks (and then,
therefore, one hopes, dismissing them) would be useful here.
Actually, this one passed the IESG review.
Thanks for the excellent feedback.
Regards, Benoit.
hm. That seems to be about it (it was a little longer than I originally
intended). Hope this helps. :)
Cheers,
Brian
On Oct 26, 2009, at 6:00 PM, Internet-Drafts at ietf.org wrote:
A New Internet-Draft is available from the
on-line Internet-Drafts
directories.
This draft is a work item of the IP Flow Information Export Working
Group of the IETF.
Title : IPFIX Export per SCTP Stream
Author(s) : B. Claise, P. Aitken, A. Johnson, G. Muenz
Filename : draft-ietf-ipfix-export-per-sctp-stream-04.txt
Pages : 22
Date : 2009-10-26
This document specifies an extension to the specifications
in RFC5101, IP Flow Information Export (IPFIX), when using
the Partial Reliability extension of SCTP (PR-SCTP, Partial
Reliability Stream Control Transmission Protocol).
When implemented at both the Exporting and Collecting Processes,
this method offers several advantages such as the ability to
calculate Data Record losses for PR-SCTP, immediate export of
Template Withdrawal Messages, immediate reuse of Template IDs
within an SCTP stream, reduced likelihood of Data Record loss,
and reduced demands on the Collecting Process. When implemented
in only the Collecting or Exporting Process then normal IPFIX
behavior will be seen without these additional benefits.
A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ipfix-export-per-sctp-stream-04.txt
Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.
<mime-attachment>_______________________________________________
IPFIX mailing list
IPFIX at ietf.org
https://www.ietf.org/mailman/listinfo/ipfix
_______________________________________________
IPFIX mailing list
IPFIX at ietf.org
https://www.ietf.org/mailman/listinfo/ipfix
|