Subject: [IPFIX] DRAFT IPFIX minutes from IETF 80

From: Nevil Brownlee <[email-masked]>
Date: Thu, 31 Mar 2011 02:23:42 -0700

Hi all:

Here are my draft minutes for Tuesday's meeting; they include my
summary of the alternatives from our 'Draft Standards?' discussion.

Please send me any corrections, changes, etc as soon as possible.

Minutes of the IPFIX meeting at IETF 80
About 36 people present
Scribes: Cyndi Mills & Nevil Brownlee

Nevil Brownlee presented current WG document status.  Three documents
completed since IETF 79 (Export-per-SCTP-stream, Mediators Framework
and Anonymisation Support), one with IESG (Structured Data).  We have
received comments on the IPFIX Configuration Model draft from the YANG
Doctors, and have been carefully considered.  Juergen will do its
write-up.  The PSAMP MIB has been revised to use the UnsiUnsigned64TC
and Float64TC Textual Conventions from other MIBs.  Nevil will do its
write-up.  The remaining work item, Flow Selection, is under review,
and will be discussed further on the IPFIX list.

Brian Trammell presented a report on the 'DEMONS IPFIX
Interoperability Test,' held in Prague, 24-25 March.  This was the
fourth such event for IPFIX, with eight implementations (4 exporters,
3 collectors) being tested.  Interoperation was complete for UDP,
less so for TCP; for SCTP it was dependent on the SCTP
implementations used.  Quite a few issues came to light (see the
slides), many were fixed during the event.
Several people commented on SCTP implementation issues, suggesting
that perhaps "template handling is needlessly complicated in the
(IPFIX) protocol."  Dan Romascanu (our AD) asked for an Interoperation
Report, Brian says he has one written as an Internet Draft.

Lothar Braun presented Recommendations for Implementing IPFIX over
DTLS/UDP.  DTLS is mandatory for IPFIX over UDP and SCTP, but using
it is difficult because IPFIX traffic is unidirectional, but DTLS
requires shared state.  Discussion centred on IPFIX's need for a
heartbeat to detect collector failures, and whether IPFIX should do
its own heartbeat.  Lothar's recommendations could fit in a revision
of IPFIX Implementation Guidelines.

Juergen lead a discussion on whether we should work on moving some of
the IPFIX standards from Proposed to Draft.  Dan explained that to
do so any changes would need to be editorial, not technical.  There
was considerable discussion, the main points being:
1. There are many errata for 5101 and 5102, it would be good to have a
    new draft that does that, along with some more explanatory
    (editorial) text where needed
2. If we move 5101 and 5102 to Draft, any changes - however small -
    would need to be a new version of the IPFIX protocol.  Doing that
    could lead to confusion among IPFIX implementors and users
3. An alternative approach would be to work on a new draft (which
    implemented small changes that did not affect interoperation, for
    example adding detail where there are gaps in 5101) as a Standards
    Track successor to 5101.  Once that had been published as an RFC
    for some time, we could work on moving it to Draft; that should be
    possible in a reasonably short time.
4. Other things that could be considered: IPFIX heartbeat provision
    (we need to consider how long it will take TSVWG to complete the
    DTLS Heartbeat Extension), change canonical transport to TCP, ... ?
5. Another possibility is to make a new "all about IPFIX" document;
    there was only weak consensus for this
The meeting reached consensus for (3, rather than 2), we will discuss
this further on the IPFIX list.

