Subject: [ipfix] DRAFT IPFIX meeting minutes, 58th IETF, Minneapolis

From: Dave Plonka <[email-masked]>
Date: Mon, 10 Nov 2003 12:52:30 -0600

IPFIXers,

Please review the attached DRAFT minutes of the IPFIX meeting this morning.
Send any follow-up comments/suggestions/corrections to the list.

The minutes can also be found here:

   http://ipfix.doit.wisc.edu/IETF58/minutes.txt
      
Thanks,
Dave

P.S. I'm missing a number of slideshows from the meeting.  Please
submit them to me so that I can put them on the IPFIX web site and fix
the "FIXME" placeholder links in the minutes.

-- 
[email-masked]  http://net.doit.wisc.edu/~plonka  ARS:N9HZF  Madison, WI

--
Help        mailto:[email-masked] and say "help" in message body
Unsubscribe mailto:[email-masked] and say
"unsubscribe ipfix" in message body
Archive     http://ipfix.doit.wisc.edu/archive/

---

From: Dave Plonka <[email-masked]>
Date: Mon, 10 Nov 2003 12:57:52 -0600

D'oh, I forgot to attach the minutes previously.
You should find them attached here.

---

From: Benoit Claise <[email-masked]>
Date: Mon, 10 Nov 2003 21:25:14 +0100

Dave,

One comment

>
>Nevil Brownlee present his short list of open issues.
>For each, consensus at the meeting was:
>
>   1) Both counters and integers are needed in the information model.
>      (Here, by integer we mean an absolute value a la SNMP.)
>
>      For most information elements (IE), one or the other is sufficient,
>      and IPFIX should specify which MUST be implemented for each IE.
>
>      For some, such as packet and byte counts, both may be required.
>
What I was saying was:
1. for flow record, we need only integers
2. for metering process statistics, the running counters seem more 
appropriate.

The proposal was also to have just one IE type. So either an IE is an 
integer or a counter.
Your notes tend to show that a same IE could be implemented once with an 
integer behavior and another time with a counter behavior. I don't think 
this is the right approach.

Regards, Benoit.

---

From: "Tal Givoly" <[email-masked]>
Date: Mon, 10 Nov 2003 13:34:54 -0800

Dave,

>      (Here, by integer we mean an absolute value a la SNMP.)

I wasn't in the meeting, but I believe your parenthesis should be the
opposite. "counters" represent the SNMP-like behavior whereas "integers"
refers to the delta between the previous record and the next record. I also
believe that the term "integer" is misleading as the counter itself is also
an integer (however one that may or may not have a wrapping/overflow
behavior). Perhaps the term "delta" would more appropriate?

Tal

-----Original Message-----
From: majordomo listserver [mailto:[email-masked]]On Behalf
Of Benoit Claise
Sent: Monday, November 10, 2003 12:25 PM
To: [email-masked]
Cc: [email-masked]
Subject: Re: [ipfix] DRAFT IPFIX meeting minutes, 58th IETF, Minneapolis

Dave,

One comment

What I was saying was:

Regards, Benoit.

--
Help        mailto:[email-masked] and say "help" in message
body
Unsubscribe mailto:[email-masked] and say
"unsubscribe ipfix" in message body
Archive     http://ipfix.doit.wisc.edu/archive/

---

From: Dave Plonka <[email-masked]>
Date: Mon, 10 Nov 2003 16:26:39 -0600

Hi Tal,

On Mon, Nov 10, 2003 at 01:34:54PM -0800, Tal Givoly wrote:
> behavior).

You're right... I see now that that is true even in SNMP, so my
parentesized qualification is insufficient.

> Perhaps the term "delta" would more appropriate?

OK, I'll clarify it.

I think instead of counter and integer, we should say "counter" and "gauge".

These terms are defined in section 3.2.1 of RFC1065
("http://www.ietf.org/rfc/rfc1065.txt"):

   3.2.3.3.  Counter
   
      This application-wide type represents a non-negative integer which
      monotonically increases until it reaches a maximum value, when it
      wraps around and starts increasing again from zero.  This memo
      specifies a maximum value of 2^32-1 (4294967295 decimal) for
      counters.

   3.2.3.4.  Gauge

      This application-wide type represents a non-negative integer, which
      may increase or decrease, but which latches at a maximum value.  This
      memo specifies a maximum value of 2^32-1 (4294967295 decimal) for
      gauges.

Thanks,
Dave

---

From: "Tal Givoly" <[email-masked]>
Date: Mon, 10 Nov 2003 15:24:20 -0800

Dave,

Counter looks good in RFC1065, but the term "integer" that was used in IPFIX
context is not equivalent to GAUGE.

