[IPFIX] DRAFT IPFIX minutes from IETF 80
Nevil Brownlee <n.brownlee@auckland.ac.nz> Thu, 31 March 2011 09:24 UTC
Return-Path: <n.brownlee@auckland.ac.nz>
X-Original-To: ipfix@core3.amsl.com
Delivered-To: ipfix@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0034728C250 for <ipfix@core3.amsl.com>; Thu, 31 Mar 2011 02:24:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.599
X-Spam-Level:
X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m8EyhYhX3HYP for <ipfix@core3.amsl.com>; Thu, 31 Mar 2011 02:24:02 -0700 (PDT)
Received: from mx2-int.auckland.ac.nz (mx2-int.auckland.ac.nz [130.216.12.41]) by core3.amsl.com (Postfix) with ESMTP id 9EE1A28C1FC for <ipfix@ietf.org>; Thu, 31 Mar 2011 02:22:53 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=n.brownlee@auckland.ac.nz; q=dns/txt; s=uoa; t=1301563474; x=1333099474; h=message-id:date:from:mime-version:to:subject: content-transfer-encoding; z=Message-ID:=20<4D94481E.6080605@auckland.ac.nz>|Date:=20 Thu,=2031=20Mar=202011=2002:23:42=20-0700|From:=20Nevil =20Brownlee=20<n.brownlee@auckland.ac.nz>|MIME-Version: =201.0|To:=20IPFIX=20list=20<ipfix@ietf.org>|Subject:=20D RAFT=20IPFIX=20minutes=20from=20IETF=2080 |Content-Transfer-Encoding:=207bit; bh=ZrrTdmbaBqssDKK2cJeknh8FMl0Om1t8ZLPq3Qn7A7U=; b=Q9Oadmm25Co7ceCoOrqPdeF52bssA4qBdE+vICiuTbf6cOMPbxpfucZM 6q8kZPlkx8Lu+x451cMiD0bkAUz4hElluVKi2ID5BjamGNrQtWZuZSI4X SEQL5F5kBWuUXHWP/Fx6+0aC0dQofUgla65NMSsONUBLYCQlMRtWvAZCi A=;
X-IronPort-AV: E=Sophos;i="4.63,274,1299409200"; d="scan'208";a="54432622"
X-Ironport-HAT: None - $RELAY-AUTH
X-Ironport-Source: 130.129.18.11 - Outgoing - Outgoing-SSL
Received: from dhcp-120b.meeting.ietf.org (HELO [130.129.18.11]) ([130.129.18.11]) by mx2-int.auckland.ac.nz with ESMTP; 31 Mar 2011 22:23:45 +1300
Message-ID: <4D94481E.6080605@auckland.ac.nz>
Date: Thu, 31 Mar 2011 02:23:42 -0700
From: Nevil Brownlee <n.brownlee@auckland.ac.nz>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.14) Gecko/20110223 Thunderbird/3.1.8
MIME-Version: 1.0
To: IPFIX list <ipfix@ietf.org>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Subject: [IPFIX] DRAFT IPFIX minutes from IETF 80
X-BeenThere: ipfix@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IPFIX WG discussion list <ipfix.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ipfix>, <mailto:ipfix-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipfix>
List-Post: <mailto:ipfix@ietf.org>
List-Help: <mailto:ipfix-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipfix>, <mailto:ipfix-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 31 Mar 2011 09:24:06 -0000
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
- [IPFIX] DRAFT IPFIX minutes from IETF 80 Nevil Brownlee
- Re: [IPFIX] DRAFT IPFIX minutes from IETF 80 Lothar Braun
- Re: [IPFIX] DRAFT IPFIX minutes from IETF 80 Brian Trammell
- Re: [IPFIX] DRAFT IPFIX minutes from IETF 80 Gerhard Muenz
- Re: [IPFIX] DRAFT IPFIX minutes from IETF 80 Benoit Claise
- Re: [IPFIX] DRAFT IPFIX minutes from IETF 80 Lothar Braun
- Re: [IPFIX] [Sender: ipfix-bounces@ietf.org] Re: … Paul Aitken
- Re: [IPFIX] [Sender: ipfix-bounces@ietf.org] Re: … Gerhard Muenz
- Re: [IPFIX] [Sender: ipfix-bounces@ietf.org] Re: … Paul Aitken
- Re: [IPFIX] DRAFT IPFIX minutes from IETF 80 Brian Trammell
- Re: [IPFIX] [Sender: ipfix-bounces@ietf.org] Re: … Lothar Braun
- Re: [IPFIX] [Sender: ipfix-bounces@ietf.org] Re: … Paul Aitken
- Re: [IPFIX] [Sender: ipfix-bounces@ietf.org] Re: … Brian Trammell
- Re: [IPFIX] [Sender: ipfix-bounces@ietf.org] Re: … Gerhard Muenz
- Re: [IPFIX] [Sender: ipfix-bounces@ietf.org] Re: … Lothar Braun
- Re: [IPFIX] DRAFT IPFIX minutes from IETF 80 Benoit Claise
- Re: [IPFIX] [Sender: ipfix-bounces@ietf.org] Re: … Benoit Claise