Five drafts were presented as candidates (in addition to the 'Standards
upgrade') for an IPFIX re-chartering.

Brian Trammell presented 'IPFIX Intermediate Aggregation,' this drew
strong consensus as a new WG item.

Brian presented the 'IE Doctors' draft, pointing out that this draft
"lays out the ground rules for developing new IPFIX Information
Elements, and clarifies how the IE Registry process works."  Michelle
Cotton (IANA) commented that other working groups, e.g. DNS, have
similar processes to those in this draft; we need to be clear about
whether we're proposing "approval by IE-Doctors," or changes to
"expert review" (which we have now).  Dan commented that to set up a
team of IE Doctors, we need AD approval, and must keep IESG informed.
Paul Aitken asked (via jabber), whether an IE could be reviewed and
not made public until the product is shipped?  Dan replied "we have a
body of experience to say that this should be an exception and not the
rule."  There was clear consensus for adopting this as a WG item,
with one person expressing strong dissent.  We will discuss this
further on the list - the issues here are
a. Should we develop an 'IE Guidelines' draft?
b. Do we want to have an 'IE Doctors' team (with IESG overview),
    an expanded group of IE Expert reviewers, or what?

Benoit Claise presented the 'IPFIX Mediation protocol' draft, now at
version -03.  There was clear consensus for adopting this.

Benoit presented 'Exporting MIB variables using IPFIX.'  A spirited
discussion of how Odis should be referred to in the IPFIX protocol.
There was stronger consensus for this than against it.  Again,
discussion of this will continue on the list.

Benoit presented 'Exporting Application Information,' prompting
considerable discussion.  Steven Campbell commented that
"vendor-specific labels for layer-7 mapping is difficult. However, the
way to discover layer 7 (behavioral, DPI) could be standardized."
Benoit said he wasn't proposing this as a WG item, however anyone
interested should continue discussing this topic on the list.

The meeting finished at 1459.

-- 
---------------------------------------------------------------------
  Nevil Brownlee                    Computer Science Department | ITS
  Phone: +64 9 373 7599 x88941             The University of Auckland
  FAX: +64 9 373 7453   Private Bag 92019, Auckland 1142, New Zealand

---

From: Lothar Braun <[email-masked]>
Date: Thu, 31 Mar 2011 14:12:12 +0200

Hi, 

>   DTLS Heartbeat Extension), change canonical transport to TCP, ... ?

I've been to the TLS WG meeting and checked upon the status and future plans of the DTLS heartbeat draft. The draft has been adopted as a working group document quite some time ago, which I completely missed.

TLS chairs were confident that it would not take very long to move it to PS.
According to them, the document is in quite good shape, and could soon progress to WGLC after a review from the transport area has been received.

> _______________________________________________
> IPFIX mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ipfix

--
Lothar Braun
Chair for Network Architectures and Services (I8)
Department of Informatics
Technische Universität München
Boltzmannstr. 3, 85748 Garching bei München, Germany
Phone:  +49 89 289-18010       Fax: +49 89 289-18033
E-mail: [email-masked]

---

From: Brian Trammell <[email-masked]>
Date: Thu, 31 Mar 2011 18:40:58 +0200

Hi, Nevil,

Minor comments, below.

On Mar 31, 2011, at 11:23 AM, Nevil Brownlee wrote:

> (IPFIX) protocol."  

The guidance regarding the complexity of template handling comes from the fact that nobody implemented template withdrawal or template number reuse, not from SCTP implementation issues.

> Dan Romascanu (our AD) asked for an Interoperation

On review, the Internet-Draft format of what I have does not meet the form or content of an Implementation Report. I'll do this, but will take a bit longer.

> strong consensus as a new WG item.

"Exporting Aggregated Flow Data with IPFIX", "the aggregation draft", or simply "a9n".

---

From: Gerhard Muenz <[email-masked]>
Date: Thu, 31 Mar 2011 21:58:03 +0200

Brian,

>> fourth such event for IPFIX, with eight implementations (4
>> exporters, 3 collectors) being tested.  Interoperation was complete
>> for UDP, less so for TCP; for SCTP it was dependent on the SCTP
>> slides), many were fixed during the event. Several people commented
>> on SCTP implementation issues, suggesting that perhaps "template
>> handling is needlessly complicated in the (IPFIX) protocol."
>
> The guidance regarding the complexity of template handling comes from
> the fact that nobody implemented template withdrawal or template
> number reuse, not from SCTP implementation issues.

That does not seem to be true. Vermont sends Template withdrawal 
messages and reuses Template IDs if you trigger an appropriate 
reconfiguration at runtime. Maybe this was just not tested at the 
interop event.

Regards,
Gerhard

---

From: Benoit Claise <[email-masked]>
Date: Thu, 31 Mar 2011 23:40:30 +0200

Hi Lothar,
>> Scribes: Cyndi Mills&  Nevil Brownlee
>>
> I've been to the TLS WG meeting
Any update on draft-ietf-tsvwg-sctp-strrst-09.txt?

Regards, Benoit.
> and checked upon the status and future plans of the DTLS heartbeat draft. The draft has been adopted as a working group document quite some time ago, which I completely missed.
>