Integers in IPFIX context, or "Delta" value is a non-negative integer that
is representative of the absolute difference in value of a theoretical
counter between one record and the other. I say theoretical counter because
no counter needs to actually exist - what delta value reports are the number
of <something> that were observed/measured since the last report.
<something> could be octets, packets, frames, time units, etc.

I'm also unsure about the term "application wide" as although a counter or a
gauge are common to all observers, delta values are not common to all
observers (so if an exporter/meter is sending to multiple destinations, it
may have different delta values for each destination and there is no
commonly agreed upon, application wide, value - unless it is imposed that
the records are identical for all recipients).

Tal

-----Original Message-----
From: majordomo listserver [mailto:[email-masked]]On Behalf
Of Dave Plonka
Sent: Monday, November 10, 2003 2:27 PM
To: [email-masked]
Cc: Tal Givoly; Benoit Claise
Subject: Re: [ipfix] DRAFT IPFIX meeting minutes, 58th IETF, Minneapolis

Hi Tal,

OK, I'll clarify it.

   3.2.3.3.  Counter

   3.2.3.4.  Gauge

Thanks,
Dave

--
[email-masked]  http://net.doit.wisc.edu/~plonka  ARS:N9HZF  Madison,
WI

---

From: Benoit Claise <[email-masked]>
Date: Wed, 12 Nov 2003 17:28:13 +0100

Dave,

One more thing to add in the IPFIX meeting minutes!
The reply from Randy Bush to Stewart Bryant's question: what about the 
use of UDP in case of TTL=1?
Note that this was also addressed by Jeff Meyer on the mailing list.

Regards, Benoit.

