From braun@net.in.tum.de Fri Apr 1 01:03:14 2011 Return-Path: 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 DCA003A6BFF for ; Fri, 1 Apr 2011 01:03:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.13 X-Spam-Level: X-Spam-Status: No, score=-2.13 tagged_above=-999 required=5 tests=[AWL=0.119, BAYES_00=-2.599, HELO_EQ_DE=0.35] 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 dRmuHwGsOrpJ for ; Fri, 1 Apr 2011 01:03:14 -0700 (PDT) Received: from mail-out1.informatik.tu-muenchen.de (mail-out1.informatik.tu-muenchen.de [131.159.0.8]) by core3.amsl.com (Postfix) with ESMTP id 4955B3A6837 for ; Fri, 1 Apr 2011 01:03:14 -0700 (PDT) Received: from dhcp-9227.meeting.ietf.org (unknown [130.129.10.39]) by mail.net.in.tum.de (Postfix) with ESMTPSA id 352E12096279; Fri, 1 Apr 2011 10:04:54 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: Lothar Braun In-Reply-To: <4D94DCCB.7090304@net.in.tum.de> Date: Fri, 1 Apr 2011 10:04:53 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4D94481E.6080605@auckland.ac.nz> <745A438B-855F-4659-AB36-B11D6B95213B@tik.ee.ethz.ch> <4D94DCCB.7090304@net.in.tum.de> To: Gerhard Muenz X-Mailer: Apple Mail (2.1084) Cc: IPFIX list Subject: Re: [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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Apr 2011 08:03:15 -0000 Hi Gerhard, On Mar 31, 2011, at 9:58 PM, Gerhard Muenz wrote: >>> 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." >>=20 >> 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. >=20 > 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. Oh, I haven't been aware that this has actually been implemented. Hence, = it wasn't tested at the Interop. Best regards, Lothar -- Lothar Braun Chair for Network Architectures and Services (I8) Department of Informatics Technische Universit=E4t M=FCnchen Boltzmannstr. 3, 85748 Garching bei M=FCnchen, Germany Phone: +49 89 289-18010 Fax: +49 89 289-18033 E-mail: braun@net.in.tum.de=20 From paitken@cisco.com Fri Apr 1 01:35:29 2011 Return-Path: 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 47A393A6405 for ; Fri, 1 Apr 2011 01:35:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.299 X-Spam-Level: X-Spam-Status: No, score=-10.299 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 o2wE8Ryamx8K for ; Fri, 1 Apr 2011 01:35:28 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 1A9AC3A63D2 for ; Fri, 1 Apr 2011 01:35:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=paitken@cisco.com; l=599; q=dns/txt; s=iport; t=1301647028; x=1302856628; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=JFKTb3sjdRLtrU21C5fL/N02tMPIG6/R6lRMwFYNm5Q=; b=MsFeoKU8YdsSirJnkIvm4snmoH7pqAQs1qOlTuu7F9ySHZ2R36h1nbI6 irP8PbdA3pEBJ41C17dBUAsP4D+sZ0BqNr0sdm1MVITQMwTztoJNqjd10 rSlK82x57HvnMcVdEAQ6vM471RNeTpUUqsjKopBVxcw2hX9iD8YZRyYz5 Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvkDANiNlU2Q/khMgWdsb2JhbAClWxQBARYmJYh5m0CcOoVrBI0bg1k X-IronPort-AV: E=Sophos;i="4.63,281,1299456000"; d="scan'208";a="81781899" Received: from ams-core-3.cisco.com ([144.254.72.76]) by ams-iport-1.cisco.com with ESMTP; 01 Apr 2011 08:37:07 +0000 Received: from cisco.com (mrwint.cisco.com [64.103.71.48]) by ams-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p318b7tp012327; Fri, 1 Apr 2011 08:37:07 GMT Received: from [10.61.86.236] (ams3-vpn-dhcp5869.cisco.com [10.61.86.236]) by cisco.com (8.11.7p3+Sun/8.8.8) with ESMTP id p318b6U23920; Fri, 1 Apr 2011 09:37:06 +0100 (BST) Message-ID: <4D958EB1.80808@cisco.com> Date: Fri, 01 Apr 2011 09:37:05 +0100 From: Paul Aitken User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.14) Gecko/20110223 Lightning/1.0b2 Thunderbird/3.1.8 MIME-Version: 1.0 To: Gerhard Muenz References: <4D94481E.6080605@auckland.ac.nz> <745A438B-855F-4659-AB36-B11D6B95213B@tik.ee.ethz.ch> <4D94DCCB.7090304@net.in.tum.de> In-Reply-To: <4D94DCCB.7090304@net.in.tum.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: IPFIX list Subject: Re: [IPFIX] [Sender: ipfix-bounces@ietf.org] Re: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Apr 2011 08:35:29 -0000 Gerhard, > Vermont sends Template withdrawal messages and reuses Template IDs if > you trigger an appropriate reconfiguration at runtime. Is this is transport dependant? Or do you not export over UDP? Obviously it's a bad idea to reuse template IDs when exporting over UDP. So 5101 says: If UDP is selected as the transport protocol, the Template Withdraw Messages MUST NOT be used, as this method is inefficient due to the unreliable nature of UDP. Of course "Withdraw" should be "Withdrawal" (here, and in three other places). Time for another errata. P. From wwwrun@rfc-editor.org Fri Apr 1 01:39:42 2011 Return-Path: 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 8B3153A672F for ; Fri, 1 Apr 2011 01:39:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.397 X-Spam-Level: X-Spam-Status: No, score=-102.397 tagged_above=-999 required=5 tests=[AWL=0.203, BAYES_00=-2.599, NO_RELAYS=-0.001, 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 Y7dbS6QzBQNx for ; Fri, 1 Apr 2011 01:39:41 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:1112:1::2f]) by core3.amsl.com (Postfix) with ESMTP id C78F93A65A5 for ; Fri, 1 Apr 2011 01:39:41 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 43D19E0760; Fri, 1 Apr 2011 01:41:09 -0700 (PDT) To: bclaise@cisco.com, dromasca@avaya.com, rbonica@juniper.net, n.brownlee@auckland.ac.nz, quittek@neclab.eu From: RFC Errata System Message-Id: <20110401084109.43D19E0760@rfc-editor.org> Date: Fri, 1 Apr 2011 01:41:09 -0700 (PDT) Cc: ipfix@ietf.org, rfc-editor@rfc-editor.org Subject: [IPFIX] [Editorial Errata Reported] RFC5101 (2761) X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Apr 2011 08:39:42 -0000 The following errata report has been submitted for RFC5101, "Specification of the IP Flow Information Export (IPFIX) Protocol for the Exchange of IP Traffic Flow Information". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=5101&eid=2761 -------------------------------------- Type: Editorial Reported by: Paul Aitken Section: 8 Original Text ------------- If the measurement parameters change such that a new Template is required, the Template MUST be withdrawn (using a Template Withdraw Message Corrected Text -------------- If the measurement parameters change such that a new Template is required, the Template MUST be withdrawn (using a Template Withdrawal Message Notes ----- correct "Template Withdraw Message" to "Template Withdrawal Message" per figure T and the rest of the document. Instructions: ------------- This errata is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary. -------------------------------------- RFC5101 (draft-ietf-ipfix-protocol-26) -------------------------------------- Title : Specification of the IP Flow Information Export (IPFIX) Protocol for the Exchange of IP Traffic Flow Information Publication Date : January 2008 Author(s) : B. Claise, Ed. Category : PROPOSED STANDARD Source : IP Flow Information Export Area : Operations and Management Stream : IETF Verifying Party : IESG From wwwrun@rfc-editor.org Fri Apr 1 01:41:08 2011 Return-Path: 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 DBCB03A63EB for ; Fri, 1 Apr 2011 01:41:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.399 X-Spam-Level: X-Spam-Status: No, score=-102.399 tagged_above=-999 required=5 tests=[AWL=0.201, BAYES_00=-2.599, NO_RELAYS=-0.001, 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 V3p5s8mUqDce for ; Fri, 1 Apr 2011 01:41:08 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:1112:1::2f]) by core3.amsl.com (Postfix) with ESMTP id 098A93A63CB for ; Fri, 1 Apr 2011 01:41:08 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 8E479E0760; Fri, 1 Apr 2011 01:42:35 -0700 (PDT) To: bclaise@cisco.com, dromasca@avaya.com, rbonica@juniper.net, n.brownlee@auckland.ac.nz, quittek@neclab.eu From: RFC Errata System Message-Id: <20110401084235.8E479E0760@rfc-editor.org> Date: Fri, 1 Apr 2011 01:42:35 -0700 (PDT) Cc: ipfix@ietf.org, rfc-editor@rfc-editor.org Subject: [IPFIX] [Editorial Errata Reported] RFC5101 (2762) X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Apr 2011 08:41:09 -0000 The following errata report has been submitted for RFC5101, "Specification of the IP Flow Information Export (IPFIX) Protocol for the Exchange of IP Traffic Flow Information". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=5101&eid=2762 -------------------------------------- Type: Editorial Reported by: Paul Aitken Section: 8 Original Text ------------- If the Metering Process restarts, the Exporting Process MUST either reuse the previously assigned Template ID for each Template, or it MUST withdraw the previously issued Template IDs by sending Template Withdraw Message(s) before reusing them. Corrected Text -------------- If the Metering Process restarts, the Exporting Process MUST either reuse the previously assigned Template ID for each Template, or it MUST withdraw the previously issued Template IDs by sending Template Withdrawal Message(s) before reusing them. Notes ----- Correct "Template Withdraw Message" to "Template Withdrawal Message" per figure T and the rest of the document. Instructions: ------------- This errata is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary. -------------------------------------- RFC5101 (draft-ietf-ipfix-protocol-26) -------------------------------------- Title : Specification of the IP Flow Information Export (IPFIX) Protocol for the Exchange of IP Traffic Flow Information Publication Date : January 2008 Author(s) : B. Claise, Ed. Category : PROPOSED STANDARD Source : IP Flow Information Export Area : Operations and Management Stream : IETF Verifying Party : IESG From wwwrun@rfc-editor.org Fri Apr 1 01:42:46 2011 Return-Path: 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 827B23A63D2 for ; Fri, 1 Apr 2011 01:42:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.401 X-Spam-Level: X-Spam-Status: No, score=-102.401 tagged_above=-999 required=5 tests=[AWL=0.199, BAYES_00=-2.599, NO_RELAYS=-0.001, 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 KKvbfQphPnnR for ; Fri, 1 Apr 2011 01:42:45 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:1112:1::2f]) by core3.amsl.com (Postfix) with ESMTP id 978933A63CB for ; Fri, 1 Apr 2011 01:42:45 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 29DB4E0760; Fri, 1 Apr 2011 01:44:13 -0700 (PDT) To: bclaise@cisco.com, dromasca@avaya.com, rbonica@juniper.net, n.brownlee@auckland.ac.nz, quittek@neclab.eu From: RFC Errata System Message-Id: <20110401084413.29DB4E0760@rfc-editor.org> Date: Fri, 1 Apr 2011 01:44:13 -0700 (PDT) Cc: ipfix@ietf.org, rfc-editor@rfc-editor.org Subject: [IPFIX] [Editorial Errata Reported] RFC5101 (2763) X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Apr 2011 08:42:46 -0000 The following errata report has been submitted for RFC5101, "Specification of the IP Flow Information Export (IPFIX) Protocol for the Exchange of IP Traffic Flow Information". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=5101&eid=2763 -------------------------------------- Type: Editorial Reported by: Paul Aitken Section: 9 Original Text ------------- If the Collecting Process receives a Template Withdraw message Corrected Text -------------- If the Collecting Process receives a Template Withdrawal message Notes ----- Correct "Template Withdraw Message" to "Template Withdrawal Message" per figure T and the rest of the document. Instructions: ------------- This errata is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary. -------------------------------------- RFC5101 (draft-ietf-ipfix-protocol-26) -------------------------------------- Title : Specification of the IP Flow Information Export (IPFIX) Protocol for the Exchange of IP Traffic Flow Information Publication Date : January 2008 Author(s) : B. Claise, Ed. Category : PROPOSED STANDARD Source : IP Flow Information Export Area : Operations and Management Stream : IETF Verifying Party : IESG From wwwrun@rfc-editor.org Fri Apr 1 01:44:13 2011 Return-Path: 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 E9DD43A63D2 for ; Fri, 1 Apr 2011 01:44:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.402 X-Spam-Level: X-Spam-Status: No, score=-102.402 tagged_above=-999 required=5 tests=[AWL=0.198, BAYES_00=-2.599, NO_RELAYS=-0.001, 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 ZbsRY3io58nS for ; Fri, 1 Apr 2011 01:44:13 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:1112:1::2f]) by core3.amsl.com (Postfix) with ESMTP id 3C7CC3A63CB for ; Fri, 1 Apr 2011 01:44:13 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id BB686E0760; Fri, 1 Apr 2011 01:45:40 -0700 (PDT) To: bclaise@cisco.com, dromasca@avaya.com, rbonica@juniper.net, n.brownlee@auckland.ac.nz, quittek@neclab.eu From: RFC Errata System Message-Id: <20110401084540.BB686E0760@rfc-editor.org> Date: Fri, 1 Apr 2011 01:45:40 -0700 (PDT) Cc: ipfix@ietf.org, rfc-editor@rfc-editor.org Subject: [IPFIX] [Editorial Errata Reported] RFC5101 (2764) X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Apr 2011 08:44:14 -0000 The following errata report has been submitted for RFC5101, "Specification of the IP Flow Information Export (IPFIX) Protocol for the Exchange of IP Traffic Flow Information". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=5101&eid=2764 -------------------------------------- Type: Editorial Reported by: Paul Aitken Section: 10.3.6 Original Text ------------- If UDP is selected as the transport protocol, the Template Withdraw Messages MUST NOT be used, as this method is inefficient due to the unreliable nature of UDP. Corrected Text -------------- If UDP is selected as the transport protocol, the Template Withdrawal Messages MUST NOT be used, as this method is inefficient due to the unreliable nature of UDP. Notes ----- Correct "Template Withdraw Message" to "Template Withdrawal Message" per figure T and the rest of the document. Instructions: ------------- This errata is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary. -------------------------------------- RFC5101 (draft-ietf-ipfix-protocol-26) -------------------------------------- Title : Specification of the IP Flow Information Export (IPFIX) Protocol for the Exchange of IP Traffic Flow Information Publication Date : January 2008 Author(s) : B. Claise, Ed. Category : PROPOSED STANDARD Source : IP Flow Information Export Area : Operations and Management Stream : IETF Verifying Party : IESG From muenz@net.in.tum.de Fri Apr 1 02:14:00 2011 Return-Path: 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 855CA3A6774 for ; Fri, 1 Apr 2011 02:14:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35] 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 kqzP3l04tQNO for ; Fri, 1 Apr 2011 02:14:00 -0700 (PDT) Received: from mail-out1.informatik.tu-muenchen.de (mail-out1.informatik.tu-muenchen.de [131.159.0.8]) by core3.amsl.com (Postfix) with ESMTP id CBD373A66B4 for ; Fri, 1 Apr 2011 02:13:59 -0700 (PDT) Received: by mail.net.in.tum.de (Postfix, from userid 81) id CC30A2096279; Fri, 1 Apr 2011 11:15:39 +0200 (CEST) To: Paul Aitken X-PHP-Originating-Script: 0:func.inc MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Date: Fri, 01 Apr 2011 11:15:39 +0200 From: Gerhard Muenz In-Reply-To: <4D958EB1.80808@cisco.com> References: "<4D94481E.6080605@auckland.ac.nz>" <745A438B-855F-4659-AB36-B11D6B95213B@tik.ee.ethz.ch> <4D94DCCB.7090304@net.in.tum.de> <4D958EB1.80808@cisco.com> Message-ID: <4a4450c41a799b3fa5d28e618706c86f@net.in.tum.de> X-Sender: muenz@net.in.tum.de User-Agent: Roundcube Webmail/0.5.1 Cc: IPFIX list Subject: Re: [IPFIX] [Sender: ipfix-bounces@ietf.org] Re: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Apr 2011 09:14:00 -0000 Paul, On Fri, 01 Apr 2011 09:37:05 +0100, Paul Aitken wrote: > Gerhard, > >> Vermont sends Template withdrawal messages and reuses Template IDs >> if you trigger an appropriate reconfiguration at runtime. > > Is this is transport dependant? Or do you not export over UDP? As defined in the standard, Vermont only sends Withdrawal Messages if SCTP is transport protocol, not with UDP (Vermont does not support TCP on the Exporter side). > Obviously it's a bad idea to reuse template IDs when exporting over > UDP. > > So 5101 says: > > If UDP is selected as the transport protocol, the Template > Withdraw > Messages MUST NOT be used, as this method is inefficient due to > the > unreliable nature of UDP. > > > Of course "Withdraw" should be "Withdrawal" (here, and in three other > places). Time for another errata. Good catch. Maybe this is the reason why I'm always unsure whether to say Withdraw or Withdrawal :) Regards, Gerhard From paitken@cisco.com Fri Apr 1 02:32:11 2011 Return-Path: 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 0C7CB3A67B3 for ; Fri, 1 Apr 2011 02:32:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.374 X-Spam-Level: X-Spam-Status: No, score=-10.374 tagged_above=-999 required=5 tests=[AWL=0.225, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 G8ataMT7V4zB for ; Fri, 1 Apr 2011 02:32:10 -0700 (PDT) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by core3.amsl.com (Postfix) with ESMTP id EBA963A67A6 for ; Fri, 1 Apr 2011 02:32:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=paitken@cisco.com; l=1373; q=dns/txt; s=iport; t=1301650430; x=1302860030; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=VUdPa4ztRkmZrLppQHvDRzjKGn3lma+Mqz55uLP072c=; b=L5y35JMujSb0HWOfJHg49CUAJDSsaTD3H6vC6txvDx1xsJTjlrCUAaWh 6PxIGJkeYlFbbLEcDM8Fx687MuTYKBUQEqo807YDpQ3bAfE5ClYjBbdto +cfsFRrOglc+H2qav2HXJpu7hadPAUoPXv5X6zzQFFFsLUJRV9jJeMqEV w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvoDADKblU2Q/khMgWdsb2JhbACER6EVFAEBFiYliHmbcIs+kQGBKINMdwSNG4NZ X-IronPort-AV: E=Sophos;i="4.63,281,1299456000"; d="scan'208";a="24084325" Received: from ams-core-3.cisco.com ([144.254.72.76]) by ams-iport-2.cisco.com with ESMTP; 01 Apr 2011 09:33:49 +0000 Received: from cisco.com (mrwint.cisco.com [64.103.71.48]) by ams-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p319Xn7u032667; Fri, 1 Apr 2011 09:33:49 GMT Received: from [10.61.86.236] (ams3-vpn-dhcp5869.cisco.com [10.61.86.236]) by cisco.com (8.11.7p3+Sun/8.8.8) with ESMTP id p319XmU29613; Fri, 1 Apr 2011 10:33:48 +0100 (BST) Message-ID: <4D959BFA.2080203@cisco.com> Date: Fri, 01 Apr 2011 10:33:46 +0100 From: Paul Aitken User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.14) Gecko/20110223 Lightning/1.0b2 Thunderbird/3.1.8 MIME-Version: 1.0 To: Gerhard Muenz References: "<4D94481E.6080605@auckland.ac.nz>" <745A438B-855F-4659-AB36-B11D6B95213B@tik.ee.ethz.ch> <4D94DCCB.7090304@net.in.tum.de> <4D958EB1.80808@cisco.com> <4a4450c41a799b3fa5d28e618706c86f@net.in.tum.de> In-Reply-To: <4a4450c41a799b3fa5d28e618706c86f@net.in.tum.de> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: IPFIX list Subject: Re: [IPFIX] [Sender: ipfix-bounces@ietf.org] Re: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Apr 2011 09:32:11 -0000 Gerhard, > Paul, > > On Fri, 01 Apr 2011 09:37:05 +0100, Paul Aitken wrote: >> Gerhard, >> >>> Vermont sends Template withdrawal messages and reuses Template IDs >>> if you trigger an appropriate reconfiguration at runtime. >> >> Is this is transport dependant? Or do you not export over UDP? > > As defined in the standard, Vermont only sends Withdrawal Messages if > SCTP is transport protocol, not with UDP (Vermont does not support TCP > on the Exporter side). Right. However, my question was whether Vermont re-uses Template IDs only for SCTP and not for UDP. It seems you'd need special case code for that. What benefits do you see in re-using template IDs rather than taking a new ID? >> Obviously it's a bad idea to reuse template IDs when exporting over UDP. >> >> So 5101 says: >> >> If UDP is selected as the transport protocol, the Template Withdraw >> Messages MUST NOT be used, as this method is inefficient due to the >> unreliable nature of UDP. >> >> >> Of course "Withdraw" should be "Withdrawal" (here, and in three other >> places). Time for another errata. > > Good catch. Maybe this is the reason why I'm always unsure whether to > say Withdraw or Withdrawal :) Apparently "withdraw" is the verb ("withdraw a Template") whereas "withdrawal" is a noun ("Template withdrawal Message"). P. From trammell@tik.ee.ethz.ch Fri Apr 1 02:33:34 2011 Return-Path: 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 A8B893A67A4 for ; Fri, 1 Apr 2011 02:33:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.532 X-Spam-Level: X-Spam-Status: No, score=-6.532 tagged_above=-999 required=5 tests=[AWL=0.067, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 1xrv8ci1gYnS for ; Fri, 1 Apr 2011 02:33:34 -0700 (PDT) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) by core3.amsl.com (Postfix) with ESMTP id D10713A67B3 for ; Fri, 1 Apr 2011 02:33:33 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id A2A47D9367; Fri, 1 Apr 2011 11:35:13 +0200 (MEST) X-Virus-Scanned: by amavisd-new on smtp.ee.ethz.ch Received: from smtp.ee.ethz.ch ([127.0.0.1]) by localhost (.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with LMTP id PUsOpFKgXCBD; Fri, 1 Apr 2011 11:35:13 +0200 (MEST) Received: from dhcp-43c4.meeting.ietf.org (dhcp-43c4.meeting.ietf.org [130.129.67.196]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: briant) by smtp.ee.ethz.ch (Postfix) with ESMTPSA id A97D7D9360; Fri, 1 Apr 2011 11:35:07 +0200 (MEST) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=iso-8859-1 From: Brian Trammell In-Reply-To: Date: Fri, 1 Apr 2011 11:34:56 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <1FBCEC70-589C-478B-BD46-599155C813B9@tik.ee.ethz.ch> References: <4D94481E.6080605@auckland.ac.nz> <745A438B-855F-4659-AB36-B11D6B95213B@tik.ee.ethz.ch> <4D94DCCB.7090304@net.in.tum.de> To: Lothar Braun X-Mailer: Apple Mail (2.1082) Cc: IPFIX list Subject: Re: [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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Apr 2011 09:33:34 -0000 hi, Lothar, Gerhard, That would explain it. :) ripfix, at least, should be able to collect this in the release sitting = on the floor of my home directory (again, once I squash some UDP bugs); = we can set up an ad hoc interop test at some point in the near future. Cheers, Brian On Apr 1, 2011, at 10:04 AM, Lothar Braun wrote: > Hi Gerhard, >=20 > On Mar 31, 2011, at 9:58 PM, Gerhard Muenz wrote: >>>> 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." >>>=20 >>> 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. >>=20 >> 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. >=20 >=20 > Oh, I haven't been aware that this has actually been implemented. = Hence, it wasn't tested at the Interop. >=20 > Best regards, > Lothar >=20 > -- > Lothar Braun > Chair for Network Architectures and Services (I8) > Department of Informatics > Technische Universit=E4t M=FCnchen > Boltzmannstr. 3, 85748 Garching bei M=FCnchen, Germany > Phone: +49 89 289-18010 Fax: +49 89 289-18033 > E-mail: braun@net.in.tum.de=20 >=20 >=20 >=20 >=20 >=20 From braun@net.in.tum.de Fri Apr 1 02:44:04 2011 Return-Path: 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 94E283A6781 for ; Fri, 1 Apr 2011 02:44:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.16 X-Spam-Level: X-Spam-Status: No, score=-2.16 tagged_above=-999 required=5 tests=[AWL=0.089, BAYES_00=-2.599, HELO_EQ_DE=0.35] 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 xzkEGAulXY4t for ; Fri, 1 Apr 2011 02:44:04 -0700 (PDT) Received: from mail-out1.informatik.tu-muenchen.de (mail-out1.informatik.tu-muenchen.de [131.159.0.8]) by core3.amsl.com (Postfix) with ESMTP id F0C873A63C9 for ; Fri, 1 Apr 2011 02:44:03 -0700 (PDT) Received: from dhcp-9227.meeting.ietf.org (unknown [130.129.10.39]) by mail.net.in.tum.de (Postfix) with ESMTPSA id C7A652096193; Fri, 1 Apr 2011 11:45:43 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: Lothar Braun In-Reply-To: <4D959BFA.2080203@cisco.com> Date: Fri, 1 Apr 2011 11:45:28 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: "<4D94481E.6080605@auckland.ac.nz>" <745A438B-855F-4659-AB36-B11D6B95213B@tik.ee.ethz.ch> <4D94DCCB.7090304@net.in.tum.de> <4D958EB1.80808@cisco.com> <4a4450c41a799b3fa5d28e618706c86f@net.in.tum.de> <4D959BFA.2080203@cisco.com> To: Paul Aitken X-Mailer: Apple Mail (2.1084) Cc: IPFIX list Subject: Re: [IPFIX] [Sender: ipfix-bounces@ietf.org] Re: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Apr 2011 09:44:04 -0000 Hi Paul, On Apr 1, 2011, at 11:33 AM, Paul Aitken wrote: >> On Fri, 01 Apr 2011 09:37:05 +0100, Paul Aitken wrote: >>> Gerhard, >>>=20 >>>> Vermont sends Template withdrawal messages and reuses Template IDs = if you trigger an appropriate reconfiguration at runtime. >>>=20 >>> Is this is transport dependant? Or do you not export over UDP? >>=20 >> As defined in the standard, Vermont only sends Withdrawal Messages if = SCTP is transport protocol, not with UDP (Vermont does not support TCP = on the Exporter side). >=20 > Right. However, my question was whether Vermont re-uses Template IDs = only for SCTP and not for UDP. > It seems you'd need special case code for that. > What benefits do you see in re-using template IDs rather than taking a = new ID? Template IDs in Vermont are configured by the user, and not chosen = automatically at run time by the probe. Vermont therefore tries to reuse = Template IDs on reconfiguration if the same ID is configured in the new = config file. Reconfiguring a SCTP Exporter will trigger a Template Withdrawal = Message, reconfiguring an UDP Exporter will result in the creation of a = new Transport Session. Best regards, Lothar=20 -- Lothar Braun Chair for Network Architectures and Services (I8) Department of Informatics Technische Universit=E4t M=FCnchen Boltzmannstr. 3, 85748 Garching bei M=FCnchen, Germany Phone: +49 89 289-18010 Fax: +49 89 289-18033 E-mail: braun@net.in.tum.de=20 From paitken@cisco.com Fri Apr 1 04:06:37 2011 Return-Path: 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 0750D3A67F3 for ; Fri, 1 Apr 2011 04:06:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.419 X-Spam-Level: X-Spam-Status: No, score=-10.419 tagged_above=-999 required=5 tests=[AWL=0.180, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 TNCsVqOLvZtU for ; Fri, 1 Apr 2011 04:06:36 -0700 (PDT) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by core3.amsl.com (Postfix) with ESMTP id E2C483A67F1 for ; Fri, 1 Apr 2011 04:06:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=paitken@cisco.com; l=1287; q=dns/txt; s=iport; t=1301656096; x=1302865696; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=anLoI4r9t0Ka8NJPsDaEWeVyIjmC2/xjnX46KQCf5JQ=; b=EX2WbmftyEqlllbJJPlPoyg4x54vqs0NlJsHvIYt3RK4KRBtCueBZh3w hA8PwHe+QlcC1+JIOe3iUepKzMSrRKwy0K85/eR8WvY/kPD38GQ3Wn/sM 53TOcFMbhcvi8naG176lbhMM8u50bXz3UomRK1/kbih2BsYdV8bpe+FH8 Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvkDAIKxlU2Q/khLgWdsb2JhbAClXRQBARYmJYh5nFScQoVrBI0bg1k X-IronPort-AV: E=Sophos;i="4.63,281,1299456000"; d="scan'208";a="24098546" Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-2.cisco.com with ESMTP; 01 Apr 2011 11:08:15 +0000 Received: from cisco.com (mrwint.cisco.com [64.103.71.48]) by ams-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p31B8FO1029986; Fri, 1 Apr 2011 11:08:15 GMT Received: from [10.61.86.236] (ams3-vpn-dhcp5869.cisco.com [10.61.86.236]) by cisco.com (8.11.7p3+Sun/8.8.8) with ESMTP id p31B8EU06799; Fri, 1 Apr 2011 12:08:14 +0100 (BST) Message-ID: <4D95B21D.7020504@cisco.com> Date: Fri, 01 Apr 2011 12:08:13 +0100 From: Paul Aitken User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.14) Gecko/20110223 Lightning/1.0b2 Thunderbird/3.1.8 MIME-Version: 1.0 To: Lothar Braun References: "<4D94481E.6080605@auckland.ac.nz>" <745A438B-855F-4659-AB36-B11D6B95213B@tik.ee.ethz.ch> <4D94DCCB.7090304@net.in.tum.de> <4D958EB1.80808@cisco.com> <4a4450c41a799b3fa5d28e618706c86f@net.in.tum.de> <4D959BFA.2080203@cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: IPFIX list Subject: Re: [IPFIX] [Sender: ipfix-bounces@ietf.org] Re: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Apr 2011 11:06:37 -0000 Lothar, > Template IDs in Vermont are configured by the user, and not chosen > automatically at run time by the probe. I'm surprised, since I consider Template IDs to be an internal part of the protocol which should be invisible to users. I see a potential danger: that users come to expect a certain template ID = specific content. eg, suppose Vermont exports Template ID #260 which contains IPv6 fields, so they configure their collector to expect #260 = IPv6. However, other exporters use different (and perhaps unpredictable) Template IDs when sending the same content. eg, the next available ID when the template is created. They might wonder how to make those exporters send template #260. They might even point to the IPFIX RFCs which show specific template IDs in the examples... I think this would be against the spirit of IPFIX, though I can't point to anything specific in the RFCs. > Vermont therefore tries to reuse Template IDs on reconfiguration if > the same ID is configured in the new config file. > > Reconfiguring a SCTP Exporter will trigger a Template Withdrawal > Message, reconfiguring an UDP Exporter will result in the creation > of a new Transport Session. ie, a new port will be selected? Thanks, P. From trammell@tik.ee.ethz.ch Fri Apr 1 04:18:38 2011 Return-Path: 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 9D69D3A6808 for ; Fri, 1 Apr 2011 04:18:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.539 X-Spam-Level: X-Spam-Status: No, score=-6.539 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 1bmHY7gsN8H3 for ; Fri, 1 Apr 2011 04:18:37 -0700 (PDT) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) by core3.amsl.com (Postfix) with ESMTP id 97F323A67F3 for ; Fri, 1 Apr 2011 04:18:37 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id 2028ED9360; Fri, 1 Apr 2011 13:20:17 +0200 (MEST) X-Virus-Scanned: by amavisd-new on smtp.ee.ethz.ch Received: from smtp.ee.ethz.ch ([127.0.0.1]) by localhost (.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with LMTP id Rr8hysxTPmMo; Fri, 1 Apr 2011 13:20:16 +0200 (MEST) Received: from dhcp-43c4.meeting.ietf.org (dhcp-43c4.meeting.ietf.org [130.129.67.196]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: briant) by smtp.ee.ethz.ch (Postfix) with ESMTPSA id 71C20D932A; Fri, 1 Apr 2011 13:20:16 +0200 (MEST) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Brian Trammell In-Reply-To: <4D958EB1.80808@cisco.com> Date: Fri, 1 Apr 2011 13:20:15 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <2325CBCF-7A37-4DD6-9425-D30BF0337478@tik.ee.ethz.ch> References: <4D94481E.6080605@auckland.ac.nz> <745A438B-855F-4659-AB36-B11D6B95213B@tik.ee.ethz.ch> <4D94DCCB.7090304@net.in.tum.de> <4D958EB1.80808@cisco.com> To: Paul Aitken X-Mailer: Apple Mail (2.1082) Cc: IPFIX list Subject: Re: [IPFIX] [Sender: ipfix-bounces@ietf.org] Re: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Apr 2011 11:18:38 -0000 Hi, Paul, all,=20 You can reuse templates in UDP after they expire. Theoretically. I would suggest in 5101bis (assuming there is such a thing) that we = remove the prohibition on sending withdrawals on UDP. Agreed that = withdrawals are useless on UDP -- templates simply get replaced anyway, = and expire according to rules involving the phase of the moon and the = casting of runes. The CP can't do anything sensible anyway if it gets a = withdrawal on UDP, so it might as well try to follow the same rules as = everywhere else. Indeed, I think it's probably possible to define new set of template = management rules that 1. interoperates with 5101 (aside from CP resets, = which are a bad idea anyway) and 2. allows a single universal policy = without regard to transport. I'll put some thought into this. Best regards, Brian On Apr 1, 2011, at 10:37 AM, Paul Aitken wrote: > Gerhard, >=20 >> Vermont sends Template withdrawal messages and reuses Template IDs if = you trigger an appropriate reconfiguration at runtime. >=20 > Is this is transport dependant? Or do you not export over UDP? >=20 > Obviously it's a bad idea to reuse template IDs when exporting over = UDP. >=20 > So 5101 says: >=20 > If UDP is selected as the transport protocol, the Template Withdraw > Messages MUST NOT be used, as this method is inefficient due to the > unreliable nature of UDP. >=20 >=20 > Of course "Withdraw" should be "Withdrawal" (here, and in three other = places). Time for another errata. >=20 > P. From muenz@net.in.tum.de Fri Apr 1 04:20:47 2011 Return-Path: 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 0BC0C3A67FA for ; Fri, 1 Apr 2011 04:20:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35] 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 hApkjVAiYLjV for ; Fri, 1 Apr 2011 04:20:46 -0700 (PDT) Received: from mail-out1.informatik.tu-muenchen.de (mail-out1.informatik.tu-muenchen.de [131.159.0.8]) by core3.amsl.com (Postfix) with ESMTP id 263763A67F3 for ; Fri, 1 Apr 2011 04:20:44 -0700 (PDT) Received: by mail.net.in.tum.de (Postfix, from userid 81) id 310912096279; Fri, 1 Apr 2011 13:22:24 +0200 (CEST) To: Lothar Braun X-PHP-Originating-Script: 0:func.inc MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Date: Fri, 01 Apr 2011 13:22:24 +0200 From: Gerhard Muenz In-Reply-To: References: "<4D94481E.6080605@auckland.ac.nz>" <745A438B-855F-4659-AB36-B11D6B95213B@tik.ee.ethz.ch> <4D94DCCB.7090304@net.in.tum.de> <4D958EB1.80808@cisco.com> <4a4450c41a799b3fa5d28e618706c86f@net.in.tum.de> <4D959BFA.2080203@cisco.com> Message-ID: X-Sender: muenz@net.in.tum.de User-Agent: Roundcube Webmail/0.5.1 Cc: IPFIX list Subject: Re: [IPFIX] [Sender: ipfix-bounces@ietf.org] Re: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Apr 2011 11:20:47 -0000 Hi Paul, Lothar On Fri, 1 Apr 2011 11:45:28 +0200, Lothar Braun wrote: > On Apr 1, 2011, at 11:33 AM, Paul Aitken wrote: >>> On Fri, 01 Apr 2011 09:37:05 +0100, Paul Aitken wrote: >>>> Gerhard, >>>> >>>>> Vermont sends Template withdrawal messages and reuses Template >>>>> IDs if you trigger an appropriate reconfiguration at runtime. >>>> >>>> Is this is transport dependant? Or do you not export over UDP? >>> >>> As defined in the standard, Vermont only sends Withdrawal Messages >>> if SCTP is transport protocol, not with UDP (Vermont does not support >>> TCP on the Exporter side). >> >> Right. However, my question was whether Vermont re-uses Template IDs >> only for SCTP and not for UDP. >> It seems you'd need special case code for that. >> What benefits do you see in re-using template IDs rather than taking >> a new ID? > > > Template IDs in Vermont are configured by the user, and not chosen > automatically at run time by the probe. Vermont therefore tries to > reuse Template IDs on reconfiguration if the same ID is configured in > the new config file. Vermont's behavior is a bit more comlex than that :) 1) The user is not required to configure a Template ID (although he was some time ago). 2) If the user configures a Template ID which does not conflict with any another Template exported by the same Exporting Process, then Vermont will use this configured Template ID. Otherwise, the Exporting Process overwrites the configured ID with another ID in order to resolve the conflict. > Reconfiguring a SCTP Exporter will trigger a Template Withdrawal > Message, reconfiguring an UDP Exporter will result in the creation of > a new Transport Session. If I remember correctly Vermont tries to be polite to the Collector by sending Withdrawal messages before shutting down a SCTP Transport Session (although this is not required by the standard). Regards, Gerhard From braun@net.in.tum.de Fri Apr 1 04:39:18 2011 Return-Path: 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 2D0ED3A680E for ; Fri, 1 Apr 2011 04:39:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.178 X-Spam-Level: X-Spam-Status: No, score=-2.178 tagged_above=-999 required=5 tests=[AWL=0.071, BAYES_00=-2.599, HELO_EQ_DE=0.35] 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 e1PgXofYw1tV for ; Fri, 1 Apr 2011 04:39:14 -0700 (PDT) Received: from mail-out1.informatik.tu-muenchen.de (mail-out1.informatik.tu-muenchen.de [131.159.0.8]) by core3.amsl.com (Postfix) with ESMTP id 459723A6805 for ; Fri, 1 Apr 2011 04:39:14 -0700 (PDT) Received: from dhcp-9227.meeting.ietf.org (unknown [130.129.10.39]) by mail.net.in.tum.de (Postfix) with ESMTPSA id D9E372096279; Fri, 1 Apr 2011 13:40:39 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: Lothar Braun In-Reply-To: Date: Fri, 1 Apr 2011 13:40:38 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: "<4D94481E.6080605@auckland.ac.nz>" <745A438B-855F-4659-AB36-B11D6B95213B@tik.ee.ethz.ch> <4D94DCCB.7090304@net.in.tum.de> <4D958EB1.80808@cisco.com> <4a4450c41a799b3fa5d28e618706c86f@net.in.tum.de> <4D959BFA.2080203@cisco.com> To: Gerhard Muenz X-Mailer: Apple Mail (2.1084) Cc: IPFIX list Subject: Re: [IPFIX] [Sender: ipfix-bounces@ietf.org] Re: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Apr 2011 11:39:18 -0000 On Apr 1, 2011, at 1:22 PM, Gerhard Muenz wrote: > Hi Paul, Lothar >=20 > On Fri, 1 Apr 2011 11:45:28 +0200, Lothar Braun wrote: >> On Apr 1, 2011, at 11:33 AM, Paul Aitken wrote: >>>> On Fri, 01 Apr 2011 09:37:05 +0100, Paul Aitken wrote: >>>>> Gerhard, >>>>>=20 >>>>>> Vermont sends Template withdrawal messages and reuses Template = IDs if you trigger an appropriate reconfiguration at runtime. >>>>>=20 >>>>> Is this is transport dependant? Or do you not export over UDP? >>>>=20 >>>> As defined in the standard, Vermont only sends Withdrawal Messages = if SCTP is transport protocol, not with UDP (Vermont does not support = TCP on the Exporter side). >>>=20 >>> Right. However, my question was whether Vermont re-uses Template IDs = only for SCTP and not for UDP. >>> It seems you'd need special case code for that. >>> What benefits do you see in re-using template IDs rather than taking = a new ID? >>=20 >>=20 >> Template IDs in Vermont are configured by the user, and not chosen >> automatically at run time by the probe. Vermont therefore tries to >> reuse Template IDs on reconfiguration if the same ID is configured in >> the new config file. >=20 > Vermont's behavior is a bit more comlex than that :) > 1) The user is not required to configure a Template ID (although he = was some time ago). > 2) If the user configures a Template ID which does not conflict with = any another Template exported by the same Exporting Process, then = Vermont will use this configured Template ID. Otherwise, the Exporting = Process overwrites the configured ID with another ID in order to resolve = the conflict. >> Reconfiguring a SCTP Exporter will trigger a Template Withdrawal >> Message, reconfiguring an UDP Exporter will result in the creation of >> a new Transport Session. >=20 > If I remember correctly Vermont tries to be polite to the Collector by = sending Withdrawal messages before shutting down a SCTP Transport = Session (although this is not required by the standard). Yes, vermont will send a Withdrawal message before shutting down the = connection. Best regards, Lothar -- Lothar Braun Chair for Network Architectures and Services (I8) Department of Informatics Technische Universit=E4t M=FCnchen Boltzmannstr. 3, 85748 Garching bei M=FCnchen, Germany Phone: +49 89 289-18010 Fax: +49 89 289-18033 E-mail: braun@net.in.tum.de=20 From andrewf@plixer.com Fri Apr 1 06:53:06 2011 Return-Path: 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 EC6233A67FA for ; Fri, 1 Apr 2011 06:53:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_53=0.6] 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 ccPu67sbJb2r for ; Fri, 1 Apr 2011 06:53:05 -0700 (PDT) Received: from smtp.plixer.com (smtp.plixer.com [66.186.184.193]) by core3.amsl.com (Postfix) with ESMTP id 88EA13A67FC for ; Fri, 1 Apr 2011 06:53:05 -0700 (PDT) Received: from [10.1.15.20] ([66.186.184.173]) by smtp.plixer.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 1 Apr 2011 09:54:45 -0400 Message-ID: <4D95D924.9010001@plixer.com> Date: Fri, 01 Apr 2011 09:54:44 -0400 From: Andrew Feren User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.15pre) Gecko/20110207 Lightning/1.0b2 Shredder/3.1.9pre MIME-Version: 1.0 To: Brian Trammell References: <3D5C83BC-E710-44FB-8D18-66FD1BF75437@cert.org> <4D949807.2000503@plixer.com> <31D0F166-112B-4BD4-98F7-7AE09BE2F4FE@tik.ee.ethz.ch> In-Reply-To: <31D0F166-112B-4BD4-98F7-7AE09BE2F4FE@tik.ee.ethz.ch> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 01 Apr 2011 13:54:45.0554 (UTC) FILETIME=[5BB34920:01CBF074] Cc: ipfix@ietf.org Subject: Re: [IPFIX] some comments on IANA IPFIX XML X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Apr 2011 13:53:07 -0000 On 03/31/2011 01:15 PM, Brian Trammell wrote: > hi, Andrew, all, > > On Mar 31, 2011, at 5:04 PM, Andrew Feren wrote: > >> On 03/31/2011 10:44 AM, Chris Inacio wrote: >>> It would be really great to wrap the record entries (defined in ipfix.xsd, each record represents an IE,) within another record which records a PEN - so that people can publish their PEN's in a standard way. >> This would be great. A registry of all the info elements above 37,768 that have been taken by vendors trying to extend v9 would be nice too. > It's up to each enterprise, of course, to determine which, whether, and how to make information about their enterprise-specific IEs (esIEs) available. I know that YAF's IEs (including esIEs) exported in PEN 6871 are documented on a manpage (http://tools.netsa.cert.org/yaf/yaf.html#OUTPUT), for example. Understood. I still think it would be useful to have a central (easily found) location where vendors could chose to make information about their enterprise specific IEs available. Consider RFC 3954 which states: " Refer to the latest documentation at http://www.cisco.com for the newly updated list." There are, in fact, many updates available there, but good luck finding them if you don't already know they exist and exactly where to find them. For IPFIX this problem is even worse. Essentially "Refer to the latest documentation on any possible vendor site for the updated list of vendor specific IEs". > FWIW, IANA's schema does have an element for describing esIEs. Though the xsl that makes their webpage doesn't appear to use it. I'm pleased to hear that it may at least be possible. >> On a related note... Is anyone implementing rfc5610? > There will be scantily-documented initial support for this in the working revision of ripfix, which requires some API interaction to make it work. I'll release this as soon as I track down the last bugs in UDP export. Thanks for the tip. -Andrew From bclaise@cisco.com Mon Apr 4 00:58:13 2011 Return-Path: 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 087A33A6936 for ; Mon, 4 Apr 2011 00:58:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.622 X-Spam-Level: X-Spam-Status: No, score=-2.622 tagged_above=-999 required=5 tests=[AWL=-0.023, BAYES_00=-2.599] 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 WI3c0oNgBiVm for ; Mon, 4 Apr 2011 00:58:06 -0700 (PDT) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by core3.amsl.com (Postfix) with ESMTP id B9C313A692F for ; Mon, 4 Apr 2011 00:58:05 -0700 (PDT) X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id p347xl5u015318; Mon, 4 Apr 2011 09:59:47 +0200 (CEST) Received: from [10.55.43.51] (ams-bclaise-8712.cisco.com [10.55.43.51]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id p347xkVQ004823; Mon, 4 Apr 2011 09:59:47 +0200 (CEST) Message-ID: <4D997A72.40608@cisco.com> Date: Mon, 04 Apr 2011 09:59:46 +0200 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: Brian Trammell References: <4D91D859.6050407@cisco.com> <4D920A05.5020103@cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: IETF IPFIX Working Group Subject: Re: [IPFIX] modifying existing IEs X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Apr 2011 07:58:13 -0000 On 30/03/2011 10:20, Brian Trammell wrote: > Hi, Paul, > > a couple of points inline... > > On Mar 29, 2011, at 6:34 PM, Paul Aitken wrote: > >> Brian, >> >>> This was a point on the open >> issues slide, but was trying to speed >> >> >> > through things today so it got missed... >> >> >> > >> >> >> > So, do we need IE versions? In my opinion, yes: otherwise we >> can't >> >> >> > change "future reserved" values in flags or code table IEs. >> >> >> We can, though there won't be any reference point for us to indicate exactly what we support. > Unless the registry contains _every_ version of each IE. Why not a simple description field: in this version, explaining in plain english text what has been added per IE version? Regards, Benoit. > But then there would still be no _runtime_ support for this... >>> I'd suggest a new column in the >> registry, initialized to 0 for >> >> >> > existing IEs. If these are essentially code tables linked to >> >> >> > subregistries, then the subregistries should probably have >> version >> >> >> > numbers themselves. >> >> >> OK. >> >> >>> A second question: what about >> an IANA Registry version - a serial >> >> >> > number incremented by one on each modification, deprecation, >> or >> >> >> > addition? The case for this is less clear for me. >> >> >> Agreed: if I add export of a new IE, or add new values in an existing IE, thus creating a new registry version, >> then I'd be obliged to bring all my exports up to date in order to comply with the version I just made. >> >> That may not be necessary, desirable or even possible. > Hm. Good point. Okay, so the consensus of two would be "versioned IEs, versioned subregistries referenced by IEs, no versioned registry"... > > Cheers, > > Brian > > _______________________________________________ > IPFIX mailing list > IPFIX@ietf.org > https://www.ietf.org/mailman/listinfo/ipfix From trammell@tik.ee.ethz.ch Mon Apr 4 01:19:44 2011 Return-Path: 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 29B623A6935 for ; Mon, 4 Apr 2011 01:19:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 ZHG33lzJoBnm for ; Mon, 4 Apr 2011 01:19:41 -0700 (PDT) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) by core3.amsl.com (Postfix) with ESMTP id 98F473A6908 for ; Mon, 4 Apr 2011 01:19:40 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id EF3DFD9336; Mon, 4 Apr 2011 10:21:21 +0200 (MEST) X-Virus-Scanned: by amavisd-new on smtp.ee.ethz.ch Received: from smtp.ee.ethz.ch ([127.0.0.1]) by localhost (.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 6Ma-TkFv6pTa; Mon, 4 Apr 2011 10:21:21 +0200 (MEST) Received: from pb-10243.ethz.ch (pb-10243.ethz.ch [82.130.102.152]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: briant) by smtp.ee.ethz.ch (Postfix) with ESMTPSA id ADE70D9324; Mon, 4 Apr 2011 10:21:21 +0200 (MEST) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Brian Trammell In-Reply-To: <4D997A72.40608@cisco.com> Date: Mon, 4 Apr 2011 10:21:24 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <12C592FF-D6E5-4DF1-A8A2-CE9566F27B05@tik.ee.ethz.ch> References: <4D91D859.6050407@cisco.com> <4D920A05.5020103@cisco.com> <4D997A72.40608@cisco.com> To: Benoit Claise X-Mailer: Apple Mail (2.1082) Cc: IETF IPFIX Working Group Subject: Re: [IPFIX] modifying existing IEs X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Apr 2011 08:19:45 -0000 On Apr 4, 2011, at 9:59 AM, Benoit Claise wrote: >>>=20 >>> > So, do we need IE versions? In my opinion, yes: otherwise = we >>> can't >>> > change "future reserved" values in flags or code table IEs. >>>=20 >>>=20 >>> We can, though there won't be any reference point for us to indicate = exactly what we support. >> Unless the registry contains _every_ version of each IE. > Why not a simple description field: in this version, explaining in = plain english text what has been added per IE version? That'll make IANA happier, certainly. (And the multiversion thing would = be better for some unspecified _future_ automated support, maybe, but on = second thought would be terribly confusing to people who weren't = expecting it, i.e. almost everyone...) Cheers, Brian From bclaise@cisco.com Mon Apr 4 01:33:18 2011 Return-Path: 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 9A7943A6908 for ; Mon, 4 Apr 2011 01:33:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.622 X-Spam-Level: X-Spam-Status: No, score=-2.622 tagged_above=-999 required=5 tests=[AWL=-0.023, BAYES_00=-2.599] 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 8vjTwDwQglDW for ; Mon, 4 Apr 2011 01:33:17 -0700 (PDT) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by core3.amsl.com (Postfix) with ESMTP id EC3DB28C0FA for ; Mon, 4 Apr 2011 01:33:03 -0700 (PDT) X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id p348R9ME017897; Mon, 4 Apr 2011 10:27:09 +0200 (CEST) Received: from [10.55.43.51] (ams-bclaise-8712.cisco.com [10.55.43.51]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id p348R8db004621; Mon, 4 Apr 2011 10:27:09 +0200 (CEST) Message-ID: <4D9980DC.4040000@cisco.com> Date: Mon, 04 Apr 2011 10:27:08 +0200 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: Nevil Brownlee References: <4D94481E.6080605@auckland.ac.nz> In-Reply-To: <4D94481E.6080605@auckland.ac.nz> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: IPFIX list Subject: Re: [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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Apr 2011 08:33:19 -0000 Nevil, Reviewing my note, I have one comment > > 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? Maybe this is an obvious one, but a conclusion from the discussion is that IANA should be point of contact for request, as opposed to IE doctors. And the IE doctors should be called for review, when necessary. Regards, Benoit. > > 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. > From bclaise@cisco.com Mon Apr 4 01:57:42 2011 Return-Path: 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 CDC1D3A6908 for ; Mon, 4 Apr 2011 01:57:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.621 X-Spam-Level: X-Spam-Status: No, score=-2.621 tagged_above=-999 required=5 tests=[AWL=-0.022, BAYES_00=-2.599] 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 WGwExlow28l2 for ; Mon, 4 Apr 2011 01:57:35 -0700 (PDT) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by core3.amsl.com (Postfix) with ESMTP id EFA8E3A6935 for ; Mon, 4 Apr 2011 01:57:34 -0700 (PDT) X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id p348E826016644; Mon, 4 Apr 2011 10:14:09 +0200 (CEST) Received: from [10.55.43.51] (ams-bclaise-8712.cisco.com [10.55.43.51]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id p348E8dX020422; Mon, 4 Apr 2011 10:14:08 +0200 (CEST) Message-ID: <4D997DD0.5040003@cisco.com> Date: Mon, 04 Apr 2011 10:14:08 +0200 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: Brian Trammell References: <4D94481E.6080605@auckland.ac.nz> <745A438B-855F-4659-AB36-B11D6B95213B@tik.ee.ethz.ch> <4D94DCCB.7090304@net.in.tum.de> <4D958EB1.80808@cisco.com> <2325CBCF-7A37-4DD6-9425-D30BF0337478@tik.ee.ethz.ch> In-Reply-To: <2325CBCF-7A37-4DD6-9425-D30BF0337478@tik.ee.ethz.ch> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: IPFIX list Subject: Re: [IPFIX] [Sender: ipfix-bounces@ietf.org] Re: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Apr 2011 08:57:43 -0000 Hi, > Hi, Paul, all, > > You can reuse templates in UDP after they expire. > > Theoretically. > > I would suggest in 5101bis (assuming there is such a thing) that we remove the prohibition on sending withdrawals on UDP. Agreed that withdrawals are useless on UDP -- templates simply get replaced anyway, and expire according to rules involving the phase of the moon and the casting of runes. The CP can't do anything sensible anyway if it gets a withdrawal on UDP, so it might as well try to follow the same rules as everywhere else. Since it simplifies the code (similar code for the three transport protocols), while having no disadvantages (withdrawals on UDP doesn't do any good or bad), I agree. This goes in the same direction as the point number 3 in http://www.ietf.org/mail-archive/web/ipfix/current/msg05809.html Regards, Benoit. > Indeed, I think it's probably possible to define new set of template management rules that 1. interoperates with 5101 (aside from CP resets, which are a bad idea anyway) and 2. allows a single universal policy without regard to transport. I'll put some thought into this. > > Best regards, > > Brian > > > On Apr 1, 2011, at 10:37 AM, Paul Aitken wrote: > >> Gerhard, >> >>> Vermont sends Template withdrawal messages and reuses Template IDs if you trigger an appropriate reconfiguration at runtime. >> Is this is transport dependant? Or do you not export over UDP? >> >> Obviously it's a bad idea to reuse template IDs when exporting over UDP. >> >> So 5101 says: >> >> If UDP is selected as the transport protocol, the Template Withdraw >> Messages MUST NOT be used, as this method is inefficient due to the >> unreliable nature of UDP. >> >> >> Of course "Withdraw" should be "Withdrawal" (here, and in three other places). Time for another errata. >> >> P. > _______________________________________________ > IPFIX mailing list > IPFIX@ietf.org > https://www.ietf.org/mailman/listinfo/ipfix From muenz@net.in.tum.de Mon Apr 4 11:10:53 2011 Return-Path: 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 725593A69C4 for ; Mon, 4 Apr 2011 11:10:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35] 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 J5Dr7Fw5ocKl for ; Mon, 4 Apr 2011 11:10:53 -0700 (PDT) Received: from mail-out1.informatik.tu-muenchen.de (mail-out1.informatik.tu-muenchen.de [131.159.0.8]) by core3.amsl.com (Postfix) with ESMTP id C5A113A69C1 for ; Mon, 4 Apr 2011 11:10:52 -0700 (PDT) Received: from [192.168.1.151] (ppp-93-104-69-240.dynamic.mnet-online.de [93.104.69.240]) by mail.net.in.tum.de (Postfix) with ESMTPSA id 54CDD2051A02; Mon, 4 Apr 2011 20:12:22 +0200 (CEST) Message-ID: <4D9A09F1.9060801@net.in.tum.de> Date: Mon, 04 Apr 2011 20:12:01 +0200 From: Gerhard Muenz User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: Nevil Brownlee References: <4D8395E7.7010604@auckland.ac.nz> In-Reply-To: <4D8395E7.7010604@auckland.ac.nz> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: IPFIX list Subject: Re: [IPFIX] Need reviews of PSAMP MIB draft -03 X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Apr 2011 18:10:53 -0000 Hi Nevil, Except this single typo, all my comments to -02 have adequately addressed: We still find "ipfixSelectionProcessSelectorFunctionentries" several times in the MIB module definition. It should be "ipfixSelectionProcessSelectorFunction entries". Cheers, Gerhard On 18.03.2011 18:27, Nevil Brownlee wrote: > > Hi all: > > The -03 version of the PSAMP MIB draft was published on 2 March, > now I'm getting set to do its writeup for IESG. > > For that I need a few reviews; just a few lines saying "yes, it > looks OK to me now" would be plenty. > > If I get these reviews in the next few days, I'll submit the writeup > before we meet in Prague ... > > Cheers, Nevil > From wwwrun@rfc-editor.org Mon Apr 4 17:26:11 2011 Return-Path: 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 B3B8528C0E0; Mon, 4 Apr 2011 17:26:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.406 X-Spam-Level: X-Spam-Status: No, score=-102.406 tagged_above=-999 required=5 tests=[AWL=0.194, BAYES_00=-2.599, NO_RELAYS=-0.001, 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 53FbFpE0u6eA; Mon, 4 Apr 2011 17:26:10 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:1112:1::2f]) by core3.amsl.com (Postfix) with ESMTP id C909E28C0DF; Mon, 4 Apr 2011 17:26:10 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 9826BE076B; Mon, 4 Apr 2011 17:27:33 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org From: rfc-editor@rfc-editor.org Message-Id: <20110405002733.9826BE076B@rfc-editor.org> Date: Mon, 4 Apr 2011 17:27:33 -0700 (PDT) Cc: ipfix@ietf.org, rfc-editor@rfc-editor.org Subject: [IPFIX] RFC 6183 on IP Flow Information Export (IPFIX) Mediation: Framework X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Apr 2011 00:26:11 -0000 A new Request for Comments is now available in online RFC libraries. RFC 6183 Title: IP Flow Information Export (IPFIX) Mediation: Framework Author: A. Kobayashi, B. Claise, G. Muenz, K. Ishibashi Status: Informational Stream: IETF Date: April 2011 Mailbox: akoba@orange.plala.or.jp, bclaise@cisco.com, muenz@net.in.tum.de, ishibashi.keisuke@lab.ntt.co.jp Pages: 29 Characters: 67997 Updates: RFC5470 I-D Tag: draft-ietf-ipfix-mediators-framework-09.txt URL: http://www.rfc-editor.org/rfc/rfc6183.txt This document describes a framework for IP Flow Information Export (IPFIX) Mediation. This framework extends the IPFIX reference model specified in RFC 5470 by defining the IPFIX Mediator components. This document is not an Internet Standards Track specification; it is published for informational purposes. This document is a product of the IP Flow Information Export Working Group of the IETF. INFORMATIONAL: This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From muenz@net.in.tum.de Tue Apr 5 03:37:25 2011 Return-Path: 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 0700D3A691A for ; Tue, 5 Apr 2011 03:37:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35] 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 LugwyL2pvvmn for ; Tue, 5 Apr 2011 03:37:22 -0700 (PDT) Received: from mail-out1.informatik.tu-muenchen.de (mail-out1.informatik.tu-muenchen.de [131.159.0.8]) by core3.amsl.com (Postfix) with ESMTP id C2DB53A691E for ; Tue, 5 Apr 2011 03:37:21 -0700 (PDT) Received: by mail.net.in.tum.de (Postfix, from userid 81) id 4F685201D68D; Tue, 5 Apr 2011 12:38:52 +0200 (CEST) To: X-PHP-Originating-Script: 0:func.inc MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Date: Tue, 05 Apr 2011 12:38:52 +0200 From: Gerhard Muenz In-Reply-To: References: Message-ID: <2646497d6c156a9362866650cde3ed1b@net.in.tum.de> X-Sender: muenz@net.in.tum.de User-Agent: Roundcube Webmail/0.5.1 Subject: Re: [IPFIX] Fwd: I-D Action:draft-ietf-ipfix-configuration-model-09.txt X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Apr 2011 10:37:25 -0000 Hi Jürgen, Some time ago, the future of PSAMP MIB was uncertain. So, we decided to removed most of the references to PSAMP MIB. Now, as PSAMP MIB seems to be completed before (or at the same time as) IPFIX-CONFIG, it would make sense to add references to those objects in the SELECTOR MIB which have the same meaning as parameters in the configuration model. We have done the same for those parameters which also appear in IPFIX MIB. Note that this would not cause any change in the model since it already is inline with PSAMP MIB. It just means adding some references in the text and in the YANG module definition. Therefore, I suggest to continue with the AD evaluation and add such references in a next revision of the draft. Regards, Gerhard On Thu, 10 Mar 2011 10:07:14 +0100, Gerhard Muenz wrote: > Hi Jürgen, > > I will not be in Prague. So, from my side, there is no need to > discuss the yang module there. > > We could wait for a brief feedback from the yang doctors. Otherwise, > the draft is ready for publication. > > Regards, > Gerhard > > On Thu, 10 Mar 2011 03:15:49 +0000, Juergen Quittek wrote: >> Hi Gerhard, >> >> Do you consider this draft ready for requesting publication? >> Or would it be better to discuss the YANG module at Prague? >> >> Thanks, >> >> Juergen >> >> >> Am 09.03.11 17:30 schrieb "Gerhard Muenz" unter >> : >> >>> >>> Dear all, >>> >>> I have submitted a new version of the configuration draft which >>> addresses the comments made by Lada and Mehmet/Bernd during the >>> second >>> WGLC. Thanks again for your valuable feedback. >>> >>> There was some concern about the size of the yang module. The >>> configuration could be split into Exporter and Collector >>> configuration, >>> or even into OP/MP, EP, and CP configuration. However, if I >>> understand >>> correctly, references (leafrefs) across yang modules are only >>> possible >>> if the source module imports the destination module. Hence, as MP >>> refers >>> to EP, the MP module would need to import the EP module. Similary, >>> the >>> CP module would need to import the EP module as well. In addition, >>> all >>> modules would need to import one module with common type >>> definitions. >>> >>> All in all, it seems that we would not gain much by splitting the >>> module. So, the current draft still contains a single yang module. >>> >>> Kind regards, >>> Gerhard >>> >>> -------- Original Message -------- >>> Subject: [IPFIX] I-D >>> Action:draft-ietf-ipfix-configuration-model-09.txt >>> Date: Wed, 09 Mar 2011 02:15:02 -0800 >>> From: Internet-Drafts@ietf.org >>> To: i-d-announce@ietf.org >>> Cc: ipfix@ietf.org >>> >>> 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 : Configuration Data Model for IPFIX and PSAMP >>> Author(s) : G. Muenz, et al. >>> Filename : draft-ietf-ipfix-configuration-model-09.txt >>> Pages : 124 >>> Date : 2011-03-09 >>> >>> This document specifies a data model for configuring and >>> monitoring >>> Selection Processes, Caches, Exporting Processes, and Collecting >>> Processes of IPFIX and PSAMP compliant Monitoring Devices using >>> the >>> NETCONF protocol [RFC4741]. The data model is defined using UML >>> (Unified Modeling Language) class diagrams and formally specified >>> using YANG [RFC6020]. The configuration data is encoded in >>> Extensible Markup Language (XML). >>> >>> A URL for this Internet-Draft is: >>> >>> >> >> http://www.ietf.org/internet-drafts/draft-ietf-ipfix-configuration-model-09.tx> >> t >>> >>> 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. >>> >>> _______________________________________________ >>> IPFIX mailing list >>> IPFIX@ietf.org >>> https://www.ietf.org/mailman/listinfo/ipfix > > _______________________________________________ > IPFIX mailing list > IPFIX@ietf.org > https://www.ietf.org/mailman/listinfo/ipfix From kashima@nttv6.net Tue Apr 5 08:22:55 2011 Return-Path: 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 5500528C0DE for ; Tue, 5 Apr 2011 08:22:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.59 X-Spam-Level: X-Spam-Status: No, score=-1.59 tagged_above=-999 required=5 tests=[AWL=-0.191, BAYES_00=-2.599, J_CHICKENPOX_37=0.6, J_CHICKENPOX_39=0.6] 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 cnWglRY03+Sw for ; Tue, 5 Apr 2011 08:22:54 -0700 (PDT) Received: from leo.nttv6.net (leo.nttv6.net [192.47.162.93]) by core3.amsl.com (Postfix) with ESMTP id D06DB3A68E8 for ; Tue, 5 Apr 2011 08:22:53 -0700 (PDT) Received: from [192.168.11.254] (localhost.nttv6.net [IPv6:::1]) by leo.nttv6.net (8.14.4/8.14.3) with ESMTP id p35FNFgw087306; Wed, 6 Apr 2011 00:23:15 +0900 (JST) (envelope-from kashima@nttv6.net) Date: Wed, 06 Apr 2011 00:23:15 +0900 From: Shingo KASHIMA To: "Laxmi Mukund (lmukund)" In-Reply-To: <061BB2F7C70CFF42BB3E8DF41D130EB903BE8531@XMB-BGL-41A.cisco.com> References: <20110324113405.DF09.1AB7FA03@nttv6.net> <061BB2F7C70CFF42BB3E8DF41D130EB903BE8531@XMB-BGL-41A.cisco.com> Message-Id: <20110406002315.B2A1.1AB7FA03@nttv6.net> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Becky! ver. 2.56.05 [ja] Cc: ipfix@ietf.org Subject: Re: [IPFIX] Fwd: New Version Notification fordraft-kashima-ipfix-data-link-layer-monitoring-05 X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Apr 2011 15:22:55 -0000 Hi Laxmi, Thank you for your comments. Please see in-line. On Mon, 28 Mar 2011 16:28:17 +0530 "Laxmi Mukund (lmukund)" san wrote: > Hi Shingo San, > I think this would be very useful to include in the draft. We have been > working on this but didn't get to put it in a draft. Glad you could put > them in here. > I have some comments about the draft. > 1) > 3.6. dot1qServiceInstanceTag > Maybe this could be reworded to: > This Information Element, which may have 16 octets length, > represents > the Backbone Service Instance Tag (I-TAG) Tag Control Information > (TCI) field of an Ethernet frame as described in > [IEEE802.1ah-2008]. It encodes the priority, drop_eligible, > destination > and source address. Yes. I will modify in a next revision. > 2) It looks like Section 3.7 and 3.8 have got interchanged. The > description and the information elements have been switched. Oh.. This is my mistake. I will modify in a next revision. > > 3) Could we include a section that would say the current and new > information elements needed to export all the 802.1ah header fields like > so: > > This is a summary of the 802.1ah fields and the new and current > informational elements that would be used to represent each of the > fields. > > <-----6---------><------6-------><--4-----><-----6--------><-----6------ > --><-----6-------><---4---> > +---------------+---------------+---------+---------------+------------- > --+--------------+--------+ > + + + + + > + + + > + B-DA + B-A + B TAG + I-TAG + C-DA > + C-SA + C-TAG + > + 1 + 2 + 3 + 4 + 5 > + 6 + 7 + > +---------------+---------------+---------+---------------+------------- > --+--------------+--------+ > > 1.(Existing Element) destinationMacAddress 80 > 2.(Existing Element) sourceMacAddress 56 > 3.(Existing Element) dot1qVlanId 243, dot1qPriority 244 > 4.(New Element) defined in section 3.6, 3.7, 3.8 of this draft > 5.(New Element) defined in section 3.9 of this draft > 6.(New Element) defined in section 3.10 of this draft > 7.(Existing Element) dot1qCustomerVlanId 245, dot1qCustomerPriority 246 > Nice comments. But as you know, I-TAG includes C-DA and C-SA How about the following ? <----6----><----6----><----4----><------18------><----4----> +----------+----------+----------+---------------+----------+ + + + + + + + B-DA + B-SA + B-TAG + I-TAG + C-TAG + + 1 + 2 + 3 + 4 + 5 + +----------+----------+----------+---------------+----------+ 1.(Existing Element) destinationMacAddress 80 2.(Existing Element) sourceMacAddress 56 3.(Existing Element) dot1qVlanId 243, dot1qPriority 244 4.(New Element) defined in section 3.6, 3.7, 3.8, 3.9 and 3.10 of this draft 5.(Existing Element) dot1qCustomerVlanId 245, dot1qCustomerPriority 246 > > Very sorry about what happened in Japan, it is very unfortunate. > My best wishes, please take care, Thank you. > Thanks, > Laxmi. > > -----Original Message----- > From: ipfix-bounces@ietf.org [mailto:ipfix-bounces@ietf.org] On Behalf > Of Shingo KASHIMA > Sent: Thursday, March 24, 2011 8:04 AM > To: ipfix@ietf.org > Subject: [IPFIX] Fwd: New Version Notification > fordraft-kashima-ipfix-data-link-layer-monitoring-05 > > > Dear all, > > Here is a new version of the draft, which includes: > - new information elements related to 802.1ah (MAC-in-MAC) > - generic offset and observed octets > > Is this valuable for WG item ? > > I wanted to make a presentaion in Prague. > But I cannot go to Prague due to huge earthquak in Japan. > Sorry. > > Best Regards, > Shingo. > > ----- Original Message ----- > Date: Tue, 15 Mar 2011 09:59:12 +0900 > From: "IETF I-D Submission Tool" > Subject: New Version Notification for > draft-kashima-ipfix-data-link-layer-monitoring-05 > > A new version of I-D, > draft-kashima-ipfix-data-link-layer-monitoring-05.txt > has been successfully submitted by Kensuke Nakata and posted to the IETF > repository. > > Filename: draft-kashima-ipfix-data-link-layer-monitoring > Revision: 05 > Title: Information Elements for Data Link Layer Traffic Measurement > Creation_date: 2011-03-15 > WG ID: Independent Submission > Number_of_pages: 26 > > Abstract: > This document describes Information Elements related to data link > layer. They are used by the IP Flow Information Export (IPFIX) > protocol for encoding measured data link layer traffic information. > > The IETF Secretariat. > > -- > Shingo KASHIMA > > _______________________________________________ > IPFIX mailing list > IPFIX@ietf.org > https://www.ietf.org/mailman/listinfo/ipfix -- Shingo KASHIMA From lmukund@cisco.com Wed Apr 6 21:19:15 2011 Return-Path: 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 B4A913A685D for ; Wed, 6 Apr 2011 21:19:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.399 X-Spam-Level: X-Spam-Status: No, score=-9.399 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_37=0.6, J_CHICKENPOX_39=0.6, RCVD_IN_DNSWL_HI=-8] 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 ofBJnq6aSZOs for ; Wed, 6 Apr 2011 21:19:14 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 00C8528C0CF for ; Wed, 6 Apr 2011 21:19:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=lmukund@cisco.com; l=5545; q=dns/txt; s=iport; t=1302150058; x=1303359658; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=xS6aiNewJmHvydmITte6r0VN8uPNqDj+6Vf7ncuZGAU=; b=EHMc7PasJfTza0Ustl/4iLR9SDZEbiH+V+n50aw2MIeLXj2guaPIqOgJ /2Ar+SW1+z7UVWvoHNeuEsvTvj55pUmMFBOKpRnsTIdu7hBcwEs7X21pd +F1U/3jpeBdEG6qoeiHzEofOl6FHiF0Cldt9Q38aqOLLwTsA1HpwHCwcb Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AroAAEc7nU2Q/khLgWdsb2JhbACYNI1MFAEBCwsmJYh5nX+cb4VsBIVMi10 X-IronPort-AV: E=Sophos;i="4.63,314,1299456000"; d="scan'208";a="82527106" Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-1.cisco.com with ESMTP; 07 Apr 2011 04:20:57 +0000 Received: from xbh-bgl-411.cisco.com (xbh-bgl-411.cisco.com [72.163.129.201]) by ams-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p374Knbb019239; Thu, 7 Apr 2011 04:20:57 GMT Received: from xmb-bgl-41a.cisco.com ([72.163.129.216]) by xbh-bgl-411.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 7 Apr 2011 09:50:56 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Thu, 7 Apr 2011 09:50:55 +0530 Message-ID: <061BB2F7C70CFF42BB3E8DF41D130EB903D8A0A3@XMB-BGL-41A.cisco.com> In-Reply-To: <20110406002315.B2A1.1AB7FA03@nttv6.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [IPFIX] Fwd: New Version Notification fordraft-kashima-ipfix-data-link-layer-monitoring-05 Thread-Index: AcvzpXURzw0XLVFWTPCIlJ2kIxsRaABNDz+A References: <20110324113405.DF09.1AB7FA03@nttv6.net> <061BB2F7C70CFF42BB3E8DF41D130EB903BE8531@XMB-BGL-41A.cisco.com> <20110406002315.B2A1.1AB7FA03@nttv6.net> From: "Laxmi Mukund (lmukund)" To: "Shingo KASHIMA" X-OriginalArrivalTime: 07 Apr 2011 04:20:56.0286 (UTC) FILETIME=[30BC67E0:01CBF4DB] Cc: ipfix@ietf.org Subject: Re: [IPFIX] Fwd: New Version Notification fordraft-kashima-ipfix-data-link-layer-monitoring-05 X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Apr 2011 04:19:15 -0000 Hi Shingo San, Thank you for the reply. Yes we can combine 4.5.6 in the list. Thanks, Laxmi. -----Original Message----- From: Shingo KASHIMA [mailto:kashima@nttv6.net]=20 Sent: Tuesday, April 05, 2011 8:53 PM To: Laxmi Mukund (lmukund) Cc: ipfix@ietf.org Subject: Re: [IPFIX] Fwd: New Version Notification fordraft-kashima-ipfix-data-link-layer-monitoring-05 Hi Laxmi, Thank you for your comments. Please see in-line. On Mon, 28 Mar 2011 16:28:17 +0530 "Laxmi Mukund (lmukund)" san wrote: > Hi Shingo San, > I think this would be very useful to include in the draft. We have been > working on this but didn't get to put it in a draft. Glad you could put > them in here. > I have some comments about the draft. > 1)=20 > 3.6. dot1qServiceInstanceTag > Maybe this could be reworded to: > This Information Element, which may have 16 octets length, > represents=20 > the Backbone Service Instance Tag (I-TAG) Tag Control Information > (TCI) field of an Ethernet frame as described in > [IEEE802.1ah-2008]. It encodes the priority, drop_eligible, > destination > and source address. =20 Yes. I will modify in a next revision. > 2) It looks like Section 3.7 and 3.8 have got interchanged. The > description and the information elements have been switched. Oh.. This is my mistake. I will modify in a next revision. >=20 > 3) Could we include a section that would say the current and new > information elements needed to export all the 802.1ah header fields like > so: >=20 > This is a summary of the 802.1ah fields and the new and current > informational elements that would be used to represent each of the > fields. >=20 > <-----6---------><------6-------><--4-----><-----6--------><-----6------ > --><-----6-------><---4---> > +---------------+---------------+---------+---------------+------------- > --+--------------+--------+ > + + + + + > + + + > + B-DA + B-A + B TAG + I-TAG + C-DA > + C-SA + C-TAG + > + 1 + 2 + 3 + 4 + 5 > + 6 + 7 + > +---------------+---------------+---------+---------------+------------- > --+--------------+--------+ >=20 > 1.(Existing Element) destinationMacAddress 80 > 2.(Existing Element) sourceMacAddress 56 > 3.(Existing Element) dot1qVlanId 243, dot1qPriority 244 > 4.(New Element) defined in section 3.6, 3.7, 3.8 of this draft > 5.(New Element) defined in section 3.9 of this draft > 6.(New Element) defined in section 3.10 of this draft > 7.(Existing Element) dot1qCustomerVlanId 245, dot1qCustomerPriority 246 >=20 Nice comments. But as you know, I-TAG includes C-DA and C-SA How about the following ? <----6----><----6----><----4----><------18------><----4----> +----------+----------+----------+---------------+----------+ + + + + + + + B-DA + B-SA + B-TAG + I-TAG + C-TAG + + 1 + 2 + 3 + 4 + 5 + +----------+----------+----------+---------------+----------+ 1.(Existing Element) destinationMacAddress 80 2.(Existing Element) sourceMacAddress 56 3.(Existing Element) dot1qVlanId 243, dot1qPriority 244 4.(New Element) defined in section 3.6, 3.7, 3.8, 3.9 and 3.10 of this draft 5.(Existing Element) dot1qCustomerVlanId 245, dot1qCustomerPriority 246 >=20 > Very sorry about what happened in Japan, it is very unfortunate. > My best wishes, please take care, Thank you. > Thanks, > Laxmi. >=20 > -----Original Message----- > From: ipfix-bounces@ietf.org [mailto:ipfix-bounces@ietf.org] On Behalf > Of Shingo KASHIMA > Sent: Thursday, March 24, 2011 8:04 AM > To: ipfix@ietf.org > Subject: [IPFIX] Fwd: New Version Notification > fordraft-kashima-ipfix-data-link-layer-monitoring-05 >=20 >=20 > Dear all, >=20 > Here is a new version of the draft, which includes: > - new information elements related to 802.1ah (MAC-in-MAC) > - generic offset and observed octets >=20 > Is this valuable for WG item ? >=20 > I wanted to make a presentaion in Prague. > But I cannot go to Prague due to huge earthquak in Japan. > Sorry. >=20 > Best Regards, > Shingo. >=20 > ----- Original Message ----- > Date: Tue, 15 Mar 2011 09:59:12 +0900 > From: "IETF I-D Submission Tool" > Subject: New Version Notification for > draft-kashima-ipfix-data-link-layer-monitoring-05 >=20 > A new version of I-D, > draft-kashima-ipfix-data-link-layer-monitoring-05.txt=20 > has been successfully submitted by Kensuke Nakata and posted to the IETF > repository. >=20 > Filename: draft-kashima-ipfix-data-link-layer-monitoring > Revision: 05 > Title: Information Elements for Data Link Layer Traffic Measurement > Creation_date: 2011-03-15 > WG ID: Independent Submission > Number_of_pages: 26 >=20 > Abstract: > This document describes Information Elements related to data link > layer. They are used by the IP Flow Information Export (IPFIX) > protocol for encoding measured data link layer traffic information. >=20 > The IETF Secretariat. >=20 > --=20 > Shingo KASHIMA >=20 > _______________________________________________ > IPFIX mailing list > IPFIX@ietf.org > https://www.ietf.org/mailman/listinfo/ipfix --=20 Shingo KASHIMA From bclaise@cisco.com Thu Apr 7 01:41:33 2011 Return-Path: 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 28F563A6952 for ; Thu, 7 Apr 2011 01:41:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.62 X-Spam-Level: X-Spam-Status: No, score=-2.62 tagged_above=-999 required=5 tests=[AWL=-0.022, BAYES_00=-2.599, HTML_MESSAGE=0.001] 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 qkAao9-dmi9v for ; Thu, 7 Apr 2011 01:41:31 -0700 (PDT) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by core3.amsl.com (Postfix) with ESMTP id BFEC83A67F3 for ; Thu, 7 Apr 2011 01:41:30 -0700 (PDT) X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id p378hEFO022022 for ; Thu, 7 Apr 2011 10:43:14 +0200 (CEST) Received: from [10.55.43.51] (ams-bclaise-8712.cisco.com [10.55.43.51]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id p378hE88010278 for ; Thu, 7 Apr 2011 10:43:14 +0200 (CEST) Message-ID: <4D9D7921.5050006@cisco.com> Date: Thu, 07 Apr 2011 10:43:13 +0200 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: "ipfix@ietf.org" Content-Type: multipart/alternative; boundary="------------060602010604020205020507" Subject: [IPFIX] New Version Notification for draft-johnson-ipfix-mib-variable-export-01 X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Apr 2011 08:41:33 -0000 This is a multi-part message in MIME format. --------------060602010604020205020507 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Dear all, At the IETF79, I presented this work both in the OPSAREA and the IPFIX meetings http://www.ietf.org/proceedings/79/minutes/opsarea.txt http://www.ietf.org/proceedings/79/minutes/ipfix.txt I thought it was well received. At the IETF80, I had to rush to presente it in IPFIX WG, and therefore I didn't do a good job of explaining the issues. A new draft version has been posted, which should clarify the goal and the proposed mechanism. Juergen Schoenwalder has been added as an author. Please review https://datatracker.ietf.org/doc/draft-johnson-ipfix-mib-variable-export/ Regards, Benoit. -------- Original Message -------- Subject: New Version Notification for draft-johnson-ipfix-mib-variable-export-01 Date: Thu, 7 Apr 2011 01:23:36 -0700 (PDT) From: IETF I-D Submission Tool To: bclaise@cisco.com CC: andrjohn@cisco.com, paitken@cisco.com, j.schoenwaelder@jacobs-university.de A new version of I-D, draft-johnson-ipfix-mib-variable-export-01.txt has been successfully submitted by Benoit Claise and posted to the IETF repository. Filename: draft-johnson-ipfix-mib-variable-export Revision: 01 Title: Exporting MIB Variables using the IPFIX Protocol Creation_date: 2011-04-07 WG ID: Independent Submission Number_of_pages: 25 Abstract: This document specifies a way to complement IPFIX Flow Records with Management Base (MIB) objects, avoiding the need to define new IPFIX Information Elements for existing Management Information Base objects that are already fully specified. This method requires an extension to the current IPFIX protocol. New Template Set and Options Template Sets are specified to allow the export of Simple Network Management Protocol (SNMP) MIB Objects along with IPFIX Information Elements. The IETF Secretariat. --------------060602010604020205020507 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit Dear all,

At the IETF79, I presented this work both in the OPSAREA and the IPFIX meetings
    http://www.ietf.org/proceedings/79/minutes/opsarea.txt
    http://www.ietf.org/proceedings/79/minutes/ipfix.txt
I thought it was well received.

At the IETF80, I had to rush to presente it in IPFIX WG, and therefore I didn't do a good job of explaining the issues.
A new draft version has been posted, which should clarify the goal and the proposed mechanism.
Juergen Schoenwalder has been added as an author.

Please review https://datatracker.ietf.org/doc/draft-johnson-ipfix-mib-variable-export/

Regards, Benoit.

-------- Original Message --------
Subject: New Version Notification for draft-johnson-ipfix-mib-variable-export-01
Date: Thu, 7 Apr 2011 01:23:36 -0700 (PDT)
From: IETF I-D Submission Tool <idsubmission@ietf.org>
To: bclaise@cisco.com
CC: andrjohn@cisco.com, paitken@cisco.com, j.schoenwaelder@jacobs-university.de 


A new version of I-D, draft-johnson-ipfix-mib-variable-export-01.txt has been successfully submitted by Benoit Claise and posted to the IETF repository.

Filename:	 draft-johnson-ipfix-mib-variable-export
Revision:	 01
Title:		 Exporting MIB Variables using the IPFIX Protocol
Creation_date:	 2011-04-07
WG ID:		 Independent Submission
Number_of_pages: 25

Abstract:
This document specifies a way to complement IPFIX Flow Records with
Management Base (MIB) objects, avoiding the need to define new IPFIX
Information Elements for existing Management Information Base objects
that are already fully specified.

This method requires an extension to the current IPFIX protocol.  New
Template Set and Options Template Sets are specified to allow the
export of Simple Network Management Protocol (SNMP) MIB Objects along
with IPFIX Information Elements.
                                                                                  


The IETF Secretariat.
--------------060602010604020205020507-- From Quittek@neclab.eu Sun Apr 10 23:18:12 2011 Return-Path: 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 8C8083A6A85 for ; Sun, 10 Apr 2011 23:18:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.284 X-Spam-Level: X-Spam-Status: No, score=-102.284 tagged_above=-999 required=5 tests=[AWL=-0.035, BAYES_00=-2.599, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, 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 Or5tXQgSZp5p for ; Sun, 10 Apr 2011 23:18:11 -0700 (PDT) Received: from smtp0.netlab.nec.de (smtp0.netlab.nec.de [195.37.70.40]) by core3.amsl.com (Postfix) with ESMTP id A7EB83A69D1 for ; Sun, 10 Apr 2011 23:18:10 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp0.netlab.nec.de (Postfix) with ESMTP id 2CABE28000181; Mon, 11 Apr 2011 08:19:29 +0200 (CEST) X-Virus-Scanned: Amavisd on Debian GNU/Linux (atlas1.office.hd) Received: from smtp0.netlab.nec.de ([127.0.0.1]) by localhost (atlas1.office.hd [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0s-Rq0wBVvmS; Mon, 11 Apr 2011 08:19:29 +0200 (CEST) Received: from METHONE.office.hd (Methone.office.hd [192.168.24.54]) by smtp0.netlab.nec.de (Postfix) with ESMTP id 0B0712800017B; Mon, 11 Apr 2011 08:19:19 +0200 (CEST) Received: from Polydeuces.office.hd ([169.254.3.246]) by METHONE.office.hd ([192.168.24.54]) with mapi id 14.01.0270.001; Mon, 11 Apr 2011 08:18:00 +0200 From: Juergen Quittek To: Gerhard Muenz Thread-Topic: [IPFIX] Fwd: I-D Action:draft-ietf-ipfix-configuration-model-09.txt Thread-Index: Acv4EDHem0Un07cBU0Sj5X2CD4OMtg== Date: Mon, 11 Apr 2011 06:17:58 +0000 Message-ID: In-Reply-To: <2646497d6c156a9362866650cde3ed1b@net.in.tum.de> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-Entourage/13.8.0.101117 x-originating-ip: [10.1.2.219] Content-Type: multipart/alternative; boundary="_000_C9C869B311268quittekneclabeu_" MIME-Version: 1.0 Cc: IETF IPFIX Working Group Subject: Re: [IPFIX] Fwd: I-D Action:draft-ietf-ipfix-configuration-model-09.txt X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Apr 2011 06:18:12 -0000 --_000_C9C869B311268quittekneclabeu_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Gerhard, Yes, please go on as you suggested. Thanks, Juergen Am 05.04.11 12:38 schrieb "Gerhard Muenz" unter : Hi J=FCrgen, Some time ago, the future of PSAMP MIB was uncertain. So, we d= ecided to removed most of the references to PSAMP MIB. Now, as PSAMP MIB se= ems to be completed before (or at the same time as) IPFIX-CONFIG, it would = make sense to add references to those objects in the SELECTOR MIB which hav= e the same meaning as parameters in the configuration model. We have done t= he same for those parameters which also appear in IPFIX MIB. Note that this= would not cause any change in the model since it already is inline with PS= AMP MIB. It just means adding some references in the text and in the YANG m= odule definition. Therefore, I suggest to continue with the AD evaluation a= nd add such references in a next revision of the draft. Regards, Gerhard On= Thu, 10 Mar 2011 10:07:14 +0100, Gerhard Muenz wrote: > Hi J=FCrgen, > > I= will not be in Prague. So, from my side, there is no need to > discuss the= yang module there. > > We could wait for a brief feedback from the yang do= ctors. Otherwise, > the draft is ready for publication. > > Regards, > Gerh= ard > > On Thu, 10 Mar 2011 03:15:49 +0000, Juergen Quittek wrote: >> Hi Ge= rhard, >> >> Do you consider this draft ready for requesting publication? >= > Or would it be better to discuss the YANG module at Prague? >> >> Thanks,= >> >> Juergen >> >> >> Am 09.03.11 17:30 schrieb "Gerhard Muenz" unter= >> : >> >>> >>> Dear all, >>> >>> I have submitted = a new version of the configuration draft which >>> addresses the comments = made by Lada and Mehmet/Bernd during the >>> second >>> WGLC. Thanks again= for your valuable feedback. >>> >>> There was some concern about the size= of the yang module. The >>> configuration could be split into Exporter an= d Collector >>> configuration, >>> or even into OP/MP, EP, and CP configur= ation. However, if I >>> understand >>> correctly, references (leafrefs) a= cross yang modules are only >>> possible >>> if the source module imports = the destination module. Hence, as MP >>> refers >>> to EP, the MP module w= ould need to import the EP module. Similary, >>> the >>> CP module would n= eed to import the EP module as well. In addition, >>> all >>> modules woul= d need to import one module with common type >>> definitions. >>> >>> All = in all, it seems that we would not gain much by splitting the >>> module. = So, the current draft still contains a single yang module. >>> >>> Kind re= gards, >>> Gerhard >>> >>> -------- Original Message -------- >>> Subjec= t: [IPFIX] I-D >>> Action:draft-ietf-ipfix-configuration-model-09.txt >>> = Date: Wed, 09 Mar 2011 02:15:02 -0800 >>> From: Internet-Drafts@ietf.org >= >> To: i-d-announce@ietf.org >>> Cc: ipfix@ietf.org >>> >>> A New Intern= et-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 : Configuration Data Mo= del for IPFIX and PSAMP >>> Author(s) : G. Muenz, et al. >>> Filename= : draft-ietf-ipfix-configuration-model-09.txt >>> Pages := 124 >>> Date : 2011-03-09 >>> >>> This document specifies a da= ta model for configuring and >>> monitoring >>> Selection Processes, Cache= s, Exporting Processes, and Collecting >>> Processes of IPFIX and PSAMP co= mpliant Monitoring Devices using >>> the >>> NETCONF protocol [RFC4741]. = The data model is defined using UML >>> (Unified Modeling Language) class = diagrams and formally specified >>> using YANG [RFC6020]. The configurati= on data is encoded in >>> Extensible Markup Language (XML). >>> >>> A URL= for this Internet-Draft is: >>> >>> >> >> http://www.ietf.org/internet-dra= fts/draft-ietf-ipfix-configuration-model-09.tx> >> t >>> >>> Internet-Draf= ts 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. >>> >>> __________________________________________= _____ >>> IPFIX mailing list >>> IPFIX@ietf.org >>> https://www.ietf.org/ma= ilman/listinfo/ipfix > > _______________________________________________ > = IPFIX mailing list > IPFIX@ietf.org > https://www.ietf.org/mailman/listinfo= /ipfix _______________________________________________ IPFIX mailing list I= PFIX@ietf.org https://www.ietf.org/mailman/listinfo/ipfix --_000_C9C869B311268quittekneclabeu_ Content-Type: text/html; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable Re: [IPFIX] Fwd: I-D Action:draft-ietf-ipfix-configuration-model-09.= txt Hi Gerhard,

Yes, please go on as you suggested.

Thanks,

    Juergen

Am 05.04.11 12:38 schrieb "Gerhard Muenz" unter <muenz@net.in.tum.de>:

Hi J=FCrgen, Some time ago, the future of PSAMP MIB was uncertain. So, we d= ecided to removed most of the references to PSAMP MIB. Now, as PSAMP MIB se= ems to be completed before (or at the same time as) IPFIX-CONFIG, it would = make sense to add references to those objects in the SELECTOR MIB which have the same meaning as parameters in t= he configuration model. We have done the same for those parameters which al= so appear in IPFIX MIB. Note that this would not cause any change in the mo= del since it already is inline with PSAMP MIB. It just means adding some references in the text and in the YAN= G module definition. Therefore, I suggest to continue with the AD evaluatio= n and add such references in a next revision of the draft. Regards, Gerhard= On Thu, 10 Mar 2011 10:07:14 +0100, Gerhard Muenz wrote: > Hi J=FCrgen, > > I will not be in Prague. = So, from my side, there is no need to > discuss the yang module there. &= gt; > We could wait for a brief feedback from the yang doctors. Otherwis= e, > the draft is ready for publication. > > Regards, > Gerhard > > On Thu, 10 Mar 2011 03:15:49 +0000, Juergen Qui= ttek wrote: >> Hi Gerhard, >> >> Do you consider this dra= ft ready for requesting publication? >> Or would it be better to disc= uss the YANG module at Prague? >> >> Thanks, >> >> =     Juergen >> >> >> Am 09.03.11 17:30 schrieb "Gerhard Muenz" unter >>= ; <muenz@net.in.tum.de>: >>= >>> >>>  Dear all, >>> >>>  = I have submitted a new version of the configuration draft which >>>= ;  addresses the comments made by Lada and Mehmet/Bernd during the >>> second >>>  WGLC. Thanks again for y= our valuable feedback. >>> >>>  There was some conce= rn about the size of the yang module. The >>>  configuration = could be split into Exporter and Collector >>> configuration, >= >>  or even into OP/MP, EP, and CP configuration. However, if I >>> understand >>>  = ;correctly, references (leafrefs) across yang modules are only >>>= possible >>>  if the source module imports the destination m= odule. Hence, as MP >>> refers >>>  to EP, the MP mo= dule would need to import the EP module. Similary, >>> the >>>  CP module wou= ld need to import the EP module as well. In addition, >>> all >= >>  modules would need to import one module with common type >= ;>> definitions. >>> >>>  All in all, it seems= that we would not gain much by splitting the >>>  module. So, the current draft still contains a sing= le yang module. >>> >>>  Kind regards, >>> =  Gerhard >>> >>>  -------- Original Message ---= ----- >>>  Subject: [IPFIX] I-D >>> Action:draft-iet= f-ipfix-configuration-model-09.txt >>>  Date: Wed, 09 Mar 2011 02:15:02 -0800 >>>  From: Internet-Drafts@ietf.org >>>  To: i-d-announce@ietf.org >>> &n= bsp;Cc: ipfix@ietf.org >>> >>>  A New Internet-Draft is = available from the on-line Internet-Drafts >>>  directories. = >>>  This draft is a work item of the IP Flow Information Exp= ort >>> Working >>>  Group of the IETF. >>>= >>> >>> Title        =    : Configuration Data Model for IPFIX and PSAMP >>> Author(s)    &n= bsp;  : G. Muenz, et al. >>> Filename    =     : draft-ietf-ipfix-configuration-model-09.txt >&= gt;> Pages           := 124 >>> Date         &nbs= p;  : 2011-03-09 >>> >>>  This document sp= ecifies a data model for configuring and >>> monitoring >>>  Selection Processes, Caches= , Exporting Processes, and Collecting >>>  Processes of IPFIX= and PSAMP compliant Monitoring Devices using >>> the >>>=  NETCONF protocol [RFC4741].  The data model is defined using UM= L >>>  (Unified Modeling Language) class diagrams and formally specified >>>  using Y= ANG [RFC6020].  The configuration data is encoded in >>> &nbs= p;Extensible Markup Language (XML). >>> >>>  A URL f= or this Internet-Draft is: >>> >>> >> >> http://www.ietf.org/internet-drafts/draft-ietf-ipfix-configuration-model-09= .tx> >> t >>> >>>  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 >>> &n= bsp;implementation to automatically retrieve the ASCII version of the >&= gt;>  Internet-Draft. >>> >>> ___________________= ____________________________ >>> IPFIX mailing list >>> IPFIX@ietf.org >>> https://www.ietf.org/mailman/listinfo/ipfix > > _________________= ______________________________ > IPFIX mailing list > IPFIX@ietf.org > https://www.ietf.org/mailman/listinfo/ipfix ___________________________= ____________________ IPFIX mailing list IPFIX@ietf.org https://= www.ietf.org/mailman/listinfo/ipfix
--_000_C9C869B311268quittekneclabeu_-- From dromasca@avaya.com Wed Apr 13 03:25:30 2011 Return-Path: X-Original-To: ipfix@ietfc.amsl.com Delivered-To: ipfix@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id AB9A9E0613 for ; Wed, 13 Apr 2011 03:25:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.539 X-Spam-Level: X-Spam-Status: No, score=-102.539 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 57MZes55HMA8 for ; Wed, 13 Apr 2011 03:25:29 -0700 (PDT) Received: from p-us1-iereast-outbound.us1.avaya.com (p-us1-iereast-outbound.us1.avaya.com [135.11.29.13]) by ietfc.amsl.com (Postfix) with ESMTP id C6FA3E0663 for ; Wed, 13 Apr 2011 03:25:29 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Am4BAJgtcU3GmAcF/2dsb2JhbACYKT+NfHSkegKZF4VhBJAM X-IronPort-AV: E=Sophos;i="4.64,203,1301889600"; d="scan'208";a="184533675" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by p-us1-iereast-outbound.us1.avaya.com with ESMTP; 13 Apr 2011 06:25:29 -0400 X-IronPort-AV: E=Sophos;i="4.64,203,1301889600"; d="scan'208";a="608258612" Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.12]) by co300216-co-erhwest-out.avaya.com with ESMTP; 13 Apr 2011 06:25:28 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 13 Apr 2011 12:25:27 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Gen-ART Telechat review of draft-ietf-ipfix-structured-data-05.txt Thread-Index: Acv5W8XAZqKepBaKRPO+LV832+lSpAAaSLsw From: "Romascanu, Dan (Dan)" To: Subject: [IPFIX] FW: Gen-ART Telechat review of draft-ietf-ipfix-structured-data-05.txt X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Apr 2011 10:25:30 -0000 =20 Hi,=20 Please see the Gen-ART review on draft-ietf-ipfix-structured-data-05.txt Thanks and Regards, Dan=20 -----Original Message----- From: Suresh Krishnan [mailto:suresh.krishnan@ericsson.com]=20 Sent: Wednesday, April 13, 2011 12:51 AM To: gen-art@ietf.org; draft-ietf-ipfix-structured-data.all@tools.ietf.org Subject: Gen-ART Telechat review of draft-ietf-ipfix-structured-data-05.txt I have been selected as the General Area Review Team (Gen-ART) reviewer for this draft (for background on Gen-ART, please see http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html). Please wait for direction from your document shepherd or AD before posting a new version of the draft. Document: draft-ietf-ipfix-structured-data-05.txt Reviewer: Suresh Krishnan Review Date: 2011/04/12 IESG Telechat date: 2011/04/14 Summary: This draft is ready for publication as a Proposed Standard but please consider fixing the following issues. Section 2: * This sentence does not read right. However, the amount of information has become so important that, when dealing with highly granular information such as Flow information, a push mechanism (as opposed to a pull mechanism, such as SNMP) is the only solution for routers whose primary function is to route packets. Did you mean that "the amount of information is so large" (or) "collecting this information has become so important" instead of "the amount of information has become so important"? * I understand aggregation based on time but what does "space" mean here? I thought that granular flow export was desired. Can you clarify? Furthermore, in order to reduce the export bandwidth requirements, the network elements have to integrate mediation functions to aggregate the collected information, both in space and time. Thanks Suresh From Quittek@neclab.eu Fri Apr 15 02:50:49 2011 Return-Path: X-Original-To: ipfix@ietfc.amsl.com Delivered-To: ipfix@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id BED62E07A9 for ; Fri, 15 Apr 2011 02:50:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.314 X-Spam-Level: X-Spam-Status: No, score=-102.314 tagged_above=-999 required=5 tests=[AWL=0.286, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ISk6IUYQO0MT for ; Fri, 15 Apr 2011 02:50:48 -0700 (PDT) Received: from smtp0.neclab.eu (smtp0.neclab.eu [195.37.70.41]) by ietfc.amsl.com (Postfix) with ESMTP id 7E63FE0767 for ; Fri, 15 Apr 2011 02:50:48 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp0.neclab.eu (Postfix) with ESMTP id 784612C00008A for ; Fri, 15 Apr 2011 11:51:00 +0200 (CEST) X-Virus-Scanned: Amavisd on Debian GNU/Linux (atlas2.office.hd) Received: from smtp0.neclab.eu ([127.0.0.1]) by localhost (atlas2.office.hd [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kDQ4EBRKftR2 for ; Fri, 15 Apr 2011 11:51:00 +0200 (CEST) Received: from METHONE.office.hd (Methone.office.hd [192.168.24.54]) by smtp0.neclab.eu (Postfix) with ESMTP id 568C32C000089 for ; Fri, 15 Apr 2011 11:50:55 +0200 (CEST) Received: from Polydeuces.office.hd ([169.254.3.246]) by METHONE.office.hd ([192.168.24.54]) with mapi id 14.01.0270.001; Fri, 15 Apr 2011 11:50:43 +0200 From: Juergen Quittek To: IETF IPFIX Working Group Thread-Topic: Paper on IPFIX in IEEE Communication Magazine Thread-Index: Acv7UpSmnN4Oiy2C2Uik/dYFBXLDzQ== Date: Fri, 15 Apr 2011 09:50:42 +0000 Message-ID: Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-Entourage/13.8.0.101117 x-originating-ip: [10.1.2.219] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [IPFIX] Paper on IPFIX in IEEE Communication Magazine X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Apr 2011 09:50:49 -0000 Dear all, There is a nice paper from Brian and Elisa giving an introduction to our WG and the IPFIX protocol in the April issue of the IEEE Communications Magazine. If you have online access to IEEE publications you can find it here: http://dl.comsoc.org/livepubs/ci1/public/2011/apr/index.html Juergen From janovak@cisco.com Fri Apr 15 05:20:48 2011 Return-Path: X-Original-To: ipfix@ietfc.amsl.com Delivered-To: ipfix@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 23C6EE06E6; Fri, 15 Apr 2011 05:20:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zxyaNoNRXi7A; Fri, 15 Apr 2011 05:20:47 -0700 (PDT) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by ietfc.amsl.com (Postfix) with ESMTP id 05331E0688; Fri, 15 Apr 2011 05:20:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=janovak@cisco.com; l=2960; q=dns/txt; s=iport; t=1302870047; x=1304079647; h=mime-version:subject:date:message-id:from:to:cc; bh=b0yutTAlHuBgDrO4oVcHqX8Yep7aqKTbaPUhyHchPcw=; b=QkbsyifshohtCHSXpeve7f9BEENXxGeMtCgLF9OvH/UC98Vj/K+S9MPD /GfTIExrslJGZx2iWDW5Q0oExt25wVg0UGuKX6yqnZzxgvzA17hPb1d3W KRgBQ5LXLcCa2QZrzcd0xOLh1eqR3D6xa+dC8HRXRbZQJVNZn9IvEnpbW o=; X-Files: draft-ietf-bmwg-ipflow-meth-01.URL, ATT9202979.txt : 95, 127 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkUEAIg3qE2Q/khMgWdsb2JhbAClfxQBARYmJaclnHmFbgSRcw X-IronPort-AV: E=Sophos;i="4.64,219,1301875200"; d="url'?txt'?scan'208";a="25859138" Received: from ams-core-3.cisco.com ([144.254.72.76]) by ams-iport-2.cisco.com with ESMTP; 15 Apr 2011 12:20:46 +0000 Received: from xbh-ams-201.cisco.com (xbh-ams-201.cisco.com [144.254.75.7]) by ams-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p3FCKkKd004732; Fri, 15 Apr 2011 12:20:46 GMT Received: from xmb-ams-107.cisco.com ([144.254.74.82]) by xbh-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 15 Apr 2011 14:20:45 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01CBFB67.8BCA8C22" Date: Fri, 15 Apr 2011 14:20:46 +0200 Message-ID: <6674CF9A9F682245A590204F819F78AD04545D65@XMB-AMS-107.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: New Version draft-ietf-bmwg-ipflow-meth-01.txt Thread-Index: Acv7ZtTz0FRTtuJIRi+DO47Des0NlQAAE6XQ From: "Jan Novak (janovak)" To: , X-OriginalArrivalTime: 15 Apr 2011 12:20:45.0990 (UTC) FILETIME=[8C0A9C60:01CBFB67] Subject: [IPFIX] New Version draft-ietf-bmwg-ipflow-meth-01.txt X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Apr 2011 12:20:48 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CBFB67.8BCA8C22 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Hi, I have just re-submitted the Flow Monitoring Perf draft which addresses the comments from WG LC reviews. The reviewers captured numerous valid technical points which improved the document - thanks everyone for that. Jan The climate of Edinburgh is such that the weak succumb young ....=20 and the strong envy them. Dr. Johnson -----Original Message----- From: bmwg-bounces@ietf.org [mailto:bmwg-bounces@ietf.org] On Behalf Of Internet-Drafts@ietf.org Sent: 15 April 2011 13:15 To: i-d-announce@ietf.org Cc: bmwg@ietf.org Subject: [bmwg] I-D Action:draft-ietf-bmwg-ipflow-meth-01.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Benchmarking Methodology Working Group of the IETF. Title : IP Flow Information Accounting and Export Benchmarking Methodology Author(s) : J. Novak Filename : draft-ietf-bmwg-ipflow-meth-01.txt Pages : 31 Date : 2011-04-15 This document provides methodology and framework for quantifying=20 performance impact of monitoring of IP flows on a network device and export of this information to a collector. It identifies the rate at which the IP flows are created, expired and successfully exported as a new performance metric in combination with traditional throughput. =20 The metric is only applicable to the devices compliant with the Architecture for IP Flow Information Export [RFC5470]. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-bmwg-ipflow-meth-01.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. ------_=_NextPart_001_01CBFB67.8BCA8C22 Content-Type: application/octet-stream; name="draft-ietf-bmwg-ipflow-meth-01.URL" Content-Transfer-Encoding: base64 Content-Description: draft-ietf-bmwg-ipflow-meth-01.URL Content-Disposition: attachment; filename="draft-ietf-bmwg-ipflow-meth-01.URL" W0ludGVybmV0U2hvcnRjdXRdDQpVUkw9ZnRwOi8vZnRwLmlldGYub3JnL2ludGVybmV0LWRyYWZ0 cy9kcmFmdC1pZXRmLWJtd2ctaXBmbG93LW1ldGgtMDEudHh0DQo= ------_=_NextPart_001_01CBFB67.8BCA8C22 Content-Type: text/plain; name="ATT9202979.txt" Content-Transfer-Encoding: base64 Content-Description: ATT9202979.txt Content-Disposition: attachment; filename="ATT9202979.txt" X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCmJtd2cgbWFp bGluZyBsaXN0DQpibXdnQGlldGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL2Jtd2cNCg== ------_=_NextPart_001_01CBFB67.8BCA8C22-- From paitken@cisco.com Mon Apr 25 04:45:07 2011 Return-Path: X-Original-To: ipfix@ietfc.amsl.com Delivered-To: ipfix@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 09967E06FB for ; Mon, 25 Apr 2011 04:45:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.482 X-Spam-Level: X-Spam-Status: No, score=-9.482 tagged_above=-999 required=5 tests=[AWL=0.516, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_53=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ujJZfGSuuyjq for ; Mon, 25 Apr 2011 04:45:05 -0700 (PDT) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by ietfc.amsl.com (Postfix) with ESMTP id 769EBE06A4 for ; Mon, 25 Apr 2011 04:45:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=paitken@cisco.com; l=7661; q=dns/txt; s=iport; t=1303731905; x=1304941505; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to; bh=2IoDYacQKHLMSqCnBvLOED2n+LNulnjmn1W0XAt2jrM=; b=NkVXbX1ZXCqLVDgTVJnTCf48aGRi+WnsxisTtFPpXLzL6e2gB1wxzRDy G2SyFpFgUO8rL1P5Qx7DXp9VJao2Mpp8hAPqqVxR+oUJGU9nxqDIbojA+ POQzFVLWBb/P/40vs9vLmbCPt6RB9o1jy3hWVH5Rbrh67uSFgMoaK0jm2 s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgYEAKxdtU2Q/khRgWdsb2JhbAClNBQBARYmJYhwnAScAYV2BI41hAg X-IronPort-AV: E=Sophos;i="4.64,265,1301875200"; d="scan'208,217";a="27011852" Received: from ams-core-1.cisco.com ([144.254.72.81]) by ams-iport-2.cisco.com with ESMTP; 25 Apr 2011 11:45:04 +0000 Received: from cisco.com (mrwint.cisco.com [64.103.71.48]) by ams-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p3PBj4rZ013054; Mon, 25 Apr 2011 11:45:04 GMT Received: from [10.61.73.248] (ams3-vpn-dhcp2552.cisco.com [10.61.73.248]) by cisco.com (8.11.7p3+Sun/8.8.8) with ESMTP id p3PBj2U04622; Mon, 25 Apr 2011 12:45:02 +0100 (BST) Message-ID: <4DB55EBB.3090709@cisco.com> Date: Mon, 25 Apr 2011 12:44:59 +0100 From: Paul Aitken User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.14) Gecko/20110223 Lightning/1.0b2 Thunderbird/3.1.8 MIME-Version: 1.0 To: Chris Inacio References: <3D5C83BC-E710-44FB-8D18-66FD1BF75437@cert.org> In-Reply-To: <3D5C83BC-E710-44FB-8D18-66FD1BF75437@cert.org> Content-Type: multipart/alternative; boundary="------------020702020702080903080301" Cc: "ipfix@ietf.org" , "ipfix-chairs@tools.ietf.org" Subject: Re: [IPFIX] [Sender: ipfix-bounces@ietf.org] some comments on IANA IPFIX XML X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Apr 2011 11:45:07 -0000 This is a multi-part message in MIME format. --------------020702020702080903080301 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Chris, > The way IANA specifies the IPFIX registry for IE's is a little > twisted. > > First, I can't validate the XML. I can get the ipfix.xml and the > ipfix.xsd, but it is wrapped in "registry" elements, which are not > described in ipfix.xsd (presumably they are defined somewhere in > IANA for use across their registries.) > > Another little nit about registries: There are 2 registries in the > ipfix.xml. The first one describes the broad rules about IE's (0 > is reserved, 1-127 is reserved for NetFlow v9 compatibility (with > expert review), and 128-32767 are for new (with expert review)). The > second one is a list of the IE's. Registry elements _can_ contain > created on and modified on dates. Ideally, yes. Perhaps the WG chairs would ask IANA to add and maintain this. > Unfortunately, in the ipfix.xml file, the first registry entry does > contain the created and modified on dates, while the second one > (with the actual elements) doesn't contain any created on/updated on > time stamps. So they are time stamping the wrong record in the > official registry. Not so: the "created" and "updated" timestamps are at the outermost level, so they apply to the entire set of IANA IPFIX assignments. > It would be really great to wrap the record entries (defined in > ipfix.xsd, each record represents an IE,) within another record > which records a PEN - so that people can publish their PEN's in a > standard way. A slightly different encoding is needed for the IANA standard versus PEN elements, since PEN doesn't apply to the standard elements. It would be misleading to specify one - or even to specify a "not applicable" value. > The current record definition allows marking up an IE with a > "status" field. The possible entries for status are: current, > deprecated, obsolete. It would be really cool to also have > "transitioned", and then a pointer to another registry. Along with > that, I would want to time stamp the IE's separately, and to put in a > pointer to the transitioned to location. This would allow me to put > something wrapped in my PEN in a standard way, propose it to IANA, > get it moved, and then reuse that IE number in my space in the > future. I would need to leave the record in my IE XML forever, > assuming collector operators might not delete the corresponding > records "for a really long time." Collectors would then be required > to use the time stamps in the flow records to resolve IE's correctly. > Is that more complicated? Absolutely. But it does make IE's a lot > more portable between everyone, and people can then reuse IE's. I was thinking of doing something similar in the exported data, so that an updated exporter can send a table of "I used to export " versus "now I export ". The IEs could be private or public. Then a collector can seamlessly map between old and new data received from that device. Cheers, P. --------------020702020702080903080301 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Chris,

> The way IANA specifies the IPFIX registry for IE's is a little
> twisted.
>
> First, I can't validate the XML. I can get the ipfix.xml and the
> ipfix.xsd, but it is wrapped in "registry" elements, which are not
> described in ipfix.xsd (presumably they are defined somewhere in
> IANA for use across their registries.)
>
> Another little nit about registries: There are 2 registries in the
> ipfix.xml. The first one describes the broad rules about IE's (0
> is reserved, 1-127 is reserved for NetFlow v9 compatibility (with
> expert review), and 128-32767 are for new (with expert review)). The
> second one is a list of the IE's. Registry elements _can_ contain
> created on and modified on dates.

Ideally, yes.

Perhaps the WG chairs would ask IANA to add and maintain this.


> Unfortunately, in the ipfix.xml file, the first registry entry does
> contain the created and modified on dates, while the second one
> (with the actual elements) doesn't contain any created on/updated on
> time stamps. So they are time stamping the wrong record in the
> official registry.

Not so: the "created" and "updated" timestamps are at the outermost level, so they apply to the entire set of IANA IPFIX assignments.


> It would be really great to wrap the record entries (defined in
> ipfix.xsd, each record represents an IE,) within another record
> which records a PEN - so that people can publish their PEN's in a
> standard way.

A slightly different encoding is needed for the IANA standard versus PEN elements, since PEN doesn't apply to the standard elements.
It would be misleading to specify one - or even to specify a "not applicable" value.


> The current record definition allows marking up an IE with a
> "status" field. The possible entries for status are: current,
> deprecated, obsolete. It would be really cool to also have
> "transitioned", and then a pointer to another registry. Along with
> that, I would want to time stamp the IE's separately, and to put in a
> pointer to the transitioned to location. This would allow me to put
> something wrapped in my PEN in a standard way, propose it to IANA,
> get it moved, and then reuse that IE number in my space in the
> future. I would need to leave the record in my IE XML forever,
> assuming collector operators might not delete the corresponding
> records "for a really long time." Collectors would then be required
> to use the time stamps in the flow records to resolve IE's correctly.
> Is that more complicated? Absolutely. But it does make IE's a lot
> more portable between everyone, and people can then reuse IE's.

I was thinking of doing something similar in the exported data, so that an updated exporter can send a table of "I used to export <this-old-IE>" versus "now I export <this-new-IE>". The IEs could be private or public. Then a collector can seamlessly map between old and new data received from that device.

Cheers,
P.

--------------020702020702080903080301-- From paitken@cisco.com Tue Apr 26 04:21:46 2011 Return-Path: X-Original-To: ipfix@ietfa.amsl.com Delivered-To: ipfix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A99EDE0728 for ; Tue, 26 Apr 2011 04:21:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.672 X-Spam-Level: X-Spam-Status: No, score=-3.672 tagged_above=-999 required=5 tests=[AWL=-6.928, BAYES_00=-2.599, FRT_LITTLE=1.555, J_CHICKENPOX_37=0.6, MANGLED_CIALIS=2.5, MANGLED_LIPS=2.3, MANGLED_LOAN=2.3, MANGLED_PILL=2.3, MANGLED_RATES=2.3, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YqOnpxk2T9Tp for ; Tue, 26 Apr 2011 04:21:45 -0700 (PDT) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by ietfa.amsl.com (Postfix) with ESMTP id E2297E0723 for ; Tue, 26 Apr 2011 04:21:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=paitken@cisco.com; l=4549; q=dns/txt; s=iport; t=1303816905; x=1305026505; h=message-id:date:from:mime-version:to:subject: content-transfer-encoding; bh=r+qI9WiLWkB21deC0x8vrjMWlJgdhGRoSwKV+nk4ArQ=; b=Z79e28BhfR6HT36KdAs12F09VGkSUKca2A61Z7OFgX+H6IYiBiHYUPq5 JfZbcZ2Z2xrhu7JwoS3VegjYqxVVR5wIyGE1oconSx8xacCQzOMxtErVj InGTDqVrf/1JDR5tV90nc/lhitixOK3VyDcOxz7H2L6v6DypZ7NnRS4au U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAD6qtk2tJXG8/2dsb2JhbAClRHenFp0ahXYEjj+EDIoV X-IronPort-AV: E=Sophos;i="4.64,267,1301875200"; d="scan'208";a="302095340" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by sj-iport-3.cisco.com with ESMTP; 26 Apr 2011 11:21:45 +0000 Received: from cisco.com (mrwint.cisco.com [64.103.71.48]) by rcdn-core2-1.cisco.com (8.14.3/8.14.3) with ESMTP id p3QBLiwf002131 for ; Tue, 26 Apr 2011 11:21:44 GMT Received: from [144.254.153.54] (dhcp-144-254-153-54.cisco.com [144.254.153.54]) by cisco.com (8.11.7p3+Sun/8.8.8) with ESMTP id p3QBLgU11748 for ; Tue, 26 Apr 2011 12:21:43 +0100 (BST) Message-ID: <4DB6AAC4.4080400@cisco.com> Date: Tue, 26 Apr 2011 12:21:40 +0100 From: Paul Aitken User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.14) Gecko/20110223 Lightning/1.0b2 Thunderbird/3.1.8 MIME-Version: 1.0 To: IETF IPFIX Working Group Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [IPFIX] IPFIX bit ordering errata X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Apr 2011 11:21:46 -0000 Dear IPFIXers, Has anyone implemented an exporter or collector for the following IPFIX fields which have errata? : isMulticast (RFC 5102, Section 5.4.22; errata 1736) ipv4Options (RFC 5102, Section 5.8.5; errata 1737) ipv6ExtensionHeaders (RFC 5102, Section 5.8.6; errata 1738) tcpOptions (RFC 5102, Section 5.8.8; errata 1739) It has been pointed out to me that the above errata are still wrong :-( In short, not only should the bits within the octets be flipped around MSB to LSB (per the existing errata), but the octets themselves should also be flipped first-to-last in order to completely reverse the bit ordering from what is currently shown. I believe the figures should be as shown below. I'd like to check whether anyone else has implemented these fields and what bit ordering they've used so we can propose a minimal set of changes to get this sorted. Thanks, P. ============================================================ 1. isMulticast Since isMulticast is a single octet, I believe the figure in errata 1736 is correct: 0 1 2 3 4 5 6 7 +------+------+------+------+------+------+------+------+ | IPv6 multicast scope | T | RES. | RES. | MCv4 | +------+------+------+------+------+------+------+------+ ============================================================ 2. ipv4Options Per the "IP OPTION NUMBERS" table at http://www.iana.org/assignments/ip-parameters and the table (though not the figure) in section 5.8.5. of RFC 5102, I believe that the ipv4Options figure should show: 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |E| | | | |Q|U|D|N|S|R|A|T|E|I|E|V|F|M|M|Z|S|S|R|C|E|T|L|S|N|E| | |X| | | | |S|M|P|S|D|T|D|R|I|M|N|I|I|T|T|S|S|I|R|I|-|S|S|E|O|O| | |P| | | | | |P|S|A|B|R|D| |P|I|C|S|N|U|U|U|R|D| |P|S| |R|C|P|O| | | | | | | | | | |P| |A|E| | |T|O|A|N|R|P| | | | |S|E| | | | |L| | | | | | | | | | |A| |L|X| | |D|D| | | | | | | | |O|C| | | | | | | | | | | | | | | | | |T|T| | | |E| | | | | | | | | | | | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ MSB LSB Allocation of the undefined bits follows IANA's "IP OPTION NUMBERS" registry. ============================================================ 3. ipv6ExtensionHeaders Per the table (though not the figure) in section 5.8.6 of RFC 5102, I believe that the ipv6ExtensionHeaders figure should show: 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |E|A|P|D|H|R|U|F|R|F|R| | Reserved |S|H|A|S|O|e|N|R|H|R|e| | |P| |Y|T|P|s|K|A| |A|s| | | | | | | | | |0| |1| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ MSB LSB ============================================================ 4. tcpOptions Per the "TCP Option Kind Numbers" table at http://www.iana.org/assignments/tcp-parameters/tcp-parameters.xml I believe that the tcpOPtions figure should show: 0 3 4 6 6 0 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 +-...-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | R | | |T|T|Q|C| |S|C|R|S|S|M|T|B|S|A|A|C|C|C|P|P|T|R|E|S|S|W|M|N|E| | e | | |C|M|S|O| |N|E|B|N|C|D|C|U|K|C|C|C|C|C|O|O|S|E|C|A|A|S|S|O|O| | s | | |P|O|R|M| |A| | |A|P|5|O|B|T|D|R|E|N|O|S|C|O|P|H|C|C|O|S|P|O| | e | | |A|U|S|P| |P| | | |S| | |B|R| | |C|E|B|P|P|P|L|O|K|K|P| | |L| | r | | |O|T|P| | | | | | | | | |A| | | |H|W|S| | |T|Y| | |P|T| | | | +-...-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ MSB LSB Allocation of the "Reserved" bits follows IANA's "TCP Option Kind Numbers" registry. ============================================================ From wwwrun@rfc-editor.org Thu Apr 28 06:53:19 2011 Return-Path: X-Original-To: ipfix@ietfa.amsl.com Delivered-To: ipfix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C143AE070D for ; Thu, 28 Apr 2011 06:53:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.341 X-Spam-Level: X-Spam-Status: No, score=-102.341 tagged_above=-999 required=5 tests=[AWL=0.259, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qjh34IEf1JsP for ; Thu, 28 Apr 2011 06:53:19 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:1112:1::2f]) by ietfa.amsl.com (Postfix) with ESMTP id 50A21E0669 for ; Thu, 28 Apr 2011 06:53:19 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 01D35E0742; Thu, 28 Apr 2011 06:53:19 -0700 (PDT) To: bclaise@cisco.com, dromasca@avaya.com, rbonica@juniper.net, n.brownlee@auckland.ac.nz, quittek@neclab.eu From: RFC Errata System Message-Id: <20110428135319.01D35E0742@rfc-editor.org> Date: Thu, 28 Apr 2011 06:53:19 -0700 (PDT) Cc: adrian.farrel@huawei.com, ipfix@ietf.org, rfc-editor@rfc-editor.org Subject: [IPFIX] [Technical Errata Reported] RFC5101 (2791) X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Apr 2011 13:53:19 -0000 The following errata report has been submitted for RFC5101, "Specification of the IP Flow Information Export (IPFIX) Protocol for the Exchange of IP Traffic Flow Information". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=5101&eid=2791 -------------------------------------- Type: Technical Reported by: Adrian Farrel Section: 7 Original Text ------------- If the length of the Information Element is greater than or equal to 255 octets, the length is encoded into 3 octets before the Information Element. The first octet is 255, and the length is carried in the second and third octets, as shown in Figure S. Corrected Text -------------- The length may also be encoded into 3 octets before the Information element allowing the length of the Information Element to be greater than or equal to 255 octets. In this case, first octet of the Lenght field MUST be 255, and the length is carried in the second and third octets, as shown in Figure S. Notes ----- The original text is ambiguous as to whether it is possible to carry a length of less than 255 encoded in a 3 octet Length field. The quoted text seems to say it is not allowed, but Figure S says that the 2nd and 3rd octets may be set to "Length (0 to 65535)". Since there is absolutely no harm (except a little inefficiency) in using a 3 octet Length field to encode a small length, the document should be clarified to remove the ambiguity. Instructions: ------------- This errata is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary. -------------------------------------- RFC5101 (draft-ietf-ipfix-protocol-26) -------------------------------------- Title : Specification of the IP Flow Information Export (IPFIX) Protocol for the Exchange of IP Traffic Flow Information Publication Date : January 2008 Author(s) : B. Claise, Ed. Category : PROPOSED STANDARD Source : IP Flow Information Export Area : Operations and Management Stream : IETF Verifying Party : IESG From wwwrun@rfc-editor.org Thu Apr 28 06:58:39 2011 Return-Path: X-Original-To: ipfix@ietfa.amsl.com Delivered-To: ipfix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 23765E071E for ; Thu, 28 Apr 2011 06:58:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.347 X-Spam-Level: X-Spam-Status: No, score=-102.347 tagged_above=-999 required=5 tests=[AWL=0.253, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IUsmh5cH5Tdb for ; Thu, 28 Apr 2011 06:58:36 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:1112:1::2f]) by ietfa.amsl.com (Postfix) with ESMTP id 75CD4E0717 for ; Thu, 28 Apr 2011 06:58:36 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 6E0F5E076B; Thu, 28 Apr 2011 06:58:36 -0700 (PDT) To: bclaise@cisco.com, dromasca@avaya.com, rbonica@juniper.net, n.brownlee@auckland.ac.nz, quittek@neclab.eu From: RFC Errata System Message-Id: <20110428135836.6E0F5E076B@rfc-editor.org> Date: Thu, 28 Apr 2011 06:58:36 -0700 (PDT) Cc: adrian.farrel@huawei.com, ipfix@ietf.org, rfc-editor@rfc-editor.org Subject: [IPFIX] [Editorial Errata Reported] RFC5101 (2792) X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Apr 2011 13:58:39 -0000 The following errata report has been submitted for RFC5101, "Specification of the IP Flow Information Export (IPFIX) Protocol for the Exchange of IP Traffic Flow Information". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=5101&eid=2792 -------------------------------------- Type: Editorial Reported by: Adrian Farrel Section: A.5.2 Original Text ------------- A.5.2. Example of Variable-Length Information Element with Length 255 to 65535 Octets Corrected Text -------------- A.5.2. Example of Variable-Length Information Element with 3 Octet Length Encoding Notes ----- Per Erratum 2791, this section header should be changed to reflect that the 3 octet Lenght encoding supports lengths of less than 255 as well as greater than or equal to 255. Note that there is a corresponding change in the Table of Contents Instructions: ------------- This errata is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary. -------------------------------------- RFC5101 (draft-ietf-ipfix-protocol-26) -------------------------------------- Title : Specification of the IP Flow Information Export (IPFIX) Protocol for the Exchange of IP Traffic Flow Information Publication Date : January 2008 Author(s) : B. Claise, Ed. Category : PROPOSED STANDARD Source : IP Flow Information Export Area : Operations and Management Stream : IETF Verifying Party : IESG From paitken@cisco.com Thu Apr 28 07:07:37 2011 Return-Path: X-Original-To: ipfix@ietfa.amsl.com Delivered-To: ipfix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 88BAFE06F0 for ; Thu, 28 Apr 2011 07:07:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.51 X-Spam-Level: X-Spam-Status: No, score=-9.51 tagged_above=-999 required=5 tests=[AWL=1.089, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wuO0JSjkaARa for ; Thu, 28 Apr 2011 07:07:35 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id 8E9E2E06E0 for ; Thu, 28 Apr 2011 07:07:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=paitken@cisco.com; l=975; q=dns/txt; s=iport; t=1303999655; x=1305209255; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=VS3KQe+hRujL6gKpwJlutRI6yB9Ijpprh0Wu/y77668=; b=KdwJLTlrTmTnri5QYFREwsNDRPpGY/VjWUMvX6Ed1VJelwliNLYBKtj/ QmcBvbYkWnWviQAhxK+NvHUaAWzYJelapZ661oGLRAFG/PmqUx0L24Ixq Iu0Ex52wuSe8dUaxbq4gMLJl2mM+2zOtDK4AdvcLx4Ftlm/IKGV5Yf6Z/ s=; X-IronPort-AV: E=Sophos;i="4.64,280,1301875200"; d="scan'208";a="85770104" Received: from ams-core-4.cisco.com ([144.254.72.77]) by ams-iport-1.cisco.com with ESMTP; 28 Apr 2011 14:07:34 +0000 Received: from cisco.com (mrwint.cisco.com [64.103.71.48]) by ams-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p3SE7Yxu017885; Thu, 28 Apr 2011 14:07:34 GMT Received: from [10.61.95.153] (ams3-vpn-dhcp8090.cisco.com [10.61.95.153]) by cisco.com (8.11.7p3+Sun/8.8.8) with ESMTP id p3SE7WU16181; Thu, 28 Apr 2011 15:07:32 +0100 (BST) Message-ID: <4DB974A4.3050901@cisco.com> Date: Thu, 28 Apr 2011 15:07:32 +0100 From: Paul Aitken User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.14) Gecko/20110223 Lightning/1.0b2 Thunderbird/3.1.8 MIME-Version: 1.0 To: adrian.farrel@huawei.com References: <20110428135319.01D35E0742@rfc-editor.org> In-Reply-To: <20110428135319.01D35E0742@rfc-editor.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: ipfix@ietf.org, rbonica@juniper.net, n.brownlee@auckland.ac.nz, RFC Errata System Subject: Re: [IPFIX] [Technical Errata Reported] RFC5101 (2791) X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Apr 2011 14:07:37 -0000 Adrian, "allowing the length of the Information Element to be greater than or equal to 255 octets" doesn't clearly state that 0-254 are also acceptable. So with your agreement, I'd like to modify your "Corrected Text" : OLD The length may also be encoded into 3 octets before the Information element allowing the length of the Information Element to be greater than or equal to 255 octets. In this case, first octet of the Lenght field MUST be 255, and the length is carried in the second and third octets, as shown in Figure S. NEW The length may also be encoded into 3 octets before the Information element allowing the length of the Information Element to be between 0 and 65535 octets. In this case, the first octet of the Length field MUST be 255, and the length is carried in the second and third octets, as shown in Figure S. Also NB: I added "the" and corrected "Lenght". Cheers. P. From dromasca@avaya.com Thu Apr 28 08:33:37 2011 Return-Path: X-Original-To: ipfix@ietfa.amsl.com Delivered-To: ipfix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 59EBDE071E for ; Thu, 28 Apr 2011 08:33:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.126 X-Spam-Level: X-Spam-Status: No, score=-103.126 tagged_above=-999 required=5 tests=[AWL=0.473, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8ViHbyfReyVq for ; Thu, 28 Apr 2011 08:33:36 -0700 (PDT) Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) by ietfa.amsl.com (Postfix) with ESMTP id A87B8E06FB for ; Thu, 28 Apr 2011 08:33:36 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiEBANGHuU3GmAcF/2dsb2JhbACYEo1wd6hvAppFhXYEkwyJWw X-IronPort-AV: E=Sophos;i="4.64,281,1301889600"; d="scan'208";a="277054264" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by co300216-co-outbound.net.avaya.com with ESMTP; 28 Apr 2011 11:33:35 -0400 X-IronPort-AV: E=Sophos;i="4.64,281,1301889600"; d="scan'208";a="613954860" Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.12]) by co300216-co-erhwest-out.avaya.com with ESMTP; 28 Apr 2011 11:33:33 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 28 Apr 2011 17:33:32 +0200 Message-ID: In-Reply-To: <08ee01cc05b8$bcc57400$36505c00$@huawei.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [IPFIX] [Technical Errata Reported] RFC5101 (2791) Thread-Index: AQJicMbAgB2B7qWMzIPhyBOqZda7awG6ukPTkzi5BRCAAALFUA== References: <20110428135319.01D35E0742@rfc-editor.org> <4DB974A4.3050901@cisco.com> <08ee01cc05b8$bcc57400$36505c00$@huawei.com> From: "Romascanu, Dan (Dan)" To: , "Paul Aitken" Cc: ipfix@ietf.org, rbonica@juniper.net, n.brownlee@auckland.ac.nz, RFC Errata System Subject: Re: [IPFIX] [Technical Errata Reported] RFC5101 (2791) X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Apr 2011 15:33:37 -0000 ACK. Dan=20 =20 > -----Original Message----- > From: Adrian Farrel [mailto:Adrian.Farrel@huawei.com]=20 > Sent: Thursday, April 28, 2011 6:27 PM > To: 'Paul Aitken' > Cc: 'RFC Errata System'; bclaise@cisco.com; Romascanu, Dan=20 > (Dan); rbonica@juniper.net; n.brownlee@auckland.ac.nz;=20 > quittek@neclab.eu; ipfix@ietf.org > Subject: RE: [IPFIX] [Technical Errata Reported] RFC5101 (2791) >=20 > Paul, >=20 > Lenght is my favourite typo. >=20 > wfm >=20 > Resolving AD can patch it up. >=20 > A >=20 > > -----Original Message----- > > From: Paul Aitken [mailto:paitken@cisco.com] > > Sent: 28 April 2011 15:08 > > To: Adrian.Farrel@huawei.com > > Cc: RFC Errata System; bclaise@cisco.com; dromasca@avaya.com;=20 > > rbonica@juniper.net; n.brownlee@auckland.ac.nz; quittek@neclab.eu;=20 > > ipfix@ietf.org > > Subject: Re: [IPFIX] [Technical Errata Reported] RFC5101 (2791) > >=20 > > Adrian, > >=20 > > "allowing the length of the Information Element to be=20 > greater than or=20 > > equal to 255 octets" doesn't clearly state that 0-254 are=20 > also acceptable. > >=20 > > So with your agreement, I'd like to modify your "Corrected Text" : > >=20 > >=20 > > OLD > >=20 > > The length may also be encoded into 3 octets before the=20 > Information > > element allowing the length of the Information Element to be > > greater than or equal to 255 octets. In this case,=20 > first octet of > > the Lenght field MUST be 255, and the length is carried in the > > second and third octets, as shown in Figure S. > >=20 > >=20 > > NEW > >=20 > > The length may also be encoded into 3 octets before the=20 > Information > > element allowing the length of the Information Element to be > > between 0 and 65535 octets. In this case, the first octet of > > the Length field MUST be 255, and the length is carried in the > > second and third octets, as shown in Figure S. > >=20 > >=20 > > Also NB: I added "the" and corrected "Lenght". > >=20 > >=20 > > Cheers. > > P. >=20 >=20 From Adrian.Farrel@huawei.com Thu Apr 28 08:27:11 2011 Return-Path: X-Original-To: ipfix@ietfa.amsl.com Delivered-To: ipfix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9AFFAE06E4 for ; Thu, 28 Apr 2011 08:27:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.932 X-Spam-Level: X-Spam-Status: No, score=-103.932 tagged_above=-999 required=5 tests=[AWL=-1.333, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M3IK4T3P6364 for ; Thu, 28 Apr 2011 08:27:11 -0700 (PDT) Received: from usaga01-in.huawei.com (usaga01-in.huawei.com [206.16.17.211]) by ietfa.amsl.com (Postfix) with ESMTP id 1B1C0E0670 for ; Thu, 28 Apr 2011 08:27:11 -0700 (PDT) Received: from huawei.com (usaml01-in [172.18.4.6]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LKD002OHC9917@usaga01-in.huawei.com> for ipfix@ietf.org; Thu, 28 Apr 2011 10:27:09 -0500 (CDT) Received: from 950129200 (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LKD00E1EC96XH@usaga01-in.huawei.com> for ipfix@ietf.org; Thu, 28 Apr 2011 10:27:09 -0500 (CDT) Date: Thu, 28 Apr 2011 16:26:59 +0100 From: Adrian Farrel In-reply-to: <4DB974A4.3050901@cisco.com> To: 'Paul Aitken' Message-id: <08ee01cc05b8$bcc57400$36505c00$@huawei.com> MIME-version: 1.0 X-Mailer: Microsoft Outlook 14.0 Content-type: text/plain; charset=us-ascii Content-language: en-gb Content-transfer-encoding: 7BIT Thread-index: AQJicMbAgB2B7qWMzIPhyBOqZda7awG6ukPTkzi5BRA= References: <20110428135319.01D35E0742@rfc-editor.org> <4DB974A4.3050901@cisco.com> X-Mailman-Approved-At: Thu, 28 Apr 2011 14:37:48 -0700 Cc: ipfix@ietf.org, rbonica@juniper.net, n.brownlee@auckland.ac.nz, 'RFC Errata System' Subject: Re: [IPFIX] [Technical Errata Reported] RFC5101 (2791) X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Adrian.Farrel@huawei.com List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Apr 2011 15:27:11 -0000 Paul, Lenght is my favourite typo. wfm Resolving AD can patch it up. A > -----Original Message----- > From: Paul Aitken [mailto:paitken@cisco.com] > Sent: 28 April 2011 15:08 > To: Adrian.Farrel@huawei.com > Cc: RFC Errata System; bclaise@cisco.com; dromasca@avaya.com; > rbonica@juniper.net; n.brownlee@auckland.ac.nz; quittek@neclab.eu; > ipfix@ietf.org > Subject: Re: [IPFIX] [Technical Errata Reported] RFC5101 (2791) > > Adrian, > > "allowing the length of the Information Element to be greater than or > equal to 255 octets" doesn't clearly state that 0-254 are also acceptable. > > So with your agreement, I'd like to modify your "Corrected Text" : > > > OLD > > The length may also be encoded into 3 octets before the Information > element allowing the length of the Information Element to be > greater than or equal to 255 octets. In this case, first octet of > the Lenght field MUST be 255, and the length is carried in the > second and third octets, as shown in Figure S. > > > NEW > > The length may also be encoded into 3 octets before the Information > element allowing the length of the Information Element to be > between 0 and 65535 octets. In this case, the first octet of > the Length field MUST be 255, and the length is carried in the > second and third octets, as shown in Figure S. > > > Also NB: I added "the" and corrected "Lenght". > > > Cheers. > P.