IP Flow Information Export (IPFIX) Implementation Guidelines
RFC 5153

[Ballot discuss]
Section 6.1:

duplicate intention of these paragraphs?

"Stream negotiation is a feature of the SCTP protocol.  Note however,
  that the IPFIX protocol doesn't provide any mechanism for the
  Exporter to convey any information about which streams are in use to
  the Collector.  Therefore, stream configuration must be done out of
  band.

  Note however, that the IPFIX protocol doesn't provide any mechanism
  for the Exporter to convey any information about which streams are in
  use to the Collector.  Therefore, stream configuration must be done
  out of band."

Note that it is moderately strange that SCTP is the required transport and then later the draft states:

" While SCTP is a standard track protocol, certain implementations as
  of this writing might be unstable.  We recommend extensive testing of
  SCTP based IPFIX implementations to build confidence in the SCTP
  stack over which your implementation runs."

With TCP and UDP as "MAY" be supported, the actual deployment seems potentially perilous. One would expect in informative implementation guidelines a stronger suggestion on what stable alternative SHOULD/MUST be built in the following sections on UDP/TCP.

[Ballot comment]
When the IPFIX protocol documents came out, I had some concerns about how well implementors would be able to understand what to do. This draft nice addressed all those and I would like the think the WG and authors for actually producing it. Often drafts are promised with good intentions but somehow fail to materialize - thanks for making this one real.

One nit ...

I sort of doubt that SCTP save resources on router line cards. (Section 6.1, para 1)

[Ballot comment]
When the IPFIX protocol documents came out, I had some concerns about how well implementors would be able to understand what to do. This draft nice addressed all those and I would like the think the WG and authors for actually producing it. Often drafts are promised with good intentions but somehow fail to materialize - thanks for making this one real.

[Ballot discuss]
Based on the Gen-ART Review by Elwyn Davies.

  The document contains some inappropriate uses of RFC 2119 language.
  Section 2 saya:
  >
  > This document is Informational.  It does not specify a protocol and
  > does not use RFC 2119 keywords [RFC2119] such as "MUST" and "SHOULD",
  > except in quotations and restatements from the IPFIX standards
  > dcouments.
  >
  The examples cited by Elwyn in the Gen-ART Review show that this is
  not always true.  It is sometimes difficult to reword and keep the
  proper context.  Paraphrases using RFC 2119 language are a problem.
  Alternative interpretations seem likely.  It would be better to
  reproduce the exact language or give a section reference.

  Elwyn Davies' Gen-ART Review can be found here:
  http://www.alvestrand.no/ietf/gen/reviews/
  draft-ietf-ipfix-implementation-guidelines-07-davies.txt

[Ballot comment]
Section 1.1., paragraph 0:
>  1.1.  History of IPFIX

  I personally feel that WG history is inappropriate for a published RFC
  and would hence recommend to remove Section 1.1. YMMV.

Section 6.2., paragraph 12:
>    Note that this could become an interoperability problem, e.g. if an
>    Exporter re-sends Templates once per day, while a Collector expires
>    Templates hourly, then they may both be IPFIX-compatible, but not be
>    interoperable.

  Why not just circumvent this problem by mandating a minimum intervall
  for the expiration timeout that is longer than the maximum
  retransmission timeout?

Section 6.3., paragraph 1:
>    TCP can be used as a transport protocol for IPFIX if one of the
>    endpoints has no support for SCTP, but a reliable transport is needed
>    and/or the network between the exporter and the collector is
>    susceptible to congestion.

  All networks are susceptible to congestion, at least unless
  reservations are in use for all flows. Suggest to replace "is
  susceptible to congestion" by "has not explicitly been provisioned for
  the IPFIX traffic."

Section 6.3., paragraph 4:
>    If the available bandwidth between exporter and collector is not
>    sufficient or the metering process generates more data records than
>    the collector is capable of processing, then TCP congestion control
>    would cause the exporter to block.

  Not necessarily. The socket API has functions to query buffer
  occupation and non-blocking I/O lets the exporter continue to sample,
  even if it cannot send to the collector.

Section 14.2., paragraph 10:
>    [RFC2960]  Stewart, R., Xie, Q., Morneault, K., Sharp, C.,
>              Schwarzbauer, H., Taylor, T., Rytina, I., Kalla, M.,
>              Zhang, L., and V. Paxson, "Stream Control Transmission
>              Protocol", RFC 2960, October 2000.

  Obsoleted by RFC 4960.

Section 14.2., paragraph 13:
>    [RFC3309]  Stone, J., Stewart, R., and D. Otis, "Stream Control
>              Transmission Protocol (SCTP) Checksum Change", RFC 3309,
>              September 2002.

  Obsoleted by RFC 4960.

PROTO write-up from Nevil Brownlee:

Shepherd Document for draft-ietf-ipfix-implementation-guidelines-05.Txt

Title:    IPFIX Implementation Guidelines
Editors:  Elisa Boschi, Lutz Mark, Juergen Quittek,
            Martin Stiemerling, Paul Aitken