>------------------------------------------------------------------------
>
>DRAFT Minutes of the IP Flow Information eXport (IPFIX) WG
>IETF 58, Minneapolis, Monday November 10, 2003
>58 people in attendance
>
>Reported by Dave Plonka & Nevil Brownlee (co-chairs) based on notes
>from Greg Ruth and George Michaelson.
>
>The text messaging log is available here:
>
>   http://www.xmpp.org/ietf-logs/[email-masked]/2003-11-10.html
>
>The meeting agenda and slides are available here:
>
>   http://ipfix.doit.wisc.edu/IETF58/
>
>[please see the agenda slides there for the sequence of topics:
> http://ipfix.doit.wisc.edu/IETF58/IETF58_IPFIX_agenda.pdf]
>
>--
>
>Juergen Quittek presented an update on the requirements draft.
>[see slides for details:
> http://ipfix.doit.wisc.edu/IETF58/FIXME]
>
>Nevil reported that, based on a conversation with Allison Mankin
>(transport area director), anonymsization IPFIX simply MAY be
>required, rather than MUST as she had suggested previously.  However,
>the requirements draft should include the rationale for why this is
>not strictly required.  (Basically that there is not yet a standard
>anonymization method.)
>
>--
>
>Ganesh Sadasivan presented an update on the architecture draft.
>[see slides for details:
> http://ipfix.doit.wisc.edu/IETF58/IPFIX_Architecture.ppt]
>
>We need volunteers to provide more text, in this and other drafts.
>
>--
>
>Juergen Quittek presented an update on the information model draft.
>[see slides for details:
> http://ipfix.doit.wisc.edu/IETF58/FIXME]
>
>Not many changes have been made recently.
>
>--
>
>Benoit Claise presented an update on the protocol draft.
>[see slides for details:
> http://ipfix.doit.wisc.edu/IETF58/IETF-58-IPFIX-PROTO.ppt]
>
>The draft has had many changes as the result of feedback regarding the
>NetFlow v9 draft, to be submitted as an individual Information RFC, which
>Benoit has been editing in parallel with the IPFIX protocol draft.
>
>Would like feedback regarding a number of issues listed in the slides:
>
>  1) Do we have consensus to use an options data record per observation
>     domain and per template?
>
>  2) Do we have consensus to replace the count with a length field,
>     in the export packet header?
>
>Lastly, he noted that the issue of transport protocol and Vendor
>Specified Information Elements are open issues. (These were addressed
>below.)
>
>--
>
>Tanja Zseby presented an update on the protocol draft.
>[see slides for details:
> http://ipfix.doit.wisc.edu/IETF58/FIXME]
>
>Highlights included that the middlebox content was removed.
>
>It was suggested that the applications discussed in the draft be
>limited to those that are considered high priority, so as to limit
>the amount of work.
>
>--
>
>Stuart Bryant presented his draft on Vendor Specified Information Elements.
>[see slides for details:
> http://ipfix.doit.wisc.edu/IETF58/FIXME]
>
>He suggested that IPFIX adopt the "compressed VI qualified" implementation.
>
>Those present afreed that text from this draft be copied directly
>into the IPFIX protocol draft.
>
>--
>
>Morizio Molina presented his draft on Flow Selection.
>[see slides for details:
> http://ipfix.doit.wisc.edu/IETF58/FIXME]
>
>While the chairs agree that this notion is worth considering, it will
>not be part of the current IPFIX documents.  However, IPFIX reviewers
>should take care not to preclude the implementation of such features
>in the future.
>
>--
>
>   2) The consensus was that a UTC-based seconds and microseconds,
>      similar to Unix struct timeval, should be adopted.
>
>      The IPFIX implementation may need to report its time resolution,
>      which presumably would require new text in the protocol draft.
>
>      It was noted that 32-bit unsigned counter wraps (c.) should
>      be defined (note precedent from NTP specification).
>
>   3) Variable length information elements are needed, and are being
>      addressed in the information model.
>
>   4) IPFIX templates will specifiy the number of bytes,
>      ie. the encoding, used for numeric information elements.
>      (The information model specifies only the range.)
>
>--
>
>At this point we opened discussion regarding the default (MUST implement)
>transport for IPFIX.
>
>Randy Bush, our area director, reminded us that one specific transport MUST
>be implemented to ensure interoperability (the goal of the IETF in general).
>
>In response to issues raised recently in the mailing list questioning
>the IETF's approval of UDP-based RTP to deliver high-bandwidth HDTV
>content, Jon Peterson (transport area director) said that the IESG
>expects IPFIX to work within the letter of its existing charter (and
>therefore must not use a UDP-based transport).  He also said that the
>IESG was mistaken, and in hindsight should not have approved the use
>of RTP in RFC-3497 ("RTP Payload Format for SMPTE Video").
>
>   --
>
>   In the context of this transport discussion, Randall Stewart
>   presented a slideshow about SCTP and PR-SCTP.
>   [see slides for details:
>    http://ipfix.doit.wisc.edu/IETF58/FIXME]
>
>   Randall hypothesized that PR-SCTP may be available as a standard as
>   soon as two months from now.
>
>   --
>
>Based on past IPFIX meeting discussions and in the mailing list, the
>chairs claimed that they felt there was rough consensus for choosing
>TCP as the default transport for IPFIX.
>
>A show of hands by in the meeting showed otherwise, with more favoring
>SCTP than TCP.  However, many did not express an opinion.  This issue
>will be taken to the mailing list to test the meeting consensus.
>
>--
>
>Nevil reviewed the working group milestones:
>
>The requirements draft and evaluation report will be submitted by
>December 1, 2003.
>
>The other four drafts need text and editing, and we're shooting for
>May 31, 2004.
>
>--
>$Id: minutes.txt,v 1.2 2003/11/10 18:45:34 dplonka Exp $
>  
>

---

From: Nevil Brownlee <[email-masked]>
Date: Thu, 13 Nov 2003 06:14:31 +1300

> Note that this was also addressed by Jeff Meyer on the mailing list.

That question was raised, but not discussed (following Ops and Transport
AD comment) at Monday's meeting.

The IPFIX charter says its transport has to be congestion-aware.
UDP - even with TTL=1 - is not congestion-aware.
We spent many, many months thrashing out the use of UDP at least a year
ago.  

Now we have a meeting consensus for SCTP as the IPFIX default transport.
Any vendor is free to implement whatever other transports they think their
customers need, but at this stage what we're looking for is text for the
IPFIX protocol draft to explain how to use SCTP, TCP (and maybe DCCP).

Let's move on and get the drafts finished!

CHeers, Nevil

-----------------------------------------------------------------------
   Nevil Brownlee                   Director, Technology Development
   Phone: +64 9 373 7599 x88941     ITSS, The University of Auckland
   FAX: +64 9 373 7021      Private Bag 92019, Auckland, New Zealand

-------------------------------------------------
This mail sent through University of Auckland
http://www.auckland.ac.nz/

---

From: "Tal Givoly" <[email-masked]>
Date: Wed, 12 Nov 2003 11:12:40 -0800

Nevil,

I saw in Dave's note that there wasn't a consensus on the default transport
protocol. What you say below contradicts those minutes.

Tal

-----Original Message-----
From: majordomo listserver [mailto:[email-masked]]On Behalf
Of Nevil Brownlee
Sent: Wednesday, November 12, 2003 9:15 AM
To: Benoit Claise
Cc: [email-masked]
Subject: Re: [ipfix] DRAFT IPFIX meeting minutes, 58th IETF, Minneapolis

CHeers, Nevil

---

From: Nevil Brownlee <[email-masked]>
Date: Thu, 13 Nov 2003 12:34:07 +1300

> protocol. What you say below contradicts those minutes.

What I said in my last note (subject 'Draft minutes') was that
 - in introducing the 'transport' discussion at the meeting we said
   that there wasn't a clear consensus on the list, but that there
   seemed to be rough consensus for TCP.
 - at the meeting there was clear consensus for SCTP, and no-one stood
   up to speak strongly against it.  Hence the minutes say that the
   meeting consensus was SCTP.
Thus, there was no contradiction.

Furthermore, in this discussion, 'default' means 'mandatory to implement,'
as we reported very clearly in the draft minutes.

The situation now is that we have a rather small number of people with
strongly-expressed opinions, which - it seems to me - is diverting energy
away from getting the drafts completed.  It's high time we concentrated
on doing that, and most of the work needed on the drafts doesn't depend
on our choice of transport protocol.  So please, let's get on with that.

We also said that we'd push the consensus discussion back to the mailing
list for further discussion.  At this stage my own view is that although
TCP is ubiquitous, SCTP has useful technical advantages.  Now I'd like
to hear constructive suggestions to help build consensus, from a wider
range of IPFIX WG participants.  For instance, can anyone report on
implementation experience with IPFIX, or IPFIX-like applications using SCTP?

Cheers, Nevil

PS: In an effort to help everyone focus on getting the drafts completed,
    I think we need to get some better tracking procedures in place.  
    I'm writing a short note about that, which I'll post to the list 
    real soon now.

---

From: Sebastian Zander <[email-masked]>
Date: Thu, 13 Nov 2003 11:37:25 +0100

Hi Nevil et al,

Nevil Brownlee wrote:
[...]
>     I'm writing a short note about that, which I'll post to the list 

I agree that SCTP is desirable but on the other hand we have to face the
reality of SCTP not being ubiquitous available. If it won't be available
people will rather use TCP than to implement SCTP even if SCTP is mandatory
in the spec.

How about making a compromise similar to what the AAA WG has done?
Please refer to RFC3539 section 3.1 or RFC3588 section 2.1. Similar IPFIX
could specify that IPFIX exporters SHOULD support SCTP but MUST support TCP
in case SCTP is not available and IPFIX collectors MUST support both. If SCTP
becomes widely deployed future versions of IPFIX may mandate SCTP as MUST for
exporters. If both protocols are supported by exporter and collector SCTP
MUST be used.

This would make SCTP the default but leaves room for TCP especially at the
exporter where its more difficult to ubiquitously support SCTP. Adds more
complexity to the spec though...

Cheers,

Sebastian

-- 
Sebastian Zander                         E-mail: [email-masked]
Fraunhofer FOKUS / METEOR                Tel: +49-30-3463-7287
Kaiserin-Augusta-Allee 31                Fax: +49-30-3463-8287
D-10589 Berlin, Germany                  www.fokus.fraunhofer.de/usr/sebastian.zander

---

From: Martin Horneffer <[email-masked]>
Date: Fri, 21 Nov 2003 13:07:04 +0100

On Thu, Nov 13, 2003 at 12:34:07PM +1300, Nevil Brownlee wrote:
[..]
>    meeting consensus was SCTP.
[..]

I'm not sure the consesus at the meeting was all that clear for SCTP.
Anyways, as the minutes says the consensus is to be found in the
mailing list.

Since I joined backbone engineering at a large European operator I
unfortunately don't usually manage to keep up with the list. Nor can I
participate in discussions of all the nice and interesting details of
the protocol, even though netflow export actually falls into my
responsibility.

But let me try to express my strong opinion on this particular matter:

  PLEASE DO CHOOSE TCP AS THE DEFAULT TRANSPORT!

I believe you experts that SCTP might actually be better. But I DO
WANT TO HAVE IPFIX.

And operational experience with large networks teaches that any
non-essential complexity can kill a good thing very easily.

SCTP might be a good thing, might have better performance and might be
the technically better approach in general. But it is not _essential_
to get IPFIX to work.

So please: do support it, recommend it and suggest it's implementation
and use; but do not make it mandatory because that would effectively
prevent wide deployment of IPFIX until also SCTP is widely available
and has matured to a high level of operational robustness and
experience.

If SCTP is indeed the technically better transport and TCP the simpler
one, then

1) if SCTP was mandatory there would be no need to implement TCP at
all.

2) if TCP was mandatory then TCP still could serve to enter the market
sooner and still leave incentive to implement and use SCTP (maybe
somewhat later).

Also I would not believe a vendor to have a reliable and actually
operationally usable implementation of SCTP soon if he still doesn't
have netflow v5 work flawlessly on certain hardware/software
combinations it should...

Best regards,

Martin Horneffer
-- 
Dr. Martin Horneffer -- [email-masked]
Deustche Telekom AG
Internet Bachbone Engineering