As required by RFC-to-be draft-ietf-proto-wgchair-doc-shepherding,
this is the current template for the Document Shepherd Write-Up.
Changes are expected over time.  This version is dated February 1, 2007.


  (1.a)  Who is the Document Shepherd for this document?  Has the
          Document Shepherd personally reviewed this version of the
          document and, in particular, does he or she believe this
          version is ready for forwarding to the IESG for publication?

          Nevil Brownlee.  I have reviewed this draft, I believe
          it is ready to forward to the IESG for publication.

  (1.b)  Has the document had adequate review both from key WG members
          and from key non-WG members?  Does the Document Shepherd have
          any concerns about the depth or breadth of the reviews that
          have been performed?

          This is version 3 of the draft, it has had extensive review
          by the WG members, particularly those who took part in the
          three IPFIX interoperability events held to date.
          These reviews seem sufficiently thorough to me.

  (1.c)  Does the Document Shepherd have concerns that the document
          needs more review from a particular or broader perspective,
          e.g., security, operational complexity, someone familiar with
          AAA, internationalization or XML?

          No.  The WG members contributing to this draft have detailed
          experience on implementing IPFIX, the guidelines are all
          aimed at new implementors.

  (1.d)  Does the Document Shepherd have any specific concerns or
          issues with this document that the Responsible Area Director
          and/or the IESG should be aware of?  For example, perhaps he
          or she is uncomfortable with certain parts of the document, or
          has concerns whether there really is a need for it.  In any
          event, if the WG has discussed those issues and has indicated
          that it still wishes to advance the document, detail those
          concerns here.  Has an IPR disclosure related to this document
          been filed?  If so, please include a reference to the
          disclosure and summarize the WG discussion and conclusion on
          this issue.

          Discussion on the IPFIX list has shown that the protocol
          draft is uduly restrictive in the way it specifies how SCTP
          streams should be used.  This draft (ipfix implementation
          guidelines) reflects experience from the ipfix interopability
          events about the use of SCTP; the WG proposes to add a new charter
          item, producing a new RFC that will amend the protocol RFC,
          making it clear how SCTP can be used for ipfix.

  (1.e)  How solid is the WG consensus behind this document?  Does it
          represent the strong concurrence of a few individuals, with
          others being silent, or does the WG as a whole understand and
          agree with it?

          This document has strong consensus within the IPFIX
          Working Group.

  (1.f)  Has anyone threatened an appeal or otherwise indicated extreme
          discontent?  If so, please summarise the areas of conflict in
          separate email messages to the Responsible Area Director.  (It
          should be in a separate email because this questionnaire is
          entered into the ID Tracker.)

          No.

  (1.g)  Has the Document Shepherd personally verified that the
          document satisfies all ID nits?  (See
          http://www.ietf.org/ID-Checklist.html and
          http://tools.ietf.org/tools/idnits/).  Boilerplate checks are
          not enough; this check needs to be thorough.  Has the document
          met all formal review criteria it needs to, such as the MIB
          Doctor, media type and URI type reviews?

          Idnits tool Version: 2.04.07 only found nits in the draft's
          references. See (1.h) for further comments on this.

          The draft is IPFIX-centric, it needs no other formal checks.

  (1.h)  Has the document split its references into normative and
          informative?  Are there normative references to documents that
          are not ready for advancement or are otherwise in an unclear
          state?  If such normative references exist, what is the
          strategy for their completion?  Are there normative references
          that are downward references, as described in [RFC3967]?  If
          so, list these downward references to support the Area
          Director in the Last Call procedure for them [RFC3967].

          Yes and yes. This draft depends on the IPFIX Protocol and
          Info Model drafts; they are in the RFC Editor Queue waiting for
          the PSAMP drafts.  The PSAMP editors/authors are now working
          on the PSAMP documents; we expect the PSAMP documents to
          be submitted to IESG in the next months or so.

  (1.i)  Has the Document Shepherd verified that the document IANA
          consideration section exists and is consistent with the body
          of the document?  If the document specifies protocol
          extensions, are reservations requested in appropriate IANA
          registries?  Are the IANA registries clearly identified?  If
          the document creates a new registry, does it define the
          proposed initial contents of the registry and an allocation
          procedure for future registrations?  Does it suggest a
          reasonable name for the new registry?  See [RFC2434].  If the
          document describes an Expert Review process has Shepherd
          conferred with the Responsible Area Director so that the IESG
          can appoint the needed Expert during the IESG Evaluation?

          This draft has no IANA Considerations section.

  (1.j)  Has the Document Shepherd verified that sections of the
          document that are written in a formal language, such as XML
          code, BNF rules, MIB definitions, etc., validate correctly in
          an automated checker?

          The draft contains nothing written in a formal language.

  (1.k)  The IESG approval announcement includes a Document
          Announcement Write-Up.  Please provide such a Document
          Announcement Write-Up?  Recent examples can be found in the
          "Action" announcements for approved documents.  The approval
          announcement contains the following sections:

Technical Summary

  The IP Flow Information eXport (IPFIX) protocol defines how IP Flow
  information can be exported from routers, measurement probes or other
  devices.  This document provides guidelines for the implementation
  and use of the IPFIX protocol.  Several sets of guidelines address
  template management, transport-specific issues, implementation of
  exporting and collecting processes and IPFIX implementation on
  middleboxes (such as firewalls, network address translators, tunnel
  endpoints, packet classifiers, etc.).

Working Group Summary

This document records experience gained in three IPFIX interopability
events.  Some of that early experience gave rise to changes in the
IPFIX protocol, later experience came in testing IPFIX over its
three transports.  Overall, this document provides in-depth discussion
about IPFIX.  It will be useful to implementors and to others wanting
more detail about its implementation.

Document Quality

The Working Group has reached consensus on this document.
It has been reviewed by by the IPFIX Working Group Chairs.

Personnel

Shepherd:      Nevil Brownlee
Area Director:  Dan Romascanu