From Sujay_Gupta@infosys.com Thu Oct 1 01:07:36 2009 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 190DF3A68EA for ; Thu, 1 Oct 2009 01:07:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.659 X-Spam-Level: X-Spam-Status: No, score=-1.659 tagged_above=-999 required=5 tests=[AWL=-0.550, BAYES_05=-1.11, 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 EQZgxiOGAZqg for ; Thu, 1 Oct 2009 01:07:33 -0700 (PDT) Received: from KECGATE08.infosys.com (Kecgate08.infosys.com [122.98.10.33]) by core3.amsl.com (Postfix) with ESMTP id 094213A6AA2 for ; Thu, 1 Oct 2009 01:07:32 -0700 (PDT) X-TM-IMSS-Message-ID: <534cb8d8000a70eb@KECGATE08.infosys.com> Received: from blrkechub01.ad.infosys.com ([10.66.236.41]) by KECGATE08.infosys.com ([122.98.10.33]) with ESMTP (TREND IMSS SMTP Service 7.0) id 534cb8d8000a70eb ; Thu, 1 Oct 2009 13:38:50 +0530 Received: from BLRKECMBX10.ad.infosys.com ([20.20.20.43]) by blrkechub01.ad.infosys.com ([10.66.236.41]) with mapi; Thu, 1 Oct 2009 13:38:54 +0530 From: Sujay Gupta To: "ipfix@ietf.org" Date: Thu, 1 Oct 2009 13:38:51 +0530 Thread-Topic: [RFC 3917]Overload & Reliability requirements of Metering process Thread-Index: AcpCbmk+vYuFqljCS7+9uwVyupiouA== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_D83DA0FBF870784BAFF69D2B3643A804813A21DDBLRKECMBX10adin_" MIME-Version: 1.0 Subject: [IPFIX] [RFC 3917]Overload & Reliability requirements of Metering process 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, 01 Oct 2009 08:07:36 -0000 --_000_D83DA0FBF870784BAFF69D2B3643A804813A21DDBLRKECMBX10adin_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, While I do understand the need for reliability and overload requirements fr= om Metering process as in Section 5.1./5.3 RFC 3917 Specifically these IE's; ignoredPacketTotalCount, ignoredOctetTotalCount, notSentFlowTotalCount, not= SentPacketTotalCount Are there collector app's in the market interpreting them? BR, -Sujay --_000_D83DA0FBF870784BAFF69D2B3643A804813A21DDBLRKECMBX10adin_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

While I do understand the need for reliability and ove= rload requirements from Metering process as in Section 5.1./5.3 RFC 3917

 

Specifically these IE’s;

ignoredPacketTotalCount, ignoredOctetTotalCount, notSe= ntFlowTotalCount, notSentPacketTotalCount

 

Are there collector app’s in the market interpre= ting them?

 

BR,

-Sujay

--_000_D83DA0FBF870784BAFF69D2B3643A804813A21DDBLRKECMBX10adin_-- From dromasca@avaya.com Fri Oct 2 03:31:01 2009 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 23F0728B23E; Fri, 2 Oct 2009 03:31:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.467 X-Spam-Level: X-Spam-Status: No, score=-2.467 tagged_above=-999 required=5 tests=[AWL=0.132, 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 khkkMGcGyhqb; Fri, 2 Oct 2009 03:31:00 -0700 (PDT) Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) by core3.amsl.com (Postfix) with ESMTP id 7316428C0D8; Fri, 2 Oct 2009 03:30:58 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.44,493,1249272000"; d="scan'208";a="158655251" Received: from unknown (HELO nj300815-nj-erheast.avaya.com) ([198.152.6.5]) by de307622-de-outbound.net.avaya.com with ESMTP; 02 Oct 2009 06:32:23 -0400 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.16]) by nj300815-nj-erheast-out.avaya.com with ESMTP; 02 Oct 2009 06:32:22 -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: Fri, 2 Oct 2009 12:32:06 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Need for WebEx at IETF 76 thread-index: AcpC62cK+Vp4d9meScWEUESp+2mT7QAXlQ/Q From: "Romascanu, Dan (Dan)" To: , "OPS Area (E-mail)" , "radext mailing list" , , , , "IETF IPFIX Working Group" Subject: [IPFIX] FW: Need for WebEx at IETF 76 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, 02 Oct 2009 10:31:01 -0000 =20 -----Original Message----- From: iesg-bounces@ietf.org [mailto:iesg-bounces@ietf.org] On Behalf Of Alexa Morris Sent: Friday, October 02, 2009 1:03 AM To: The IESG Subject: Need for WebEx at IETF 76 I'd like to know if any of you might need to use WebEx for any working group sessions taking place at IETF 76. Please note that at present I'm looking more for a "I need WebEx because one of my key presenters will not be physically present"=20 From juarezpsj@gmail.com Sun Oct 4 14:06:24 2009 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 299073A6881 for ; Sun, 4 Oct 2009 14:06:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.185 X-Spam-Level: X-Spam-Status: No, score=-0.185 tagged_above=-999 required=5 tests=[BAYES_40=-0.185] 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 08Lse0UdtRZq for ; Sun, 4 Oct 2009 14:06:23 -0700 (PDT) Received: from mail-yw0-f185.google.com (mail-yw0-f185.google.com [209.85.211.185]) by core3.amsl.com (Postfix) with ESMTP id 5FC293A683D for ; Sun, 4 Oct 2009 14:06:23 -0700 (PDT) Received: by ywh15 with SMTP id 15so2212157ywh.5 for ; Sun, 04 Oct 2009 14:07:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type; bh=vhBu9EA9new9Qd4ohyR4YzNtmT3zftDX+SmNGpROSjo=; b=AH3HrGs+nvxAxz7VPtq+T08E56hlPLMbpPM7Eib6/kvEtb+tq4mplrpFH4zG4IfYR9 tM/cj/V0XRVg7MKWcGQyvPXIWcXYV8v0Velh85hnwO1Uf0DXW+/SRS6fTJkyGZQ+WR/l l7vupQkUdaotTXpqDxknoWHroGaJGuVGhZmfQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=CLhQiRz5ajkiwPbL/RbuOr3Penr2fPhCcrjeMUqNqOsAeIibQouphPP2LGep4jnWDU vAiHV5VYjHlZ5pqwd/ufU8D0yLrDKlPGSrRrUto3vr8kXuLO1lMYh3uTsvrKPqQsh7Yg fo1AjaYzwBR4YltXXPYj9Rfqh1MZmgwD2PBbc= MIME-Version: 1.0 Received: by 10.151.25.21 with SMTP id c21mr8654130ybj.23.1254690471479; Sun, 04 Oct 2009 14:07:51 -0700 (PDT) Date: Sun, 4 Oct 2009 18:07:51 -0300 Message-ID: <47d693270910041407p21fd012aj44c752e7c3ceed9a@mail.gmail.com> From: Juarez Paulino To: ipfix@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: [IPFIX] IPFIX / Netflow 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: Sun, 04 Oct 2009 21:06:24 -0000 Hello friends, I have a simple question and maybe a stupid one. Anyway, I will do this: Why do ipfix implementations such as vermont, maji, YAF(silk) just export ipfix messages and not netflow v9 messages? I mean I know that such implementations - for those which implements a simple capable collector - can aparently read netflow v9 messages or at least show it on stdout. This is also vermont's case. But is there any specific reason for not exporting? Is there some legal restrictions with cisco? Or is just a matter of estabilishing and defining only what is written on the most promising standard (RFC 5101)?? I know the requirements about netflow v9 (RFC 3954) and IPFIX (RFC 5101) and also that IPFIX was an improvement standadization of netflow v9. I know also some differences as a 16-bit field on the headers and some not compatible information elements's id. But it all seems to be easy to implement... My main concerns is about a great fraction of users/clients whose have only paid closed netflow v9 collectors and expects receiving netflow v9 messages. I think that it would be great if some of these ipfix implementations could also be exporting these messages. Sorry if this is a irrelevant or repeated discussion, but I would apreciate if someone clarify it to me. Thanks all, -- Juarez Paulino From muenz@net.in.tum.de Sun Oct 4 15:17:03 2009 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 1EB093A682D for ; Sun, 4 Oct 2009 15:17:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.76 X-Spam-Level: X-Spam-Status: No, score=-0.76 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, 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 QxtchFgeQI+y for ; Sun, 4 Oct 2009 15:17:02 -0700 (PDT) Received: from smtp.cs.uni-tuebingen.de (u-173-c156.cs.uni-tuebingen.de [134.2.173.156]) by core3.amsl.com (Postfix) with ESMTP id 02DEC3A67E9 for ; Sun, 4 Oct 2009 15:17:01 -0700 (PDT) Received: from ppp-93-104-76-211.dynamic.mnet-online.de ([93.104.76.211] helo=[192.168.128.99]) by smtp.cs.uni-tuebingen.de with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1MuZPW-0003Uv-Bx; Mon, 05 Oct 2009 00:18:34 +0200 Message-ID: <4AC91F3D.1080709@net.in.tum.de> Date: Mon, 05 Oct 2009 00:18:37 +0200 From: Gerhard Muenz User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Juarez Paulino References: <47d693270910041407p21fd012aj44c752e7c3ceed9a@mail.gmail.com> In-Reply-To: <47d693270910041407p21fd012aj44c752e7c3ceed9a@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Cc: ipfix@ietf.org Subject: Re: [IPFIX] IPFIX / Netflow 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: Sun, 04 Oct 2009 22:17:03 -0000 Hi Juarez, I can talk for vermont only. We do not use any netflow v9 collectors (apart from vermont itself), therefore we do not have this problem. But vermont is an open-source project. So, if you want to implement a Netflow.v9 exporter for vermont, you are very welcome to join the developer team :) BTW, there are netflow.v9 exporters out there (e.g., ntop). Regards, Gerhard Juarez Paulino wrote: > Hello friends, > > I have a simple question and maybe a stupid one. Anyway, I will do this: > > Why do ipfix implementations such as vermont, maji, YAF(silk) just > export ipfix messages and not netflow v9 messages? > > I mean I know that such implementations - for those which implements a > simple capable collector - can aparently read netflow v9 messages or > at least show it on stdout. This is also vermont's case. But is there > any specific reason for not exporting? > > Is there some legal restrictions with cisco? Or is just a matter of > estabilishing and defining only what is written on the most promising > standard (RFC 5101)?? > > I know the requirements about netflow v9 (RFC 3954) and IPFIX (RFC > 5101) and also that IPFIX was an improvement standadization of netflow > v9. I know also some differences as a 16-bit field on the headers and > some not compatible information elements's id. But it all seems to be > easy to implement... > > My main concerns is about a great fraction of users/clients whose have > only paid closed netflow v9 collectors and expects receiving netflow > v9 messages. I think that it would be great if some of these ipfix > implementations could also be exporting these messages. > > Sorry if this is a irrelevant or repeated discussion, but I would > apreciate if someone clarify it to me. > > Thanks all, > > > -- > Juarez Paulino > _______________________________________________ > IPFIX mailing list > IPFIX@ietf.org > https://www.ietf.org/mailman/listinfo/ipfix -- Dipl.-Ing. Gerhard Münz Chair for Network Architectures and Services (I8) Technische Universität München - Department of Informatics Boltzmannstr. 3, 85748 Garching bei München, Germany Phone: +49 89 289-18008 Fax: +49 89 289-18033 E-mail: muenz@net.in.tum.de WWW: http://www.net.in.tum.de/~muenz From paitken@cisco.com Mon Oct 5 00:54:24 2009 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 391A828C148 for ; Mon, 5 Oct 2009 00:54:24 -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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bLHxSFO0n-Ko for ; Mon, 5 Oct 2009 00:54:23 -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 0872728C143 for ; Mon, 5 Oct 2009 00:54:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=paitken@cisco.com; l=768; q=dns/txt; s=amsiport01001; t=1254729358; x=1255938958; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20Paul=20Aitken=20|Subject:=20R e:=20[IPFIX]=20IPFIX=20/=20Netflow|Date:=20Mon,=2005=20Oc t=202009=2008:55:55=20+0100|Message-ID:=20<4AC9A68B.70008 09@cisco.com>|To:=20Juarez=20Paulino=20|CC:=20ipfix@ietf.org|MIME-Version:=201.0 |Content-Transfer-Encoding:=207bit|In-Reply-To:=20<47d693 270910041407p21fd012aj44c752e7c3ceed9a@mail.gmail.com> |References:=20<47d693270910041407p21fd012aj44c752e7c3cee d9a@mail.gmail.com>; bh=Yoxvu74F8oZiUqsJmF4oJ8nnOavUkrFt6IkCj0JrEX4=; b=lFb+eexz1OqUndVLAHrvhW5kUnz6UaXzaeVH0Qu2o45RkLFlhViRU+tX Ngpqzuallm0/youVXny2B4Lgcanvw4jHXdXifU1YOS8DLRrha3byOWmcE UbTwKr+ThIDmBqO461UXMZGbuiTyjD0h7vEY11V0/Yp3qAWIsTPtW+Sy8 A=; Authentication-Results: ams-iport-1.cisco.com; dkim=pass (signature verified [TEST]) header.i=paitken@cisco.com X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjUAAAFDyUqQ/uCLe2dsb2JhbACadwEBFiQGnkOIYQGNTAaEKoFW X-IronPort-AV: E=Sophos;i="4.44,505,1249257600"; d="scan'208";a="50913200" Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 05 Oct 2009 07:55:56 +0000 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n957tuWJ019772; Mon, 5 Oct 2009 09:55:56 +0200 Received: from [144.254.153.60] (dhcp-144-254-153-60.cisco.com [144.254.153.60]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n957tuYb011950; Mon, 5 Oct 2009 07:55:56 GMT Message-ID: <4AC9A68B.7000809@cisco.com> Date: Mon, 05 Oct 2009 08:55:55 +0100 From: Paul Aitken User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-GB; rv:1.8.1.22) Gecko/20090605 SeaMonkey/1.1.17 (Ubuntu-1.1.17+nobinonly-0ubuntu0.9.04.1) MIME-Version: 1.0 To: Juarez Paulino References: <47d693270910041407p21fd012aj44c752e7c3ceed9a@mail.gmail.com> In-Reply-To: <47d693270910041407p21fd012aj44c752e7c3ceed9a@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=768; t=1254729356; x=1255593356; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=paitken@cisco.com; z=From:=20Paul=20Aitken=20 |Subject:=20Re=3A=20[IPFIX]=20IPFIX=20/=20Netflow |Sender:=20; bh=Yoxvu74F8oZiUqsJmF4oJ8nnOavUkrFt6IkCj0JrEX4=; b=ALm+1wy2ZDi6QXDLAKdiWSFAlB2lsmykLKY7/K58B5O1yG7+G16wLXzYsX XsOScA/qwc0bRYOsZp/gc2tdEdJxa/8ZaULBlekcOPog5CDZuIRvYaa47Tdy rQDrvyGjfa; Cc: ipfix@ietf.org Subject: Re: [IPFIX] IPFIX / Netflow 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, 05 Oct 2009 07:54:24 -0000 Juarez, > Why do ipfix implementations such as vermont, maji, YAF(silk) just > export ipfix messages and not netflow v9 messages? > > [...] > > Is there some legal restrictions with cisco? No. While Cisco holds patents pertaining to NFv9 export, we allow that: "If any claims of any issued Cisco patents are necessary for implementing this specification, any party will have the right to use any such patent claims under reasonable, non-discriminatory terms, with reciprocity, to implement and fully comply with the specification." IPR for RFC 3954 can be found here: https://datatracker.ietf.org/ipr/search/?option=rfc_search&rfc_search=3954 Cheers, P. -- Paul Aitken Cisco Systems Ltd, Edinburgh, Scotland. From juarez.paulino@gmail.com Mon Oct 5 08:04:21 2009 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 D58563A6873 for ; Mon, 5 Oct 2009 08:04:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.392 X-Spam-Level: X-Spam-Status: No, score=-1.392 tagged_above=-999 required=5 tests=[AWL=1.206, 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 slbGgVvziKUl for ; Mon, 5 Oct 2009 08:04:20 -0700 (PDT) Received: from mail-yx0-f174.google.com (mail-yx0-f174.google.com [209.85.210.174]) by core3.amsl.com (Postfix) with ESMTP id 77A163A67FD for ; Mon, 5 Oct 2009 08:04:20 -0700 (PDT) Received: by yxe4 with SMTP id 4so3017978yxe.32 for ; Mon, 05 Oct 2009 08:05:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to:cc :content-type; bh=jlzum0tfBcqzNtx2EHOGOVD0tup6lIYH8z+vbnlZn2A=; b=f18UUOlmPYWc+9nXV/Touv5mCv0OfRMeYABTeqIJEugfOuNEoIcXItwbm4e6qqWrzD 5pdqzF7pkDGQSlZ/PVc/JxieRyxQXctPd9oqFd6ISSoOQqAdgdf8zCZIEOr/5IU5Lhue T2EUe+8S0vdAiZSBWCyszQF6cNhbx7mEoCKFk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; b=ptCkLXApDJKD+nmyW8N5BVyIlh/cJtyPd7NBqhV2mAOZmNxYM/d0Qm3TjywTJIiF3s YXmuxaKh7gSedYhR+eg5CPlsfBfLj/fU7i+hUVdXvNPJNjUyVro5AzAWFjPU2e0hHEJ9 IR5Mq4qRqQRHHyW4AJkCRxcAgqAC03dVaj2uE= MIME-Version: 1.0 Sender: juarez.paulino@gmail.com Received: by 10.101.193.25 with SMTP id v25mr123108anp.132.1254755152802; Mon, 05 Oct 2009 08:05:52 -0700 (PDT) In-Reply-To: <4AC91F3D.1080709@net.in.tum.de> References: <47d693270910041407p21fd012aj44c752e7c3ceed9a@mail.gmail.com> <4AC91F3D.1080709@net.in.tum.de> Date: Mon, 5 Oct 2009 12:05:52 -0300 X-Google-Sender-Auth: 2855b434040825eb Message-ID: <163dc1d60910050805i1c15696ejec019af11c340e2f@mail.gmail.com> From: Juarez Paulino To: Gerhard Muenz Content-Type: multipart/alternative; boundary=001636c9257529b1fb0475317357 Cc: ipfix@ietf.org Subject: Re: [IPFIX] IPFIX / Netflow 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, 05 Oct 2009 15:13:52 -0000 --001636c9257529b1fb0475317357 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Thanks Gerhard, I was looking for some implementations to ipfix and vermont really seems to be a complete and easy-to-use one. I really like the way vermont is being developed and maybe I'll be developing something with your developer team. I'll keep contact if our group decide to be upgrading vermont's capabilitie= s in this way... =3D) -- Juarez Paulino On Sun, Oct 4, 2009 at 7:18 PM, Gerhard Muenz wrote: > > Hi Juarez, > > I can talk for vermont only. We do not use any netflow v9 collectors > (apart from vermont itself), therefore we do not have this problem. But > vermont is an open-source project. So, if you want to implement a > Netflow.v9 exporter for vermont, you are very welcome to join the > developer team :) > > BTW, there are netflow.v9 exporters out there (e.g., ntop). > > Regards, > Gerhard > > > Juarez Paulino wrote: > > Hello friends, > > > > I have a simple question and maybe a stupid one. Anyway, I will do this= : > > > > Why do ipfix implementations such as vermont, maji, YAF(silk) just > > export ipfix messages and not netflow v9 messages? > > > > I mean I know that such implementations - for those which implements a > > simple capable collector - can aparently read netflow v9 messages or > > at least show it on stdout. This is also vermont's case. But is there > > any specific reason for not exporting? > > > > Is there some legal restrictions with cisco? Or is just a matter of > > estabilishing and defining only what is written on the most promising > > standard (RFC 5101)?? > > > > I know the requirements about netflow v9 (RFC 3954) and IPFIX (RFC > > 5101) and also that IPFIX was an improvement standadization of netflow > > v9. I know also some differences as a 16-bit field on the headers and > > some not compatible information elements's id. But it all seems to be > > easy to implement... > > > > My main concerns is about a great fraction of users/clients whose have > > only paid closed netflow v9 collectors and expects receiving netflow > > v9 messages. I think that it would be great if some of these ipfix > > implementations could also be exporting these messages. > > > > Sorry if this is a irrelevant or repeated discussion, but I would > > apreciate if someone clarify it to me. > > > > Thanks all, > > > > > > -- > > Juarez Paulino > > _______________________________________________ > > IPFIX mailing list > > IPFIX@ietf.org > > https://www.ietf.org/mailman/listinfo/ipfix > > > -- > Dipl.-Ing. Gerhard M=FCnz > Chair for Network Architectures and Services (I8) > Technische Universit=E4t M=FCnchen - Department of Informatics > Boltzmannstr. 3, 85748 Garching bei M=FCnchen, Germany > Phone: +49 89 289-18008 Fax: +49 89 289-18033 > E-mail: muenz@net.in.tum.de WWW: http://www.net.in.tum.de/~muenz > --001636c9257529b1fb0475317357 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Thanks Gerhard,

I was looking for some implementations to ipfix and = vermont really seems to be a complete and easy-to-use one. I really like th= e way vermont is being developed and maybe I'll be developing something= with your developer team.

I'll keep contact if our group decide to be upgrading vermont's= capabilities in this way... =3D)


--
Juarez Paulino

On Sun, Oct 4, 2009 at 7:18 PM, Gerhard Muenz <muenz@net.in.tum.d= e> wrote:

Hi Juarez,

I can talk for vermont only. We do not use any netflow v9 collectors
(apart from vermont itself), therefore we do not have this problem. But
vermont is an open-source project. So, if you want to implement a
Netflow.v9 exporter for vermont, you are very welcome to join the
developer team :)

BTW, there are netflow.v9 exporters out there (e.g., ntop).

Regards,
Gerhard


Juarez Paulino wrote:
> Hello friends,
>
> I have a simple question and maybe a stupid one. Anyway, I will do thi= s:
>
> Why do ipfix implementations such as vermont, maji, YAF(silk) just
> export ipfix messages and not netflow v9 messages?
>
> I mean I know that such implementations - for those which implements a=
> simple capable collector - can aparently read netflow v9 messages or > at least show it on stdout. This is also vermont's case. But is th= ere
> any specific reason for not exporting?
>
> Is there some legal restrictions with cisco? Or is just a matter of > estabilishing and defining only what is written on the most promising<= br> > standard (RFC 5101)??
>
> I know the requirements about netflow v9 (RFC 3954) and IPFIX (RFC
> 5101) and also that IPFIX was an improvement standadization of netflow=
> v9. I know also some differences as a 16-bit field on the headers and<= br> > some not compatible information elements's id. But it all seems to= be
> easy to implement...
>
> My main concerns is about a great fraction of users/clients whose have=
> only paid closed netflow v9 collectors and expects receiving netflow > v9 messages. I think that it would be great if some of these ipfix
> implementations could also be exporting these messages.
>
> Sorry if this is a irrelevant or repeated discussion, but I would
> apreciate if someone clarify it to me.
>
> Thanks all,
>
>
> --
> Juarez Paulino
> _______________________________________________
> IPFIX mailing list
> IPFIX@ietf.org
> https://www.ietf.org/mailman/listinfo/ipfix


--
Dipl.-Ing. Gerhard M=FCnz
Chair for Network Architectures and Services (I8)
Technische Universit=E4t M=FCnchen - Department of Informatics
Boltzmannstr. 3, 85748 Garching bei M=FCnchen, Germany
Phone: =A0+49 89 289-18008 =A0 =A0 =A0 Fax: +49 89 289-18033
E-mail: muenz@net.in.tum.de =A0 = =A0WWW: htt= p://www.net.in.tum.de/~muenz

--001636c9257529b1fb0475317357-- From juarez.paulino@gmail.com Mon Oct 5 08:12:34 2009 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 19FF228C1D9 for ; Mon, 5 Oct 2009 08:12:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.995 X-Spam-Level: X-Spam-Status: No, score=-1.995 tagged_above=-999 required=5 tests=[AWL=0.603, 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 8ScgebbPjm-5 for ; Mon, 5 Oct 2009 08:12:33 -0700 (PDT) Received: from mail-yx0-f174.google.com (mail-yx0-f174.google.com [209.85.210.174]) by core3.amsl.com (Postfix) with ESMTP id 3A8A13A6A01 for ; Mon, 5 Oct 2009 08:12:33 -0700 (PDT) Received: by yxe4 with SMTP id 4so3026040yxe.32 for ; Mon, 05 Oct 2009 08:14:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to:cc :content-type; bh=IW+LlL8S8XF5Bt+eL8DPPJbVuijxPzmL0QPEbSJK+Sw=; b=nZWEwz7a1qKXufb7+8FUNY0xkfecnmhEdmRiuLKAT2YypPOpIJYqxXPIEeR5tyv5Dz 28tYMVn+cIHn8gwzZf2dgjpBrbeQfTseFZmcT6FWK6azjP6x1lCiCudTyI1XBv3A8U5k 1HXUq2rWMd6ZG2e4jRp1a6qRs4V8puT0ZK3Xk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; b=CasI8fX6JkU4lfasMZvPoAWd/2eMqp1foxH9cfvsjdAjjQtdFTtiB7kXSrfEUXqefy b4x63LJveGkjuFzQ9kZLZkOuqk33fx8NGKGpcD5L60NiGKdkJjRAg2i7cBUZHHPvSrKV 0h5IUzhDhY5ocRnPZ4lZ2e84N5o/ko9/pf34g= MIME-Version: 1.0 Sender: juarez.paulino@gmail.com Received: by 10.101.81.8 with SMTP id i8mr110441anl.185.1254755645480; Mon, 05 Oct 2009 08:14:05 -0700 (PDT) In-Reply-To: <4AC9A68B.7000809@cisco.com> References: <47d693270910041407p21fd012aj44c752e7c3ceed9a@mail.gmail.com> <4AC9A68B.7000809@cisco.com> Date: Mon, 5 Oct 2009 12:14:05 -0300 X-Google-Sender-Auth: 55dfee62bf04046a Message-ID: <163dc1d60910050814s28501fe1tffa22e507e79b517@mail.gmail.com> From: Juarez Paulino To: Paul Aitken Content-Type: multipart/alternative; boundary=001636ed73d0876091047531907a Cc: ipfix@ietf.org Subject: Re: [IPFIX] IPFIX / Netflow 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, 05 Oct 2009 15:14:43 -0000 --001636ed73d0876091047531907a Content-Type: text/plain; charset=ISO-8859-1 Thanks Paul, This really simplifies things here. Now we're certainly about what we can develop or use on ways to maintain compatibility between IPFIX and NFv9 standards. -- Juarez Paulino On Mon, Oct 5, 2009 at 4:55 AM, Paul Aitken wrote: > Juarez, > > Why do ipfix implementations such as vermont, maji, YAF(silk) just >> export ipfix messages and not netflow v9 messages? >> >> [...] >> >> Is there some legal restrictions with cisco? >> > > No. While Cisco holds patents pertaining to NFv9 export, we allow that: > > "If any claims of any issued Cisco patents are necessary for > implementing this specification, any party will have the right to use > any such patent claims under reasonable, non-discriminatory terms, > with reciprocity, to implement and fully comply with the > specification." > > > IPR for RFC 3954 can be found here: > > https://datatracker.ietf.org/ipr/search/?option=rfc_search&rfc_search=3954 > > > Cheers, > P. > > -- > Paul Aitken > Cisco Systems Ltd, Edinburgh, Scotland. > --001636ed73d0876091047531907a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Thanks Paul,

This really simplifies things here. Now we're certa= inly about what we can develop or use on ways to maintain compatibility bet= ween IPFIX and NFv9 standards.

--
Juarez Paulino

On Mon, Oct 5, 2009 at 4:55 AM, Paul Aitken <paitken@cisco.com> wrote:
Juarez,

Why do ipfix implementations such as vermont, maji, YAF(silk) just
export ipfix messages and not netflow v9 messages?

[...]


Is there some legal restrictions with cisco?

No. While Cisco holds patents pertaining to NFv9 export, we allow that:

=A0"If any claims of any issued Cisco patents are necessary for
=A0 implementing this specification, any party will have the right to use<= br> =A0 any such patent claims under reasonable, non-discriminatory terms,
=A0 with reciprocity, to implement and fully comply with the
=A0 specification."


IPR for RFC 3954 can be found here:

https://datatracker.ietf.org/ipr/sear= ch/?option=3Drfc_search&rfc_search=3D3954


Cheers,
P.

--
Paul Aitken
Cisco Systems Ltd, Edinburgh, Scotland.

--001636ed73d0876091047531907a-- From paitken@cisco.com Mon Oct 5 10:19:09 2009 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 69B803A6997 for ; Mon, 5 Oct 2009 10:19:09 -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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H+Z7QlAo4tZm for ; Mon, 5 Oct 2009 10:19:08 -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 2E1BB3A693F for ; Mon, 5 Oct 2009 10:19:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=paitken@cisco.com; l=640; q=dns/txt; s=amsiport01001; t=1254763244; x=1255972844; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20Paul=20Aitken=20|Subject:=20R e:=20[Sender:=20=20juarez.paulino@gmail.com]=20=20Re:=20[ IPFIX]=20IPFIX=20/=20Netflow|Date:=20Mon,=2005=20Oct=2020 09=2018:20:41=20+0100|Message-ID:=20<4ACA2AE9.70704@cisco .com>|To:=20Juarez=20Paulino=20|CC: =20ipfix@ietf.org|MIME-Version:=201.0 |Content-Transfer-Encoding:=207bit|In-Reply-To:=20<163dc1 d60910050814s28501fe1tffa22e507e79b517@mail.gmail.com> |References:=20<47d693270910041407p21fd012aj44c752e7c3cee d9a@mail.gmail.com>=09=20<4AC9A68B.7000809@cisco.com>=20< 163dc1d60910050814s28501fe1tffa22e507e79b517@mail.gmail.c om>; bh=f3Tfcs3jaxCF+VMf7Ce0bSlPmM7C6NKdzH33mAqpBJs=; b=Kxto8fpsk+yXcI/DkN5tULR/LQES7wLonkjDUJf0fAg81MqSQD/DYJQr dgEkTmPhCKeqIn3AcXVJv9SgnxSodH/4jEahE94WmN4FjIY7Xte0YfqU2 zJDmRRqFREeNhkyrCffnHTazaiNkfNXJnftngE1Kl+fZIm9aZu3oORNFG w=; Authentication-Results: ams-iport-1.cisco.com; dkim=pass (signature verified [TEST]) header.i=paitken@cisco.com X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkAAAGPHyUqQ/uCKe2dsb2JhbACadwEBFiQGoEeIYQGOHgaEKoFW X-IronPort-AV: E=Sophos;i="4.44,506,1249257600"; d="scan'208";a="50993497" Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 05 Oct 2009 17:20:42 +0000 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n95HKgHw016974; Mon, 5 Oct 2009 19:20:42 +0200 Received: from [10.61.81.222] (ams3-vpn-dhcp4575.cisco.com [10.61.81.222]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n95HKgkf003865; Mon, 5 Oct 2009 17:20:42 GMT Message-ID: <4ACA2AE9.70704@cisco.com> Date: Mon, 05 Oct 2009 18:20:41 +0100 From: Paul Aitken User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-GB; rv:1.8.1.22) Gecko/20090605 SeaMonkey/1.1.17 (Ubuntu-1.1.17+nobinonly-0ubuntu0.9.04.1) MIME-Version: 1.0 To: Juarez Paulino References: <47d693270910041407p21fd012aj44c752e7c3ceed9a@mail.gmail.com> <4AC9A68B.7000809@cisco.com> <163dc1d60910050814s28501fe1tffa22e507e79b517@mail.gmail.com> In-Reply-To: <163dc1d60910050814s28501fe1tffa22e507e79b517@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=640; t=1254763242; x=1255627242; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=paitken@cisco.com; z=From:=20Paul=20Aitken=20 |Subject:=20Re=3A=20[Sender=3A=20=20juarez.paulino@gmail.co m]=20=20Re=3A=20[IPFIX]=20IPFIX=20/=20Netflow |Sender:=20; bh=f3Tfcs3jaxCF+VMf7Ce0bSlPmM7C6NKdzH33mAqpBJs=; b=PAN8/SXGXRDgDk/J5wX5LJdDKJs3EU3DQuFDQqk+WN5OCDhnh7lamhAQCR gTIzsq+K1c61wonKDxq519bkI9YI+0YnzvrfBDmBhmPECbp6rcq6mlpdrWc0 JOE2zFQEqu; Cc: ipfix@ietf.org Subject: Re: [IPFIX] [Sender: juarez.paulino@gmail.com] Re: IPFIX / Netflow 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, 05 Oct 2009 17:19:09 -0000 Juarez, > This really simplifies things here. Now we're certainly about what we > can develop or use on ways to maintain compatibility between IPFIX and > NFv9 standards. Great! Re: "I know also some differences as [...] some not compatible information elements's id.", which information elements were you thinking of? We try to keep the NFv9 and IPFIX information elements as unified as possible. There are some NFv9 fields which we chose not to standardise in IPFIX only because they're quite proprietary to cisco and not very useful to anyone else. -- Paul Aitken Cisco Systems Ltd, Edinburgh, Scotland. From juarez.paulino@gmail.com Mon Oct 5 15:07:45 2009 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 ED5503A686E for ; Mon, 5 Oct 2009 15:07:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.196 X-Spam-Level: X-Spam-Status: No, score=-2.196 tagged_above=-999 required=5 tests=[AWL=0.402, 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 DYHlUh8jO2OY for ; Mon, 5 Oct 2009 15:07:45 -0700 (PDT) Received: from mail-gx0-f215.google.com (mail-gx0-f215.google.com [209.85.217.215]) by core3.amsl.com (Postfix) with ESMTP id 1BCDE3A67AB for ; Mon, 5 Oct 2009 15:07:45 -0700 (PDT) Received: by gxk7 with SMTP id 7so111771gxk.14 for ; Mon, 05 Oct 2009 15:09:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to:cc :content-type; bh=cPfIgMFTLZj6kI7pRTkbGqdR6JHuouxJRRlig3wHRCs=; b=AvQBo+idfotfAityUddvn1z/nxt2CJrrHZEKcOzFiav2n1mz8L6iRVkTTQMcJHSoyD hMzHOChDsQGyTd2UqW2BLAcI+gvU93vGlwkrUxNOlPLDKgAYk3T/NmfbpF9rSbBl0rCu uh8KNvj9VmQnISw+213KC35NNQRa1235CGfsU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; b=RwREQP6rDXSEUoqJ886RMELqP65BCXHk5Md19zNndB9fkDUf8hi7bfbmL4atHsfqBj bBCtT0lNlTjmN/i4+UvVdJWKUGRb3uVzpBOjvttR2DY2w5H7n7aej6dxj0UEmQciVYk6 1Y1B7t+fJ/8nzYbOFEVxsZ4mBuivNyo4NrpeY= MIME-Version: 1.0 Sender: juarez.paulino@gmail.com Received: by 10.101.113.16 with SMTP id q16mr671953anm.47.1254780558089; Mon, 05 Oct 2009 15:09:18 -0700 (PDT) In-Reply-To: <4ACA2AE9.70704@cisco.com> References: <47d693270910041407p21fd012aj44c752e7c3ceed9a@mail.gmail.com> <4AC9A68B.7000809@cisco.com> <163dc1d60910050814s28501fe1tffa22e507e79b517@mail.gmail.com> <4ACA2AE9.70704@cisco.com> Date: Mon, 5 Oct 2009 19:09:18 -0300 X-Google-Sender-Auth: c182862add0d9374 Message-ID: <163dc1d60910051509v3f2298dax96b8f3ef05f8c3d4@mail.gmail.com> From: Juarez Paulino To: Paul Aitken Content-Type: multipart/alternative; boundary=001636ed70ae6f9d540475375de2 Cc: ipfix@ietf.org Subject: Re: [IPFIX] [Sender: juarez.paulino@gmail.com] Re: IPFIX / Netflow 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, 05 Oct 2009 22:07:46 -0000 --001636ed70ae6f9d540475375de2 Content-Type: text/plain; charset=ISO-8859-1 I review the standards here, you're right. It's just some of reserved cisco information elements. The most relevant and useful were made unified... -- Juarez Paulino On Mon, Oct 5, 2009 at 2:20 PM, Paul Aitken wrote: > Juarez, > > This really simplifies things here. Now we're certainly about what we can >> develop or use on ways to maintain compatibility between IPFIX and NFv9 >> standards. >> > > Great! > > Re: "I know also some differences as [...] some not compatible information > elements's id.", which information elements were you thinking of? > > We try to keep the NFv9 and IPFIX information elements as unified as > possible. There are some NFv9 fields which we chose not to standardise in > IPFIX only because they're quite proprietary to cisco and not very useful to > anyone else. > > > -- > Paul Aitken > Cisco Systems Ltd, Edinburgh, Scotland. > --001636ed70ae6f9d540475375de2 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I review the standards here, you're right. It's just some of reserv= ed cisco information elements. The most relevant and useful were made unifi= ed...


--
Juarez Paulino

On = Mon, Oct 5, 2009 at 2:20 PM, Paul Aitken <paitken@cisco.com> wrote:
Juarez,


This really simplifies things here. Now we're certainly about what we c= an develop or use on ways to maintain compatibility between IPFIX and NFv9 = standards.

Great!

Re: "I know also some differences as [...] some not compatible informa= tion elements's id.", which information elements were you thinking= of?

We try to keep the NFv9 and IPFIX information elements as unified as possib= le. There are some NFv9 fields which we chose not to standardise in IPFIX o= nly because they're quite proprietary to cisco and not very useful to a= nyone else.


--
Paul Aitken
Cisco Systems Ltd, Edinburgh, Scotland.

--001636ed70ae6f9d540475375de2-- From bclaise@cisco.com Fri Oct 9 13:42:11 2009 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 540513A62C1 for ; Fri, 9 Oct 2009 13:42:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.492 X-Spam-Level: X-Spam-Status: No, score=-2.492 tagged_above=-999 required=5 tests=[AWL=0.106, 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 B-PP+HqZhOsp for ; Fri, 9 Oct 2009 13:42:10 -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 9B6773A685B for ; Fri, 9 Oct 2009 13:42:09 -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 n99Ke8eM019300; Fri, 9 Oct 2009 22:40:08 +0200 (CEST) Received: from [10.55.43.53] (ams-bclaise-8714.cisco.com [10.55.43.53]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id n99Ke6WW029910; Fri, 9 Oct 2009 22:40:06 +0200 (CEST) Message-ID: <4ACF9FA5.8010607@cisco.com> Date: Fri, 09 Oct 2009 22:40:05 +0200 From: Benoit Claise User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: ipfix-chairs@tools.ietf.org References: <20090731100001.3EB6D3A6CD8@core3.amsl.com> <20090801130620.A8EE.17391CF2@nttv6.net> In-Reply-To: <20090801130620.A8EE.17391CF2@nttv6.net> Content-Type: multipart/alternative; boundary="------------090909070800060707070503" Cc: ipfix@ietf.org Subject: Re: [IPFIX] I-D Action:draft-ietf-ipfix-mediators-problem-statement-05.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: Fri, 09 Oct 2009 20:42:11 -0000 This is a multi-part message in MIME format. --------------090909070800060707070503 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit IPFIX chairs, During the last IETF meeting, we worked hard to produce a new version of the mediators problem statement. Actually one version that resolves all open issues. Isn't it time to start the WG last-call ... if we want to respect our charter? To be frank, I believe it's my first ever where I could meet the charter date ;-) Oct 2009 Submit Mediation Problem Statement I-D to IESG for publication as Informational RFC If there are any open issues, they could be discussed at the next IETF. Regards, Benoit. > Dear all, > > I have submitted new version yesterday thanks to Brian, Gerhard, and > Benoit. Thank you very much. All of issues have resolved. > It is ready for 2nd WG Last Call. > > Regards, > Atsushi > > On Fri, 31 Jul 2009 03:00:01 -0700 (PDT) > Internet-Drafts@ietf.org wrote: > > >> 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 : IPFIX Mediation: Problem Statement >> Author(s) : A. Kobayashi, et al. >> Filename : draft-ietf-ipfix-mediators-problem-statement-05.txt >> Pages : 31 >> Date : 2009-07-31 >> >> Flow-based measurement is a popular method for various network >> monitoring usages. The sharing of flow-based information for >> monitoring applications having different requirements raises some >> open issues in terms of measurement system scalability, flow-based >> measurement flexibility, and export reliability that IPFIX Mediation >> may help resolve. This document describes the IPFIX Mediation >> applicability examples, along with some problems that network >> administrators have been facing. >> >> A URL for this Internet-Draft is: >> http://www.ietf.org/internet-drafts/draft-ietf-ipfix-mediators-problem-statement-05.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. >> > > --------------090909070800060707070503 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit IPFIX chairs,

During the last IETF meeting, we worked hard to produce a new version of the mediators problem statement. Actually one version that resolves all open issues.
Isn't it time to start the WG last-call ... if we want to respect our charter?  To be frank, I believe it's my first ever where I could meet the charter date ;-)
Oct 2009    Submit Mediation Problem Statement I-D to IESG for publication as Informational RFC

If there are any open issues, they could be discussed at the next IETF.

Regards, Benoit.
Dear all,

I have submitted new version yesterday thanks to Brian, Gerhard, and
Benoit. Thank you very much. All of issues have resolved. 
It is ready for 2nd WG Last Call. 

Regards,
Atsushi

On Fri, 31 Jul 2009 03:00:01 -0700 (PDT)
Internet-Drafts@ietf.org wrote:

  
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           : IPFIX Mediation: Problem Statement
	Author(s)       : A. Kobayashi, et al.
	Filename        : draft-ietf-ipfix-mediators-problem-statement-05.txt
	Pages           : 31
	Date            : 2009-07-31

Flow-based measurement is a popular method for various network
monitoring usages.  The sharing of flow-based information for
monitoring applications having different requirements raises some
open issues in terms of measurement system scalability, flow-based
measurement flexibility, and export reliability that IPFIX Mediation
may help resolve.  This document describes the IPFIX Mediation
applicability examples, along with some problems that network
administrators have been facing.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ipfix-mediators-problem-statement-05.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.

--------------090909070800060707070503-- From root@core3.amsl.com Mon Oct 12 16:00:02 2009 Return-Path: X-Original-To: ipfix@ietf.org Delivered-To: ipfix@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 211683A68D3; Mon, 12 Oct 2009 16:00:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20091012230002.211683A68D3@core3.amsl.com> Date: Mon, 12 Oct 2009 16:00:02 -0700 (PDT) Cc: ipfix@ietf.org Subject: [IPFIX] I-D Action:draft-ietf-ipfix-anon-00.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, 12 Oct 2009 23:00:02 -0000 --NextPart 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 : IP Flow Anonymisation Support Author(s) : E. Boschi, B. Trammell Filename : draft-ietf-ipfix-anon-00.txt Pages : 31 Date : 2009-10-12 This document describes anonymisation techniques for IP flow data and the export of anonymised data using the IPFIX protocol. It provides a categorization of common anonymisation schemes and defines the parameters needed to describe them. It provides guidelines for the implementation of anonymised data export and storage over IPFIX, and describes an Options-based method for anonymisation metadata export within the IPFIX protocol, providing the basis for the definition of information models for configuring anonymisation techniques within an IPFIX Metering or Exporting Process, and for reporting the technique in use to an IPFIX Collecting Process. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipfix-anon-00.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 Content-Type: Message/External-body; name="draft-ietf-ipfix-anon-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-10-12154705.I-D@ietf.org> --NextPart-- From bclaise@cisco.com Thu Oct 15 02:08:48 2009 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 BF9F43A679F; Thu, 15 Oct 2009 02:08:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.002 X-Spam-Level: X-Spam-Status: No, score=0.002 tagged_above=-999 required=5 tests=[BAYES_50=0.001, 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 879v6dPnoskv; Thu, 15 Oct 2009 02:08:47 -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 9B84D3A67CC; Thu, 15 Oct 2009 02:08:47 -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 n9F8jLaW028767; Thu, 15 Oct 2009 10:45:21 +0200 (CEST) Received: from [10.55.43.53] (ams-bclaise-8714.cisco.com [10.55.43.53]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id n9F8jLGC010240; Thu, 15 Oct 2009 10:45:21 +0200 (CEST) Message-ID: <4AD6E120.50002@cisco.com> Date: Thu, 15 Oct 2009 10:45:20 +0200 From: Benoit Claise User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: "ipfix@ietf.org" , psamp Content-Type: multipart/alternative; boundary="------------070103020702000003040104" Subject: [IPFIX] Mistake in PSAMP RFCs: Selector ID length 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, 15 Oct 2009 09:08:48 -0000 This is a multi-part message in MIME format. --------------070103020702000003040104 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Dear all, We found a mistake in the PSAMP RFCs. RFC5477 8.1.2. selectorId Description: The Selector ID is the unique ID identifying a Primitive Selector. Each Primitive Selector must have a unique ID in the Observation Domain. Abstract Data Type: unsigned16 <------------------ Data Type Semantics: identifier ElementId: 302 Status: current RFC5476, the selectorID length is 4 bytes in ALL examples (and there are many). IPFIX Options Template Record: 0 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Set ID = 3 | Length = 26 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Template ID = 262 | Field Count = 4 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Scope Field Count = 1 |0| selectionSequenceId = 301 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Scope 1 Length = 4 |0| ingressInterface = 10 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Field Length = 4 |0| selectorId = 302 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Field Length = 4 |0| selectorId = 302 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Field Length = 4 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The proposed solution is to increase the Selector ID length and put an ERRATA on RFC5477. 16 bits is definitely not enough and clearly not was intended. Since we can do reduced length encoding with larger identifiers, we don't see any harm in making all identifiers 64 bit Feedback? Regards, Benoit. --------------070103020702000003040104 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Dear all,

We found a mistake in the PSAMP RFCs.

RFC5477
8.1.2.  selectorId


   Description:

      The Selector ID is the unique ID identifying a Primitive Selector.
      Each Primitive Selector must have a unique ID in the Observation
      Domain.

   Abstract Data Type:  unsigned16                  <------------------

   Data Type Semantics:  identifier

   ElementId:  302

   Status:  current


RFC5476, the selectorID length is 4 bytes in ALL examples (and there are many).

   IPFIX Options Template Record:

       0                   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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |          Set ID = 3           |          Length = 26          |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |        Template ID = 262      |         Field Count = 4       |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |     Scope Field Count =  1    |0|  selectionSequenceId = 301  |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |       Scope 1 Length = 4      |0|     ingressInterface = 10   |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |        Field Length = 4       |0|      selectorId = 302       |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |        Field Length = 4       |0|      selectorId = 302       |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |        Field Length = 4       |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The proposed solution is to increase the Selector ID length and put an ERRATA on RFC5477.
16 bits is definitely not enough and clearly not was intended. Since we can do reduced length encoding with larger identifiers, we don't see any harm in making all identifiers 64 bit

Feedback?

Regards, Benoit.
--------------070103020702000003040104-- From muenz@net.in.tum.de Thu Oct 15 02:26:42 2009 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 C1E053A6859; Thu, 15 Oct 2009 02:26:42 -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 Keow79cIbGJl; Thu, 15 Oct 2009 02:26:42 -0700 (PDT) Received: from smtp.cs.uni-tuebingen.de (u-173-c156.cs.uni-tuebingen.de [134.2.173.156]) by core3.amsl.com (Postfix) with ESMTP id E62B63A679C; Thu, 15 Oct 2009 02:26:41 -0700 (PDT) Received: from p4fe5c19d.dip.t-dialin.net ([79.229.193.157] helo=[192.168.3.123]) by smtp.cs.uni-tuebingen.de with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1MyMbY-0000pu-9x; Thu, 15 Oct 2009 11:26:40 +0200 Message-ID: <4AD6EAF4.9040303@net.in.tum.de> Date: Thu, 15 Oct 2009 11:27:16 +0200 From: Gerhard Muenz User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Benoit Claise References: <4AD6E120.50002@cisco.com> In-Reply-To: <4AD6E120.50002@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: psamp , "ipfix@ietf.org" Subject: Re: [IPFIX] Mistake in PSAMP RFCs: Selector ID length 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, 15 Oct 2009 09:26:42 -0000 Benoit, Benoit Claise wrote: > Dear all, > > We found a mistake in the PSAMP RFCs. > > RFC5477 > > > 8.1.2. selectorId > > > > Description: > > The Selector ID is the unique ID identifying a Primitive Selector. > Each Primitive Selector must have a unique ID in the Observation > Domain. > > Abstract Data Type: unsigned16 <------------------ > > Data Type Semantics: identifier > > ElementId: 302 > > Status: current > > > > > RFC5476, the selectorID length is 4 bytes in ALL examples (and there are > many). > > IPFIX Options Template Record: > > 0 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 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Set ID = 3 | Length = 26 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Template ID = 262 | Field Count = 4 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Scope Field Count = 1 |0| selectionSequenceId = 301 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Scope 1 Length = 4 |0| ingressInterface = 10 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Field Length = 4 |0| selectorId = 302 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Field Length = 4 |0| selectorId = 302 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Field Length = 4 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > The proposed solution is to increase the Selector ID length and put an > ERRATA on RFC5477. > 16 bits is definitely not enough and clearly not was intended. Since we > can do reduced length encoding with larger identifiers, we don't see any > harm in making all identifiers 64 bit > > Feedback? 4 Bytes = 32 Bit You propose to increase it to 64 (=8 Byte), which means that both RFCs need to be corrected. Or is 64 a mistake? Regards, Gerhard > > Regards, Benoit. > > > ------------------------------------------------------------------------ > > _______________________________________________ > IPFIX mailing list > IPFIX@ietf.org > https://www.ietf.org/mailman/listinfo/ipfix -- Dipl.-Ing. Gerhard Münz Chair for Network Architectures and Services (I8) Technische Universität München - Department of Informatics Boltzmannstr. 3, 85748 Garching bei München, Germany Phone: +49 89 289-18008 Fax: +49 89 289-18033 E-mail: muenz@net.in.tum.de WWW: http://www.net.in.tum.de/~muenz From bclaise@cisco.com Thu Oct 15 02:38:44 2009 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 7C2403A6859; Thu, 15 Oct 2009 02:38:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.299 X-Spam-Level: X-Spam-Status: No, score=-1.299 tagged_above=-999 required=5 tests=[AWL=1.300, 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 Qk1+wB0XIkzV; Thu, 15 Oct 2009 02:38:43 -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 6A65C3A682A; Thu, 15 Oct 2009 02:38:43 -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 n9F9Z0NM006972; Thu, 15 Oct 2009 11:35:00 +0200 (CEST) Received: from [10.55.43.53] (ams-bclaise-8714.cisco.com [10.55.43.53]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id n9F9Z0HE024156; Thu, 15 Oct 2009 11:35:00 +0200 (CEST) Message-ID: <4AD6ECC3.30209@cisco.com> Date: Thu, 15 Oct 2009 11:34:59 +0200 From: Benoit Claise User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Gerhard Muenz References: <4AD6E120.50002@cisco.com> <4AD6EAF4.9040303@net.in.tum.de> In-Reply-To: <4AD6EAF4.9040303@net.in.tum.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: psamp , "ipfix@ietf.org" Subject: Re: [IPFIX] Mistake in PSAMP RFCs: Selector ID length 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, 15 Oct 2009 09:38:44 -0000 Gerhard, > > Benoit, > > Benoit Claise wrote: >> Dear all, >> >> We found a mistake in the PSAMP RFCs. >> >> RFC5477 >> >> >> 8.1.2. selectorId >> >> >> >> Description: >> >> The Selector ID is the unique ID identifying a Primitive >> Selector. >> Each Primitive Selector must have a unique ID in the >> Observation >> Domain. >> >> Abstract Data Type: unsigned16 >> <------------------ >> >> Data Type Semantics: identifier >> >> ElementId: 302 >> >> Status: current >> >> >> >> RFC5476, the selectorID length is 4 bytes in ALL examples (and there >> are many). >> >> IPFIX Options Template Record: >> >> 0 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 >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | Set ID = 3 | Length = 26 | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | Template ID = 262 | Field Count = 4 | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | Scope Field Count = 1 |0| selectionSequenceId = 301 | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | Scope 1 Length = 4 |0| ingressInterface = 10 | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | Field Length = 4 |0| selectorId = 302 | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | Field Length = 4 |0| selectorId = 302 | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | Field Length = 4 | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> >> >> The proposed solution is to increase the Selector ID length and put >> an ERRATA on RFC5477. >> 16 bits is definitely not enough and clearly not was intended. Since >> we can do reduced length encoding with larger identifiers, we don't >> see any harm in making all identifiers 64 bit >> >> Feedback? > > 4 Bytes = 32 Bit > > You propose to increase it to 64 (=8 Byte), which means that both RFCs > need to be corrected. Not really since the examples can use reduced length encoding. Since we have to change it (at least this is the proposed solution), why not going directly to 64 bits? Regards, Benoit. > Or is 64 a mistake? > > Regards, > Gerhard > >> >> Regards, Benoit. >> >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> IPFIX mailing list >> IPFIX@ietf.org >> https://www.ietf.org/mailman/listinfo/ipfix > From trammell@tik.ee.ethz.ch Thu Oct 15 02:41:08 2009 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 58FF93A6879; Thu, 15 Oct 2009 02:41:07 -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 y+0NoQBsk2+p; Thu, 15 Oct 2009 02:41:06 -0700 (PDT) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) by core3.amsl.com (Postfix) with ESMTP id F377D3A6859; Thu, 15 Oct 2009 02:41:04 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id 5AAE8D93A2; Thu, 15 Oct 2009 11:41:06 +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 9V-yu1Z2bm47; Thu, 15 Oct 2009 11:41:06 +0200 (MEST) Received: from pb-10072.ethz.ch (pb-10072.ethz.ch [82.130.103.195]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: briant) by smtp.ee.ethz.ch (Postfix) with ESMTP id 00B3CD937B; Thu, 15 Oct 2009 11:41:05 +0200 (MEST) Message-Id: From: Brian Trammell To: Gerhard Muenz In-Reply-To: <4AD6EAF4.9040303@net.in.tum.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v936) Date: Thu, 15 Oct 2009 11:41:05 +0200 References: <4AD6E120.50002@cisco.com> <4AD6EAF4.9040303@net.in.tum.de> X-Mailer: Apple Mail (2.936) Cc: psamp , "ipfix@ietf.org" Subject: Re: [IPFIX] Mistake in PSAMP RFCs: Selector ID length 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, 15 Oct 2009 09:41:08 -0000 hi Benoit, Gerhard, I agree with the change to 64 bit, to keep it in line with every other =20= protocol-level identifier (save odID, bound by the header format to 32 =20= bits), with the understanding that RLE will often be used to use it as =20= 32 bit. However, in this case we might want as well to update 5476 with a line =20= noting that all the examples use RLE. Best regards, Brian On Oct 15, 2009, at 11:27 AM, Gerhard Muenz wrote: > > Benoit, > > Benoit Claise wrote: >> Dear all, >> We found a mistake in the PSAMP RFCs. >> RFC5477 >> 8.1.2. selectorId >> Description: >> The Selector ID is the unique ID identifying a Primitive =20 >> Selector. >> Each Primitive Selector must have a unique ID in the =20 >> Observation >> Domain. >> Abstract Data Type: unsigned16 =20 >> <------------------ >> Data Type Semantics: identifier >> ElementId: 302 >> Status: current >> RFC5476, the selectorID length is 4 bytes in ALL examples (and =20= >> there are many). >> IPFIX Options Template Record: >> 0 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 >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-=20= >> +-+ >> | Set ID =3D 3 | Length =3D =20 >> 26 | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-=20= >> +-+ >> | Template ID =3D 262 | Field Count =3D =20 >> 4 | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-=20= >> +-+ >> | Scope Field Count =3D 1 |0| selectionSequenceId =3D =20= >> 301 | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-=20= >> +-+ >> | Scope 1 Length =3D 4 |0| ingressInterface =3D =20= >> 10 | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-=20= >> +-+ >> | Field Length =3D 4 |0| selectorId =3D =20 >> 302 | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-=20= >> +-+ >> | Field Length =3D 4 |0| selectorId =3D =20 >> 302 | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-=20= >> +-+ >> | Field Length =3D 4 | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> The proposed solution is to increase the Selector ID length and put =20= >> an ERRATA on RFC5477. >> 16 bits is definitely not enough and clearly not was intended. =20 >> Since we can do reduced length encoding with larger identifiers, we =20= >> don't see any harm in making all identifiers 64 bit >> Feedback? > > 4 Bytes =3D 32 Bit > > You propose to increase it to 64 (=3D8 Byte), which means that both =20= > RFCs need to be corrected. Or is 64 a mistake? > > Regards, > Gerhard > >> Regards, Benoit. >> = ------------------------------------------------------------------------ >> _______________________________________________ >> IPFIX mailing list >> IPFIX@ietf.org >> https://www.ietf.org/mailman/listinfo/ipfix > > --=20 > Dipl.-Ing. Gerhard M=FCnz > Chair for Network Architectures and Services (I8) > Technische Universit=E4t M=FCnchen - Department of Informatics > Boltzmannstr. 3, 85748 Garching bei M=FCnchen, Germany > Phone: +49 89 289-18008 Fax: +49 89 289-18033 > E-mail: muenz@net.in.tum.de WWW: http://www.net.in.tum.de/~muenz > > _______________________________________________ > IPFIX mailing list > IPFIX@ietf.org > https://www.ietf.org/mailman/listinfo/ipfix From dromasca@avaya.com Thu Oct 15 04:44:41 2009 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 092ED3A680C; Thu, 15 Oct 2009 04:44:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.235 X-Spam-Level: X-Spam-Status: No, score=-2.235 tagged_above=-999 required=5 tests=[AWL=0.364, 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 d4joLnRRDQGR; Thu, 15 Oct 2009 04:44:40 -0700 (PDT) Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) by core3.amsl.com (Postfix) with ESMTP id 5EED13A6781; Thu, 15 Oct 2009 04:44:39 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.44,566,1249272000"; d="scan'208";a="160361100" Received: from unknown (HELO nj300815-nj-erheast.avaya.com) ([198.152.6.5]) by de307622-de-outbound.net.avaya.com with ESMTP; 15 Oct 2009 07:44:40 -0400 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.14]) by nj300815-nj-erheast-out.avaya.com with ESMTP; 15 Oct 2009 07:44:39 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Thu, 15 Oct 2009 13:44:32 +0200 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [IPFIX] Mistake in PSAMP RFCs: Selector ID length thread-index: AcpNe6Rug5FSJI29Sre20TXyfLKgNgAEOhOA References: <4AD6E120.50002@cisco.com> <4AD6EAF4.9040303@net.in.tum.de> From: "Romascanu, Dan (Dan)" To: "Brian Trammell" , "Gerhard Muenz" Cc: psamp , ipfix@ietf.org Subject: Re: [IPFIX] Mistake in PSAMP RFCs: Selector ID length 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, 15 Oct 2009 11:44:41 -0000 It looks like two errata on RFC 5478 and 5477 should be issues. I = suggest that one of you takes the pen to enter the errata texts, and = when they are ready and have reached consensus I can approve them.=20 Dan =20 > -----Original Message----- > From: ipfix-bounces@ietf.org [mailto:ipfix-bounces@ietf.org]=20 > On Behalf Of Brian Trammell > Sent: Thursday, October 15, 2009 11:41 AM > To: Gerhard Muenz > Cc: psamp; ipfix@ietf.org > Subject: Re: [IPFIX] Mistake in PSAMP RFCs: Selector ID length >=20 > hi Benoit, Gerhard, >=20 > I agree with the change to 64 bit, to keep it in line with=20 > every other protocol-level identifier (save odID, bound by=20 > the header format to 32 bits), with the understanding that=20 > RLE will often be used to use it as > 32 bit. >=20 > However, in this case we might want as well to update 5476=20 > with a line noting that all the examples use RLE. >=20 > Best regards, >=20 > Brian >=20 > On Oct 15, 2009, at 11:27 AM, Gerhard Muenz wrote: >=20 > > > > Benoit, > > > > Benoit Claise wrote: > >> Dear all, > >> We found a mistake in the PSAMP RFCs. > >> RFC5477 > >> 8.1.2. selectorId > >> Description: > >> The Selector ID is the unique ID identifying a Primitive=20 > >> Selector. > >> Each Primitive Selector must have a unique ID in the=20 > >> Observation > >> Domain. > >> Abstract Data Type: unsigned16 =20 > >> <------------------ > >> Data Type Semantics: identifier > >> ElementId: 302 > >> Status: current > >> RFC5476, the selectorID length is 4 bytes in ALL=20 > examples (and=20 > >> there are many). > >> IPFIX Options Template Record: > >> 0 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=20 > 6 7 8 9 0 1 > >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- > >> +-+ > >> | Set ID =3D 3 | Length =3D =20 > >> 26 | > >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- > >> +-+ > >> | Template ID =3D 262 | Field Count =3D =20 > >> 4 | > >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- > >> +-+ > >> | Scope Field Count =3D 1 |0| selectionSequenceId =3D = =20 > >> 301 | > >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- > >> +-+ > >> | Scope 1 Length =3D 4 |0| ingressInterface =3D = =20 > >> 10 | > >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- > >> +-+ > >> | Field Length =3D 4 |0| selectorId =3D =20 > >> 302 | > >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- > >> +-+ > >> | Field Length =3D 4 |0| selectorId =3D =20 > >> 302 | > >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- > >> +-+ > >> | Field Length =3D 4 | > >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The proposed solution is to=20 > >> increase the Selector ID length and put an ERRATA on RFC5477. > >> 16 bits is definitely not enough and clearly not was intended. =20 > >> Since we can do reduced length encoding with larger=20 > identifiers, we=20 > >> don't see any harm in making all identifiers 64 bit Feedback? > > > > 4 Bytes =3D 32 Bit > > > > You propose to increase it to 64 (=3D8 Byte), which means=20 > that both RFCs=20 > > need to be corrected. Or is 64 a mistake? > > > > Regards, > > Gerhard > > > >> Regards, Benoit. > >>=20 > --------------------------------------------------------------------- > >> --- _______________________________________________ > >> IPFIX mailing list > >> IPFIX@ietf.org > >> https://www.ietf.org/mailman/listinfo/ipfix > > > > -- > > Dipl.-Ing. Gerhard M=FCnz > > Chair for Network Architectures and Services (I8) Technische=20 > > Universit=E4t M=FCnchen - Department of Informatics=20 > Boltzmannstr. 3, 85748=20 > > Garching bei M=FCnchen, Germany > > Phone: +49 89 289-18008 Fax: +49 89 289-18033 > > E-mail: muenz@net.in.tum.de WWW: http://www.net.in.tum.de/~muenz > > > > _______________________________________________ > > IPFIX mailing list > > IPFIX@ietf.org > > https://www.ietf.org/mailman/listinfo/ipfix >=20 > _______________________________________________ > IPFIX mailing list > IPFIX@ietf.org > https://www.ietf.org/mailman/listinfo/ipfix >=20 From root@core3.amsl.com Fri Oct 16 06:15:02 2009 Return-Path: X-Original-To: ipfix@ietf.org Delivered-To: ipfix@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id EBBEE3A690C; Fri, 16 Oct 2009 06:15:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20091016131501.EBBEE3A690C@core3.amsl.com> Date: Fri, 16 Oct 2009 06:15:01 -0700 (PDT) Cc: ipfix@ietf.org Subject: [IPFIX] I-D Action:draft-ietf-ipfix-mediators-problem-statement-06.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: Fri, 16 Oct 2009 13:15:02 -0000 --NextPart 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 : IPFIX Mediation: Problem Statement Author(s) : A. Kobayashi, et al. Filename : draft-ietf-ipfix-mediators-problem-statement-06.txt Pages : 31 Date : 2009-10-16 Flow-based measurement is a popular method for various network monitoring usages. The sharing of flow-based information for monitoring applications having different requirements raises some open issues in terms of measurement system scalability, flow-based measurement flexibility, and export reliability that IPFIX Mediation may help resolve. This document describes the IPFIX Mediation applicability examples, along with some problems that network administrators have been facing. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipfix-mediators-problem-statement-06.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 Content-Type: Message/External-body; name="draft-ietf-ipfix-mediators-problem-statement-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-10-16060919.I-D@ietf.org> --NextPart-- From root@core3.amsl.com Fri Oct 16 06:15:02 2009 Return-Path: X-Original-To: ipfix@ietf.org Delivered-To: ipfix@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 17B033A686B; Fri, 16 Oct 2009 06:15:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20091016131502.17B033A686B@core3.amsl.com> Date: Fri, 16 Oct 2009 06:15:01 -0700 (PDT) Cc: ipfix@ietf.org Subject: [IPFIX] I-D Action:draft-ietf-ipfix-mediators-framework-04.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: Fri, 16 Oct 2009 13:15:02 -0000 --NextPart 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 : IPFIX Mediation: Framework Author(s) : A. Kobayashi, et al. Filename : draft-ietf-ipfix-mediators-framework-04.txt Pages : 33 Date : 2009-10-16 This document describes a framework for IPFIX Mediation. This framework details the IPFIX Mediation reference model and IPFIX Mediator components. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipfix-mediators-framework-04.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 Content-Type: Message/External-body; name="draft-ietf-ipfix-mediators-framework-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-10-16061415.I-D@ietf.org> --NextPart-- From akoba@nttv6.net Fri Oct 16 10:02:32 2009 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 F136C3A692B for ; Fri, 16 Oct 2009 10:02:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-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 PRYRrpa-XBJw for ; Fri, 16 Oct 2009 10:02:31 -0700 (PDT) Received: from mail.nttv6.net (mail.nttv6.net [IPv6:2001:fa8::25]) by core3.amsl.com (Postfix) with ESMTP id B72F63A68F5 for ; Fri, 16 Oct 2009 10:02:30 -0700 (PDT) Received: from [10.10.10.20] ([IPv6:2001:fa8:1000:0:4082:4a39:ad79:8b13]) by mail.nttv6.net (8.14.3/8.14.3) with ESMTP id n9GH2Xwp037155 for ; Sat, 17 Oct 2009 02:02:33 +0900 (JST) (envelope-from akoba@nttv6.net) Date: Sat, 17 Oct 2009 01:53:17 +0900 From: Atsushi Kobayashi To: ipfix@ietf.org In-Reply-To: <20091016131502.17B033A686B@core3.amsl.com> References: <20091016131502.17B033A686B@core3.amsl.com> Message-Id: <20091017011805.5BA4.17391CF2@nttv6.net> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Becky! ver. 2.50.05 [ja] (Unregistered) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.3 (mail.nttv6.net [IPv6:2001:fa8::25]); Sat, 17 Oct 2009 02:02:33 +0900 (JST) Subject: Re: [IPFIX] I-D Action:draft-ietf-ipfix-mediators-framework-04.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: Fri, 16 Oct 2009 17:02:32 -0000 Hi IPFIX chairs, and all, I posted two drafts related to IPFIX Mediation. In problem statement draft, during last IETF meeting week, all of open issues had been resolved at that time thanks to Brian, Gerhard, and Benoit Changes from previous version includes minor corrections in terminology section. The due date on our milestone is approaching, so it is time to start 2nd WG last call. Juergen and Nevil, could you please call WGLC. Oct 2009 - Submit Mediation Problem Statement I-D to IESG for publication as Informational RFC In framework draft, after last IETF meeting, we have reviewed and rewrote it again and again. All of open issues are resolved, it is ready to WGLC as well. It is better that the framework WGLC follows problem statement WGLC, so we get the feedback on problem statement draft. Regards, Atsushi On Fri, 16 Oct 2009 06:15:01 -0700 (PDT) Internet-Drafts@ietf.org wrote: > 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 : IPFIX Mediation: Framework > Author(s) : A. Kobayashi, et al. > Filename : draft-ietf-ipfix-mediators-framework-04.txt > Pages : 33 > Date : 2009-10-16 > > This document describes a framework for IPFIX Mediation. This > framework details the IPFIX Mediation reference model and IPFIX > Mediator components. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-ipfix-mediators-framework-04.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. --- Atsushi KOBAYASHI NTT Information Sharing Platform Lab. tel:+81-(0)422-59-3978 fax:+81-(0)422-59-5637 From Quittek@nw.neclab.eu Sun Oct 18 22:02:22 2009 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 8EE7528B23E for ; Sun, 18 Oct 2009 22:02:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.855 X-Spam-Level: X-Spam-Status: No, score=-1.855 tagged_above=-999 required=5 tests=[AWL=-0.745, BAYES_05=-1.11] 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 pJQEFxJgOSKn for ; Sun, 18 Oct 2009 22:02:21 -0700 (PDT) Received: from smtp0.neclab.eu (smtp0.neclab.eu [195.37.70.41]) by core3.amsl.com (Postfix) with ESMTP id 53B913A672E for ; Sun, 18 Oct 2009 22:02:21 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp0.neclab.eu (Postfix) with ESMTP id 4DA222C01898B for ; Mon, 19 Oct 2009 07:02:22 +0200 (CEST) X-Virus-Scanned: Amavisd on Debian GNU/Linux (atlas2.office) Received: from smtp0.neclab.eu ([127.0.0.1]) by localhost (atlas2.office [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Mo0sGbWxexhF for ; Mon, 19 Oct 2009 07:02:22 +0200 (CEST) Received: from VENUS.office (mx1.office [192.168.24.3]) by smtp0.neclab.eu (Postfix) with ESMTP id 17B2A2C017B2F for ; Mon, 19 Oct 2009 07:02:17 +0200 (CEST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Received: from 10.7.0.54 ([10.7.0.54]) by VENUS.office ([192.168.24.102]) with Microsoft Exchange Server HTTP-DAV ; Mon, 19 Oct 2009 05:02:16 +0000 MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="B_3338805726_1540870" Content-class: urn:content-classes:message Date: Mon, 19 Oct 2009 07:02:06 +0200 Message-ID: X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: WG last call on draft-ietf-ipfix-mediators-problem-statement-06 thread-index: AcpQeU3M8DPjQJMPR0mj8ATNKpRCdw== From: "Juergen Quittek" To: "IETF IPFIX Working Group" Subject: [IPFIX] WG last call on draft-ietf-ipfix-mediators-problem-statement-06 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, 19 Oct 2009 05:02:22 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3338805726_1540870 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Dear all, At our session in Stockholm we agreed to start the 2nd working group last call on the mediation problem state as soon as a new version of it would be available. The new version is http://www.ietf.org/internet-drafts/draft-ietf-ipfix-mediators-problem-state ment-06.txt The call starts today and will last until Friday October 30. Please read the draft! Please send your comments to this mailing list! Please also send a message if you are fine with the draft as it is! Thank you, Juergen --B_3338805726_1540870 Content-type: application/pkcs7-signature; name="smime.p7s" Content-transfer-encoding: base64 Content-disposition: attachment; filename="smime.p7s" MIIQ6gYJKoZIhvcNAQcCoIIQ2zCCENcCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC DpIwggU2MIIEHqADAgECAgQNLisHMA0GCSqGSIb3DQEBBQUAMIGQMQswCQYDVQQGEwJERTEY MBYGA1UEChMPTkVDIEV1cm9wZSBMdGQuMSAwHgYDVQQLExdORUMgTGFib3JhdG9yaWVzIEV1 cm9wZTESMBAGA1UEAxMJTkVDTEFCLUNBMTEwLwYJKoZIhvcNAQkBFiJ6ZXJ0aWZpemllcnVu Z3NzdGVsbGVAbncubmVjbGFiLmV1MB4XDTA4MTEwMzA3NTEyMFoXDTExMTEwMzA3NTEyMFow YzELMAkGA1UEBhMCREUxGDAWBgNVBAoTD05FQyBFdXJvcGUgTHRkLjEgMB4GA1UECxMXTkVD IExhYm9yYXRvcmllcyBFdXJvcGUxGDAWBgNVBAMTD0p1ZXJnZW4gUXVpdHRlazCCASIwDQYJ KoZIhvcNAQEBBQADggEPADCCAQoCggEBALYRfFB9x4h1YO6Mva6A5GCwKjwpgvzjiayFSmdD HwV8u5gHp3sHIhyVtxgMSifEp9AV+ChxWHS3KQwuQ3XhDAP/xDN6QSk4Bmqa6rCZuTJygxYh K39rNKd47ZfpuRC7j/Mbzwe9DTsbbBtpBgl5UKFc9c+zMbPlSwwlVbshWaUEoM6HoVFaDJdh tJBIpsblz1oQVKXDjxjGkUNh9Ds3m7BGXkr5yaGsEuEa0J/QAFdO+auvBJlAzIM0UwBAmlcT UHanS6Sdw5MkeutQqnmsUBtoenydq2Tmd9hfSfuTfiFuLmsvL3udH/jDAgQZ+PH6Mprqpyd3 wSycF/xZF5zz8X0CAwEAAaOCAcIwggG+MAkGA1UdEwQCMAAwCwYDVR0PBAQDAgXgMCkGA1Ud JQQiMCAGCCsGAQUFBwMCBggrBgEFBQcDBAYKKwYBBAGCNxQCAjAdBgNVHQ4EFgQUWQo3BPrO OLA4qljzDL1H8/6hIWEwHwYDVR0jBBgwFoAUTxyHeh3gL5n2vhWq0TWdDkrmujYwHwYDVR0R BBgwFoEUUXVpdHRla0Budy5uZWNsYWIuZXUwfQYDVR0fBHYwdDA4oDagNIYyaHR0cDovL2Nk cDEucGNhLmRmbi5kZS9uZWNsYWItY2EvcHViL2NybC9jYWNybC5jcmwwOKA2oDSGMmh0dHA6 Ly9jZHAyLnBjYS5kZm4uZGUvbmVjbGFiLWNhL3B1Yi9jcmwvY2FjcmwuY3JsMIGYBggrBgEF BQcBAQSBizCBiDBCBggrBgEFBQcwAoY2aHR0cDovL2NkcDEucGNhLmRmbi5kZS9uZWNsYWIt Y2EvcHViL2NhY2VydC9jYWNlcnQuY3J0MEIGCCsGAQUFBzAChjZodHRwOi8vY2RwMi5wY2Eu ZGZuLmRlL25lY2xhYi1jYS9wdWIvY2FjZXJ0L2NhY2VydC5jcnQwDQYJKoZIhvcNAQEFBQAD ggEBAB37+54yupDBTDpEMuyf+ouCRrOE3fPAD2SEGBXCpKTYteFkFSWvHlgN8ecRSma0Dz/5 QShzacGMeJ8o+XzVXHe2gtZbjzSVvJn+/nAKtKgDCzw0ltt3xkdMMv2ax6IKGR7BcccsXx7B R2PMaxdmHfCJseXiMzZO9QlWN2NZq2SSo3eGX/YDhHCWXDsoSu+uaKU/aRL2uZa92ptak2MA uKI5tylKLFZ3FHf08F8J+5tTaMGem6DfaMZR/9GZ8aRFJrdA7tzUAGKpl+CzRxsJVHbAAU5L hm5oTt6XYbh2G/cgdpeucsHJWBz9NQJrSrfWZYSwrv6AekMcvMi9X/CVZxEwggUvMIIEF6AD AgECAgQNIQpHMA0GCSqGSIb3DQEBBQUAMFoxCzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpERk4t VmVyZWluMRAwDgYDVQQLEwdERk4tUEtJMSQwIgYDVQQDExtERk4tVmVyZWluIFBDQSBHbG9i YWwgLSBHMDEwHhcNMDgxMDI0MDg1MjA4WhcNMTkwNjMwMDAwMDAwWjCBkDELMAkGA1UEBhMC REUxGDAWBgNVBAoTD05FQyBFdXJvcGUgTHRkLjEgMB4GA1UECxMXTkVDIExhYm9yYXRvcmll cyBFdXJvcGUxEjAQBgNVBAMTCU5FQ0xBQi1DQTExMC8GCSqGSIb3DQEJARYiemVydGlmaXpp ZXJ1bmdzc3RlbGxlQG53Lm5lY2xhYi5ldTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoC ggEBAJ7yFbG1EaoyDnG5367mJEXHljmacrzNnm52KW3dXD/s3Vpuskex0jvaaTntWWRSGrAK 6kKXnTxBb3J3EhveBUbltzQ+K0XKtPJm6VE5qVpl33WJSaUHs27Dhwlke+DV6BBGyukz2SDB aSa+nc0AwMZ0XO1DoDuiUNVeNmd/QT4SGzyFs+uLfLL2n8WzkZsbpSZ+xecwyw3EdQBBsp/i /W+uOQBsGqaCjYe3EkBU6nW+pBsj0Iy1n7b9PXb5gQynrK3Mi2V7g1idSzHos0o1BMoHUrMz Vw94Hj4CWlWmQ0t6Pdt1uYAMjwk0saQBY/Fyfv+wKeYycGIYyYCfJIRUeyUCAwEAAaOCAcQw ggHAMBIGA1UdEwEB/wQIMAYBAf8CAQEwCwYDVR0PBAQDAgEGMB0GA1UdDgQWBBRPHId6HeAv mfa+FarRNZ0OSua6NjAfBgNVHSMEGDAWgBRJt8bP6D0ff+pEexMp9/EKcD7eZDAtBgNVHREE JjAkgSJ6ZXJ0aWZpemllcnVuZ3NzdGVsbGVAbncubmVjbGFiLmV1MIGIBgNVHR8EgYAwfjA9 oDugOYY3aHR0cDovL2NkcDEucGNhLmRmbi5kZS9nbG9iYWwtcm9vdC1jYS9wdWIvY3JsL2Nh Y3JsLmNybDA9oDugOYY3aHR0cDovL2NkcDIucGNhLmRmbi5kZS9nbG9iYWwtcm9vdC1jYS9w dWIvY3JsL2NhY3JsLmNybDCBogYIKwYBBQUHAQEEgZUwgZIwRwYIKwYBBQUHMAKGO2h0dHA6 Ly9jZHAxLnBjYS5kZm4uZGUvZ2xvYmFsLXJvb3QtY2EvcHViL2NhY2VydC9jYWNlcnQuY3J0 MEcGCCsGAQUFBzAChjtodHRwOi8vY2RwMi5wY2EuZGZuLmRlL2dsb2JhbC1yb290LWNhL3B1 Yi9jYWNlcnQvY2FjZXJ0LmNydDANBgkqhkiG9w0BAQUFAAOCAQEAbDEPnQ9JpouPHYA1OEek P3l3GNM0HBzadVbtbN5MDtFmoVgdLYqlQaHb30wFhuOMbsNCOzV0k8EOvBVOT9BiEJ70RWcl SZQ460jZS2MY6n5oG/ilZuu6N/N3GSLg2pBBNH9vZFCyBJ9n4Px7A4gQF07G+CNfV2jdE1yy PjzIVPhg6bBgia8nXroBFe6oteavMspo0gLGIJ63NsCbl6ckPa96grT+mnnQD0h6jk/IGtXS 09mEWRbN7zZu0x0q+SScpljG36Q+jnG0U5zQI0jAx8CcYEQQH5QOlsw1Zu35OI4lsi7ycFkz JNfbfEC4ihuw9J2L43BFGMojkhPkhVExHTCCBCEwggMJoAMCAQICAgDHMA0GCSqGSIb3DQEB BQUAMHExCzAJBgNVBAYTAkRFMRwwGgYDVQQKExNEZXV0c2NoZSBUZWxla29tIEFHMR8wHQYD VQQLExZULVRlbGVTZWMgVHJ1c3QgQ2VudGVyMSMwIQYDVQQDExpEZXV0c2NoZSBUZWxla29t IFJvb3QgQ0EgMjAeFw0wNjEyMTkxMDI5MDBaFw0xOTA2MzAyMzU5MDBaMFoxCzAJBgNVBAYT AkRFMRMwEQYDVQQKEwpERk4tVmVyZWluMRAwDgYDVQQLEwdERk4tUEtJMSQwIgYDVQQDExtE Rk4tVmVyZWluIFBDQSBHbG9iYWwgLSBHMDEwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEK AoIBAQDpm8NnhfkNrvWNVMOWUDU9YuluTO2U1wBblSJ01CDrNI/W7MAxBAuZgeKmFNJSoCgj hIt0iQReW+DieMF4yxbLKDU5ey2QRdDtoAB6fL9KDhsAw4bpXCsxEXsM84IkQ4wcOItqaACa 7txPeKvSxhObdq3u3ibo7wGvdA/BCaL2a869080UME/15eOkyGKbghoDJzANAmVgTe3RCSMq ljVYJ9N2xnG2kB3E7f81hn1vM7PbD8URwoqDoZRdQWvY0hD1TP3KUazZve+Sg7va64sWVlZD z+HVEz2mHycwzUlU28kTNJpxdcVs6qcLmPkhnSevPqM5OUhqjK3JmfvDEvK9AgMBAAGjgdkw gdYwcAYDVR0fBGkwZzBloGOgYYZfaHR0cDovL3BraS50ZWxlc2VjLmRlL2NnaS1iaW4vc2Vy dmljZS9hZl9Eb3dubG9hZEFSTC5jcmw/LWNybF9mb3JtYXQ9WF81MDkmLWlzc3Vlcj1EVF9S T09UX0NBXzIwHQYDVR0OBBYEFEm3xs/oPR9/6kR7Eyn38QpwPt5kMB8GA1UdIwQYMBaAFDHD eRu69VPXF+CJei0XbAqzK50zMA4GA1UdDwEB/wQEAwIBBjASBgNVHRMBAf8ECDAGAQH/AgEC MA0GCSqGSIb3DQEBBQUAA4IBAQA74Vp3wEgX3KkY7IGvWonwvSiSpspZGBJw7Cjy565/lizn 8l0ZMfYTK3S9vYCyufdnyTmieTvhERHua3iRM347XyYndVNljjNj7s9zw7CSI0khUHUjoR8Y 4pSFPT8z6XcgjaK95qGFKUD2P3MyWA0Ja6bahWzAP7uNZmRWJE6uDT8yNQFb6YyC2XJZT7GG hfF0hVblw/hc843uR7NTBXDn5U2KaYMo4RMJhp5eyOpYHgwf+aTUWgRo/Sg+iwK2WLX2oSw3 VwBnqyNojWOl75lrXP1LVvarQIc01BGSbOyHxQoLBzNytG8MHVQs2FHHzL8w00Ny8TK/jM5J Y6gA9/IcMYICIDCCAhwCAQEwgZkwgZAxCzAJBgNVBAYTAkRFMRgwFgYDVQQKEw9ORUMgRXVy b3BlIEx0ZC4xIDAeBgNVBAsTF05FQyBMYWJvcmF0b3JpZXMgRXVyb3BlMRIwEAYDVQQDEwlO RUNMQUItQ0ExMTAvBgkqhkiG9w0BCQEWInplcnRpZml6aWVydW5nc3N0ZWxsZUBudy5uZWNs YWIuZXUCBA0uKwcwCQYFKw4DAhoFAKBdMCMGCSqGSIb3DQEJBDEWBBTD56TUgWSVW/7RAXqv zjq5mzvkYTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wOTEw MTkwNTAyMDZaMA0GCSqGSIb3DQEBAQUABIIBAAzcNn1wG8gNE1pH4wLDRyCgoB6Isysy69rH FMabC87QzTqpK9UpR6p0gHHkiS1mChwkVyONlqkkGZwVDRy6KbPRlF5CLhVlsLyp0OXtXd34 DwKbhMKQhwa/bWTnrkWdPGDpwYEpZNGX7EIetjQGekNKnevPaeBgT89RdOjadYiO2dGgsOUa OzUSe71c+hHwbCO6rkyXY2bm54lIzy5/5ygzGDetAvd8XOW2OLFTEqaPqWB5Vjogef69xduo D43kCP1FEmcFLHElJHCQ8MriyWDw3Y1a0h0DJohovea67ctjfIICZa1THXeIY5y0RllZ+d1R DdnSTvAuBOAgtDb7KD4= --B_3338805726_1540870-- From muenz@net.in.tum.de Mon Oct 19 08:41:08 2009 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 A71FE3A681E for ; Mon, 19 Oct 2009 08:41:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.165 X-Spam-Level: X-Spam-Status: No, score=0.165 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, 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 t+otQHBWVZJn for ; Mon, 19 Oct 2009 08:41:07 -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 0D99E3A698F for ; Mon, 19 Oct 2009 08:41:06 -0700 (PDT) Received: from phoenix.net.informatik.tu-muenchen.de (phoenix.net.in.tum.de [131.159.14.1]) by services.net.informatik.tu-muenchen.de (Postix Mailer @ mail) with ESMTP id CCB1A4847A; Mon, 19 Oct 2009 17:40:56 +0200 (CEST) Received: from [131.159.20.108] (repulse.net.in.tum.de [131.159.20.108]) by phoenix.net.informatik.tu-muenchen.de (Postfix) with ESMTP id A39D25522; Mon, 19 Oct 2009 17:40:56 +0200 (CEST) Message-ID: <4ADC88B1.4020608@net.in.tum.de> Date: Mon, 19 Oct 2009 17:41:37 +0200 From: Gerhard Muenz User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: "ipfix@ietf.org" , Tanja Zseby , Benoit Claise Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms020000080904010200040709" X-Virus-Scanned: ClamAV using ClamSMTP Subject: [IPFIX] Hash-based filtering config parameters 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, 19 Oct 2009 15:41:08 -0000 This is a cryptographically signed message in MIME format. --------------ms020000080904010200040709 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Hi Tanja, Benoit, all, I have two questions regarding the configuration of hash-based filtering.= 1) Are IP header fields/bits fixed or configurable? RFC 5475, Section 7.2 says: http://tools.ietf.org/html/rfc5475#section-7.2 Case hashing: - Hash Domain (input bits from packet) -
- -
- - - =3D> header bits seems to be configurable RFC 5476, Section 6.5.2.6 says: http://tools.ietf.org/html/rfc5476#section-6.5.2.6 In Hash-based Selection, a Hash Function is run on IPv4 traffic. The= following fields MUST be used as input to that Hash Function: - IP identification field - Flags field - Fragment offset - Source IP address - Destination IP address - A number of bytes from the IP payload. The number of bytes and starting offset MUST be configurable if the Hash Function supports it. =3D> header fields seems to be fixed. 2) Is the output range of the hash function a configuration parameter or = just an invariant property of the hash function itself? If yes, should it be configured as min and max or as length and bitmask? RFC 5475, Section 7.2 says: http://tools.ietf.org/html/rfc5475#section-7.2 - Hash Function - Hash Function name - Length of input key (eliminate 0x bytes) - Output value (length M and bitmask) - Hash Selection Range, as a list of non-overlapping intervals [start value, end value] where value is in [0,2^M-1] - Additional parameters are dependent on specific Hash Function (e.g., hash input bits (seed)) =3D> output value length and bitmask seem to correspond to the output=20 range defined by hashOutputRangeMin and hashOutputRangeMax Thanks, Gerhard --=20 Dipl.-Ing. Gerhard M=FCnz Chair for Network Architectures and Services (I8) Technische Universit=E4t M=FCnchen - Department of Informatics Boltzmannstr. 3, 85748 Garching bei M=FCnchen, Germany Phone: +49 89 289-18008 Fax: +49 89 289-18033 E-mail: muenz@net.in.tum.de WWW: http://www.net.in.tum.de/~muenz --------------ms020000080904010200040709 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJ6TCC Az8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJBgNVBAYTAlpBMRUwEwYDVQQI EwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgGA1UEChMRVGhhd3RlIENv bnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMgRGl2aXNpb24xJDAi BgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3DQEJARYccGVy c29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3MTYyMzU5 NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBM dGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzAN BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9Vvy Gna9fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOC dz0Dviv+uxg+B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCB kTASBgNVHRMBAf8ECDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhh d3RlLmNvbS9UaGF3dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIBBjApBgNV HREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEFBQAD gYEASIzRUIPqCy7MDaNmrGcPf6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFi w9k6GX6EsZkbAMUaC4J0niVQlGLH2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpb NU1341YheILcIRk13iSx0x1G/11fZU8wggNPMIICuKADAgECAhAqxerdN2XVRkUZsuk5IKdP MA0GCSqGSIb3DQEBBQUAMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3Vs dGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNz dWluZyBDQTAeFw0wOTAyMTkxMDI5NDVaFw0xMDAyMTkxMDI5NDVaMIGQMQ4wDAYDVQQEEwVN dWVuejEQMA4GA1UEKhMHR2VyaGFyZDEWMBQGA1UEAxMNR2VyaGFyZCBNdWVuejEwMC4GCSqG SIb3DQEJARYhbXVlbnpAaW5mb3JtYXRpay51bmktdHVlYmluZ2VuLmRlMSIwIAYJKoZIhvcN AQkBFhNtdWVuekBuZXQuaW4udHVtLmRlMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKC AQEAxC8p+6KRpyQyKvT9LAxUB2m8azrci+c5oQUYac2A4WsjoqiCqi2k/wgCrCIHrN0USQeH LmcbtSWT5O+1kMai28KGUdZG5xmJ7PLuLejKlYIu2TkR8tI1Q4gyu1Gs45yn9Rf+EGWmqa/s ebjMV3tc/zrpEN2b1ls8U9rM2/h0NcUUU+g170e8DlXNOL7+bsQD+tLH5G3nlV9mZntMQ68t PaaLG4MtupHuS99YGoo0yB4rzuTxiWRKTJgqjboQL0eS9+6dxsrT01g7sOc2QtXbO45PBnsG Ra5CAMpGLrqGT1ISZIpqYrGuMH9Rv7HTR3rLygL81WMDtNCa6W5/PPMlSwIDAQABo1MwUTBB BgNVHREEOjA4gSFtdWVuekBpbmZvcm1hdGlrLnVuaS10dWViaW5nZW4uZGWBE211ZW56QG5l dC5pbi50dW0uZGUwDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUFAAOBgQBOkMsohjpIH4Mr 33zNnhc5PkzAi0RZ6UAOB28nTtfjVZ25UVLWqmLgYEszbloTd07y5PcUZhSuPuwGzEwn4XdX i3VWl6qk5VcPpyP7+b5XEY5CU1A8cqeaXS88qWyshu1dXm2ToqueRPv+E2b3GJHAciNt2Qfc T4SNWymkvUyPSjCCA08wggK4oAMCAQICECrF6t03ZdVGRRmy6Tkgp08wDQYJKoZIhvcNAQEF BQAwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0 ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA5 MDIxOTEwMjk0NVoXDTEwMDIxOTEwMjk0NVowgZAxDjAMBgNVBAQTBU11ZW56MRAwDgYDVQQq EwdHZXJoYXJkMRYwFAYDVQQDEw1HZXJoYXJkIE11ZW56MTAwLgYJKoZIhvcNAQkBFiFtdWVu ekBpbmZvcm1hdGlrLnVuaS10dWViaW5nZW4uZGUxIjAgBgkqhkiG9w0BCQEWE211ZW56QG5l dC5pbi50dW0uZGUwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDELyn7opGnJDIq 9P0sDFQHabxrOtyL5zmhBRhpzYDhayOiqIKqLaT/CAKsIges3RRJB4cuZxu1JZPk77WQxqLb woZR1kbnGYns8u4t6MqVgi7ZORHy0jVDiDK7UazjnKf1F/4QZaapr+x5uMxXe1z/OukQ3ZvW WzxT2szb+HQ1xRRT6DXvR7wOVc04vv5uxAP60sfkbeeVX2Zme0xDry09posbgy26ke5L31ga ijTIHivO5PGJZEpMmCqNuhAvR5L37p3GytPTWDuw5zZC1ds7jk8GewZFrkIAykYuuoZPUhJk impisa4wf1G/sdNHesvKAvzVYwO00Jrpbn888yVLAgMBAAGjUzBRMEEGA1UdEQQ6MDiBIW11 ZW56QGluZm9ybWF0aWsudW5pLXR1ZWJpbmdlbi5kZYETbXVlbnpAbmV0LmluLnR1bS5kZTAM BgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBQUAA4GBAE6QyyiGOkgfgyvffM2eFzk+TMCLRFnp QA4HbydO1+NVnblRUtaqYuBgSzNuWhN3TvLk9xRmFK4+7AbMTCfhd1eLdVaXqqTlVw+nI/v5 vlcRjkJTUDxyp5pdLzypbKyG7V1ebZOiq55E+/4TZvcYkcByI23ZB9xPhI1bKaS9TI9KMYID cTCCA20CAQEwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcg KFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3Vpbmcg Q0ECECrF6t03ZdVGRRmy6Tkgp08wCQYFKw4DAhoFAKCCAdAwGAYJKoZIhvcNAQkDMQsGCSqG SIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDkxMDE5MTU0MTM4WjAjBgkqhkiG9w0BCQQxFgQU EKW3QZddvR+rchhogwpQQX+sTpUwXwYJKoZIhvcNAQkPMVIwUDALBglghkgBZQMEAQIwCgYI KoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqG SIb3DQMCAgEoMIGFBgkrBgEEAYI3EAQxeDB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxU aGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwg RnJlZW1haWwgSXNzdWluZyBDQQIQKsXq3Tdl1UZFGbLpOSCnTzCBhwYLKoZIhvcNAQkQAgsx eKB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBM dGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQKsXq 3Tdl1UZFGbLpOSCnTzANBgkqhkiG9w0BAQEFAASCAQCyUQc3RyIDpHim0Rdigted3S1J6OeO u1eApdYn9J2xt05plzm8W540We2ONaA/RUqIJjXef6r3x2oiB3MURxsDbAxN6Bzk6kzMNnz4 kXc5W+i/uZfPyU5wZ/laK4rGcUmV0rSA31OmqbiUcO5e0LDH+FL+7CYVYiA7S2EgwM1l3Vwi 3rWgiA4qFwhGr6c8oEMlURhxeLV4dK5XDXFpCdXCRh2O4+UWorBhm84jpIdejl0oCkPb8Dn0 w/6tS7oNhI/yQ8CuJjB4rV1RCfOxmAp4B92EMRvPDn5otX6e6bEE4LlWxV9ioex9Nj1xS/d3 YXcC0AebHTjH5T8V7h+MHp00AAAAAAAA --------------ms020000080904010200040709-- From root@core3.amsl.com Mon Oct 19 13:00:03 2009 Return-Path: X-Original-To: ipfix@ietf.org Delivered-To: ipfix@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 304E328C131; Mon, 19 Oct 2009 13:00:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20091019200003.304E328C131@core3.amsl.com> Date: Mon, 19 Oct 2009 13:00:02 -0700 (PDT) Cc: ipfix@ietf.org Subject: [IPFIX] I-D ACTION:draft-ietf-ipfix-structured-data-00.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, 19 Oct 2009 20:00:03 -0000 --NextPart 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 : Export of Structured Data in IPFIX Author(s) : B. Claise, G. Dhandapani, S. Yates, P. Aitken Filename : draft-ietf-ipfix-structured-data-00.txt Pages : 57 Date : 2009-10-15 This document specifies an extension to IP Flow Information eXport (IPFIX) protocol specification in [RFC5101] and the IPFIX information model specified in [RFC5102] to support hierarchical structured data and lists (sequences) of Information Elements in data records. This extension allows definition of complex data structures such as variable-length lists and specification of hierarchical containment relationships between Temp A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipfix-structured-data-00.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 Content-Type: Message/External-body; name="draft-ietf-ipfix-structured-data-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-10-19125900.I-D@ietf.org> --NextPart-- From root@core3.amsl.com Mon Oct 19 15:30:02 2009 Return-Path: X-Original-To: ipfix@ietf.org Delivered-To: ipfix@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 208BF3A68EC; Mon, 19 Oct 2009 15:30:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20091019223002.208BF3A68EC@core3.amsl.com> Date: Mon, 19 Oct 2009 15:30:02 -0700 (PDT) Cc: ipfix@ietf.org Subject: [IPFIX] I-D ACTION:draft-ietf-ipfix-flow-selection-tech-00.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, 19 Oct 2009 22:30:02 -0000 --NextPart 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 : Flow Selection Techniques Author(s) : L. Peluso, T. Zseby, S. D'Antonio, M. Molina Filename : draft-ietf-ipfix-flow-selection-tech-00.txt Pages : 25 Date : 2009-10-18 Flow selection is the process in charge of electing a limited number of flows from all of those observed at an observation point to be considered into the measurement process chain. The flow selection process can be enabled at different stages of the monitoring reference model. It can be performed at metering time once the packet classification has been executed, i.e. flow state dependent packet selection, or at recording/exporting time by limiting the number of flows to be stored and/or exported to the collector applications. This document illustrates the motivations which might lead flow selection to be performed and presents a classification of the related techniques. The document furthermore provides an information model for configuring flow selection techniques and discusses what information about the flow selection process is beneficial to be exported by adopting a suitable information model. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipfix-flow-selection-tech-00.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 Content-Type: Message/External-body; name="draft-ietf-ipfix-flow-selection-tech-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-10-19152422.I-D@ietf.org> --NextPart-- From bclaise@cisco.com Tue Oct 20 17:26:08 2009 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 A4E053A693F; Tue, 20 Oct 2009 17:26:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.77 X-Spam-Level: X-Spam-Status: No, score=-1.77 tagged_above=-999 required=5 tests=[AWL=0.472, BAYES_00=-2.599, HTML_MESSAGE=0.001, SARE_SUB_6CONS_WORD=0.356] 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 i5TndoZ8oVvv; Tue, 20 Oct 2009 17:26:07 -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 7DBCC3A68FA; Tue, 20 Oct 2009 17:26:07 -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 n9L0B4OI029532; Wed, 21 Oct 2009 02:11:05 +0200 (CEST) Received: from [10.55.43.53] (ams-bclaise-8714.cisco.com [10.55.43.53]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id n9L0B1Ot019033; Wed, 21 Oct 2009 02:11:01 +0200 (CEST) Message-ID: <4ADE5195.50705@cisco.com> Date: Wed, 21 Oct 2009 02:11:01 +0200 From: Benoit Claise User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: "Peter Lei (peterlei)" , Randy Stewart , Michael Tuexen References: <20090705201501.95EAF3A6BFE@core3.amsl.com> In-Reply-To: <20090705201501.95EAF3A6BFE@core3.amsl.com> Content-Type: multipart/alternative; boundary="------------010105080100050905090708" Cc: gorry@erg.abdn.ac.uk, James Polk , tsvwg@ietf.org, "ipfix@ietf.org" Subject: Re: [IPFIX] I-D Action:draft-ietf-tsvwg-sctp-strrst-00.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: Wed, 21 Oct 2009 00:26:08 -0000 This is a multi-part message in MIME format. --------------010105080100050905090708 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Randy, Peter, Michael, As you know, we have this draft http://tools.ietf.org/html/draft-ietf-ipfix-export-per-sctp-stream-03 that depends on the your draft below. With the latest version 04, which will be posted before the end of the week, we move your draft from an informative to a normative reference ... as discussed with the IESG. So, this message is a friendly reminder that we'll like to see some progress on this draft ;-) Regards, Benoit. > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Transport Area Working Group Working Group of the IETF. > > > Title : Stream Control Transmission Protocol (SCTP) Stream Reconfiguration > Author(s) : R. Stewart, et al. > Filename : draft-ietf-tsvwg-sctp-strrst-00.txt > Pages : 20 > Date : 2009-07-05 > > Many applications that desire to use SCTP have requested the ability > to "reset" a stream. The intention of resetting a stream is to start > the numbering sequence of the stream back at 'zero' with a > corresponding notification to the upper layer that this act as been > performed. The applications that have requested this feature > normally desire it so that they can "re-use" streams for different > purposes but still utilize the stream sequence number for the > application to track the message flows. Thus, without this feature, > a new use on an old stream would result in message numbers larger > than expected without a protocol mechanism to "start the streams back > at zero". This documents presents also a method for resetting the > transport sequence numbers and all stream sequence numbers. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-tsvwg-sctp-strrst-00.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. > > ------------------------------------------------------------------------ > > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > --------------010105080100050905090708 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Randy, Peter, Michael,

As you know, we have this draft http://tools.ietf.org/html/draft-ietf-ipfix-export-per-sctp-stream-03 that depends on the your draft below.
With the latest version 04, which will be posted before the end of the week, we move your draft from an informative to a normative reference ... as discussed with the IESG.
So, this message is a friendly reminder that we'll like to see some progress on this draft ;-)

Regards, Benoit.
A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Transport Area Working Group Working Group of the IETF.


	Title           : Stream Control Transmission Protocol (SCTP) Stream Reconfiguration
	Author(s)       : R. Stewart, et al.
	Filename        : draft-ietf-tsvwg-sctp-strrst-00.txt
	Pages           : 20
	Date            : 2009-07-05

Many applications that desire to use SCTP have requested the ability
to "reset" a stream.  The intention of resetting a stream is to start
the numbering sequence of the stream back at 'zero' with a
corresponding notification to the upper layer that this act as been
performed.  The applications that have requested this feature
normally desire it so that they can "re-use" streams for different
purposes but still utilize the stream sequence number for the
application to track the message flows.  Thus, without this feature,
a new use on an old stream would result in message numbers larger
than expected without a protocol mechanism to "start the streams back
at zero".  This documents presents also a method for resetting the
transport sequence numbers and all stream sequence numbers.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-tsvwg-sctp-strrst-00.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.
  

_______________________________________________
I-D-Announce mailing list
I-D-Announce@ietf.org
https://www.ietf.org/mailman/listinfo/i-d-announce
Internet-Draft directories: http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

--------------010105080100050905090708-- From rrs@lakerest.net Tue Oct 20 22:29:40 2009 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 0F73C3A68D1; Tue, 20 Oct 2009 22:29:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.243 X-Spam-Level: X-Spam-Status: No, score=-2.243 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, SARE_SUB_6CONS_WORD=0.356] 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 gRc47T4H9AbG; Tue, 20 Oct 2009 22:29:39 -0700 (PDT) Received: from lakerest.net (unknown [IPv6:2001:240:585:2:213:d4ff:fef3:2d8d]) by core3.amsl.com (Postfix) with ESMTP id 310973A6838; Tue, 20 Oct 2009 22:29:37 -0700 (PDT) Received: from rrs.extremenetworks.com ([80.81.68.42]) (authenticated bits=0) by lakerest.net (8.14.3/8.14.3) with ESMTP id n9L5TIEE031714 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 21 Oct 2009 01:29:24 -0400 (EDT) (envelope-from rrs@lakerest.net) Message-Id: <8C706BD1-BF93-4CCA-9FFB-CC8EFF3D1E37@lakerest.net> From: Randall Stewart To: Benoit Claise In-Reply-To: <4ADE5195.50705@cisco.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Wed, 21 Oct 2009 10:59:12 +0530 References: <20090705201501.95EAF3A6BFE@core3.amsl.com> <4ADE5195.50705@cisco.com> X-Mailer: Apple Mail (2.936) Cc: gorry@erg.abdn.ac.uk, tsvwg , ipfix@ietf.org, Michael Tuexen , "Peter Lei \(peterlei\)" , James Polk Subject: Re: [IPFIX] I-D Action:draft-ietf-tsvwg-sctp-strrst-00.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: Wed, 21 Oct 2009 05:29:40 -0000 Benoit: -00 is the current version. As to what needs done in the document I think: 1) We need to add a socket-api section (Michael and I were going to work on that at EuroBSD but I think we got distracted by the vnet stuff .. opps ;-D) 2) We probably need to touch up the IANA section, it looks to me that it needs a bit of polishing. 3) We need to go back through and make sure the rest of the rules are clear. and finally 4) We need to get a bit more working group review. As to implementation state, I believe the FreeBSD implementation and the IOS implementation are the only two I know that implement this feature. Not sure if IOS has added the "add stream" feature yet, Peter might be able to tell ;-) When we add the socket-api section, I am sure the FreeBSD implementation will also need to "adjust" its current socket API to match the draft... which we will most likely do in real time. Michael, do you have any other things to list here? Note: I don't think either Michael or I will be in Japan, we will both attend Anaheim though (at least we currently intend to) R On Oct 21, 2009, at 5:41 AM, Benoit Claise wrote: > Randy, Peter, Michael, > > As you know, we have this draft http://tools.ietf.org/html/draft-ietf-ipfix-export-per-sctp-stream-03 > that depends on the your draft below. > With the latest version 04, which will be posted before the end of > the week, we move your draft from an informative to a normative > reference ... as discussed with the IESG. > So, this message is a friendly reminder that we'll like to see some > progress on this draft ;-) > > Regards, Benoit. >> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. >> This draft is a work item of the Transport Area Working Group >> Working Group of the IETF. >> >> >> Title : Stream Control Transmission Protocol (SCTP) >> Stream Reconfiguration >> Author(s) : R. Stewart, et al. >> Filename : draft-ietf-tsvwg-sctp-strrst-00.txt >> Pages : 20 >> Date : 2009-07-05 >> >> Many applications that desire to use SCTP have requested the ability >> to "reset" a stream. The intention of resetting a stream is to start >> the numbering sequence of the stream back at 'zero' with a >> corresponding notification to the upper layer that this act as been >> performed. The applications that have requested this feature >> normally desire it so that they can "re-use" streams for different >> purposes but still utilize the stream sequence number for the >> application to track the message flows. Thus, without this feature, >> a new use on an old stream would result in message numbers larger >> than expected without a protocol mechanism to "start the streams back >> at zero". This documents presents also a method for resetting the >> transport sequence numbers and all stream sequence numbers. >> >> A URL for this Internet-Draft is: >> http://www.ietf.org/internet-drafts/draft-ietf-tsvwg-sctp-strrst-00.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. >> >> >> _______________________________________________ >> I-D-Announce mailing list >> I-D-Announce@ietf.org >> https://www.ietf.org/mailman/listinfo/i-d-announce >> Internet-Draft directories: http://www.ietf.org/shadow.html >> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt >> > > _______________________________________________ > IPFIX mailing list > IPFIX@ietf.org > https://www.ietf.org/mailman/listinfo/ipfix ------------------------------ Randall Stewart 803-317-4952 (cell) 803-345-0391(direct) From sujay.ietf@gmail.com Wed Oct 21 01:36:04 2009 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 267493A6860 for ; Wed, 21 Oct 2009 01:36:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 CrxrnhSAaDji for ; Wed, 21 Oct 2009 01:36:03 -0700 (PDT) Received: from mail-pz0-f204.google.com (mail-pz0-f204.google.com [209.85.222.204]) by core3.amsl.com (Postfix) with ESMTP id 481CB3A6767 for ; Wed, 21 Oct 2009 01:36:03 -0700 (PDT) Received: by pzk42 with SMTP id 42so5438043pzk.31 for ; Wed, 21 Oct 2009 01:36:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type :content-transfer-encoding; bh=tdayMKHzg9CPZIgAsZ+5nqxuJcg0AXl3hazfTTO/W5I=; b=Zdbu+Xjpfpm6kd5bakvOEiIU4WJ0BFKCketKl1MrZiXI6GllaKU5ulOCt7N552GDWv Sugqw9q2ZrkMzPwi4euIsJxMsJixYrpZxbWON2RQfJHFOvypza/STH1v9wMqCm0OWSHK OIQxLKn8d+gSV6n50LVtX13JP9UWJqr1oBuYA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; b=R7fDKzCYmAHmkV2u0cf0x/iIuUiYq9lzQ8mO4J7mEPfC8c3UdPK2tGNJseuc8XzLK6 hhK9daTyCUy8bB+1xRRUv90yr2R5fjPTuB4h/aWkV+8aYC3mT4wBXKlaT6+aZyi+WgVL 2Kgrtir7QyviBbkk9yZ0pzw1MojMAeNgGEpIY= MIME-Version: 1.0 Received: by 10.142.119.7 with SMTP id r7mr567655wfc.261.1256114169403; Wed, 21 Oct 2009 01:36:09 -0700 (PDT) In-Reply-To: References: Date: Wed, 21 Oct 2009 01:36:09 -0700 Message-ID: From: sujay gupta To: ipfix@ietf.org Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Subject: [IPFIX] Fwd: [RFC 3917]Overload & Reliability requirements of Metering process 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: Wed, 21 Oct 2009 08:36:04 -0000 Hi All, I have been trying to collect information from about the usage of IE's for Overload/Reliability by collector apps. I have not received any response till now. Internally (for the OEM I work for) I had communicated with our Collector a= pp's design team asking them the same, there response is in the negative, ie they do not make sense out of this data even if my switch sends it. On the switch side, as an implementor I have a problem to get these parameters when my system is under O/L (ex: parameters like ignoredcount or notsentcount) Under O/L the system is not capable of keeping these counts. In a similar lines, when my system is undergoing a soft restart ( control layer restart) I would not be able to keep track of packets not counted etc. So what I am proposing ( and is possible) is that under these conditions like O/L , soft restart the system (switch/router) can easily send to the collector at least the "duration under which it was in the O/L/reset condition" . This information I am thinking would be useful as a rough estimate of monitoring lost, canbe converted in to number of packets not accounted for or may be used as an unaccounted period by the collector. Any thoughts from the group? BR, -Sujay ---------- Forwarded message ---------- From: Sujay Gupta Date: Thu, Oct 1, 2009 at 1:08 AM Subject: [IPFIX] [RFC 3917]Overload & Reliability requirements of Metering process To: "ipfix@ietf.org" Hi, While I do understand the need for reliability and overload requirements from Metering process as in Section 5.1./5.3 RFC 3917 Specifically these IE=92s; ignoredPacketTotalCount, ignoredOctetTotalCount, notSentFlowTotalCount, notSentPacketTotalCount Are there collector app=92s in the market interpreting them? BR, -Sujay _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www.ietf.org/mailman/listinfo/ipfix From muenz@net.in.tum.de Wed Oct 21 01:55:22 2009 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 BBD333A6980 for ; Wed, 21 Oct 2009 01:55:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.042 X-Spam-Level: X-Spam-Status: No, score=-1.042 tagged_above=-999 required=5 tests=[AWL=1.207, 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 3I-nDZGNxz-r for ; Wed, 21 Oct 2009 01:55:21 -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 317153A67A1 for ; Wed, 21 Oct 2009 01:55:21 -0700 (PDT) Received: from phoenix.net.informatik.tu-muenchen.de (phoenix.net.in.tum.de [131.159.14.1]) by services.net.informatik.tu-muenchen.de (Postix Mailer @ mail) with ESMTP id CF36048481; Wed, 21 Oct 2009 10:55:27 +0200 (CEST) Received: from [131.159.20.108] (repulse.net.in.tum.de [131.159.20.108]) by phoenix.net.informatik.tu-muenchen.de (Postfix) with ESMTP id B906254D4; Wed, 21 Oct 2009 10:55:27 +0200 (CEST) Message-ID: <4ADECCB0.1090704@net.in.tum.de> Date: Wed, 21 Oct 2009 10:56:16 +0200 From: Gerhard Muenz User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: sujay gupta References: In-Reply-To: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms050407020901030502000208" X-Virus-Scanned: ClamAV using ClamSMTP Cc: ipfix@ietf.org Subject: Re: [IPFIX] Fwd: [RFC 3917]Overload & Reliability requirements of Metering process 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: Wed, 21 Oct 2009 08:55:22 -0000 This is a cryptographically signed message in MIME format. --------------ms050407020901030502000208 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: quoted-printable Hi Sujay, If you did not get an answer to > Are there collector app=92s in the market interpreting them? the answer is probably "no". What you are proposing is a new Information Element, right? IANA maintains the registry of standard IEs: http://www.iana.org/assignments/ipfix/ipfix.xhtml RFC5102 explains the procedure of adding new standard IEs: http://tools.ietf.org/html/rfc5102#section-7 So, if you think that additional IEs are useful to be standardized, you=20 can write a short Internet-Draft describing them. Furthermore, you are free to define and use enterprise-specific IEs. Regards, Gerhard sujay gupta wrote: > Hi All, >=20 > I have been trying to collect information from about the usage of IE's > for Overload/Reliability by collector apps. >=20 > I have not received any response till now. >=20 > Internally (for the OEM I work for) I had communicated with our Collect= or app's > design team asking them the same, there response is in the negative, > ie they do not make sense out of this data even if my switch sends it. >=20 > On the switch side, as an implementor I have a problem to get these > parameters when my system is under O/L (ex: parameters like > ignoredcount or notsentcount) > Under O/L the system is not capable of keeping these counts. >=20 > In a similar lines, when my system is undergoing a soft restart ( > control layer restart) I would not be able to keep track of packets > not counted etc. >=20 > So what I am proposing ( and is possible) is that under these > conditions like O/L , soft restart the system (switch/router) can > easily send to the collector at least the "duration under which it > was in the O/L/reset condition" . This information I am thinking would > be useful as a rough estimate of monitoring lost, canbe converted in > to number of packets not accounted for or may be used as an > unaccounted period by the collector. >=20 > Any thoughts from the group? >=20 > BR, > -Sujay >=20 >=20 > ---------- Forwarded message ---------- > From: Sujay Gupta > Date: Thu, Oct 1, 2009 at 1:08 AM > Subject: [IPFIX] [RFC 3917]Overload & Reliability requirements of > Metering process > To: "ipfix@ietf.org" >=20 >=20 > Hi, >=20 >=20 >=20 > While I do understand the need for reliability and overload > requirements from Metering process as in Section 5.1./5.3 RFC 3917 >=20 >=20 >=20 > Specifically these IE=92s; >=20 > ignoredPacketTotalCount, ignoredOctetTotalCount, > notSentFlowTotalCount, notSentPacketTotalCount >=20 >=20 >=20 > Are there collector app=92s in the market interpreting them? >=20 >=20 >=20 > BR, >=20 > -Sujay >=20 > _______________________________________________ > 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 --=20 Dipl.-Ing. Gerhard M=FCnz Chair for Network Architectures and Services (I8) Technische Universit=E4t M=FCnchen - Department of Informatics Boltzmannstr. 3, 85748 Garching bei M=FCnchen, Germany Phone: +49 89 289-18008 Fax: +49 89 289-18033 E-mail: muenz@net.in.tum.de WWW: http://www.net.in.tum.de/~muenz --------------ms050407020901030502000208 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJ6TCC Az8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJBgNVBAYTAlpBMRUwEwYDVQQI EwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgGA1UEChMRVGhhd3RlIENv bnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMgRGl2aXNpb24xJDAi BgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3DQEJARYccGVy c29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3MTYyMzU5 NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBM dGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzAN BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9Vvy Gna9fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOC dz0Dviv+uxg+B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCB kTASBgNVHRMBAf8ECDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhh d3RlLmNvbS9UaGF3dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIBBjApBgNV HREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEFBQAD gYEASIzRUIPqCy7MDaNmrGcPf6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFi w9k6GX6EsZkbAMUaC4J0niVQlGLH2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpb NU1341YheILcIRk13iSx0x1G/11fZU8wggNPMIICuKADAgECAhAqxerdN2XVRkUZsuk5IKdP MA0GCSqGSIb3DQEBBQUAMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3Vs dGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNz dWluZyBDQTAeFw0wOTAyMTkxMDI5NDVaFw0xMDAyMTkxMDI5NDVaMIGQMQ4wDAYDVQQEEwVN dWVuejEQMA4GA1UEKhMHR2VyaGFyZDEWMBQGA1UEAxMNR2VyaGFyZCBNdWVuejEwMC4GCSqG SIb3DQEJARYhbXVlbnpAaW5mb3JtYXRpay51bmktdHVlYmluZ2VuLmRlMSIwIAYJKoZIhvcN AQkBFhNtdWVuekBuZXQuaW4udHVtLmRlMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKC AQEAxC8p+6KRpyQyKvT9LAxUB2m8azrci+c5oQUYac2A4WsjoqiCqi2k/wgCrCIHrN0USQeH LmcbtSWT5O+1kMai28KGUdZG5xmJ7PLuLejKlYIu2TkR8tI1Q4gyu1Gs45yn9Rf+EGWmqa/s ebjMV3tc/zrpEN2b1ls8U9rM2/h0NcUUU+g170e8DlXNOL7+bsQD+tLH5G3nlV9mZntMQ68t PaaLG4MtupHuS99YGoo0yB4rzuTxiWRKTJgqjboQL0eS9+6dxsrT01g7sOc2QtXbO45PBnsG Ra5CAMpGLrqGT1ISZIpqYrGuMH9Rv7HTR3rLygL81WMDtNCa6W5/PPMlSwIDAQABo1MwUTBB BgNVHREEOjA4gSFtdWVuekBpbmZvcm1hdGlrLnVuaS10dWViaW5nZW4uZGWBE211ZW56QG5l dC5pbi50dW0uZGUwDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUFAAOBgQBOkMsohjpIH4Mr 33zNnhc5PkzAi0RZ6UAOB28nTtfjVZ25UVLWqmLgYEszbloTd07y5PcUZhSuPuwGzEwn4XdX i3VWl6qk5VcPpyP7+b5XEY5CU1A8cqeaXS88qWyshu1dXm2ToqueRPv+E2b3GJHAciNt2Qfc T4SNWymkvUyPSjCCA08wggK4oAMCAQICECrF6t03ZdVGRRmy6Tkgp08wDQYJKoZIhvcNAQEF BQAwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0 ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA5 MDIxOTEwMjk0NVoXDTEwMDIxOTEwMjk0NVowgZAxDjAMBgNVBAQTBU11ZW56MRAwDgYDVQQq EwdHZXJoYXJkMRYwFAYDVQQDEw1HZXJoYXJkIE11ZW56MTAwLgYJKoZIhvcNAQkBFiFtdWVu ekBpbmZvcm1hdGlrLnVuaS10dWViaW5nZW4uZGUxIjAgBgkqhkiG9w0BCQEWE211ZW56QG5l dC5pbi50dW0uZGUwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDELyn7opGnJDIq 9P0sDFQHabxrOtyL5zmhBRhpzYDhayOiqIKqLaT/CAKsIges3RRJB4cuZxu1JZPk77WQxqLb woZR1kbnGYns8u4t6MqVgi7ZORHy0jVDiDK7UazjnKf1F/4QZaapr+x5uMxXe1z/OukQ3ZvW WzxT2szb+HQ1xRRT6DXvR7wOVc04vv5uxAP60sfkbeeVX2Zme0xDry09posbgy26ke5L31ga ijTIHivO5PGJZEpMmCqNuhAvR5L37p3GytPTWDuw5zZC1ds7jk8GewZFrkIAykYuuoZPUhJk impisa4wf1G/sdNHesvKAvzVYwO00Jrpbn888yVLAgMBAAGjUzBRMEEGA1UdEQQ6MDiBIW11 ZW56QGluZm9ybWF0aWsudW5pLXR1ZWJpbmdlbi5kZYETbXVlbnpAbmV0LmluLnR1bS5kZTAM BgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBQUAA4GBAE6QyyiGOkgfgyvffM2eFzk+TMCLRFnp QA4HbydO1+NVnblRUtaqYuBgSzNuWhN3TvLk9xRmFK4+7AbMTCfhd1eLdVaXqqTlVw+nI/v5 vlcRjkJTUDxyp5pdLzypbKyG7V1ebZOiq55E+/4TZvcYkcByI23ZB9xPhI1bKaS9TI9KMYID cTCCA20CAQEwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcg KFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3Vpbmcg Q0ECECrF6t03ZdVGRRmy6Tkgp08wCQYFKw4DAhoFAKCCAdAwGAYJKoZIhvcNAQkDMQsGCSqG SIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDkxMDIxMDg1NjE2WjAjBgkqhkiG9w0BCQQxFgQU rZA/EPSreSslR1Sjgb4Z1+WItNcwXwYJKoZIhvcNAQkPMVIwUDALBglghkgBZQMEAQIwCgYI KoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqG SIb3DQMCAgEoMIGFBgkrBgEEAYI3EAQxeDB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxU aGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwg RnJlZW1haWwgSXNzdWluZyBDQQIQKsXq3Tdl1UZFGbLpOSCnTzCBhwYLKoZIhvcNAQkQAgsx eKB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBM dGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQKsXq 3Tdl1UZFGbLpOSCnTzANBgkqhkiG9w0BAQEFAASCAQBMPiXPHbQqC+QRpqaIVBAZFiyZZ96C Pf3NJom+Z0oOXEUyzf0DZRWTDF1Euyd3o0jMhNH64hLSfMIJLspIx3NLOx6PEUgzRZxkseqC /oUylSTiUopCLHSw4Z7X66Ph0+bn95ml6HlUAo2nrz1gJ9yO+fJHr7k0jfsebPbNLIForBXD S/99RG2IN52g/NnHjmBtuCPOe3YcAEHT11/9Qm8kUhL3mO7+E49UaYh6+y2IeqnD4Ks+uBLw EdcNJEXAOfkeNHxvRAUmXeJ/xSs5bNY2bPpoipY2579ETIQis6t/csYACbFTkQGRX75zEvWD kM6OqPru/r7YmfgTctwf09eaAAAAAAAA --------------ms050407020901030502000208-- From Tanja.Zseby9ab33xy531fokus.fraunhofer.de@bounce.antispameurope.com Wed Oct 21 03:08:26 2009 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 8A44C3A6801 for ; Wed, 21 Oct 2009 03:08:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 klfkoWD8Jn7Y for ; Wed, 21 Oct 2009 03:08:25 -0700 (PDT) Received: from relay01-haj2.antispameurope.com (relay01-haj2.antispameurope.com [83.246.65.51]) by core3.amsl.com (Postfix) with ESMTP id 6BD8A3A67DF for ; Wed, 21 Oct 2009 03:08:24 -0700 (PDT) Received: by relay01-haj2.antispameurope.com (ASE-Secure-MTA, from userid 1000) id 0E626940AC; Wed, 21 Oct 2009 12:08:31 +0200 (CEST) Received: from pluto.fokus.fraunhofer.de (pluto.fokus.fraunhofer.de [195.37.77.164]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by relay01-haj2.antispameurope.com (ASE-Secure-MTA) with ESMTP id 116BB94086; Wed, 21 Oct 2009 12:08:29 +0200 (CEST) Received: from EXCHSRV.fokus.fraunhofer.de (bohr.fokus.fraunhofer.de [10.147.9.231]) by pluto.fokus.fraunhofer.de (8.14.2/8.14.2) with SMTP id n9LA8Sgo022372; Wed, 21 Oct 2009 12:08:28 +0200 (MEST) x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Wed, 21 Oct 2009 12:08:34 +0200 Message-ID: <804B13F8F3D94A4AB18B9B01ACB68FA102F746E1@EXCHSRV.fokus.fraunhofer.de> In-Reply-To: <4ADECC41.7050905@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Hash-based filtering config parameters Thread-Index: AcpSLrr0jFypbMKKQmy8Ma9ML5ep7wABzbfA References: <4ADC88B1.4020608@net.in.tum.de> <4ADECC41.7050905@cisco.com> From: "Zseby, Tanja" To: "Benoit Claise" , "Gerhard Muenz" Cc: ipfix@ietf.org Subject: Re: [IPFIX] Hash-based filtering config parameters 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: Wed, 21 Oct 2009 10:08:26 -0000 Hi all, in general the parameters are configurable (section 7.2 of RFC5475) in = order to support different (proprietary) hash functions. But for the = usage of the recommended BOB function these parameters have to be filled = with the according values and are fixed (see section 6.2.4.1. of RFC5475 = which is in line with RFC 5476). Kind regards Tanja > -----Urspr=FCngliche Nachricht----- > Von: Benoit Claise [mailto:bclaise@cisco.com] > Gesendet: Mittwoch, 21. Oktober 2009 10:54 > An: Gerhard Muenz > Cc: ipfix@ietf.org; Zseby, Tanja; DUFFIELD, NICHOLAS G (NICK); me; > Aamer Akhter (aakhter) > Betreff: Re: Hash-based filtering config parameters >=20 > Gerhard, >=20 > > > > Hi Tanja, Benoit, all, > > > > I have two questions regarding the configuration of hash-based > filtering. > > > > 1) Are IP header fields/bits fixed or configurable? > > > > RFC 5475, Section 7.2 says: > > http://tools.ietf.org/html/rfc5475#section-7.2 > > > > Case hashing: > > - Hash Domain (input bits from packet) > > -
> > - > > -
> > - > > - > > - > > > > =3D> header bits seems to be configurable > > > > > > RFC 5476, Section 6.5.2.6 says: > > http://tools.ietf.org/html/rfc5476#section-6.5.2.6 > > > > In Hash-based Selection, a Hash Function is run on IPv4 traffic. > The > > following fields MUST be used as input to that Hash Function: > > > > - IP identification field > > > > - Flags field > > > > - Fragment offset > > > > - Source IP address > > > > - Destination IP address > > > > - A number of bytes from the IP payload. The number of bytes > and > > starting offset MUST be configurable if the Hash Function > > supports it. > > > > =3D> header fields seems to be fixed. > I would be tempted to believe the protocol. So RFC5476. >=20 > I'll let Tanja or Nick answer the question below. >=20 > Regards, Benoit. > > > > > > > > 2) Is the output range of the hash function a configuration = parameter > > or just an invariant property of the hash function itself? > > If yes, should it be configured as min and max or as length and > bitmask? > > > > RFC 5475, Section 7.2 says: > > http://tools.ietf.org/html/rfc5475#section-7.2 > > > > - Hash Function > > - Hash Function name > > - Length of input key (eliminate 0x bytes) > > - Output value (length M and bitmask) > > - Hash Selection Range, as a list of non-overlapping > > intervals [start value, end value] where value is in > > [0,2^M-1] > > - Additional parameters are dependent on specific Hash > > Function (e.g., hash input bits (seed)) > > > > =3D> output value length and bitmask seem to correspond to the = output > > range defined by hashOutputRangeMin and hashOutputRangeMax > > > > Thanks, > > Gerhard > > From bclaise@cisco.com Wed Oct 21 03:50:07 2009 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 2EA963A6999 for ; Wed, 21 Oct 2009 03:50:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.106 X-Spam-Level: X-Spam-Status: No, score=-2.106 tagged_above=-999 required=5 tests=[AWL=0.493, 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 PNchuCOYjtwz for ; Wed, 21 Oct 2009 03:50: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 E7E633A691A for ; Wed, 21 Oct 2009 03:50: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 n9L8sUq3029543; Wed, 21 Oct 2009 10:54:30 +0200 (CEST) Received: from [10.55.43.53] (ams-bclaise-8714.cisco.com [10.55.43.53]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id n9L8sPMl022738; Wed, 21 Oct 2009 10:54:25 +0200 (CEST) Message-ID: <4ADECC41.7050905@cisco.com> Date: Wed, 21 Oct 2009 10:54:25 +0200 From: Benoit Claise User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Gerhard Muenz References: <4ADC88B1.4020608@net.in.tum.de> In-Reply-To: <4ADC88B1.4020608@net.in.tum.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "ipfix@ietf.org" Subject: Re: [IPFIX] Hash-based filtering config parameters 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: Wed, 21 Oct 2009 10:50:07 -0000 Gerhard, > > Hi Tanja, Benoit, all, > > I have two questions regarding the configuration of hash-based filtering. > > 1) Are IP header fields/bits fixed or configurable? > > RFC 5475, Section 7.2 says: > http://tools.ietf.org/html/rfc5475#section-7.2 > > Case hashing: > - Hash Domain (input bits from packet) > -
> - > -
> - > - > - > > => header bits seems to be configurable > > > RFC 5476, Section 6.5.2.6 says: > http://tools.ietf.org/html/rfc5476#section-6.5.2.6 > > In Hash-based Selection, a Hash Function is run on IPv4 traffic. The > following fields MUST be used as input to that Hash Function: > > - IP identification field > > - Flags field > > - Fragment offset > > - Source IP address > > - Destination IP address > > - A number of bytes from the IP payload. The number of bytes and > starting offset MUST be configurable if the Hash Function > supports it. > > => header fields seems to be fixed. I would be tempted to believe the protocol. So RFC5476. I'll let Tanja or Nick answer the question below. Regards, Benoit. > > > > 2) Is the output range of the hash function a configuration parameter > or just an invariant property of the hash function itself? > If yes, should it be configured as min and max or as length and bitmask? > > RFC 5475, Section 7.2 says: > http://tools.ietf.org/html/rfc5475#section-7.2 > > - Hash Function > - Hash Function name > - Length of input key (eliminate 0x bytes) > - Output value (length M and bitmask) > - Hash Selection Range, as a list of non-overlapping > intervals [start value, end value] where value is in > [0,2^M-1] > - Additional parameters are dependent on specific Hash > Function (e.g., hash input bits (seed)) > > => output value length and bitmask seem to correspond to the output > range defined by hashOutputRangeMin and hashOutputRangeMax > > Thanks, > Gerhard > From sujay.ietf@gmail.com Wed Oct 21 04:11:11 2009 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 71A2A3A69FD for ; Wed, 21 Oct 2009 04:11:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 PmTkdRc5exhn for ; Wed, 21 Oct 2009 04:11:10 -0700 (PDT) Received: from mail-pw0-f50.google.com (mail-pw0-f50.google.com [209.85.160.50]) by core3.amsl.com (Postfix) with ESMTP id 5D8CB3A69F8 for ; Wed, 21 Oct 2009 04:11:10 -0700 (PDT) Received: by pwi4 with SMTP id 4so1065095pwi.29 for ; Wed, 21 Oct 2009 04:11:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=y8RBI+mEp+aSyFjRHINbnL/GemIiL15HzISA3uURkyA=; b=SYbu82AyUI1MJPaBASjkma02c8tw8wC90ows4UItPJf/7SewxtYWFZ4QmZd4LdSBiC H7N9Cl+fUCb6eCEXdGqb3LyBswS9iGV/8k2GF0G9WDym4OZLXhlI3rkd3m/wdP1V64e4 2W5cSboIMHb3//BbMJP5JoV9GGAyjUPhqWTVU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=GD2R6t+OJ7mqrpeBnOoyD5An84V5Ar9OOPd1yYstOcceV4MC4o4Ldg6ALYq/I3VeFn TLSak7bKlxMkxqzBO+T1aBFvnMyQ7Ey1uf4VY16XF1c/tRiprFojUsodkepqZoFRBN04 CWQZHfR/Om57xFPFUsXYiaDDXWCz1XY7F3aK4= MIME-Version: 1.0 Received: by 10.142.4.17 with SMTP id 17mr554182wfd.85.1256123474486; Wed, 21 Oct 2009 04:11:14 -0700 (PDT) In-Reply-To: <4ADECCB0.1090704@net.in.tum.de> References: <4ADECCB0.1090704@net.in.tum.de> Date: Wed, 21 Oct 2009 04:11:14 -0700 Message-ID: From: sujay gupta To: Gerhard Muenz Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Cc: ipfix@ietf.org Subject: Re: [IPFIX] Fwd: [RFC 3917]Overload & Reliability requirements of Metering process 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: Wed, 21 Oct 2009 11:11:11 -0000 Thanks Gerhard, That would be my intent. BR, -Sujay On Wed, Oct 21, 2009 at 1:56 AM, Gerhard Muenz wrote: > > Hi Sujay, > > If you did not get an answer to >> Are there collector app=92s in the market interpreting them? > the answer is probably "no". > > What you are proposing is a new Information Element, right? > > IANA maintains the registry of standard IEs: > http://www.iana.org/assignments/ipfix/ipfix.xhtml > > RFC5102 explains the procedure of adding new standard IEs: > http://tools.ietf.org/html/rfc5102#section-7 > So, if you think that additional IEs are useful to be standardized, you c= an > write a short Internet-Draft describing them. > > Furthermore, you are free to define and use enterprise-specific IEs. > > Regards, > Gerhard > > > sujay gupta wrote: >> >> Hi All, >> >> I have been trying to collect information from about the usage of IE's >> for Overload/Reliability by collector apps. >> >> I have not received any response till now. >> >> Internally (for the OEM I work for) I had communicated with our Collecto= r >> app's >> design team asking them the same, there response is in the negative, >> ie they do not make sense out of this data even if my switch sends it. >> >> On the switch side, as an implementor I have a problem to get these >> parameters when my system is under O/L (ex: parameters like >> ignoredcount or notsentcount) >> Under O/L the system is not capable of keeping these counts. >> >> In a similar lines, when my system is undergoing a soft restart ( >> control layer restart) I would not be able to keep track of packets >> not counted etc. >> >> So what I am proposing ( and is possible) is that under these >> conditions like O/L , soft restart the system (switch/router) can >> easily send to the collector at least the "duration under which it >> was in the O/L/reset condition" . This information I am thinking would >> be useful as a rough estimate of monitoring lost, canbe converted in >> to number of packets not accounted for or may be used as an >> unaccounted period by the collector. >> >> Any thoughts from the group? >> >> BR, >> -Sujay >> >> >> ---------- Forwarded message ---------- >> From: Sujay Gupta >> Date: Thu, Oct 1, 2009 at 1:08 AM >> Subject: [IPFIX] [RFC 3917]Overload & Reliability requirements of >> Metering process >> To: "ipfix@ietf.org" >> >> >> Hi, >> >> >> >> While I do understand the need for reliability and overload >> requirements from Metering process as in Section 5.1./5.3 RFC 3917 >> >> >> >> Specifically these IE=92s; >> >> ignoredPacketTotalCount, ignoredOctetTotalCount, >> notSentFlowTotalCount, notSentPacketTotalCount >> >> >> >> Are there collector app=92s in the market interpreting them? >> >> >> >> BR, >> >> -Sujay >> >> _______________________________________________ >> 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 > > -- > Dipl.-Ing. Gerhard M=FCnz > Chair for Network Architectures and Services (I8) > Technische Universit=E4t M=FCnchen - Department of Informatics > Boltzmannstr. 3, 85748 Garching bei M=FCnchen, Germany > Phone: +49 89 289-18008 Fax: +49 89 289-18033 > E-mail: muenz@net.in.tum.de WWW: http://www.net.in.tum.de/~muenz > > > From muenz@net.in.tum.de Wed Oct 21 04:37:31 2009 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 4E47C3A6A06 for ; Wed, 21 Oct 2009 04:37:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.646 X-Spam-Level: X-Spam-Status: No, score=-1.646 tagged_above=-999 required=5 tests=[AWL=0.604, 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 9+cageLmjTMr for ; Wed, 21 Oct 2009 04:37:30 -0700 (PDT) Received: from mail-out2.informatik.tu-muenchen.de (mail-out2.informatik.tu-muenchen.de [131.159.0.36]) by core3.amsl.com (Postfix) with ESMTP id D8BA43A695C for ; Wed, 21 Oct 2009 04:37:29 -0700 (PDT) Received: from phoenix.net.informatik.tu-muenchen.de (phoenix.net.in.tum.de [131.159.14.1]) by services.net.informatik.tu-muenchen.de (Postix Mailer @ mail) with ESMTP id 9A62948481; Wed, 21 Oct 2009 13:37:35 +0200 (CEST) Received: from [131.159.20.108] (repulse.net.in.tum.de [131.159.20.108]) by phoenix.net.informatik.tu-muenchen.de (Postfix) with ESMTP id 775F61522; Wed, 21 Oct 2009 13:37:35 +0200 (CEST) Message-ID: <4ADEF2B0.5040509@net.in.tum.de> Date: Wed, 21 Oct 2009 13:38:24 +0200 From: Gerhard Muenz User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: "Zseby, Tanja" References: <4ADC88B1.4020608@net.in.tum.de> <4ADECC41.7050905@cisco.com> <804B13F8F3D94A4AB18B9B01ACB68FA102F746E1@EXCHSRV.fokus.fraunhofer.de> In-Reply-To: <804B13F8F3D94A4AB18B9B01ACB68FA102F746E1@EXCHSRV.fokus.fraunhofer.de> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms000006000607060208090302" X-Virus-Scanned: ClamAV using ClamSMTP Cc: ipfix@ietf.org Subject: Re: [IPFIX] Hash-based filtering config parameters 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: Wed, 21 Oct 2009 11:37:31 -0000 This is a cryptographically signed message in MIME format. --------------ms000006000607060208090302 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Hi Tanja, all, Ok, so if I understand correctly, the hash range directly results from=20 the choice of the hash function. BOB -> 0..2^32-1 IPSX -> 0..2^16-1 CRC-32 -> 0..2^32-1 Which means that we do not configure the hash range, only the hash functi= on. Please find below how the configuration data model looks like at the=20 moment. Feel free to comment. One detail which may be worth discussing: If initiliserValue is not configured, the monitoring devices chooses one = arbitrarily. Should the NETCONF manager be able to retrieve this chosen value? At the moment, this is not foreseen in the model, meaning that the=20 chosen value will not be given to the NETCONF manager. Not sure which=20 behavior is desired. Regards, Gerhard +--------------------------+ | FilterHash | +--------------------------+ 1..* +---------------+ | hashFunction =3D BOB |<>-------| SelectedRange | | ipPayloadOffset =3D 0 | +---------------+ | ipPayloadSize =3D 8 | | name | | digestOutput =3D false | | min | | initialiserValue[0..1] | | max | +--------------------------+ +---------------+ Figure 10: Filter classes For hash-based filtering, the configuration parameters are: hashFunction: Hash function to be used. The following parameter values are defined by the configuration data model: * BOB: BOB Hash Function as specified in [RFC5475], Appendix A.2 * IPSX: IP Shift-XOR (IPSX) Hash Function as specified in [RFC5475], Appendix A.1 * CRC: CRC-32 function as specified in [RFC1141] The default value is "BOB". ipPayloadOffset, ipPayloadSize: ipPayloadOffset and ipPayloadSize configure the offset and the size of the payload section used as input to the hash function. These parameters correspond to the Information Elements hashIPPayloadOffset and hashIPPayloadSize [RFC5477]. Default values are 0 and 8, respectively, corresponding to the minimum configurable values according to [RFC5476], Section 6.2.5.6. digestOutput: digestOutput enables or disables the inclusion of the packet digest in the resulting PSAMP Packet Report. This requires= that the Cache Layout of the Cache generating the Packet Reports includes a digestHashValue field. This parameter corresponds to the Information Element hashDigestOutput [RFC5477]. initialiserValue: Initialiser value to the hash function. This parameter corresponds to the Information Element hashInitialiserValue [RFC5477]. If not configured, the monitoring= device arbitrarily chooses an initialiser value. One or more ranges of matching hash values are defined by the min and= max parameters of the SelectedRange subclass. These parameters correspond to the Information Elements hashSelectedRangeMin and hashSelectedRangeMax [RFC5477]. Zseby, Tanja wrote: > Hi all, >=20 > in general the parameters are configurable (section 7.2 of RFC5475) in = order to support different (proprietary) hash functions. But for the usag= e of the recommended BOB function these parameters have to be filled with= the according values and are fixed (see section 6.2.4.1. of RFC5475 whic= h is in line with RFC 5476). >=20 > Kind regards > Tanja >=20 >=20 >> -----Urspr=FCngliche Nachricht----- >> Von: Benoit Claise [mailto:bclaise@cisco.com] >> Gesendet: Mittwoch, 21. Oktober 2009 10:54 >> An: Gerhard Muenz >> Cc: ipfix@ietf.org; Zseby, Tanja; DUFFIELD, NICHOLAS G (NICK); me; >> Aamer Akhter (aakhter) >> Betreff: Re: Hash-based filtering config parameters >> >> Gerhard, >> >>> Hi Tanja, Benoit, all, >>> >>> I have two questions regarding the configuration of hash-based >> filtering. >>> 1) Are IP header fields/bits fixed or configurable? >>> >>> RFC 5475, Section 7.2 says: >>> http://tools.ietf.org/html/rfc5475#section-7.2 >>> >>> Case hashing: >>> - Hash Domain (input bits from packet) >>> -
>>> - >>> -
>>> - >>> - >>> - >>> >>> =3D> header bits seems to be configurable >>> >>> >>> RFC 5476, Section 6.5.2.6 says: >>> http://tools.ietf.org/html/rfc5476#section-6.5.2.6 >>> >>> In Hash-based Selection, a Hash Function is run on IPv4 traffic. >> The >>> following fields MUST be used as input to that Hash Function: >>> >>> - IP identification field >>> >>> - Flags field >>> >>> - Fragment offset >>> >>> - Source IP address >>> >>> - Destination IP address >>> >>> - A number of bytes from the IP payload. The number of bytes >> and >>> starting offset MUST be configurable if the Hash Function >>> supports it. >>> >>> =3D> header fields seems to be fixed. >> I would be tempted to believe the protocol. So RFC5476. >> >> I'll let Tanja or Nick answer the question below. >> >> Regards, Benoit. >>> >>> >>> 2) Is the output range of the hash function a configuration parameter= >>> or just an invariant property of the hash function itself? >>> If yes, should it be configured as min and max or as length and >> bitmask? >>> RFC 5475, Section 7.2 says: >>> http://tools.ietf.org/html/rfc5475#section-7.2 >>> >>> - Hash Function >>> - Hash Function name >>> - Length of input key (eliminate 0x bytes) >>> - Output value (length M and bitmask) >>> - Hash Selection Range, as a list of non-overlapping >>> intervals [start value, end value] where value is in >>> [0,2^M-1] >>> - Additional parameters are dependent on specific Hash >>> Function (e.g., hash input bits (seed)) >>> >>> =3D> output value length and bitmask seem to correspond to the output= >>> range defined by hashOutputRangeMin and hashOutputRangeMax >>> >>> Thanks, >>> Gerhard >>> >=20 --=20 Dipl.-Ing. Gerhard M=FCnz Chair for Network Architectures and Services (I8) Technische Universit=E4t M=FCnchen - Department of Informatics Boltzmannstr. 3, 85748 Garching bei M=FCnchen, Germany Phone: +49 89 289-18008 Fax: +49 89 289-18033 E-mail: muenz@net.in.tum.de WWW: http://www.net.in.tum.de/~muenz --------------ms000006000607060208090302 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJ6TCC Az8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJBgNVBAYTAlpBMRUwEwYDVQQI EwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgGA1UEChMRVGhhd3RlIENv bnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMgRGl2aXNpb24xJDAi BgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3DQEJARYccGVy c29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3MTYyMzU5 NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBM dGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzAN BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9Vvy Gna9fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOC dz0Dviv+uxg+B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCB kTASBgNVHRMBAf8ECDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhh d3RlLmNvbS9UaGF3dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIBBjApBgNV HREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEFBQAD gYEASIzRUIPqCy7MDaNmrGcPf6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFi w9k6GX6EsZkbAMUaC4J0niVQlGLH2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpb NU1341YheILcIRk13iSx0x1G/11fZU8wggNPMIICuKADAgECAhAqxerdN2XVRkUZsuk5IKdP MA0GCSqGSIb3DQEBBQUAMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3Vs dGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNz dWluZyBDQTAeFw0wOTAyMTkxMDI5NDVaFw0xMDAyMTkxMDI5NDVaMIGQMQ4wDAYDVQQEEwVN dWVuejEQMA4GA1UEKhMHR2VyaGFyZDEWMBQGA1UEAxMNR2VyaGFyZCBNdWVuejEwMC4GCSqG SIb3DQEJARYhbXVlbnpAaW5mb3JtYXRpay51bmktdHVlYmluZ2VuLmRlMSIwIAYJKoZIhvcN AQkBFhNtdWVuekBuZXQuaW4udHVtLmRlMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKC AQEAxC8p+6KRpyQyKvT9LAxUB2m8azrci+c5oQUYac2A4WsjoqiCqi2k/wgCrCIHrN0USQeH LmcbtSWT5O+1kMai28KGUdZG5xmJ7PLuLejKlYIu2TkR8tI1Q4gyu1Gs45yn9Rf+EGWmqa/s ebjMV3tc/zrpEN2b1ls8U9rM2/h0NcUUU+g170e8DlXNOL7+bsQD+tLH5G3nlV9mZntMQ68t PaaLG4MtupHuS99YGoo0yB4rzuTxiWRKTJgqjboQL0eS9+6dxsrT01g7sOc2QtXbO45PBnsG Ra5CAMpGLrqGT1ISZIpqYrGuMH9Rv7HTR3rLygL81WMDtNCa6W5/PPMlSwIDAQABo1MwUTBB BgNVHREEOjA4gSFtdWVuekBpbmZvcm1hdGlrLnVuaS10dWViaW5nZW4uZGWBE211ZW56QG5l dC5pbi50dW0uZGUwDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUFAAOBgQBOkMsohjpIH4Mr 33zNnhc5PkzAi0RZ6UAOB28nTtfjVZ25UVLWqmLgYEszbloTd07y5PcUZhSuPuwGzEwn4XdX i3VWl6qk5VcPpyP7+b5XEY5CU1A8cqeaXS88qWyshu1dXm2ToqueRPv+E2b3GJHAciNt2Qfc T4SNWymkvUyPSjCCA08wggK4oAMCAQICECrF6t03ZdVGRRmy6Tkgp08wDQYJKoZIhvcNAQEF BQAwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0 ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA5 MDIxOTEwMjk0NVoXDTEwMDIxOTEwMjk0NVowgZAxDjAMBgNVBAQTBU11ZW56MRAwDgYDVQQq EwdHZXJoYXJkMRYwFAYDVQQDEw1HZXJoYXJkIE11ZW56MTAwLgYJKoZIhvcNAQkBFiFtdWVu ekBpbmZvcm1hdGlrLnVuaS10dWViaW5nZW4uZGUxIjAgBgkqhkiG9w0BCQEWE211ZW56QG5l dC5pbi50dW0uZGUwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDELyn7opGnJDIq 9P0sDFQHabxrOtyL5zmhBRhpzYDhayOiqIKqLaT/CAKsIges3RRJB4cuZxu1JZPk77WQxqLb woZR1kbnGYns8u4t6MqVgi7ZORHy0jVDiDK7UazjnKf1F/4QZaapr+x5uMxXe1z/OukQ3ZvW WzxT2szb+HQ1xRRT6DXvR7wOVc04vv5uxAP60sfkbeeVX2Zme0xDry09posbgy26ke5L31ga ijTIHivO5PGJZEpMmCqNuhAvR5L37p3GytPTWDuw5zZC1ds7jk8GewZFrkIAykYuuoZPUhJk impisa4wf1G/sdNHesvKAvzVYwO00Jrpbn888yVLAgMBAAGjUzBRMEEGA1UdEQQ6MDiBIW11 ZW56QGluZm9ybWF0aWsudW5pLXR1ZWJpbmdlbi5kZYETbXVlbnpAbmV0LmluLnR1bS5kZTAM BgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBQUAA4GBAE6QyyiGOkgfgyvffM2eFzk+TMCLRFnp QA4HbydO1+NVnblRUtaqYuBgSzNuWhN3TvLk9xRmFK4+7AbMTCfhd1eLdVaXqqTlVw+nI/v5 vlcRjkJTUDxyp5pdLzypbKyG7V1ebZOiq55E+/4TZvcYkcByI23ZB9xPhI1bKaS9TI9KMYID cTCCA20CAQEwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcg KFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3Vpbmcg Q0ECECrF6t03ZdVGRRmy6Tkgp08wCQYFKw4DAhoFAKCCAdAwGAYJKoZIhvcNAQkDMQsGCSqG SIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDkxMDIxMTEzODI0WjAjBgkqhkiG9w0BCQQxFgQU mlO35bOQIPzyIO53koxssqz3fikwXwYJKoZIhvcNAQkPMVIwUDALBglghkgBZQMEAQIwCgYI KoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqG SIb3DQMCAgEoMIGFBgkrBgEEAYI3EAQxeDB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxU aGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwg RnJlZW1haWwgSXNzdWluZyBDQQIQKsXq3Tdl1UZFGbLpOSCnTzCBhwYLKoZIhvcNAQkQAgsx eKB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBM dGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQKsXq 3Tdl1UZFGbLpOSCnTzANBgkqhkiG9w0BAQEFAASCAQBWSeP2bcGF15n0/LuWscHkNkfsYhQ2 bHXNV3GvvAxjtj6Z8QuaLqQXHO1ZqU0JYIwHilxahdlqWOQNL5lZLrs8yV4soGxYfInCC3PH 2hdk2pQYcYI4YHdCrZdI/waMZ1voVVge8uYuumSZWOENpmG7P92Uri+6K0QfDJyoVvtrhBZT q1vKuKXy6chHVnzLX9JCzOjdFAmKDnjGyckr0HbT8Wx+Ma8hQL/V7Gk+wjlmDC8bTlkbTdLN EkmwBadY8A8YH+Pq4F3u+El1vEwQdAIPgQU8+rLrXuq8hFHi4/qTu6np6ovfP51Z5K6GxU+P w9ae5XwNEUlh4yxOks6YG8PiAAAAAAAA --------------ms000006000607060208090302-- From paitken@cisco.com Wed Oct 21 04:52:46 2009 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 8C0FE3A6858 for ; Wed, 21 Oct 2009 04:52:46 -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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HWW1JapU7jDO for ; Wed, 21 Oct 2009 04:52:44 -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 248873A67AC for ; Wed, 21 Oct 2009 04:52:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=paitken@cisco.com; l=1068; q=dns/txt; s=amsiport01001; t=1256125973; x=1257335573; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20Paul=20Aitken=20|Subject:=20R e:=20[IPFIX]=20Fwd:=20[RFC=203917]Overload=20&=20Reliabil ity=20requirements=20of=0D=0A=20Metering=20process|Date: =20Wed,=2021=20Oct=202009=2012:52:51=20+0100|Message-ID: =20<4ADEF613.90901@cisco.com>|To:=20sujay=20gupta=20|CC:=20ipfix@ietf.org|MIME-Version:=201. 0|Content-Transfer-Encoding:=207bit|In-Reply-To:=20 |References:=20=09=20; bh=IvIbNcA/8WTV38GctsJA5WkEoZpJhNoY31TnF2VuC5o=; b=He7a/XNMJnU0WMVjkKqrPnikRmXnuJoZzmz9v3vGAFW/nWIF0F6yAzec zjKrfsWaFw2kxvm7r9QOpxtaLzqtlZsVl2D2LaBhVOJljxNAI7AWGLD5t DokWSiQPtHMlPKXzA9oizcTLVPgLcXDprxs+9Dn6z6aQydzq4AzjMoHL4 Y=; Authentication-Results: ams-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjwAAEeS3kqQ/uCWe2dsb2JhbACbIQEBFiQGphGYY4QxBA X-IronPort-AV: E=Sophos;i="4.44,596,1249257600"; d="scan'208";a="52351437" Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-1.cisco.com with ESMTP; 21 Oct 2009 11:52:51 +0000 Received: from [144.254.153.60] (dhcp-144-254-153-60.cisco.com [144.254.153.60]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n9LBqpjP011169; Wed, 21 Oct 2009 11:52:51 GMT Message-ID: <4ADEF613.90901@cisco.com> Date: Wed, 21 Oct 2009 12:52:51 +0100 From: Paul Aitken User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-GB; rv:1.8.1.22) Gecko/20090605 SeaMonkey/1.1.17 (Ubuntu-1.1.17+nobinonly-0ubuntu0.9.04.1) MIME-Version: 1.0 To: sujay gupta References: In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Cc: ipfix@ietf.org Subject: Re: [IPFIX] Fwd: [RFC 3917]Overload & Reliability requirements of Metering process 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: Wed, 21 Oct 2009 11:52:46 -0000 sujay, > So what I am proposing ( and is possible) is that under these > conditions like O/L , soft restart the system (switch/router) can > easily send to the collector at least the "duration under which it > was in the O/L/reset condition" . This information I am thinking would > be useful as a rough estimate of monitoring lost, canbe converted in > to number of packets not accounted for No, it can't. There are too many variables which the collecting process would have to know. eg how many active monitoring processes are there on the exporting device, and how much traffic are they each measuring on average? The delay between measuring and exporting, and the flow lifetime on the switch will also be relevant, since you'll export some partially filled flows for some period of time after the reset. > or may be used as an unaccounted period by the collector. I think that's the only possibility. Let's not try to guess how much traffic was lost. Cheers, P. -- Paul Aitken Cisco Systems Ltd, Edinburgh, Scotland. From sujay.ietf@gmail.com Wed Oct 21 10:53:43 2009 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 3C89E28C13B for ; Wed, 21 Oct 2009 10:53:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 lPN6hLtTxS9g for ; Wed, 21 Oct 2009 10:53:42 -0700 (PDT) Received: from mail-pw0-f50.google.com (mail-pw0-f50.google.com [209.85.160.50]) by core3.amsl.com (Postfix) with ESMTP id 662B128C136 for ; Wed, 21 Oct 2009 10:53:42 -0700 (PDT) Received: by pwi4 with SMTP id 4so1183120pwi.29 for ; Wed, 21 Oct 2009 10:53:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=i8RwPEiE+2qyBmZr21CM/5YLx9NfmHpPrSwb3dHCdrQ=; b=eDUWNtku+yFib7D+PN/gjFIxYDiejBES0COjMsMMty6pBe6Y//JoZVteRFShdICvQj zBIeg0Un5LHS+4jf8t6JM78p20NAqnM4OIJsbgkQe8LA4B8WI5JRZlvPJKwjujVEERWq DHzSNBoGrlx/s75ur9YoF6QB025iqEmAFatpM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=DTBNPOYDzf/Dfx+1mIivdG8kYCRGN8b3CAQnQsPHNV0OX8EimFD7HiFLHtt4UlWfGC M5RbF8dhnR5PSPyejNmiVlMB89u23RrgVOYIRusWVj/fHi5Z6PCgsXDrNX0IDZacN4ZY NuzP0Y7y8Li4UhfPQsXB1lZIOidCAqjbHxyyQ= MIME-Version: 1.0 Received: by 10.142.119.7 with SMTP id r7mr619802wfc.261.1256147628377; Wed, 21 Oct 2009 10:53:48 -0700 (PDT) In-Reply-To: <4ADEF613.90901@cisco.com> References: <4ADEF613.90901@cisco.com> Date: Wed, 21 Oct 2009 23:23:48 +0530 Message-ID: From: sujay gupta To: Paul Aitken Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: ipfix@ietf.org Subject: Re: [IPFIX] Fwd: [RFC 3917]Overload & Reliability requirements of Metering process 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: Wed, 21 Oct 2009 17:53:43 -0000 Hi Paul, Thanks, IMO it is safer to call the period as an outage period. But then if the reset period is short, and the collector has sufficient data points it may very well model and interpolate the missing data. And if it does this it may as well choose to ignore the partial flows residing during the reset period, even if the switch attempts to send it. But then your email is helpful to point out collectors may not resort to stats modeling. BR, -Sujay On Wed, Oct 21, 2009 at 5:22 PM, Paul Aitken wrote: > sujay, > >> So what I am proposing ( and is possible) is that under these >> conditions like O/L , soft restart the system (switch/router) can >> easily send to the collector =A0at least the "duration under which it >> was in the O/L/reset condition" . This information I am thinking would >> be useful as a rough estimate of monitoring lost, canbe converted in >> to number of packets not accounted for > > No, it can't. > > There are too many variables which the collecting process would have to > know. eg how many active monitoring processes are there on the exporting > device, and how much traffic are they each measuring on average? > > The delay between measuring and exporting, and the flow lifetime on the > switch will also be relevant, since you'll export some partially filled > flows for some period of time after the reset. > > >> or may be used as an unaccounted period by the collector. > > I think that's the only possibility. Let's not try to guess how much traf= fic > was lost. > > Cheers, > P. > > -- > Paul Aitken > Cisco Systems Ltd, Edinburgh, Scotland. > From paitken@cisco.com Wed Oct 21 13:44:08 2009 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 B3ED728C14C for ; Wed, 21 Oct 2009 13:44:07 -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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l-WsUZ+YyiIo for ; Wed, 21 Oct 2009 13:44:06 -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 84E8628C13F for ; Wed, 21 Oct 2009 13:44:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=paitken@cisco.com; l=1139; q=dns/txt; s=amsiport01001; t=1256157855; x=1257367455; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20Paul=20Aitken=20|Subject:=20R e:=20[IPFIX]=20Fwd:=20[RFC=203917]Overload=20&=20Reliabil ity=20requirements=20of=0D=0A=20Metering=20process|Date: =20Wed,=2021=20Oct=202009=2021:43:59=20+0100|Message-ID: =20<4ADF728F.2070506@cisco.com>|To:=20sujay=20gupta=20|CC:=20ipfix@ietf.org|MIME-Version:=20 1.0|Content-Transfer-Encoding:=207bit|In-Reply-To:=20 |References:=20=09=20=09=20=09=20<4ADEF 613.90901@cisco.com>=20; bh=laJDag7kC0Mt8IDnYkKZ2GzJWgJdE3he1+8khBVVNB4=; b=iZGNH86Zht+xAFbX9W6+fDRMkc0MDZrcYQDJbj+DVWd90mb3eOGcEYSy vw2SqbSBzBj/hAnoxKjfHQX4sMQJ2pVQC4APPGD7VOgy2MlQ/7+XThIdn ekBOzP7bnxaQecHp30nRQGxPCcBrdWdEuopi8KYldDqFcYnczZxcNI4TF 8=; Authentication-Results: ams-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkcAAOcP30qQ/uCWe2dsb2JhbACbJgEBFiQGp26YYoQzBA X-IronPort-AV: E=Sophos;i="4.44,599,1249257600"; d="scan'208";a="52418005" Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-1.cisco.com with ESMTP; 21 Oct 2009 20:44:00 +0000 Received: from [10.61.85.70] (ams3-vpn-dhcp5447.cisco.com [10.61.85.70]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n9LKhxGA011989; Wed, 21 Oct 2009 20:43:59 GMT Message-ID: <4ADF728F.2070506@cisco.com> Date: Wed, 21 Oct 2009 21:43:59 +0100 From: Paul Aitken User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-GB; rv:1.8.1.22) Gecko/20090605 SeaMonkey/1.1.17 (Ubuntu-1.1.17+nobinonly-0ubuntu0.9.04.1) MIME-Version: 1.0 To: sujay gupta References: <4ADEF613.90901@cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: ipfix@ietf.org Subject: Re: [IPFIX] Fwd: [RFC 3917]Overload & Reliability requirements of Metering process 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: Wed, 21 Oct 2009 20:44:08 -0000 Sujay, > IMO it is safer to call the period as an outage period. > But then if the reset period is short, and the collector has > sufficient data points it may very well model and interpolate the missing data. You mean it will guess. That wouldn't be appropriate for many applications. > And if it does this it may as well choose > to ignore the partial flows residing during the reset period, even if > the switch attempts to send it. My point is that it might be difficult for the collector to know which flows are partial, since those flows may have started before or during the outage and may be exported during or some time after the outage. So, the implication is that the collecting process builds a model, receives notification of a monitoring outage, decides that certain flows are lower than expected, and adjusts them to fit the model. If you propose sending such an outage notification, I'd be very interested to see a proposal for how the CP should model the EP - ideally backed up by some experimental evidence. Cheers, P. -- Paul Aitken Cisco Systems Ltd, Edinburgh, Scotland. From Quittek@nw.neclab.eu Thu Oct 22 12:26:56 2009 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 1C5A53A69B4 for ; Thu, 22 Oct 2009 12:26:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.475 X-Spam-Level: X-Spam-Status: No, score=-2.475 tagged_above=-999 required=5 tests=[AWL=0.124, 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 PZn88H9JjvFZ for ; Thu, 22 Oct 2009 12:26:55 -0700 (PDT) Received: from smtp0.neclab.eu (smtp0.neclab.eu [195.37.70.41]) by core3.amsl.com (Postfix) with ESMTP id BFB8E3A68C3 for ; Thu, 22 Oct 2009 12:26:54 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp0.neclab.eu (Postfix) with ESMTP id 63BE22C019172; Thu, 22 Oct 2009 21:27:04 +0200 (CEST) X-Virus-Scanned: Amavisd on Debian GNU/Linux (atlas2.office) Received: from smtp0.neclab.eu ([127.0.0.1]) by localhost (atlas2.office [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nG20gGgVKWbZ; Thu, 22 Oct 2009 21:27:04 +0200 (CEST) Received: from VENUS.office (mx1.office [192.168.24.3]) by smtp0.neclab.eu (Postfix) with ESMTP id 20EAE2C019170; Thu, 22 Oct 2009 21:26:49 +0200 (CEST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Received: from 10.7.0.54 ([10.7.0.54]) by VENUS.office ([192.168.24.102]) with Microsoft Exchange Server HTTP-DAV ; Thu, 22 Oct 2009 19:26:49 +0000 MIME-Version: 1.0 Content-class: urn:content-classes:message Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="B_3339116800_5389388" Date: Thu, 22 Oct 2009 21:26:40 +0200 Message-ID: In-Reply-To: <4ADEF613.90901@cisco.com> X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: [IPFIX] Fwd: [RFC 3917]Overload & Reliability requirements of Metering process thread-index: AcpTTZRaeGfzJH9OMkWxF3J6klGf2w== From: "Juergen Quittek" To: "Paul Aitken" , "sujay gupta" Cc: IETF IPFIX Working Group Subject: Re: [IPFIX] Fwd: [RFC 3917]Overload & Reliability requirements of Metering process 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, 22 Oct 2009 19:26:56 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3339116800_5389388 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Hi Paul, Certainly, you cannot make a precise estimation how many packets have been lost. But as consumer of the exported flow information I would be highly interested how long a router was restarting. Whether or noit I can use this information for an estimate depends a lot on the scenario. Sujay, Do you assume that the router is still forwarding packets while restarting ? Thanks, Juergen On 21.10.09 20:52 "Paul Aitken" wrote: > sujay, > >> So what I am proposing ( and is possible) is that under these >> conditions like O/L , soft restart the system (switch/router) can >> easily send to the collector at least the "duration under which it >> was in the O/L/reset condition" . This information I am thinking would >> be useful as a rough estimate of monitoring lost, canbe converted in >> to number of packets not accounted for > > No, it can't. > > There are too many variables which the collecting process would have to > know. eg how many active monitoring processes are there on the exporting > device, and how much traffic are they each measuring on average? > > The delay between measuring and exporting, and the flow lifetime on the > switch will also be relevant, since you'll export some partially filled > flows for some period of time after the reset. > > >> or may be used as an unaccounted period by the collector. > > I think that's the only possibility. Let's not try to guess how much > traffic was lost. > > Cheers, > P. --B_3339116800_5389388 Content-type: application/pkcs7-signature; name="smime.p7s" Content-transfer-encoding: base64 Content-disposition: attachment; filename="smime.p7s" MIIQ6gYJKoZIhvcNAQcCoIIQ2zCCENcCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC DpIwggU2MIIEHqADAgECAgQNLisHMA0GCSqGSIb3DQEBBQUAMIGQMQswCQYDVQQGEwJERTEY MBYGA1UEChMPTkVDIEV1cm9wZSBMdGQuMSAwHgYDVQQLExdORUMgTGFib3JhdG9yaWVzIEV1 cm9wZTESMBAGA1UEAxMJTkVDTEFCLUNBMTEwLwYJKoZIhvcNAQkBFiJ6ZXJ0aWZpemllcnVu Z3NzdGVsbGVAbncubmVjbGFiLmV1MB4XDTA4MTEwMzA3NTEyMFoXDTExMTEwMzA3NTEyMFow YzELMAkGA1UEBhMCREUxGDAWBgNVBAoTD05FQyBFdXJvcGUgTHRkLjEgMB4GA1UECxMXTkVD IExhYm9yYXRvcmllcyBFdXJvcGUxGDAWBgNVBAMTD0p1ZXJnZW4gUXVpdHRlazCCASIwDQYJ KoZIhvcNAQEBBQADggEPADCCAQoCggEBALYRfFB9x4h1YO6Mva6A5GCwKjwpgvzjiayFSmdD HwV8u5gHp3sHIhyVtxgMSifEp9AV+ChxWHS3KQwuQ3XhDAP/xDN6QSk4Bmqa6rCZuTJygxYh K39rNKd47ZfpuRC7j/Mbzwe9DTsbbBtpBgl5UKFc9c+zMbPlSwwlVbshWaUEoM6HoVFaDJdh tJBIpsblz1oQVKXDjxjGkUNh9Ds3m7BGXkr5yaGsEuEa0J/QAFdO+auvBJlAzIM0UwBAmlcT UHanS6Sdw5MkeutQqnmsUBtoenydq2Tmd9hfSfuTfiFuLmsvL3udH/jDAgQZ+PH6Mprqpyd3 wSycF/xZF5zz8X0CAwEAAaOCAcIwggG+MAkGA1UdEwQCMAAwCwYDVR0PBAQDAgXgMCkGA1Ud JQQiMCAGCCsGAQUFBwMCBggrBgEFBQcDBAYKKwYBBAGCNxQCAjAdBgNVHQ4EFgQUWQo3BPrO OLA4qljzDL1H8/6hIWEwHwYDVR0jBBgwFoAUTxyHeh3gL5n2vhWq0TWdDkrmujYwHwYDVR0R BBgwFoEUUXVpdHRla0Budy5uZWNsYWIuZXUwfQYDVR0fBHYwdDA4oDagNIYyaHR0cDovL2Nk cDEucGNhLmRmbi5kZS9uZWNsYWItY2EvcHViL2NybC9jYWNybC5jcmwwOKA2oDSGMmh0dHA6 Ly9jZHAyLnBjYS5kZm4uZGUvbmVjbGFiLWNhL3B1Yi9jcmwvY2FjcmwuY3JsMIGYBggrBgEF BQcBAQSBizCBiDBCBggrBgEFBQcwAoY2aHR0cDovL2NkcDEucGNhLmRmbi5kZS9uZWNsYWIt Y2EvcHViL2NhY2VydC9jYWNlcnQuY3J0MEIGCCsGAQUFBzAChjZodHRwOi8vY2RwMi5wY2Eu ZGZuLmRlL25lY2xhYi1jYS9wdWIvY2FjZXJ0L2NhY2VydC5jcnQwDQYJKoZIhvcNAQEFBQAD ggEBAB37+54yupDBTDpEMuyf+ouCRrOE3fPAD2SEGBXCpKTYteFkFSWvHlgN8ecRSma0Dz/5 QShzacGMeJ8o+XzVXHe2gtZbjzSVvJn+/nAKtKgDCzw0ltt3xkdMMv2ax6IKGR7BcccsXx7B R2PMaxdmHfCJseXiMzZO9QlWN2NZq2SSo3eGX/YDhHCWXDsoSu+uaKU/aRL2uZa92ptak2MA uKI5tylKLFZ3FHf08F8J+5tTaMGem6DfaMZR/9GZ8aRFJrdA7tzUAGKpl+CzRxsJVHbAAU5L hm5oTt6XYbh2G/cgdpeucsHJWBz9NQJrSrfWZYSwrv6AekMcvMi9X/CVZxEwggUvMIIEF6AD AgECAgQNIQpHMA0GCSqGSIb3DQEBBQUAMFoxCzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpERk4t VmVyZWluMRAwDgYDVQQLEwdERk4tUEtJMSQwIgYDVQQDExtERk4tVmVyZWluIFBDQSBHbG9i YWwgLSBHMDEwHhcNMDgxMDI0MDg1MjA4WhcNMTkwNjMwMDAwMDAwWjCBkDELMAkGA1UEBhMC REUxGDAWBgNVBAoTD05FQyBFdXJvcGUgTHRkLjEgMB4GA1UECxMXTkVDIExhYm9yYXRvcmll cyBFdXJvcGUxEjAQBgNVBAMTCU5FQ0xBQi1DQTExMC8GCSqGSIb3DQEJARYiemVydGlmaXpp ZXJ1bmdzc3RlbGxlQG53Lm5lY2xhYi5ldTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoC ggEBAJ7yFbG1EaoyDnG5367mJEXHljmacrzNnm52KW3dXD/s3Vpuskex0jvaaTntWWRSGrAK 6kKXnTxBb3J3EhveBUbltzQ+K0XKtPJm6VE5qVpl33WJSaUHs27Dhwlke+DV6BBGyukz2SDB aSa+nc0AwMZ0XO1DoDuiUNVeNmd/QT4SGzyFs+uLfLL2n8WzkZsbpSZ+xecwyw3EdQBBsp/i /W+uOQBsGqaCjYe3EkBU6nW+pBsj0Iy1n7b9PXb5gQynrK3Mi2V7g1idSzHos0o1BMoHUrMz Vw94Hj4CWlWmQ0t6Pdt1uYAMjwk0saQBY/Fyfv+wKeYycGIYyYCfJIRUeyUCAwEAAaOCAcQw ggHAMBIGA1UdEwEB/wQIMAYBAf8CAQEwCwYDVR0PBAQDAgEGMB0GA1UdDgQWBBRPHId6HeAv mfa+FarRNZ0OSua6NjAfBgNVHSMEGDAWgBRJt8bP6D0ff+pEexMp9/EKcD7eZDAtBgNVHREE JjAkgSJ6ZXJ0aWZpemllcnVuZ3NzdGVsbGVAbncubmVjbGFiLmV1MIGIBgNVHR8EgYAwfjA9 oDugOYY3aHR0cDovL2NkcDEucGNhLmRmbi5kZS9nbG9iYWwtcm9vdC1jYS9wdWIvY3JsL2Nh Y3JsLmNybDA9oDugOYY3aHR0cDovL2NkcDIucGNhLmRmbi5kZS9nbG9iYWwtcm9vdC1jYS9w dWIvY3JsL2NhY3JsLmNybDCBogYIKwYBBQUHAQEEgZUwgZIwRwYIKwYBBQUHMAKGO2h0dHA6 Ly9jZHAxLnBjYS5kZm4uZGUvZ2xvYmFsLXJvb3QtY2EvcHViL2NhY2VydC9jYWNlcnQuY3J0 MEcGCCsGAQUFBzAChjtodHRwOi8vY2RwMi5wY2EuZGZuLmRlL2dsb2JhbC1yb290LWNhL3B1 Yi9jYWNlcnQvY2FjZXJ0LmNydDANBgkqhkiG9w0BAQUFAAOCAQEAbDEPnQ9JpouPHYA1OEek P3l3GNM0HBzadVbtbN5MDtFmoVgdLYqlQaHb30wFhuOMbsNCOzV0k8EOvBVOT9BiEJ70RWcl SZQ460jZS2MY6n5oG/ilZuu6N/N3GSLg2pBBNH9vZFCyBJ9n4Px7A4gQF07G+CNfV2jdE1yy PjzIVPhg6bBgia8nXroBFe6oteavMspo0gLGIJ63NsCbl6ckPa96grT+mnnQD0h6jk/IGtXS 09mEWRbN7zZu0x0q+SScpljG36Q+jnG0U5zQI0jAx8CcYEQQH5QOlsw1Zu35OI4lsi7ycFkz JNfbfEC4ihuw9J2L43BFGMojkhPkhVExHTCCBCEwggMJoAMCAQICAgDHMA0GCSqGSIb3DQEB BQUAMHExCzAJBgNVBAYTAkRFMRwwGgYDVQQKExNEZXV0c2NoZSBUZWxla29tIEFHMR8wHQYD VQQLExZULVRlbGVTZWMgVHJ1c3QgQ2VudGVyMSMwIQYDVQQDExpEZXV0c2NoZSBUZWxla29t IFJvb3QgQ0EgMjAeFw0wNjEyMTkxMDI5MDBaFw0xOTA2MzAyMzU5MDBaMFoxCzAJBgNVBAYT AkRFMRMwEQYDVQQKEwpERk4tVmVyZWluMRAwDgYDVQQLEwdERk4tUEtJMSQwIgYDVQQDExtE Rk4tVmVyZWluIFBDQSBHbG9iYWwgLSBHMDEwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEK AoIBAQDpm8NnhfkNrvWNVMOWUDU9YuluTO2U1wBblSJ01CDrNI/W7MAxBAuZgeKmFNJSoCgj hIt0iQReW+DieMF4yxbLKDU5ey2QRdDtoAB6fL9KDhsAw4bpXCsxEXsM84IkQ4wcOItqaACa 7txPeKvSxhObdq3u3ibo7wGvdA/BCaL2a869080UME/15eOkyGKbghoDJzANAmVgTe3RCSMq ljVYJ9N2xnG2kB3E7f81hn1vM7PbD8URwoqDoZRdQWvY0hD1TP3KUazZve+Sg7va64sWVlZD z+HVEz2mHycwzUlU28kTNJpxdcVs6qcLmPkhnSevPqM5OUhqjK3JmfvDEvK9AgMBAAGjgdkw gdYwcAYDVR0fBGkwZzBloGOgYYZfaHR0cDovL3BraS50ZWxlc2VjLmRlL2NnaS1iaW4vc2Vy dmljZS9hZl9Eb3dubG9hZEFSTC5jcmw/LWNybF9mb3JtYXQ9WF81MDkmLWlzc3Vlcj1EVF9S T09UX0NBXzIwHQYDVR0OBBYEFEm3xs/oPR9/6kR7Eyn38QpwPt5kMB8GA1UdIwQYMBaAFDHD eRu69VPXF+CJei0XbAqzK50zMA4GA1UdDwEB/wQEAwIBBjASBgNVHRMBAf8ECDAGAQH/AgEC MA0GCSqGSIb3DQEBBQUAA4IBAQA74Vp3wEgX3KkY7IGvWonwvSiSpspZGBJw7Cjy565/lizn 8l0ZMfYTK3S9vYCyufdnyTmieTvhERHua3iRM347XyYndVNljjNj7s9zw7CSI0khUHUjoR8Y 4pSFPT8z6XcgjaK95qGFKUD2P3MyWA0Ja6bahWzAP7uNZmRWJE6uDT8yNQFb6YyC2XJZT7GG hfF0hVblw/hc843uR7NTBXDn5U2KaYMo4RMJhp5eyOpYHgwf+aTUWgRo/Sg+iwK2WLX2oSw3 VwBnqyNojWOl75lrXP1LVvarQIc01BGSbOyHxQoLBzNytG8MHVQs2FHHzL8w00Ny8TK/jM5J Y6gA9/IcMYICIDCCAhwCAQEwgZkwgZAxCzAJBgNVBAYTAkRFMRgwFgYDVQQKEw9ORUMgRXVy b3BlIEx0ZC4xIDAeBgNVBAsTF05FQyBMYWJvcmF0b3JpZXMgRXVyb3BlMRIwEAYDVQQDEwlO RUNMQUItQ0ExMTAvBgkqhkiG9w0BCQEWInplcnRpZml6aWVydW5nc3N0ZWxsZUBudy5uZWNs YWIuZXUCBA0uKwcwCQYFKw4DAhoFAKBdMCMGCSqGSIb3DQEJBDEWBBSbje6vTyDkkOi0s/T3 CA5RiJdWEjAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wOTEw MjIxOTI2NDBaMA0GCSqGSIb3DQEBAQUABIIBAGF+HiZKe5hzT79OWixefkgpNiFXQg3TvG9z d9PQ6PqCOifTVwuDRJqfBOov7Rbxnvjl4dqV558aHph2fm/nEx0Poqeju7HVbItyk2Popeq/ tHx4np2b6LhkdcwcddSkkyf2edyWFo4l6fJf1rttXQTCpFcCFoLQ7BdhhnKwaWGrAZA1HhxV At94xhZwsXuCVozL1PiguByNKXH2bWe/FYseAj54SJlNLV9sCfh/lmHnuk6FnVfAV4Ry9San g5RbRPhzMIWWs2aTeSIScjYo3iMdW06ri/7ZkzZBBUEfCDn9qePVo3zs/5WtieVov5q7Woki Gy9DrUyBd3gbas9PWXU= --B_3339116800_5389388-- From sujay.ietf@gmail.com Fri Oct 23 01:00:01 2009 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 693063A695C for ; Fri, 23 Oct 2009 01:00:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, 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 kFd87PDvVR83 for ; Fri, 23 Oct 2009 01:00:00 -0700 (PDT) Received: from mail-pz0-f176.google.com (mail-pz0-f176.google.com [209.85.222.176]) by core3.amsl.com (Postfix) with ESMTP id 8F5363A6966 for ; Fri, 23 Oct 2009 01:00:00 -0700 (PDT) Received: by pzk6 with SMTP id 6so502025pzk.29 for ; Fri, 23 Oct 2009 01:00:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=WgtXOR2RKIwty9LlymqhZ5FdIlqvLOCCHR3CSCE+oOQ=; b=bb6EYJ8ofhHlkYnRJpnflimvJoCbWqide6TIbI8RLrMx+1m9xUfzGSoulsQRrZbzFS PczWRkVodI4ur4rnqK7alQ0urmPtAdd1z5O4gg4qn/kkoFIlyO3bx1vmlw13QqWZWaqi pdMpCoVOt7sc8gzp1u9OqwtX5sjN80c7tPqWc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=nIubb8e841Z8GRY+mCfnSWW3y7hs3u0V6cXpCsFaHHT5AHKC5uNSK4vxpyooNg40GD vU9T5rWHo2+TvysKvVdqiDNi5aVLDmmYEmFXzuDN0ggoS6amW3LlQcxZjXuX9VL0T1iP qZdH9/X6Uc8upcWEumytpA8dgnzZmBB8wA02w= MIME-Version: 1.0 Received: by 10.142.6.11 with SMTP id 11mr796651wff.260.1256284808677; Fri, 23 Oct 2009 01:00:08 -0700 (PDT) In-Reply-To: References: <4ADEF613.90901@cisco.com> Date: Fri, 23 Oct 2009 01:00:08 -0700 Message-ID: From: sujay gupta To: Juergen Quittek Content-Type: text/plain; charset=ISO-8859-1 Cc: IETF IPFIX Working Group Subject: Re: [IPFIX] Fwd: [RFC 3917]Overload & Reliability requirements of Metering process 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, 23 Oct 2009 08:00:01 -0000 Hi Juergen, I am assuming a control plane restart, with the forwarding plane running in the while. This would be probably a planned restart, And in the overload condition where i would throttle the monitoring & other features to keep the essentials (like forwarding/switching/hello exchange) alive. Of course there may be platforms with coupled forwarding / control plane where seperation is not possible. BR, -Sujay On Thu, Oct 22, 2009 at 12:26 PM, Juergen Quittek wrote: > Hi Paul, > > Certainly, you cannot make a precise estimation how many packets > have been lost. > > But as consumer of the exported flow information I would be > highly interested how long a router was restarting. Whether or > noit I can use this information for an estimate depends a lot > on the scenario. > > Sujay, > > Do you assume that the router is still forwarding packets > while restarting ? > > Thanks, > > Juergen > > > On 21.10.09 20:52 "Paul Aitken" wrote: > >> sujay, >> >>> So what I am proposing ( and is possible) is that under these >>> conditions like O/L , soft restart the system (switch/router) can >>> easily send to the collector at least the "duration under which it >>> was in the O/L/reset condition" . This information I am thinking would >>> be useful as a rough estimate of monitoring lost, canbe converted in >>> to number of packets not accounted for >> >> No, it can't. >> >> There are too many variables which the collecting process would have to >> know. eg how many active monitoring processes are there on the exporting >> device, and how much traffic are they each measuring on average? >> >> The delay between measuring and exporting, and the flow lifetime on the >> switch will also be relevant, since you'll export some partially filled >> flows for some period of time after the reset. >> >> >>> or may be used as an unaccounted period by the collector. >> >> I think that's the only possibility. Let's not try to guess how much >> traffic was lost. >> >> Cheers, >> P. > From root@core3.amsl.com Fri Oct 23 04:45:01 2009 Return-Path: X-Original-To: ipfix@ietf.org Delivered-To: ipfix@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id A87AC3A691A; Fri, 23 Oct 2009 04:45:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20091023114501.A87AC3A691A@core3.amsl.com> Date: Fri, 23 Oct 2009 04:45:01 -0700 (PDT) Cc: ipfix@ietf.org Subject: [IPFIX] I-D Action:draft-ietf-ipfix-configuration-model-04.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: Fri, 23 Oct 2009 11:45:01 -0000 --NextPart 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-04.txt Pages : 94 Date : 2009-10-23 This document specifies a data model for the configuration of selection processes, caches, exporting processes, and collecting processes of IPFIX and PSAMP compliant monitoring devices using UML (Unified Modeling Language) class diagrams. The configuration data is encoded in Extensible Markup Language (XML). The structure of the data model is specified in a YANG module to ensure compatibility with the NETCONF protocol. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipfix-configuration-model-04.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 Content-Type: Message/External-body; name="draft-ietf-ipfix-configuration-model-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-10-23044304.I-D@ietf.org> --NextPart-- From bclaise@cisco.com Fri Oct 23 16:38:50 2009 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 972A73A6833 for ; Fri, 23 Oct 2009 16:38:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.303 X-Spam-Level: X-Spam-Status: No, score=-2.303 tagged_above=-999 required=5 tests=[AWL=0.296, 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 JQQhwNsnjhj9 for ; Fri, 23 Oct 2009 16:38:49 -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 6B7CD3A676A for ; Fri, 23 Oct 2009 16:38:49 -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 n9NN3vor023609 for ; Sat, 24 Oct 2009 01:03:57 +0200 (CEST) Received: from [10.55.43.53] (ams-bclaise-8714.cisco.com [10.55.43.53]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id n9NN3uY0007291 for ; Sat, 24 Oct 2009 01:03:56 +0200 (CEST) Message-ID: <4AE2365C.1030404@cisco.com> Date: Sat, 24 Oct 2009 01:03:56 +0200 From: Benoit Claise User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: "ipfix@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [IPFIX] draft-ietf-ipfix-export-per-sctp-stream: new draft version. 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, 23 Oct 2009 23:38:50 -0000 Dear all, A new version of "IPFIX Export per SCTP Stream", draft-ietf-ipfix-export-per-sctp-stream-04, has been submitted. It's actually a manual posting, so if you're impatient to review the draft, the link is below. We think that it addresses all comments from the IESG and from the mailing list. See the details at http://www.ietf.org/mail-archive/web/ipfix/current/msg05085.html Regards, Benoit. Filename: draft-ietf-ipfix-export-per-sctp-stream Version: 04 Staging URL: http://www.ietf.org/staging/draft-ietf-ipfix-export-per-sctp-stream-04.txt Title: IPFIX Export per SCTP Stream Creation_date: 2009-10-24 WG ID: ipfix Number_of_pages: 22 Abstract: This document specifies an extension to the specifications in RFC5101, IP Flow Information Export (IPFIX), when using the Partial Reliability extension of SCTP (PR-SCTP, Partial Reliability Stream Control Transmission Protocol). When implemented at both the Exporting and Collecting Processes, this method offers several advantages such as the ability to calculate Data Record losses for PR-SCTP, immediate export of Template Withdrawal Messages, immediate reuse of Template IDs within an SCTP stream, reduced likelihood of Data Record loss, and reduced demands on the Collecting Process. When implemented in only the Collecting or Exporting Process then normal IPFIX behavior will be seen without these additional benefits. Regards, Benoit From n.brownlee@auckland.ac.nz Sat Oct 24 15:39:00 2009 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 0C3073A6960 for ; Sat, 24 Oct 2009 15:39:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.554 X-Spam-Level: X-Spam-Status: No, score=-5.554 tagged_above=-999 required=5 tests=[AWL=1.045, 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 MYmDhGjOZ1BD for ; Sat, 24 Oct 2009 15:38:59 -0700 (PDT) Received: from mailhost.auckland.ac.nz (larry.its.auckland.ac.nz [130.216.12.34]) by core3.amsl.com (Postfix) with ESMTP id 0229C3A680F for ; Sat, 24 Oct 2009 15:38:56 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mailhost.auckland.ac.nz (Postfix) with ESMTP id F172319DBC for ; Sun, 25 Oct 2009 11:38:56 +1300 (NZDT) X-Virus-Scanned: by amavisd-new at mailhost.auckland.ac.nz Received: from mailhost.auckland.ac.nz ([127.0.0.1]) by localhost (larry.its.auckland.ac.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bvb+0Sawo6uL for ; Sun, 25 Oct 2009 11:38:56 +1300 (NZDT) Received: from [192.168.0.6] (unknown [121.98.151.149]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailhost.auckland.ac.nz (Postfix) with ESMTP id C031719925 for ; Sun, 25 Oct 2009 11:38:56 +1300 (NZDT) Message-ID: <4AE381FC.1010407@auckland.ac.nz> Date: Sat, 24 Oct 2009 15:38:52 -0700 From: Nevil Brownlee User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: IPFIX list Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [IPFIX] First DRAFT agenda for IPFIX in Hirshima 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: Sat, 24 Oct 2009 22:39:00 -0000 Hi all: Here's my first draft of an agenda for our upcoming meeting. Please would those involved with each of the drafts email me and let me know who will be presenting on their draft(s), and about how many minutes they think they'll need - when I have that information I'll update the agenda. Also, if you have any other drafts you'd like to present, please email me the details. Cheers, Nevil -- --------------------------------------------------------------------- Nevil Brownlee Computer Science Department | ITS Phone: +64 9 373 7599 x88941 The University of Auckland FAX: +64 9 373 7453 Private Bag 92019, Auckland 1142, New Zealand ====================================================== Ip Flow Information Export WG (ipfix) IETF #76, Hiroshima Wednesday, 11 November 09 at 1300-1500 ====================================================== Chairs: Juergen Quittek Nevil Brownlee AGENDA: 1. Agenda review WG Status = 5 min 2. Update from last meeting = 5 min [New charter approved. IPFIX Information Elements Registry tidied up. Two RFCs published: File Format RFC 5655, and Exporting Type Info RFC 5610 (Erratum 1822: IEs Expert Review, not FCFS, correct in Registry) ] 3. Current WG drafts = 90 min a) MIB draft draft-ietf-ipfix-mib-07, 13 Jul 09 b) Config Data Model draft-ietf-ipfix-configuration-model-04, 23 Oct 09 c) SCTP per-stream draft draft-ietf-ipfix-export-per-sctp-stream-04, 24 Oct 09 d) Mediators Problem Statement draft-ietf-ipfix-mediators-problem-statement-06, 16 Oct 09 Finished WGLC, ready to submit? e) Mediators Framework draft-ietf-ipfix-mediators-framework-04, 16 Oct 09 Ready for WGLC? f) Export of Structured Data in IPFIX draft-ietf-ipfix-structured-data-00, 15 Oct 09 (Claise, Dhandapani , Yates & Aitken) g) Flow Selection Techniques draft-ietf-ipfix-flow-selection-tech-00, 18 Oct 09 (Peluso, Zseby. D'Antonio & Molina) h) IP Flow Anonymisation Support draft-ietf-ipfix-anon-00, 11 Oct 09 (Boschi & Trammel) 4. Other drafts = 15 min 5. Any Other Business = 5 min - Milestones Review Presentation slides will be available at https://datatracker.ietf.org/public/meeting_materials.cgi?meeting_num=76 (search for IPFIX in the Operations and Management Area) Participation via jabber is offered at ipfix@jabber.ietf.org ------------------ From kashima@nttv6.net Mon Oct 26 00:13:02 2009 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 508843A699F for ; Mon, 26 Oct 2009 00:13:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.188 X-Spam-Level: X-Spam-Status: No, score=-2.188 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HOST_MISMATCH_COM=0.311, RDNS_DYNAMIC=0.1] 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 nyvpcTtEZbuv for ; Mon, 26 Oct 2009 00:13:01 -0700 (PDT) Received: from mail.nttv6.net (mail.nttv6.net [IPv6:2001:fa8::25]) by core3.amsl.com (Postfix) with ESMTP id 0B18D3A68B4 for ; Mon, 26 Oct 2009 00:13:00 -0700 (PDT) Received: from [127.0.0.1] (dhcp-3-195.nttv6.com [192.47.163.195]) by mail.nttv6.net (8.14.3/8.14.3) with ESMTP id n9Q7D2ke084536; Mon, 26 Oct 2009 16:13:04 +0900 (JST) (envelope-from kashima@nttv6.net) Date: Mon, 26 Oct 2009 16:12:54 +0900 From: Shingo KASHIMA To: Nevil Brownlee In-Reply-To: <4AE381FC.1010407@auckland.ac.nz> References: <4AE381FC.1010407@auckland.ac.nz> Message-Id: <20091026161221.9C61.1AB7FA03@nttv6.net> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Becky! ver. 2.50.05 [ja] X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.3 (mail.nttv6.net [192.16.178.5]); Mon, 26 Oct 2009 16:13:04 +0900 (JST) Cc: IPFIX list Subject: Re: [IPFIX] First DRAFT agenda for IPFIX in Hirshima 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, 26 Oct 2009 07:13:02 -0000 Hi Nevil, all, I would like to present the following draft. http://tools.ietf.org/html/draft-kashima-ipfix-data-link-layer-monitoring-00 This draft is about adding Information Elements related to the Data Link header. Could you give me 5 minutes for my presentation ? Regards, Shingo On Sat, 24 Oct 2009 15:38:52 -0700 Nevil Brownlee san wrote: > Hi all: > > Here's my first draft of an agenda for our upcoming meeting. > Please would those involved with each of the drafts email me > and let me know who will be presenting on their draft(s), and > about how many minutes they think they'll need - when I have > that information I'll update the agenda. > > Also, if you have any other drafts you'd like to present, > please email me the details. > > Cheers, Nevil > > -- > --------------------------------------------------------------------- > Nevil Brownlee Computer Science Department | ITS > Phone: +64 9 373 7599 x88941 The University of Auckland > FAX: +64 9 373 7453 Private Bag 92019, Auckland 1142, New Zealand > > > ====================================================== > Ip Flow Information Export WG (ipfix) > IETF #76, Hiroshima > Wednesday, 11 November 09 at 1300-1500 > ====================================================== > > Chairs: > Juergen Quittek > Nevil Brownlee > > AGENDA: > > 1. Agenda review WG Status = 5 min > > 2. Update from last meeting = 5 min > [New charter approved. > IPFIX Information Elements Registry tidied up. > Two RFCs published: > File Format RFC 5655, and > Exporting Type Info RFC 5610 (Erratum 1822: > IEs Expert Review, not FCFS, correct in Registry) > ] > > 3. Current WG drafts = 90 min > a) MIB draft > draft-ietf-ipfix-mib-07, 13 Jul 09 > > b) Config Data Model > draft-ietf-ipfix-configuration-model-04, 23 Oct 09 > > c) SCTP per-stream draft > draft-ietf-ipfix-export-per-sctp-stream-04, 24 Oct 09 > > d) Mediators Problem Statement > draft-ietf-ipfix-mediators-problem-statement-06, 16 Oct 09 > Finished WGLC, ready to submit? > > e) Mediators Framework > draft-ietf-ipfix-mediators-framework-04, 16 Oct 09 > Ready for WGLC? > > f) Export of Structured Data in IPFIX > draft-ietf-ipfix-structured-data-00, 15 Oct 09 > (Claise, Dhandapani , Yates & Aitken) > > g) Flow Selection Techniques > draft-ietf-ipfix-flow-selection-tech-00, 18 Oct 09 > (Peluso, Zseby. D'Antonio & Molina) > > h) IP Flow Anonymisation Support > draft-ietf-ipfix-anon-00, 11 Oct 09 > (Boschi & Trammel) > > 4. Other drafts = 15 min > > 5. Any Other Business = 5 min > - Milestones Review > > Presentation slides will be available at > https://datatracker.ietf.org/public/meeting_materials.cgi?meeting_num=76 > (search for IPFIX in the Operations and Management Area) > > Participation via jabber is offered at ipfix@jabber.ietf.org > > ------------------ > > _______________________________________________ > IPFIX mailing list > IPFIX@ietf.org > https://www.ietf.org/mailman/listinfo/ipfix --- Shingo KASHIMA NTT Information Sharing Platform Lab. tel:+81-(0)422-59-3894 fax:+81-(0)422-59-5637 From bclaise@cisco.com Mon Oct 26 08:53:55 2009 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 6F63C28C24F for ; Mon, 26 Oct 2009 08:53:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.434 X-Spam-Level: X-Spam-Status: No, score=-2.434 tagged_above=-999 required=5 tests=[AWL=0.164, 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 hxvullU7iiaE for ; Mon, 26 Oct 2009 08:53:54 -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 DAA2B28C1E9 for ; Mon, 26 Oct 2009 08:53:53 -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 n9QFaOxP006945 for ; Mon, 26 Oct 2009 16:36:24 +0100 (CET) Received: from [10.55.43.53] (ams-bclaise-8714.cisco.com [10.55.43.53]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id n9QFaNe1012784 for ; Mon, 26 Oct 2009 16:36:23 +0100 (CET) Message-ID: <4AE5C1F7.10205@cisco.com> Date: Mon, 26 Oct 2009 16:36:23 +0100 From: Benoit Claise User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: "ipfix@ietf.org" Content-Type: multipart/alternative; boundary="------------020101060808050009010102" Subject: [IPFIX] [Fwd: I-D ACTION:draft-claise-ipfix-mediation-protocol-00.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, 26 Oct 2009 15:53:55 -0000 This is a multi-part message in MIME format. --------------020101060808050009010102 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Dear all, I just posted the version 00 of the IPFIX Mediation Protocol draft. This new draft discusses some of the IPFIX protocol considerations on IPFIX Mediators. This is the logical step after the IPFIX Mediators problem statement and framework drafts: IPFIX Mediation: Problem Statement (58384 bytes) IPFIX Mediation: Framework (64946 bytes) There are still a lot of open issues to be discussed regarding the IPFIX mediation protocol. So this is a starting point. I don't believe this protocol specifications will be specifically difficult, but it should contain the IPFIX protocol conventions for IPFIX Mediators. Regards, Benoit. -------- Original Message -------- Subject: I-D ACTION:draft-claise-ipfix-mediation-protocol-00.txt Date: Mon, 19 Oct 2009 14:15:03 -0700 (PDT) From: Internet-Drafts@ietf.org Reply-To: internet-drafts@ietf.org To: i-d-announce@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Specification of the Protocol for IPFIX Mediations Author(s) : B. Claise, A. Kobayashi, B. Trammell Filename : draft-claise-ipfix-mediation-protocol-00.txt Pages : 17 Date : 2009-10-19 This document specifies the IP Flow Information Export (IPFIX) protocol specific to the Mediation. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-claise-ipfix-mediation-protocol-00.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. --------------020101060808050009010102 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Dear all,

I just posted the version 00 of the IPFIX Mediation Protocol draft.
This new draft discusses some of the IPFIX protocol considerations on IPFIX Mediators.
This is the logical step after the IPFIX Mediators problem statement and framework drafts:
IPFIX Mediation: Problem Statement (58384 bytes)
IPFIX Mediation: Framework (64946 bytes)
There are still a lot of open issues to be discussed regarding the IPFIX mediation protocol. So this is a starting point.
I don't believe this protocol specifications will be specifically difficult, but it should contain the IPFIX protocol conventions for IPFIX Mediators.

Regards, Benoit.

-------- Original Message --------
Subject: I-D ACTION:draft-claise-ipfix-mediation-protocol-00.txt
Date: Mon, 19 Oct 2009 14:15:03 -0700 (PDT)
From: Internet-Drafts@ietf.org
Reply-To: internet-drafts@ietf.org
To: i-d-announce@ietf.org 


A New Internet-Draft is available from the on-line Internet-Drafts 
directories.


	Title		: Specification of the Protocol for IPFIX Mediations 
	Author(s)	: B. Claise, A. Kobayashi, B. Trammell
	Filename	: draft-claise-ipfix-mediation-protocol-00.txt
	Pages		: 17
	Date		: 2009-10-19
	
        This document specifies the IP Flow Information Export 
        (IPFIX) protocol specific to the Mediation. 

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-claise-ipfix-mediation-protocol-00.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.
--------------020101060808050009010102-- From root@core3.amsl.com Mon Oct 26 09:00:01 2009 Return-Path: X-Original-To: ipfix@ietf.org Delivered-To: ipfix@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id C2E1D3A6841; Mon, 26 Oct 2009 09:00:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20091026160001.C2E1D3A6841@core3.amsl.com> Date: Mon, 26 Oct 2009 09:00:01 -0700 (PDT) Cc: ipfix@ietf.org Subject: [IPFIX] I-D Action:draft-ietf-ipfix-mib-08.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, 26 Oct 2009 16:00:01 -0000 --NextPart 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 : Definitions of Managed Objects for IP Flow Information Export Author(s) : T. Dietz, et al. Filename : draft-ietf-ipfix-mib-08.txt Pages : 67 Date : 2009-10-26 This document defines managed objects for IP Flow Information Export (IPFIX). These objects provide information for monitoring IPFIX Exporters and IPFIX Collectors including the basic configuration information. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipfix-mib-08.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 Content-Type: Message/External-body; name="draft-ietf-ipfix-mib-08.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-10-26084808.I-D@ietf.org> --NextPart-- From bclaise@cisco.com Mon Oct 26 09:16:49 2009 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 A91243A6AE8 for ; Mon, 26 Oct 2009 09:16:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.409 X-Spam-Level: X-Spam-Status: No, score=-2.409 tagged_above=-999 required=5 tests=[AWL=0.190, 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 mJ253QAoku8x for ; Mon, 26 Oct 2009 09:16:49 -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 70D493A6AE7 for ; Mon, 26 Oct 2009 09:16:47 -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 n9QFk407008734; Mon, 26 Oct 2009 16:46:04 +0100 (CET) Received: from [10.55.43.53] (ams-bclaise-8714.cisco.com [10.55.43.53]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id n9QFk3jS029643; Mon, 26 Oct 2009 16:46:03 +0100 (CET) Message-ID: <4AE5C43A.1060402@cisco.com> Date: Mon, 26 Oct 2009 16:46:02 +0100 From: Benoit Claise User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Nevil Brownlee References: <4AE381FC.1010407@auckland.ac.nz> In-Reply-To: <4AE381FC.1010407@auckland.ac.nz> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: IPFIX list Subject: Re: [IPFIX] First DRAFT agenda for IPFIX in Hirshima 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, 26 Oct 2009 16:16:49 -0000 Nevil, From your proposed agenda, I will present: c) SCTP per-stream draft f) Export of Structured Data in IPFIX I would like to have one slot to discuss draft-claise-ipfix-mediation-protocol-00.txt Regards, Benoit > Hi all: > > Here's my first draft of an agenda for our upcoming meeting. > Please would those involved with each of the drafts email me > and let me know who will be presenting on their draft(s), and > about how many minutes they think they'll need - when I have > that information I'll update the agenda. > > Also, if you have any other drafts you'd like to present, > please email me the details. > > Cheers, Nevil > From Tanja.Zseby9ab33xy531fokus.fraunhofer.de@bounce.antispameurope.com Mon Oct 26 09:51:31 2009 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 722A73A6407 for ; Mon, 26 Oct 2009 09:51:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 mkz-Er2SjbEA for ; Mon, 26 Oct 2009 09:51:30 -0700 (PDT) Received: from relay01-haj2.antispameurope.com (relay01-haj2.antispameurope.com [83.246.65.51]) by core3.amsl.com (Postfix) with ESMTP id 5087228C203 for ; Mon, 26 Oct 2009 09:51:28 -0700 (PDT) Received: by relay01-haj2.antispameurope.com (ASE-Secure-MTA, from userid 1000) id 9E81516003C; Mon, 26 Oct 2009 17:51:40 +0100 (CET) Received: from pluto.fokus.fraunhofer.de (pluto.fokus.fraunhofer.de [195.37.77.164]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by relay01-haj2.antispameurope.com (ASE-Secure-MTA) with ESMTP id 26A9216003A; Mon, 26 Oct 2009 17:51:39 +0100 (CET) Received: from EXCHSRV.fokus.fraunhofer.de (bohr.fokus.fraunhofer.de [10.147.9.231]) by pluto.fokus.fraunhofer.de (8.14.2/8.14.2) with SMTP id n9QGpdEZ026798; Mon, 26 Oct 2009 17:51:39 +0100 (MET) x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 26 Oct 2009 17:51:41 +0100 Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0010_01CA5664.F9466920" Message-ID: <804B13F8F3D94A4AB18B9B01ACB68FA102F74D44@EXCHSRV.fokus.fraunhofer.de> In-Reply-To: <4ADEF2B0.5040509@net.in.tum.de> X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: AW: Hash-based filtering config parameters Thread-Index: AcpSQunsUHVYZ8bvT0iOIdUChkgLPQEFlfdg References: <4ADC88B1.4020608@net.in.tum.de> <4ADECC41.7050905@cisco.com> <804B13F8F3D94A4AB18B9B01ACB68FA102F746E1@EXCHSRV.fokus.fraunhofer.de> <4ADEF2B0.5040509@net.in.tum.de> From: "Zseby, Tanja" To: "Gerhard Muenz" Cc: ipfix@ietf.org Subject: Re: [IPFIX] Hash-based filtering config parameters 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, 26 Oct 2009 16:51:31 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_0010_01CA5664.F9466920 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Gerhard, yes this is correct. The hash range is given by the function. But you = need to define the "hash selection range" which is a subset of the hash range = and gives you the range of hash values for which packets are selected.=20 I think in general it would be good if it is possible to retrieve the initialiserValue but it should be possible to restrict access to this information.=20 Kind regards Tanja > -----Urspr=FCngliche Nachricht----- > Von: Gerhard Muenz [mailto:muenz@net.in.tum.de] > Gesendet: Mittwoch, 21. Oktober 2009 13:38 > An: Zseby, Tanja > Cc: Benoit Claise; ipfix@ietf.org; DUFFIELD, NICHOLAS G (NICK); Aamer > Akhter (aakhter) > Betreff: Re: AW: Hash-based filtering config parameters >=20 >=20 > Hi Tanja, all, >=20 > Ok, so if I understand correctly, the hash range directly results from > the choice of the hash function. >=20 > BOB -> 0..2^32-1 > IPSX -> 0..2^16-1 > CRC-32 -> 0..2^32-1 >=20 > Which means that we do not configure the hash range, only the hash > function. >=20 > Please find below how the configuration data model looks like at the > moment. Feel free to comment. >=20 > One detail which may be worth discussing: > If initiliserValue is not configured, the monitoring devices chooses > one > arbitrarily. > Should the NETCONF manager be able to retrieve this chosen value? > At the moment, this is not foreseen in the model, meaning that the > chosen value will not be given to the NETCONF manager. Not sure which > behavior is desired. >=20 > Regards, > Gerhard >=20 >=20 > +--------------------------+ > | FilterHash | > +--------------------------+ 1..* +---------------+ > | hashFunction =3D BOB |<>-------| SelectedRange | > | ipPayloadOffset =3D 0 | +---------------+ > | ipPayloadSize =3D 8 | | name | > | digestOutput =3D false | | min | > | initialiserValue[0..1] | | max | > +--------------------------+ +---------------+ >=20 > Figure 10: Filter classes >=20 > For hash-based filtering, the configuration parameters are: >=20 > hashFunction: Hash function to be used. The following parameter > values are defined by the configuration data model: > * BOB: BOB Hash Function as specified in [RFC5475], Appendix > A.2 > * IPSX: IP Shift-XOR (IPSX) Hash Function as specified in > [RFC5475], Appendix A.1 > * CRC: CRC-32 function as specified in [RFC1141] > The default value is "BOB". >=20 > ipPayloadOffset, ipPayloadSize: ipPayloadOffset and ipPayloadSize > configure the offset and the size of the payload section used = as > input to the hash function. These parameters correspond to the > Information Elements hashIPPayloadOffset and hashIPPayloadSize > [RFC5477]. Default values are 0 and 8, respectively, > corresponding to the minimum configurable values according to > [RFC5476], Section 6.2.5.6. >=20 > digestOutput: digestOutput enables or disables the inclusion of > the > packet digest in the resulting PSAMP Packet Report. This > requires > that the Cache Layout of the Cache generating the Packet = Reports > includes a digestHashValue field. This parameter corresponds = to > the Information Element hashDigestOutput [RFC5477]. >=20 > initialiserValue: Initialiser value to the hash function. This > parameter corresponds to the Information Element > hashInitialiserValue [RFC5477]. If not configured, the > monitoring > device arbitrarily chooses an initialiser value. >=20 > One or more ranges of matching hash values are defined by the min > and > max parameters of the SelectedRange subclass. These parameters > correspond to the Information Elements hashSelectedRangeMin and > hashSelectedRangeMax [RFC5477]. >=20 >=20 > Zseby, Tanja wrote: > > Hi all, > > > > in general the parameters are configurable (section 7.2 of RFC5475) > in order to support different (proprietary) hash functions. But for = the > usage of the recommended BOB function these parameters have to be > filled with the according values and are fixed (see section 6.2.4.1. = of > RFC5475 which is in line with RFC 5476). > > > > Kind regards > > Tanja > > > > > >> -----Urspr=FCngliche Nachricht----- > >> Von: Benoit Claise [mailto:bclaise@cisco.com] > >> Gesendet: Mittwoch, 21. Oktober 2009 10:54 > >> An: Gerhard Muenz > >> Cc: ipfix@ietf.org; Zseby, Tanja; DUFFIELD, NICHOLAS G (NICK); me; > >> Aamer Akhter (aakhter) > >> Betreff: Re: Hash-based filtering config parameters > >> > >> Gerhard, > >> > >>> Hi Tanja, Benoit, all, > >>> > >>> I have two questions regarding the configuration of hash-based > >> filtering. > >>> 1) Are IP header fields/bits fixed or configurable? > >>> > >>> RFC 5475, Section 7.2 says: > >>> http://tools.ietf.org/html/rfc5475#section-7.2 > >>> > >>> Case hashing: > >>> - Hash Domain (input bits from packet) > >>> -
> >>> - > >>> -
> >>> - > >>> - > >>> - > >>> > >>> =3D> header bits seems to be configurable > >>> > >>> > >>> RFC 5476, Section 6.5.2.6 says: > >>> http://tools.ietf.org/html/rfc5476#section-6.5.2.6 > >>> > >>> In Hash-based Selection, a Hash Function is run on IPv4 = traffic. > >> The > >>> following fields MUST be used as input to that Hash Function: > >>> > >>> - IP identification field > >>> > >>> - Flags field > >>> > >>> - Fragment offset > >>> > >>> - Source IP address > >>> > >>> - Destination IP address > >>> > >>> - A number of bytes from the IP payload. The number of = bytes > >> and > >>> starting offset MUST be configurable if the Hash Function > >>> supports it. > >>> > >>> =3D> header fields seems to be fixed. > >> I would be tempted to believe the protocol. So RFC5476. > >> > >> I'll let Tanja or Nick answer the question below. > >> > >> Regards, Benoit. > >>> > >>> > >>> 2) Is the output range of the hash function a configuration > parameter > >>> or just an invariant property of the hash function itself? > >>> If yes, should it be configured as min and max or as length and > >> bitmask? > >>> RFC 5475, Section 7.2 says: > >>> http://tools.ietf.org/html/rfc5475#section-7.2 > >>> > >>> - Hash Function > >>> - Hash Function name > >>> - Length of input key (eliminate 0x bytes) > >>> - Output value (length M and bitmask) > >>> - Hash Selection Range, as a list of non-overlapping > >>> intervals [start value, end value] where value is in > >>> [0,2^M-1] > >>> - Additional parameters are dependent on specific Hash > >>> Function (e.g., hash input bits (seed)) > >>> > >>> =3D> output value length and bitmask seem to correspond to the = output > >>> range defined by hashOutputRangeMin and hashOutputRangeMax > >>> > >>> Thanks, > >>> Gerhard > >>> > > >=20 > -- > Dipl.-Ing. Gerhard M=FCnz > Chair for Network Architectures and Services (I8) > Technische Universit=E4t M=FCnchen - Department of Informatics > Boltzmannstr. 3, 85748 Garching bei M=FCnchen, Germany > Phone: +49 89 289-18008 Fax: +49 89 289-18033 > E-mail: muenz@net.in.tum.de WWW: http://www.net.in.tum.de/~muenz >=20 ------=_NextPart_000_0010_01CA5664.F9466920 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIQlzCCBSow ggQSoAMCAQICAQAwDQYJKoZIhvcNAQEFBQAwTzELMAkGA1UEBhMCREUxEzARBgNVBAoTCkZyYXVu aG9mZXIxKzApBgNVBAMTIkZyYXVuaG9mZXItR2VzZWxsc2NoYWZ0IFJvb3QtQ0EgdjIwHhcNMDQw MzAzMTcwMDQ0WhcNMDkxMjMxMDAwMDAwWjBPMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5o b2ZlcjErMCkGA1UEAxMiRnJhdW5ob2Zlci1HZXNlbGxzY2hhZnQgUm9vdC1DQSB2MjCCASIwDQYJ KoZIhvcNAQEBBQADggEPADCCAQoCggEBAP7p8snYgwNnnvm6bPOzEqSzGS3ejM/vNhmFBgwvmHJV ExxftllSfjZ+3CQxybY7AmRAaKkzt17Zq9ECuXSCnMfEisfXFposgWWy5KInfZ1IR/BjGaHCoK42 rfg4+pJ2nQ5k74JZF54LsT6QCa0aWpNBMEGRIvIay/RsyuzU/EUj7yBGNo5IjpsUWzPd4SAG726a lUzFc/G/syGCqk5f+33cQvRaGY7BEkMGoJvjFb/Sg8tsXCWi6kTbnuI06FiSxCyczC8CE+QaKxbl LVSBGOlf4ROnmY+EKmHkJW1LccEvrO8AccXp+x/n/uIfCv/TleGPRrQPQmfQkBcOM1hsj2MCAwEA AaOCAg8wggILMIGbBglghkgBhvhCAQ0EgY0WgYpXdXJ6ZWx6ZXJ0aWZpa2F0IGRlciBaZXJ0aWZp emllcnVuZ2luc3RhbnogKENBKSBkZXIgRnJhdW5ob2Zlci1HZXNlbGxzY2hhZnQgZS5WLiwgTXVl bmNoZW47IFd1cnplbHplcnRpZmlrYXQgdmlhIGh0dHA6Ly9wa2kuZnJhdW5ob2Zlci5kZS8wTQYI KwYBBQUHAQEEQTA/MD0GCCsGAQUFBzABhjFodHRwOi8vcGtpLmZyYXVuaG9mZXIuZGUvRmhHLUNB X3YyX09DU1AtUmVzcG9uZGVyMEgGA1UdHwRBMD8wPaA7oDmGN2h0dHA6Ly9wa2kuZnJhdW5ob2Zl ci5kZS9GaEctQ0EtQ2VydHMvRmhHLUNBX3YyX0NSTC5jcmwwDAYDVR0TBAUwAwEB/zBKBgNVHREE QzBBgSR6ZXJ0aWZpemllcnVuZ3NpbnN0YW56QGZyYXVuaG9mZXIuZGWGGWh0dHA6Ly9wa2kuZnJh dW5ob2Zlci5kZS8wTAYDVR0gBEUwQzBBBgsrBgEEAYYKUAIBATAyMDAGCCsGAQUFBwIBFiRodHRw Oi8vcGtpLmZyYXVuaG9mZXIuZGUvcG9saWN5Lmh0bWwwCwYDVR0PBAQDAgEGMB0GA1UdDgQWBBQA w/zvY8JWKC9RC3VW/3sF6RzJ8TANBgkqhkiG9w0BAQUFAAOCAQEAQr1itlUWwckwysi11vI0B7Mc xgdLgjPkuqrkFypLtankODXcueYBuJeO5b4dGl+tQWU7Or0lpi9YCJcPkz93yQ42RThjqVDSyUIj PSwIAKRViosrkjXJzQwmzvhbrBb3Q9nLDiiJ2shQEceqQs0GygCm5GXLBr0L/yUMkpyTRzwG77CD eRxumXzdqIqXL2gxcJcF5g7DcJWTXFXhyInFmZyWpElk1FDqjCZZfRiAXDDm7oLyZlcC/rokB+EZ mmFpZqx0JoVjy6ywWEtKEfMZJ+t79XQ16N/FOZrYNCHCXr+YSCmwpo16O3akdfqSVCjPmH9v+EqC k5yueCPpzghWQzCCBa4wggSWoAMCAQICAhaHMA0GCSqGSIb3DQEBBQUAME8xCzAJBgNVBAYTAkRF MRMwEQYDVQQKEwpGcmF1bmhvZmVyMSswKQYDVQQDEyJGcmF1bmhvZmVyLUdlc2VsbHNjaGFmdCBS b290LUNBIHYyMB4XDTA2MDMwMzEyMjYyMloXDTA5MTIzMTIzMDAwMFowWTELMAkGA1UEBhMCREUx EzARBgNVBAoTCkZyYXVuaG9mZXIxDjAMBgNVBAsTBUZPS1VTMQ8wDQYDVQQLEwZQZW9wbGUxFDAS BgNVBAMTC1RhbmphIFpzZWJ5MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAu4nD7zY9 s/Msbjd5YnkcHF1H1Ns1IP9qeildSDLrpWEhUqMJJT3Ncy9uHUnrbFHp8AOSLg3CjkpP/9XwrNS3 hjSrdHddOgF/mIU3OuJ2Q9A5cMYKei4hmqF7EvAh0HWL7HdxoMJFo/DDaoftuH2XhgkXHmbvi+7j 3uN7tKJOXD4uaj5rFQP2I81J+P8dOl3xclKgYptE6pU9RaIleBEOk/qWPAIUrVMih7vrhZOTYRdR tKUaxnmMe1OMGaWDDwKtCfK7HDjO6WJ5FFJnteGLGmNKDnwI8AHSlcIDCyNlaiG6YXFa7FwEmEHx Qf9CQXZQFaLYkLv5cTFSUXboMifpGwIDAQABo4ICiDCCAoQwgaAGCWCGSAGG+EIBDQSBkhaBj1Nv ZnR3YXJlLVplcnRpZmlrYXQgZGVyIFplcnRpZml6aWVydW5nc2luc3RhbnogKENBKSBkZXIgRnJh dW5ob2Zlci1HZXNlbGxzY2hhZnQgZS5WLiwgTXVlbmNoZW47IFd1cnplbHplcnRpZmlrYXQgdmlh IGh0dHBzOi8vcGtpLmZyYXVuaG9mZXIuZGUvME0GCCsGAQUFBwEBBEEwPzA9BggrBgEFBQcwAYYx aHR0cDovL3BraS5mcmF1bmhvZmVyLmRlL0ZoRy1DQV92Ml9PQ1NQLVJlc3BvbmRlcjBIBgNVHR8E QTA/MD2gO6A5hjdodHRwOi8vcGtpLmZyYXVuaG9mZXIuZGUvRmhHLUNBLUNlcnRzL0ZoRy1DQV92 Ml9DUkwuY3JsMAwGA1UdEwEB/wQCMAAwSgYDVR0SBEMwQYEkemVydGlmaXppZXJ1bmdzaW5zdGFu ekBmcmF1bmhvZmVyLmRlhhlodHRwOi8vcGtpLmZyYXVuaG9mZXIuZGUvMCoGA1UdEQQjMCGBH3Rh bmphLnpzZWJ5QGZva3VzLmZyYXVuaG9mZXIuZGUwTAYDVR0gBEUwQzBBBgsrBgEEAYYKUAIBATAy MDAGCCsGAQUFBwIBFiRodHRwOi8vcGtpLmZyYXVuaG9mZXIuZGUvcG9saWN5Lmh0bWwwIgYDVR0l AQH/BBgwFgYIKwYBBQUHAwQGCisGAQQBgjcKAwQwDgYDVR0PAQH/BAQDAgQwMB0GA1UdDgQWBBQB llql0Jd/p2NvOXKaw+9B/F/5hzAfBgNVHSMEGDAWgBQAw/zvY8JWKC9RC3VW/3sF6RzJ8TANBgkq hkiG9w0BAQUFAAOCAQEAO2s7T1Y62h+7n4ZUZeFdx33XBVvDRxJypFymps2H0Y7k5ejLbtelDTvs BDb5vR2ItH47o4ryaL/FEhvrcn8ihAHtmB9q7+VCR+oS2FjVnl4FpiGqYYzsipFBjp5rcXAuQ772 ADVkMXGvJ0amVgt9lEmIJrTOerbkBWcXjctQFqorM4MB0Uibixs9Dqz6tLYlaQsWM7zxn4+DC/Lj zLl8V6LqfzQav/dtuA7yNcxjh7baWhypaL4sqMiFA0vovqAA+RWKS7dxDpzZvtvsHCHmT2TrH4ld XgyDeVXRltgF7zxsW4eGsjdUzlbftjIqwTiRZm0iaNRA+WtMF3Di6btWaTCCBbMwggSboAMCAQIC AhaGMA0GCSqGSIb3DQEBBQUAME8xCzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVyMSsw KQYDVQQDEyJGcmF1bmhvZmVyLUdlc2VsbHNjaGFmdCBSb290LUNBIHYyMB4XDTA2MDMwMzEyMjYy MVoXDTA5MTIzMTIzMDAwMFowWTELMAkGA1UEBhMCREUxEzARBgNVBAoTCkZyYXVuaG9mZXIxDjAM BgNVBAsTBUZPS1VTMQ8wDQYDVQQLEwZQZW9wbGUxFDASBgNVBAMTC1RhbmphIFpzZWJ5MIIBIjAN BgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAvN7x8sJ+RBZagyqoGbwBlp6gTXvC46xX1k+LTsKF jlwKFpifzszFwSzTSwngHTZK7V1gXaV1MAUTrIeL6SQO+F2V31X6CIZdC26mUTkORRYono+Lfmvq Ieij3yK3dWxGTKEuj3tNlKAKpwVu6uROdXEa+Kz7wrYioxamXZvbJ9/RT0LVXtWd73P3Mp+EmRLI UavDkJrhx5h9xkVy7fIt5tj0jMgwarPrt58otcYvxW9yn5OkLw5SRt1E574ulgzvX12JQqjC1bgE IVJ9ADulL/HcM4YvMjaxTvNurZJBfhkewy+g0yuZrppA4CBTyglzJEKED9xj9aQtj48Wpsgr6QID AQABo4ICjTCCAokwgaAGCWCGSAGG+EIBDQSBkhaBj1NvZnR3YXJlLVplcnRpZmlrYXQgZGVyIFpl cnRpZml6aWVydW5nc2luc3RhbnogKENBKSBkZXIgRnJhdW5ob2Zlci1HZXNlbGxzY2hhZnQgZS5W LiwgTXVlbmNoZW47IFd1cnplbHplcnRpZmlrYXQgdmlhIGh0dHBzOi8vcGtpLmZyYXVuaG9mZXIu ZGUvME0GCCsGAQUFBwEBBEEwPzA9BggrBgEFBQcwAYYxaHR0cDovL3BraS5mcmF1bmhvZmVyLmRl L0ZoRy1DQV92Ml9PQ1NQLVJlc3BvbmRlcjBIBgNVHR8EQTA/MD2gO6A5hjdodHRwOi8vcGtpLmZy YXVuaG9mZXIuZGUvRmhHLUNBLUNlcnRzL0ZoRy1DQV92Ml9DUkwuY3JsMAwGA1UdEwEB/wQCMAAw SgYDVR0SBEMwQYEkemVydGlmaXppZXJ1bmdzaW5zdGFuekBmcmF1bmhvZmVyLmRlhhlodHRwOi8v cGtpLmZyYXVuaG9mZXIuZGUvMCoGA1UdEQQjMCGBH3RhbmphLnpzZWJ5QGZva3VzLmZyYXVuaG9m ZXIuZGUwTAYDVR0gBEUwQzBBBgsrBgEEAYYKUAIBATAyMDAGCCsGAQUFBwIBFiRodHRwOi8vcGtp LmZyYXVuaG9mZXIuZGUvcG9saWN5Lmh0bWwwJwYDVR0lBCAwHgYIKwYBBQUHAwIGCCsGAQUFBwMD BggrBgEFBQcDBDAOBgNVHQ8BAf8EBAMCBsAwHQYDVR0OBBYEFHB2VPe9X1vC2wP2o/cGjEJnZwne MB8GA1UdIwQYMBaAFADD/O9jwlYoL1ELdVb/ewXpHMnxMA0GCSqGSIb3DQEBBQUAA4IBAQB3SVjk 9IKaTks+Kc5nzPzmYBjaUiWBpCgb4NniOOxBDICo85y/CGGgNvYVPOGRxlcgCzkfF3AHJeX1R+nz Ya57jJ675P7pR2xWYP0rAJomI2JxjNE+TGmr+hGffr6BecrXmXi9pFlnwQnPzX7i8/ZW4kFLp9Ft 3LdbtjKAkwcYkhtLct0nxnkettcLvaFB9Yl2o3yQleIFUar9kMG8BcAwWBktdYfyrnQ72lMtb/LJ +74lIP8aa3wxIbI/mc/OsrNKTeXvtEKu9oEmBC59gR5JScwyLMAgw5hRgInVexisVHGF3wlZYJad H/5dQS72SujVqYPtCpJIcNdJ/HZb8gBpMYIDFDCCAxACAQEwVTBPMQswCQYDVQQGEwJERTETMBEG A1UEChMKRnJhdW5ob2ZlcjErMCkGA1UEAxMiRnJhdW5ob2Zlci1HZXNlbGxzY2hhZnQgUm9vdC1D QSB2MgICFoYwCQYFKw4DAhoFAKCCAZQwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG 9w0BCQUxDxcNMDkxMDI2MTY1MTQxWjAjBgkqhkiG9w0BCQQxFgQULhr3ugtSYMmxYlEJDf1yFkI3 Z98wZAYJKwYBBAGCNxAEMVcwVTBPMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEr MCkGA1UEAxMiRnJhdW5ob2Zlci1HZXNlbGxzY2hhZnQgUm9vdC1DQSB2MgICFocwZgYLKoZIhvcN AQkQAgsxV6BVME8xCzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVyMSswKQYDVQQDEyJG cmF1bmhvZmVyLUdlc2VsbHNjaGFmdCBSb290LUNBIHYyAgIWhzBnBgkqhkiG9w0BCQ8xWjBYMAoG CCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG 9w0DAgIBKDAHBgUrDgMCGjAKBggqhkiG9w0CBTANBgkqhkiG9w0BAQEFAASCAQBSw3jdjDHu28nD RFI9NhZemkSkxRRpYPmhBQIfHpK9jHIRx+ff6lPGP+ImAfQWxdc4JpbQuca8iq4dLIN+CtEeHdFo XJXjuYro8G9+ujyrrPL3kcMi33gTpGAmHW4WFb+pEwPWHUQ+Iyhe0cQ+4P9uOIxbofwZqnjXmqOL 6IuwgDphZ28o5R03vDnWKxRp9SzrSs4S+SNNRtjsk7M//4CNndfcYm8ZBGAINIxKnWyt0oXQOBRN U5TXS6oszNCUC1GtzDlOf6ncJlxJOCRI0Gya2z8CDgklIB3fzTDBFnKWgj9xkTqAklBrc+uUF1Vc H8aNRJxNQ1Rz9wsGw6404t2wAAAAAAAA ------=_NextPart_000_0010_01CA5664.F9466920-- From root@core3.amsl.com Mon Oct 26 10:00:01 2009 Return-Path: X-Original-To: ipfix@ietf.org Delivered-To: ipfix@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 6437728C107; Mon, 26 Oct 2009 10:00:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20091026170001.6437728C107@core3.amsl.com> Date: Mon, 26 Oct 2009 10:00:01 -0700 (PDT) Cc: ipfix@ietf.org Subject: [IPFIX] I-D ACTION:draft-ietf-ipfix-export-per-sctp-stream-04.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, 26 Oct 2009 17:00:01 -0000 --NextPart 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 : IPFIX Export per SCTP Stream Author(s) : B. Claise, P. Aitken, A. Johnson, G. Muenz Filename : draft-ietf-ipfix-export-per-sctp-stream-04.txt Pages : 22 Date : 2009-10-26 This document specifies an extension to the specifications in RFC5101, IP Flow Information Export (IPFIX), when using the Partial Reliability extension of SCTP (PR-SCTP, Partial Reliability Stream Control Transmission Protocol). When implemented at both the Exporting and Collecting Processes, this method offers several advantages such as the ability to calculate Data Record losses for PR-SCTP, immediate export of Template Withdrawal Messages, immediate reuse of Template IDs within an SCTP stream, reduced likelihood of Data Record loss, and reduced demands on the Collecting Process. When implemented in only the Collecting or Exporting Process then normal IPFIX behavior will be seen without these additional benefits. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipfix-export-per-sctp-stream-04.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 Content-Type: Message/External-body; name="draft-ietf-ipfix-export-per-sctp-stream-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-10-26095417.I-D@ietf.org> --NextPart-- From schmitt@net.in.tum.de Tue Oct 27 02:54:46 2009 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 54CC93A67BD for ; Tue, 27 Oct 2009 02:54:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.575 X-Spam-Level: X-Spam-Status: No, score=-0.575 tagged_above=-999 required=5 tests=[AWL=0.185, BAYES_05=-1.11, 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 ST-bM0-O5P9q for ; Tue, 27 Oct 2009 02:54:45 -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 899933A67F0 for ; Tue, 27 Oct 2009 02:54:40 -0700 (PDT) Received: from phoenix.net.informatik.tu-muenchen.de (phoenix.net.in.tum.de [131.159.14.1]) by services.net.informatik.tu-muenchen.de (Postix Mailer @ mail) with ESMTP id E8ADB47FB7 for ; Tue, 27 Oct 2009 10:54:52 +0100 (CET) Received: from [127.0.0.1] (ldap [131.159.14.1]) by phoenix.net.informatik.tu-muenchen.de (Postfix) with ESMTP id DBB8E22D7 for ; Tue, 27 Oct 2009 10:54:52 +0100 (CET) Message-ID: <4AE6C35F.1060209@net.in.tum.de> Date: Tue, 27 Oct 2009 10:54:39 +0100 From: Schmitt User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: ipfix@ietf.org Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 8bit X-Virus-Scanned: ClamAV using ClamSMTP Subject: [IPFIX] New draft about IPFIX for Wireless Sensors 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, 27 Oct 2009 09:54:46 -0000 Dear members, as you can see on the working group site. A new draft called draft-schmitt-6lowapp-ipfix-ws-00.txt was added. This draft deals with IPFIX for Wireless Sensors. Zach Shelby motivated us to write an IETF-Draft about our work on applications above 6LoWPAN. Abstract In this draft we want to introduce an idea to develop a protocol for efficient data transmission for Wireless Sensors using the ideas of IPFIX. We will call this protocol IPFIX-WS. Introduction Today everyone calls for new approaches for data acquisition in real-time. Different challenging requirements must be solved, such as efficient collection of environmental data using Wireless Sensors and efficient data transmission due to hardware limitations. Constraints on size, energy consumption and price lead to very limited memory, computational and communications resources. The desire for sensor nodes to be operational for a long time without external intervention, such as exchange of the batteries, which are often the only source of energy, leads to additional restrictions in the usage of the resources. Some research is done to address the issue of the sole dependency on battery power, but for now it remains the prevalent source of energy for WSNs. The physical size of a sensor node is another limiting factor. The IRIS mote which is used in our setup has the dimensions of 58 x 32 x 7 mm, without the battery pack. Thus it does not leave much room for the micro controller, flash memory (128 kb) and RF transceiver, all of which are located on this board. To satisfy those needs, standard protocols for efficient data transmission from common networks, such as the IP Flow Information Export (IPFIX) protocol, should be adapted to the equipment of Wireless Sensors. Another possibility is to reduce the data amount by implementing in-network data aggregation functionality. The most important thing is to develop these approaches while still providing interoperability between devices of different vendors. Feel free to read the draft and make comments. Regards, Corinna Schmitt -- Corinna Schmitt, Dipl.-Inf. (Bioinf.) Technische Universität München Chair for Network Architectures and Services (I8) Boltzmannstr. 3 85748 Garching b. München Germany Phone.: +49 (0)89 289 18005 Email: schmitt@net.in.tum.de http://www.net.in.tum.de/~schmitt/ From trammell@tik.ee.ethz.ch Tue Oct 27 03:15:54 2009 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 9E5563A68E8 for ; Tue, 27 Oct 2009 03:15:54 -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 qe-wLKmOSSv4 for ; Tue, 27 Oct 2009 03:15:53 -0700 (PDT) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) by core3.amsl.com (Postfix) with ESMTP id AE8BE3A67F0 for ; Tue, 27 Oct 2009 03:15:53 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id 48439D9465 for ; Tue, 27 Oct 2009 11:16:06 +0100 (MET) 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 KZg25f1Xkj9k for ; Tue, 27 Oct 2009 11:16:06 +0100 (MET) Received: from pb-10072.ethz.ch (pb-10072.ethz.ch [82.130.103.195]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: briant) by smtp.ee.ethz.ch (Postfix) with ESMTP id 128C3D93F7 for ; Tue, 27 Oct 2009 11:16:05 +0100 (MET) Message-Id: From: Brian Trammell To: "ipfix@ietf.org Working Group" In-Reply-To: <4AE5CF2F.1000702@cisco.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Tue, 27 Oct 2009 11:16:05 +0100 References: <4AE5C359.6090306@cisco.com> <4AE5CF2F.1000702@cisco.com> X-Mailer: Apple Mail (2.936) Subject: [IPFIX] WGLC comments on draft-ietf-ipfix-mediators-problem-statement-06 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, 27 Oct 2009 10:15:54 -0000 Greetings, all, Please find below my WGLC comments on the Mediator PS draft. The Implementation Analyses in Section 5.x are in my opinion still too tied to specific mediator devices. We're talking about Concentrators and Masquerading Proxies and Distributors as if there was a substantive difference among them. There isn't. There are Mediators. They run Intermediate Functions. They accept IPFIX, or something like it (e.g. NetFlow). They produce IPFIX. They might change the content or framing based on configuration and state. Drawing more restrictive labeled boxes around specific types of intermediate functions risks limiting flexibility and provides the impression that complicated mediation might require multiple devices. However, we've had this discussion for a very long time without coming to agreement, and it's a relatively minor point, so I'm willing to let these sections go as they are. However, I will state that I find the Intermediate Process and Mediator definitions in the Terminology to be quite useful (as they should be considering the amount of work we put into them before and during the Stockholm meeting :) ), but the others, not so much. The Security Considerations section is a little week; I suspect the IESG in particular will require a more in-depth analysis of Mediator- specific attacks. Mitigation could, of course, also be handled in the Mediator Protocol draft. One thing that came up in the 5655 review is the issue of chains of trust, so I suspect there will also be questions about how a final collector will be able to authenticate an Original Exporter across a Mediator. But these can be handled at the IESG stage. (Also, one very minor nit, in the Acknowledgments sections, my last name is spelled Trammell.) Best regards, Brian From Quittek@nw.neclab.eu Tue Oct 27 03:36:50 2009 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 B43BD3A6A0E for ; Tue, 27 Oct 2009 03:36:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.506 X-Spam-Level: X-Spam-Status: No, score=-2.506 tagged_above=-999 required=5 tests=[AWL=0.093, 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 oXhoqpyGLKrb for ; Tue, 27 Oct 2009 03:36:49 -0700 (PDT) Received: from smtp0.neclab.eu (smtp0.neclab.eu [195.37.70.41]) by core3.amsl.com (Postfix) with ESMTP id 47A483A6A0D for ; Tue, 27 Oct 2009 03:36:49 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp0.neclab.eu (Postfix) with ESMTP id 0FF052C00C525; Tue, 27 Oct 2009 11:37:01 +0100 (CET) X-Virus-Scanned: Amavisd on Debian GNU/Linux (atlas2.office) Received: from smtp0.neclab.eu ([127.0.0.1]) by localhost (atlas2.office [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G02fY+zns+Ff; Tue, 27 Oct 2009 11:37:00 +0100 (CET) Received: from VENUS.office (mx1.office [192.168.24.3]) by smtp0.neclab.eu (Postfix) with ESMTP id CD9342C0002FC; Tue, 27 Oct 2009 11:36:50 +0100 (CET) Received: from VENUS.office ([192.168.24.102]) by VENUS.office with Microsoft SMTPSVC(6.0.3790.3959); Tue, 27 Oct 2009 11:36:50 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Received: from 10.7.0.54 ([10.7.0.54]) by VENUS.office ([192.168.24.102]) with Microsoft Exchange Server HTTP-DAV ; Tue, 27 Oct 2009 10:36:50 +0000 MIME-Version: 1.0 Content-class: urn:content-classes:message Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="B_3339488194_15023743" Date: Tue, 27 Oct 2009 11:36:33 +0100 Message-ID: In-Reply-To: <4AE6C35F.1060209@net.in.tum.de> X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: [IPFIX] New draft about IPFIX for Wireless Sensors thread-index: AcpW8Vn3ntEYbG47FE2QA/CDyimd3w== From: "Juergen Quittek" To: "Schmitt" , "IETF IPFIX Working Group" X-OriginalArrivalTime: 27 Oct 2009 10:36:50.0768 (UTC) FILETIME=[648EFD00:01CA56F1] Subject: Re: [IPFIX] New draft about IPFIX for Wireless Sensors 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, 27 Oct 2009 10:36:50 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3339488194_15023743 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Dear Corinna, This is a draft I am waiting for for a long time already. I think this opens a new wide application area for IPFIX. Thanks, Juergen On 27.10.09 10:54 "Schmitt" wrote: > Dear members, > > as you can see on the working group site. A new draft called > draft-schmitt-6lowapp-ipfix-ws-00.txt was added. This draft deals with > IPFIX for Wireless Sensors. Zach Shelby motivated us to write an > IETF-Draft about our work on applications above 6LoWPAN. > > Abstract > In this draft we want to introduce an idea to develop a protocol for > efficient data transmission for Wireless Sensors using the ideas of > IPFIX. We will call this protocol IPFIX-WS. > > Introduction > Today everyone calls for new approaches for data acquisition in > real-time. Different challenging requirements must be solved, such as > efficient collection of environmental data using Wireless Sensors and > efficient data transmission due to hardware limitations. Constraints on > size, energy consumption and price lead to very limited memory, > computational and communications resources. The desire for sensor nodes > to be operational for a long time without external intervention, such as > exchange of the batteries, which are often the only source of energy, > leads to additional restrictions in the usage of the resources. Some > research is done to address the issue of the sole dependency on battery > power, but for now it remains the prevalent source of energy for WSNs. > The physical size of a sensor node is another limiting factor. The IRIS > mote which is used in our setup has the dimensions of 58 x 32 x 7 mm, > without the battery pack. Thus it does not leave much room for the micro > controller, flash memory (128 kb) and RF transceiver, all of which are > located on this board. > To satisfy those needs, standard protocols for efficient data > transmission from common networks, such as the IP Flow Information > Export (IPFIX) protocol, should be adapted to the equipment of Wireless > Sensors. Another possibility is to reduce the data amount by > implementing in-network data aggregation functionality. The most > important thing is to develop these approaches while still providing > interoperability between devices of different vendors. > > Feel free to read the draft and make comments. > > Regards, > Corinna Schmitt --B_3339488194_15023743 Content-type: application/pkcs7-signature; name="smime.p7s" Content-transfer-encoding: base64 Content-disposition: attachment; filename="smime.p7s" MIIQ6gYJKoZIhvcNAQcCoIIQ2zCCENcCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC DpIwggU2MIIEHqADAgECAgQNLisHMA0GCSqGSIb3DQEBBQUAMIGQMQswCQYDVQQGEwJERTEY MBYGA1UEChMPTkVDIEV1cm9wZSBMdGQuMSAwHgYDVQQLExdORUMgTGFib3JhdG9yaWVzIEV1 cm9wZTESMBAGA1UEAxMJTkVDTEFCLUNBMTEwLwYJKoZIhvcNAQkBFiJ6ZXJ0aWZpemllcnVu Z3NzdGVsbGVAbncubmVjbGFiLmV1MB4XDTA4MTEwMzA3NTEyMFoXDTExMTEwMzA3NTEyMFow YzELMAkGA1UEBhMCREUxGDAWBgNVBAoTD05FQyBFdXJvcGUgTHRkLjEgMB4GA1UECxMXTkVD IExhYm9yYXRvcmllcyBFdXJvcGUxGDAWBgNVBAMTD0p1ZXJnZW4gUXVpdHRlazCCASIwDQYJ KoZIhvcNAQEBBQADggEPADCCAQoCggEBALYRfFB9x4h1YO6Mva6A5GCwKjwpgvzjiayFSmdD HwV8u5gHp3sHIhyVtxgMSifEp9AV+ChxWHS3KQwuQ3XhDAP/xDN6QSk4Bmqa6rCZuTJygxYh K39rNKd47ZfpuRC7j/Mbzwe9DTsbbBtpBgl5UKFc9c+zMbPlSwwlVbshWaUEoM6HoVFaDJdh tJBIpsblz1oQVKXDjxjGkUNh9Ds3m7BGXkr5yaGsEuEa0J/QAFdO+auvBJlAzIM0UwBAmlcT UHanS6Sdw5MkeutQqnmsUBtoenydq2Tmd9hfSfuTfiFuLmsvL3udH/jDAgQZ+PH6Mprqpyd3 wSycF/xZF5zz8X0CAwEAAaOCAcIwggG+MAkGA1UdEwQCMAAwCwYDVR0PBAQDAgXgMCkGA1Ud JQQiMCAGCCsGAQUFBwMCBggrBgEFBQcDBAYKKwYBBAGCNxQCAjAdBgNVHQ4EFgQUWQo3BPrO OLA4qljzDL1H8/6hIWEwHwYDVR0jBBgwFoAUTxyHeh3gL5n2vhWq0TWdDkrmujYwHwYDVR0R BBgwFoEUUXVpdHRla0Budy5uZWNsYWIuZXUwfQYDVR0fBHYwdDA4oDagNIYyaHR0cDovL2Nk cDEucGNhLmRmbi5kZS9uZWNsYWItY2EvcHViL2NybC9jYWNybC5jcmwwOKA2oDSGMmh0dHA6 Ly9jZHAyLnBjYS5kZm4uZGUvbmVjbGFiLWNhL3B1Yi9jcmwvY2FjcmwuY3JsMIGYBggrBgEF BQcBAQSBizCBiDBCBggrBgEFBQcwAoY2aHR0cDovL2NkcDEucGNhLmRmbi5kZS9uZWNsYWIt Y2EvcHViL2NhY2VydC9jYWNlcnQuY3J0MEIGCCsGAQUFBzAChjZodHRwOi8vY2RwMi5wY2Eu ZGZuLmRlL25lY2xhYi1jYS9wdWIvY2FjZXJ0L2NhY2VydC5jcnQwDQYJKoZIhvcNAQEFBQAD ggEBAB37+54yupDBTDpEMuyf+ouCRrOE3fPAD2SEGBXCpKTYteFkFSWvHlgN8ecRSma0Dz/5 QShzacGMeJ8o+XzVXHe2gtZbjzSVvJn+/nAKtKgDCzw0ltt3xkdMMv2ax6IKGR7BcccsXx7B R2PMaxdmHfCJseXiMzZO9QlWN2NZq2SSo3eGX/YDhHCWXDsoSu+uaKU/aRL2uZa92ptak2MA uKI5tylKLFZ3FHf08F8J+5tTaMGem6DfaMZR/9GZ8aRFJrdA7tzUAGKpl+CzRxsJVHbAAU5L hm5oTt6XYbh2G/cgdpeucsHJWBz9NQJrSrfWZYSwrv6AekMcvMi9X/CVZxEwggUvMIIEF6AD AgECAgQNIQpHMA0GCSqGSIb3DQEBBQUAMFoxCzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpERk4t VmVyZWluMRAwDgYDVQQLEwdERk4tUEtJMSQwIgYDVQQDExtERk4tVmVyZWluIFBDQSBHbG9i YWwgLSBHMDEwHhcNMDgxMDI0MDg1MjA4WhcNMTkwNjMwMDAwMDAwWjCBkDELMAkGA1UEBhMC REUxGDAWBgNVBAoTD05FQyBFdXJvcGUgTHRkLjEgMB4GA1UECxMXTkVDIExhYm9yYXRvcmll cyBFdXJvcGUxEjAQBgNVBAMTCU5FQ0xBQi1DQTExMC8GCSqGSIb3DQEJARYiemVydGlmaXpp ZXJ1bmdzc3RlbGxlQG53Lm5lY2xhYi5ldTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoC ggEBAJ7yFbG1EaoyDnG5367mJEXHljmacrzNnm52KW3dXD/s3Vpuskex0jvaaTntWWRSGrAK 6kKXnTxBb3J3EhveBUbltzQ+K0XKtPJm6VE5qVpl33WJSaUHs27Dhwlke+DV6BBGyukz2SDB aSa+nc0AwMZ0XO1DoDuiUNVeNmd/QT4SGzyFs+uLfLL2n8WzkZsbpSZ+xecwyw3EdQBBsp/i /W+uOQBsGqaCjYe3EkBU6nW+pBsj0Iy1n7b9PXb5gQynrK3Mi2V7g1idSzHos0o1BMoHUrMz Vw94Hj4CWlWmQ0t6Pdt1uYAMjwk0saQBY/Fyfv+wKeYycGIYyYCfJIRUeyUCAwEAAaOCAcQw ggHAMBIGA1UdEwEB/wQIMAYBAf8CAQEwCwYDVR0PBAQDAgEGMB0GA1UdDgQWBBRPHId6HeAv mfa+FarRNZ0OSua6NjAfBgNVHSMEGDAWgBRJt8bP6D0ff+pEexMp9/EKcD7eZDAtBgNVHREE JjAkgSJ6ZXJ0aWZpemllcnVuZ3NzdGVsbGVAbncubmVjbGFiLmV1MIGIBgNVHR8EgYAwfjA9 oDugOYY3aHR0cDovL2NkcDEucGNhLmRmbi5kZS9nbG9iYWwtcm9vdC1jYS9wdWIvY3JsL2Nh Y3JsLmNybDA9oDugOYY3aHR0cDovL2NkcDIucGNhLmRmbi5kZS9nbG9iYWwtcm9vdC1jYS9w dWIvY3JsL2NhY3JsLmNybDCBogYIKwYBBQUHAQEEgZUwgZIwRwYIKwYBBQUHMAKGO2h0dHA6 Ly9jZHAxLnBjYS5kZm4uZGUvZ2xvYmFsLXJvb3QtY2EvcHViL2NhY2VydC9jYWNlcnQuY3J0 MEcGCCsGAQUFBzAChjtodHRwOi8vY2RwMi5wY2EuZGZuLmRlL2dsb2JhbC1yb290LWNhL3B1 Yi9jYWNlcnQvY2FjZXJ0LmNydDANBgkqhkiG9w0BAQUFAAOCAQEAbDEPnQ9JpouPHYA1OEek P3l3GNM0HBzadVbtbN5MDtFmoVgdLYqlQaHb30wFhuOMbsNCOzV0k8EOvBVOT9BiEJ70RWcl SZQ460jZS2MY6n5oG/ilZuu6N/N3GSLg2pBBNH9vZFCyBJ9n4Px7A4gQF07G+CNfV2jdE1yy PjzIVPhg6bBgia8nXroBFe6oteavMspo0gLGIJ63NsCbl6ckPa96grT+mnnQD0h6jk/IGtXS 09mEWRbN7zZu0x0q+SScpljG36Q+jnG0U5zQI0jAx8CcYEQQH5QOlsw1Zu35OI4lsi7ycFkz JNfbfEC4ihuw9J2L43BFGMojkhPkhVExHTCCBCEwggMJoAMCAQICAgDHMA0GCSqGSIb3DQEB BQUAMHExCzAJBgNVBAYTAkRFMRwwGgYDVQQKExNEZXV0c2NoZSBUZWxla29tIEFHMR8wHQYD VQQLExZULVRlbGVTZWMgVHJ1c3QgQ2VudGVyMSMwIQYDVQQDExpEZXV0c2NoZSBUZWxla29t IFJvb3QgQ0EgMjAeFw0wNjEyMTkxMDI5MDBaFw0xOTA2MzAyMzU5MDBaMFoxCzAJBgNVBAYT AkRFMRMwEQYDVQQKEwpERk4tVmVyZWluMRAwDgYDVQQLEwdERk4tUEtJMSQwIgYDVQQDExtE Rk4tVmVyZWluIFBDQSBHbG9iYWwgLSBHMDEwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEK AoIBAQDpm8NnhfkNrvWNVMOWUDU9YuluTO2U1wBblSJ01CDrNI/W7MAxBAuZgeKmFNJSoCgj hIt0iQReW+DieMF4yxbLKDU5ey2QRdDtoAB6fL9KDhsAw4bpXCsxEXsM84IkQ4wcOItqaACa 7txPeKvSxhObdq3u3ibo7wGvdA/BCaL2a869080UME/15eOkyGKbghoDJzANAmVgTe3RCSMq ljVYJ9N2xnG2kB3E7f81hn1vM7PbD8URwoqDoZRdQWvY0hD1TP3KUazZve+Sg7va64sWVlZD z+HVEz2mHycwzUlU28kTNJpxdcVs6qcLmPkhnSevPqM5OUhqjK3JmfvDEvK9AgMBAAGjgdkw gdYwcAYDVR0fBGkwZzBloGOgYYZfaHR0cDovL3BraS50ZWxlc2VjLmRlL2NnaS1iaW4vc2Vy dmljZS9hZl9Eb3dubG9hZEFSTC5jcmw/LWNybF9mb3JtYXQ9WF81MDkmLWlzc3Vlcj1EVF9S T09UX0NBXzIwHQYDVR0OBBYEFEm3xs/oPR9/6kR7Eyn38QpwPt5kMB8GA1UdIwQYMBaAFDHD eRu69VPXF+CJei0XbAqzK50zMA4GA1UdDwEB/wQEAwIBBjASBgNVHRMBAf8ECDAGAQH/AgEC MA0GCSqGSIb3DQEBBQUAA4IBAQA74Vp3wEgX3KkY7IGvWonwvSiSpspZGBJw7Cjy565/lizn 8l0ZMfYTK3S9vYCyufdnyTmieTvhERHua3iRM347XyYndVNljjNj7s9zw7CSI0khUHUjoR8Y 4pSFPT8z6XcgjaK95qGFKUD2P3MyWA0Ja6bahWzAP7uNZmRWJE6uDT8yNQFb6YyC2XJZT7GG hfF0hVblw/hc843uR7NTBXDn5U2KaYMo4RMJhp5eyOpYHgwf+aTUWgRo/Sg+iwK2WLX2oSw3 VwBnqyNojWOl75lrXP1LVvarQIc01BGSbOyHxQoLBzNytG8MHVQs2FHHzL8w00Ny8TK/jM5J Y6gA9/IcMYICIDCCAhwCAQEwgZkwgZAxCzAJBgNVBAYTAkRFMRgwFgYDVQQKEw9ORUMgRXVy b3BlIEx0ZC4xIDAeBgNVBAsTF05FQyBMYWJvcmF0b3JpZXMgRXVyb3BlMRIwEAYDVQQDEwlO RUNMQUItQ0ExMTAvBgkqhkiG9w0BCQEWInplcnRpZml6aWVydW5nc3N0ZWxsZUBudy5uZWNs YWIuZXUCBA0uKwcwCQYFKw4DAhoFAKBdMCMGCSqGSIb3DQEJBDEWBBTlWc7dN7ScfTQNPYtG /xVDp6N1cDAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wOTEw MjcxMDM2MzRaMA0GCSqGSIb3DQEBAQUABIIBAKApb4wYUKRGwUmpbaQaUWromH2SOAmSHadL bz6MOahDJYj4tCQPBpZmUVAzBpTHpLF/hb4YYrzEDE2HwzQQoSP4x6RgbTCKdZH0JYm6bWHS haTq/FjKwS8XJLcZvaWW/T+KQxx9T4VUxr47HvspkdQ+FSOg8UZyMfOflgXsWfjo4y0wSs7a nrUJ5eD1lW87HAqIq1N62xNtf1wGT80tUa99E++EkfLmJfQqX+jyqqwK+5/V1DIUK95Pu9ur 73TJ92b8j2v9nB0o3vhQfQkQrzhAaRmIYCvLFGtJiwRCHs4vvQc++Yim7h/MASf4dwh1Az45 ihlvuKhRfkrRpPi4zis= --B_3339488194_15023743-- From ishibashi.keisuke@lab.ntt.co.jp Tue Oct 27 17:27:12 2009 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 AE35028C165 for ; Tue, 27 Oct 2009 17:27:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.09 X-Spam-Level: X-Spam-Status: No, score=-0.09 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265] 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 nfpaqO1DJXif for ; Tue, 27 Oct 2009 17:27:11 -0700 (PDT) Received: from tama500.ecl.ntt.co.jp (tama500.ecl.ntt.co.jp [129.60.39.148]) by core3.amsl.com (Postfix) with ESMTP id 9F09928C16A for ; Tue, 27 Oct 2009 17:27:11 -0700 (PDT) Received: from mfs6.rdh.ecl.ntt.co.jp (mfs6.rdh.ecl.ntt.co.jp [129.60.39.149]) by tama500.ecl.ntt.co.jp (8.14.3/8.14.3) with ESMTP id n9S0RPhx006122 for ; Wed, 28 Oct 2009 09:27:25 +0900 (JST) Received: from mfs6.rdh.ecl.ntt.co.jp (localhost [127.0.0.1]) by mfs6.rdh.ecl.ntt.co.jp (Postfix) with ESMTP id BA9645E64 for ; Wed, 28 Oct 2009 09:27:25 +0900 (JST) Received: from imb.m.ecl.ntt.co.jp (imb0.m.ecl.ntt.co.jp [129.60.5.140]) by mfs6.rdh.ecl.ntt.co.jp (Postfix) with ESMTP id A41555C66 for ; Wed, 28 Oct 2009 09:27:25 +0900 (JST) Received: from localhost (guatemala.pflab.ecl.ntt.co.jp [129.60.227.49]) by imb.m.ecl.ntt.co.jp (8.13.8/8.13.8) with ESMTP id n9S0RPd6021744 for ; Wed, 28 Oct 2009 09:27:25 +0900 (JST) Date: Wed, 28 Oct 2009 09:27:28 +0900 (JST) Message-Id: <20091028.092728.74746876.ishibashi.keisuke@lab.ntt.co.jp> To: ipfix@ietf.org From: Keisuke ISHIBASHI In-Reply-To: References: <4AE5CF2F.1000702@cisco.com> X-Mailer: Mew version 4.2 on Emacs 21.4 / Mule 5.0 =?iso-2022-jp?B?KBskQjgtTFobKEIp?= Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Tue, 27 Oct 2009 17:43:20 -0700 Subject: Re: [IPFIX] WGLC comments on draft-ietf-ipfix-mediators-problem-statement-06 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: Wed, 28 Oct 2009 00:27:12 -0000 Hi all, Although it's about specific mediator devices, I'm bit uncertain of the hierachical collection system built with IPFIX Concentrators in Section 5.2. If the Cocentrators only aggregate the flow records from original Exporters, then, from the Collector's point of view, there is no difference from the case that the original Exporters gererate aggregated flow records. I don't have a image that this type of mediator provide a solution to the problem stated in Section 4.1. What about an example that those Concentrators have retention capabilities of original Flow Records, as follow: To cope with the increase of IPFIX Exporters and traffic, one possible implementation uses IPFIX Concentrators with Collecting Process to build a hierarchical collection system. , which is similar to the last implementation example in Section 5.7. This is a very minor comment, however, I'm willing to go on as they are. > The Security Considerations section is a little week; I suspect the > IESG in particular will require a more in-depth analysis of Mediator- > specific attacks. Yes, for example, weakening of the trust chain by supporting legacy protocols may be one of the above case? Best regards, Keisuke ISHIBASHI NTT Information Sharing Platform Labs. From: Brian Trammell Subject: [IPFIX] WGLC comments on draft-ietf-ipfix-mediators-problem-statement-06 Date: Tue, 27 Oct 2009 11:16:05 +0100 Message-ID: > Greetings, all, > > Please find below my WGLC comments on the Mediator PS draft. > > The Implementation Analyses in Section 5.x are in my opinion still too > tied to specific mediator devices. We're talking about Concentrators > and Masquerading Proxies and Distributors as if there was a > substantive difference among them. There isn't. There are Mediators. > They run Intermediate Functions. They accept IPFIX, or something like > it (e.g. NetFlow). They produce IPFIX. They might change the content > or framing based on configuration and state. Drawing more restrictive > labeled boxes around specific types of intermediate functions risks > limiting flexibility and provides the impression that complicated > mediation might require multiple devices. > > However, we've had this discussion for a very long time without coming > to agreement, and it's a relatively minor point, so I'm willing to let > these sections go as they are. However, I will state that I find the > Intermediate Process and Mediator definitions in the Terminology to be > quite useful (as they should be considering the amount of work we put > into them before and during the Stockholm meeting :) ), but the > others, not so much. > > The Security Considerations section is a little week; I suspect the > IESG in particular will require a more in-depth analysis of Mediator- > specific attacks. Mitigation could, of course, also be handled in the > Mediator Protocol draft. One thing that came up in the 5655 review is > the issue of chains of trust, so I suspect there will also be > questions about how a final collector will be able to authenticate an > Original Exporter across a Mediator. But these can be handled at the > IESG stage. > > (Also, one very minor nit, in the Acknowledgments sections, my last > name is spelled Trammell.) > > Best regards, > > Brian > _______________________________________________ > IPFIX mailing list > IPFIX@ietf.org > https://www.ietf.org/mailman/listinfo/ipfix From rfc-editor@rfc-editor.org Wed Oct 28 09:20:05 2009 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 C987128C1CA; Wed, 28 Oct 2009 09:20:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -16.906 X-Spam-Level: X-Spam-Status: No, score=-16.906 tagged_above=-999 required=5 tests=[AWL=0.093, BAYES_00=-2.599, J_CHICKENPOX_93=0.6, USER_IN_DEF_WHITELIST=-15] 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 x+97v3oEnitH; Wed, 28 Oct 2009 09:20:04 -0700 (PDT) Received: from bosco.isi.edu (bosco.isi.edu [128.9.168.207]) by core3.amsl.com (Postfix) with ESMTP id 98BF528C1CE; Wed, 28 Oct 2009 09:20:04 -0700 (PDT) Received: by bosco.isi.edu (Postfix, from userid 70) id DECCE35697F; Wed, 28 Oct 2009 09:17:14 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org From: rfc-editor@rfc-editor.org Message-Id: <20091028161714.DECCE35697F@bosco.isi.edu> Date: Wed, 28 Oct 2009 09:17:14 -0700 (PDT) Cc: ipfix@ietf.org, rfc-editor@rfc-editor.org Subject: [IPFIX] RFC 5655 on Specification of the IP Flow Information Export (IPFIX) File Format 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: Wed, 28 Oct 2009 16:20:05 -0000 A new Request for Comments is now available in online RFC libraries. RFC 5655 Title: Specification of the IP Flow Information Export (IPFIX) File Format Author: B. Trammell, E. Boschi, L. Mark, T. Zseby, A. Wagner Status: Standards Track Date: October 2009 Mailbox: brian.trammell@hitachi-eu.com, elisa.boschi@hitachi-eu.com, lutz.mark@ifam.fraunhofer.de, tanja.zseby@fokus.fraunhofer.de, arno@wagner.name Pages: 64 Characters: 154566 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-ipfix-file-05.txt URL: http://www.rfc-editor.org/rfc/rfc5655.txt This document describes a file format for the storage of flow data based upon the IP Flow Information Export (IPFIX) protocol. It proposes a set of requirements for flat-file, binary flow data file formats, then specifies the IPFIX File format to meet these requirements based upon IPFIX Messages. This IPFIX File format is designed to facilitate interoperability and reusability among a wide variety of flow storage, processing, and analysis tools. [STANDARDS TRACK] This document is a product of the IP Flow Information Export Working Group of the IETF. This is now a Proposed Standard Protocol. STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion and suggestions for improvements. Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. 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 USC/Information Sciences Institute From trammell@tik.ee.ethz.ch Thu Oct 29 03:01:33 2009 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 6D7253A6A56 for ; Thu, 29 Oct 2009 03:01:33 -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 WNxCGDv3e4lj for ; Thu, 29 Oct 2009 03:01:32 -0700 (PDT) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) by core3.amsl.com (Postfix) with ESMTP id B987F3A6993 for ; Thu, 29 Oct 2009 03:01:31 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id B312CD9377 for ; Thu, 29 Oct 2009 11:01:45 +0100 (MET) 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 wvmOb8MqmXFH for ; Thu, 29 Oct 2009 11:01:45 +0100 (MET) Received: from [10.0.1.11] (84-75-160-12.dclient.hispeed.ch [84.75.160.12]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: briant) by smtp.ee.ethz.ch (Postfix) with ESMTP id 6C3D4D939B for ; Thu, 29 Oct 2009 11:01:45 +0100 (MET) From: Brian Trammell Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Date: Thu, 29 Oct 2009 11:01:44 +0100 References: To: ipfix@ietf.org Message-Id: <7A07131A-78E8-44DA-85A7-FF7D839A6AA8@tik.ee.ethz.ch> Mime-Version: 1.0 (Apple Message framework v1076) X-Mailer: Apple Mail (2.1076) Subject: [IPFIX] Fwd: I-D ACTION:draft-ietf-ipfix-export-per-sctp-stream-04.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: Thu, 29 Oct 2009 10:01:33 -0000 Hi, Benoit, all, I have a few comments on the -04 perstream draft. In general the quality of the draft has improved greatly. I'm quite happy with the detail in section 4.5 for guaranteeing interoperability while still allowing CPs to get the benefits of per-stream, which was my main issue with the previous revision. I notice too the Intended Status is now Standards Track. I presume that this Standards Track designation is equivalent to that of e.g. 5103 (Biflow): this is an optional specification with specific applicability; otherwise, it's still fine IMO as Informational, but then you have to ditch all the 2119 language. I think it was the appearance of 2119 language in an Informational draft that made the IESG suggest Standards Track; see 5473 for an example of how to describe a mechanism with specific applicability in a non-normative way. Of course, then there's the problem with an Informative RFC contradicting a Standards Track one (5101), necessary for the CP to realize the perstream advantages... In any case, I'm not convinced the discussion is complete on this point. Presuming we're talking about a restricted-applicability Standards Track draft, the applicability of the draft is now clearer in previous versions, but I would still suggest certain changes to the language in order to avoid confusion on this point, as follows. 2.2 Applicability para 1 OLD: The specifications are required in cases where we must know how many data records of a certain type... NEW: The specifications contained in this document are applicable to cases where application requirements include knowing how many data records of a certain type... [Yes, I know that required isn't a REQUIRED, but I want implementors to be sure they don't have to do perstream if they're not splitting templates by app; I believe the suggested text clarifies this point] 2.2 Applicability para 3 OLD: However, in order to benefit from the advantages, the Collecting Process specified in [RFC5101] must implement some additional specifications that this document introduces. NEW: However, Collecting Processes may implement additional support for per-stream export specified in this document in order to realize all the benefits of the approach specified herein. [Same thing. Make it clear we're not updating 5101.] 3.2.1 Transmission Order within an SCTP Stream / IPFIX Protocol Specifications Limitation paragraph 5 DELETE: In practice, Data Records without associated (Options) template records will most likely be discarded by the Collecting Process. [Maybe true. Probably, even. Appropriate for an Informational draft or an implementation report. But this comes too close to contradicting a MAY in 5101 to be appropriate for a Standards Track draft.] 4. Specifications para 1 OLD: This section introduces improvements compared to the IPFIX specifications in [RFC5101]. NEW: This section specifies Exporting Process and Collecting Process behavior different from that in [RFC5101] in order to realize the benefits of per-stream export. Note that Exporting Processes following these Specifications will interoperate with [RFC5101]-compliant Collecting Processes, but that Collecting Processes will have to follow additional non-interoperable specifications to realize the full benefits of the technique. [The current text does not take applicability under consideration.] 4.2 Template Management para 1 OLD: This section introduces some additional specifications compared to the Template Management section 8 in [RFC 5101] NEW: To take advantage of per-stream export, Exporting Processes should follow the specification in this section in addition to Section 8, Template Management, of [RFC5101]. [As for 4 above.] 4.3 SCTP para 1 OLD: This section introduces some more specific specifications compared to the SCTP section 10.2 in [RFC 5101], in particular the "Stream" section 10.2.4.3. NEW: To take advantage of per-stream export, Exporting Processes should manage SCTP streams according to the specification in this section, in addition to Section 10.2.4.3, Stream, of [RFC5101]. [As for 4 above.] 4.4 Template Withdrawal Message para 1 OLD: This section introduces some more specific Template Withdrawal Message-related specifications compared to [RFC 5101] NEW: To take advantage of per-stream export, Exporting Processes should send Template Withdrawal Messages according to the specification in this section, in addition to Section 8, Template Management, of [RFC5101]. [As for 4 above.] 4.5 The Collecting Process's Side para 1 OLD: This section introduces some more specific specifications to the Collection Process compared to section 9 in [RFC5101]. However, the new specifications are backwards compatible with RFC5101- compliant Collecting Processes and are only needed to benefit from the advantages offered by the per-SCTP-stream extension. NEW: Collecting Processes must operate slightly contrary to [RFC5101] in order to realize the full benefits of per-stream export. However, the specification in this section contains a mechanism which allows per-stream-capable Collecting Processes to selectively enable per- stream export, in order to ensure interoperability of per-stream- capable Collecting Processes with Exporting Processes which do not implement per-stream export. [As for 4. Clarified that CPs need to interoperate with EPs, not "have backward compatibility" with other CPs.] A suggestion not strictly limited to applicability: 4.1 dataRecordsReliability Information Element [This information element is specified to only apply to Template ID scopes. Could it not also be scoped to other things (SCTP Stream ID, for instance) for a generalization of the approach? suggest the following:] OLD: dataRecordsReliability Description: The Data Records reliability associated with this Template ID. The true value means that the Data Records are sent reliably, while the false value means that the Data Records are not sent reliably. NEW: dataRecordsReliability Description: The Data Records reliability associated with the elements in the Options Template scope, usually a templateID. A true value means that the Data Records are sent reliably, while a false value means that the Data Records are not sent reliably. In addition, on review I found the following editorial issues: Subsections of 3, stylistic: The structure of this section reads a little like a sales pitch (with the subsubsections IPFIX limitations / perstream advantages per each subsection). Further, I don't actually think the split into subsubsections is necessary; the text flows fine without the headings. If you really want to keep the subsubsections, name the 3.x.1 "IPFIX Protocol Specification Limitations" for plurality agreement with 3.x.2. 3.2.1 Transmission Order within an SCTP Stream / IPFIX Protocol Specifications Limitation paragraph 1 OLD: The IPFIX protocol specification foresees: NEW: [RFC5101] specifies: 3.3.2 No Transmission Order across SCTP Streams / IPFIX Export Per SCTP Stream Advantages, general [This section should mention Options Templates, since 3.3.1 does.] 4.1 dataRecordsReliability [should have an IANA NOTE pointing out that IANA should change the xxx. They'll probably figure it out anyway but why not be helpful? :) ] Further, I suspect you'll get a Security question asking about what SCTP-RESET does to the SCTP-relevant bits of the 5101 security considerations, so a paragraph exploring the potential risks (and then, therefore, one hopes, dismissing them) would be useful here. hm. That seems to be about it (it was a little longer than I originally intended). Hope this helps. :) Cheers, Brian On Oct 26, 2009, at 6:00 PM, Internet-Drafts@ietf.org wrote: > 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 : IPFIX Export per SCTP Stream > Author(s) : B. Claise, P. Aitken, A. Johnson, G. Muenz > Filename : draft-ietf-ipfix-export-per-sctp-stream-04.txt > Pages : 22 > Date : 2009-10-26 > > This document specifies an extension to the specifications > in RFC5101, IP Flow Information Export (IPFIX), when using > the Partial Reliability extension of SCTP (PR-SCTP, Partial > Reliability Stream Control Transmission Protocol). > When implemented at both the Exporting and Collecting Processes, > this method offers several advantages such as the ability to > calculate Data Record losses for PR-SCTP, immediate export of > Template Withdrawal Messages, immediate reuse of Template IDs > within an SCTP stream, reduced likelihood of Data Record loss, > and reduced demands on the Collecting Process. When implemented > in only the Collecting or Exporting Process then normal IPFIX > behavior will be seen without these additional benefits. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-ipfix-export-per-sctp-stream-04.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. > _______________________________________________ > IPFIX mailing list > IPFIX@ietf.org > https://www.ietf.org/mailman/listinfo/ipfix From Quittek@nw.neclab.eu Thu Oct 29 08:09:46 2009 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 619DC3A69AB for ; Thu, 29 Oct 2009 08:09:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.531 X-Spam-Level: X-Spam-Status: No, score=-2.531 tagged_above=-999 required=5 tests=[AWL=0.068, 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 qk5kck1zTlXZ for ; Thu, 29 Oct 2009 08:09:45 -0700 (PDT) Received: from smtp0.neclab.eu (smtp0.neclab.eu [195.37.70.41]) by core3.amsl.com (Postfix) with ESMTP id BBAE93A698F for ; Thu, 29 Oct 2009 08:09:40 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp0.neclab.eu (Postfix) with ESMTP id ACE812C01918D for ; Thu, 29 Oct 2009 16:09:56 +0100 (CET) X-Virus-Scanned: Amavisd on Debian GNU/Linux (atlas2.office) Received: from smtp0.neclab.eu ([127.0.0.1]) by localhost (atlas2.office [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 122lzdtAnwXm for ; Thu, 29 Oct 2009 16:09:56 +0100 (CET) Received: from VENUS.office (mx1.office [192.168.24.3]) by smtp0.neclab.eu (Postfix) with ESMTP id 705F32C0002FC for ; Thu, 29 Oct 2009 16:09:51 +0100 (CET) Received: from VENUS.office ([192.168.24.102]) by VENUS.office with Microsoft SMTPSVC(6.0.3790.3959); Thu, 29 Oct 2009 16:09:52 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Received: from 10.7.0.54 ([10.7.0.54]) by VENUS.office ([192.168.24.102]) with Microsoft Exchange Server HTTP-DAV ; Thu, 29 Oct 2009 15:09:52 +0000 MIME-Version: 1.0 Content-class: urn:content-classes:message Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="B_3339670274_18052638" Date: Thu, 29 Oct 2009 16:09:52 +0100 Message-ID: In-Reply-To: X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: [OPS-AREA] OPS Area open office hours in Hiroshima thread-index: AcpXHQm+0Cafz0RVS+CiSZG/lC1u2QBfED3e From: "Juergen Quittek" To: "IETF IPFIX Working Group" X-OriginalArrivalTime: 29 Oct 2009 15:09:52.0184 (UTC) FILETIME=[DD783380:01CA58A9] Subject: [IPFIX] FW: [OPS-AREA] OPS Area open office hours in Hiroshima 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, 29 Oct 2009 15:09:46 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3339670274_18052638 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Dear all, This is FYI. Juergen ------ forwarded message Von: Dan Romascanu Datum: Tue, 27 Oct 2009 16:49:16 +0100 An: "OPS Area (E-mail)" , Betreff: [OPS-AREA] OPS Area open office hours in Hiroshima The OPS Area will hold the Open Office Hours at the Hiroshima IETF meeting on Thursday 11/12 between 15:00 and 16:30 in the IESG breakout room which is Room Castleview 2. Please join us for any OPS Area or IETF business issues that you would like to talk with us. OPS-CHAIRS - please distribute this message to your WG's. Thanks and Regards, Ron and Dan _______________________________________________ OPS-AREA mailing list OPS-AREA@ietf.org https://www.ietf.org/mailman/listinfo/ops-area ------ end of forwarded message --B_3339670274_18052638 Content-type: application/pkcs7-signature; name="smime.p7s" Content-transfer-encoding: base64 Content-disposition: attachment; filename="smime.p7s" MIIQ6gYJKoZIhvcNAQcCoIIQ2zCCENcCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC DpIwggU2MIIEHqADAgECAgQNLisHMA0GCSqGSIb3DQEBBQUAMIGQMQswCQYDVQQGEwJERTEY MBYGA1UEChMPTkVDIEV1cm9wZSBMdGQuMSAwHgYDVQQLExdORUMgTGFib3JhdG9yaWVzIEV1 cm9wZTESMBAGA1UEAxMJTkVDTEFCLUNBMTEwLwYJKoZIhvcNAQkBFiJ6ZXJ0aWZpemllcnVu Z3NzdGVsbGVAbncubmVjbGFiLmV1MB4XDTA4MTEwMzA3NTEyMFoXDTExMTEwMzA3NTEyMFow YzELMAkGA1UEBhMCREUxGDAWBgNVBAoTD05FQyBFdXJvcGUgTHRkLjEgMB4GA1UECxMXTkVD IExhYm9yYXRvcmllcyBFdXJvcGUxGDAWBgNVBAMTD0p1ZXJnZW4gUXVpdHRlazCCASIwDQYJ KoZIhvcNAQEBBQADggEPADCCAQoCggEBALYRfFB9x4h1YO6Mva6A5GCwKjwpgvzjiayFSmdD HwV8u5gHp3sHIhyVtxgMSifEp9AV+ChxWHS3KQwuQ3XhDAP/xDN6QSk4Bmqa6rCZuTJygxYh K39rNKd47ZfpuRC7j/Mbzwe9DTsbbBtpBgl5UKFc9c+zMbPlSwwlVbshWaUEoM6HoVFaDJdh tJBIpsblz1oQVKXDjxjGkUNh9Ds3m7BGXkr5yaGsEuEa0J/QAFdO+auvBJlAzIM0UwBAmlcT UHanS6Sdw5MkeutQqnmsUBtoenydq2Tmd9hfSfuTfiFuLmsvL3udH/jDAgQZ+PH6Mprqpyd3 wSycF/xZF5zz8X0CAwEAAaOCAcIwggG+MAkGA1UdEwQCMAAwCwYDVR0PBAQDAgXgMCkGA1Ud JQQiMCAGCCsGAQUFBwMCBggrBgEFBQcDBAYKKwYBBAGCNxQCAjAdBgNVHQ4EFgQUWQo3BPrO OLA4qljzDL1H8/6hIWEwHwYDVR0jBBgwFoAUTxyHeh3gL5n2vhWq0TWdDkrmujYwHwYDVR0R BBgwFoEUUXVpdHRla0Budy5uZWNsYWIuZXUwfQYDVR0fBHYwdDA4oDagNIYyaHR0cDovL2Nk cDEucGNhLmRmbi5kZS9uZWNsYWItY2EvcHViL2NybC9jYWNybC5jcmwwOKA2oDSGMmh0dHA6 Ly9jZHAyLnBjYS5kZm4uZGUvbmVjbGFiLWNhL3B1Yi9jcmwvY2FjcmwuY3JsMIGYBggrBgEF BQcBAQSBizCBiDBCBggrBgEFBQcwAoY2aHR0cDovL2NkcDEucGNhLmRmbi5kZS9uZWNsYWIt Y2EvcHViL2NhY2VydC9jYWNlcnQuY3J0MEIGCCsGAQUFBzAChjZodHRwOi8vY2RwMi5wY2Eu ZGZuLmRlL25lY2xhYi1jYS9wdWIvY2FjZXJ0L2NhY2VydC5jcnQwDQYJKoZIhvcNAQEFBQAD ggEBAB37+54yupDBTDpEMuyf+ouCRrOE3fPAD2SEGBXCpKTYteFkFSWvHlgN8ecRSma0Dz/5 QShzacGMeJ8o+XzVXHe2gtZbjzSVvJn+/nAKtKgDCzw0ltt3xkdMMv2ax6IKGR7BcccsXx7B R2PMaxdmHfCJseXiMzZO9QlWN2NZq2SSo3eGX/YDhHCWXDsoSu+uaKU/aRL2uZa92ptak2MA uKI5tylKLFZ3FHf08F8J+5tTaMGem6DfaMZR/9GZ8aRFJrdA7tzUAGKpl+CzRxsJVHbAAU5L hm5oTt6XYbh2G/cgdpeucsHJWBz9NQJrSrfWZYSwrv6AekMcvMi9X/CVZxEwggUvMIIEF6AD AgECAgQNIQpHMA0GCSqGSIb3DQEBBQUAMFoxCzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpERk4t VmVyZWluMRAwDgYDVQQLEwdERk4tUEtJMSQwIgYDVQQDExtERk4tVmVyZWluIFBDQSBHbG9i YWwgLSBHMDEwHhcNMDgxMDI0MDg1MjA4WhcNMTkwNjMwMDAwMDAwWjCBkDELMAkGA1UEBhMC REUxGDAWBgNVBAoTD05FQyBFdXJvcGUgTHRkLjEgMB4GA1UECxMXTkVDIExhYm9yYXRvcmll cyBFdXJvcGUxEjAQBgNVBAMTCU5FQ0xBQi1DQTExMC8GCSqGSIb3DQEJARYiemVydGlmaXpp ZXJ1bmdzc3RlbGxlQG53Lm5lY2xhYi5ldTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoC ggEBAJ7yFbG1EaoyDnG5367mJEXHljmacrzNnm52KW3dXD/s3Vpuskex0jvaaTntWWRSGrAK 6kKXnTxBb3J3EhveBUbltzQ+K0XKtPJm6VE5qVpl33WJSaUHs27Dhwlke+DV6BBGyukz2SDB aSa+nc0AwMZ0XO1DoDuiUNVeNmd/QT4SGzyFs+uLfLL2n8WzkZsbpSZ+xecwyw3EdQBBsp/i /W+uOQBsGqaCjYe3EkBU6nW+pBsj0Iy1n7b9PXb5gQynrK3Mi2V7g1idSzHos0o1BMoHUrMz Vw94Hj4CWlWmQ0t6Pdt1uYAMjwk0saQBY/Fyfv+wKeYycGIYyYCfJIRUeyUCAwEAAaOCAcQw ggHAMBIGA1UdEwEB/wQIMAYBAf8CAQEwCwYDVR0PBAQDAgEGMB0GA1UdDgQWBBRPHId6HeAv mfa+FarRNZ0OSua6NjAfBgNVHSMEGDAWgBRJt8bP6D0ff+pEexMp9/EKcD7eZDAtBgNVHREE JjAkgSJ6ZXJ0aWZpemllcnVuZ3NzdGVsbGVAbncubmVjbGFiLmV1MIGIBgNVHR8EgYAwfjA9 oDugOYY3aHR0cDovL2NkcDEucGNhLmRmbi5kZS9nbG9iYWwtcm9vdC1jYS9wdWIvY3JsL2Nh Y3JsLmNybDA9oDugOYY3aHR0cDovL2NkcDIucGNhLmRmbi5kZS9nbG9iYWwtcm9vdC1jYS9w dWIvY3JsL2NhY3JsLmNybDCBogYIKwYBBQUHAQEEgZUwgZIwRwYIKwYBBQUHMAKGO2h0dHA6 Ly9jZHAxLnBjYS5kZm4uZGUvZ2xvYmFsLXJvb3QtY2EvcHViL2NhY2VydC9jYWNlcnQuY3J0 MEcGCCsGAQUFBzAChjtodHRwOi8vY2RwMi5wY2EuZGZuLmRlL2dsb2JhbC1yb290LWNhL3B1 Yi9jYWNlcnQvY2FjZXJ0LmNydDANBgkqhkiG9w0BAQUFAAOCAQEAbDEPnQ9JpouPHYA1OEek P3l3GNM0HBzadVbtbN5MDtFmoVgdLYqlQaHb30wFhuOMbsNCOzV0k8EOvBVOT9BiEJ70RWcl SZQ460jZS2MY6n5oG/ilZuu6N/N3GSLg2pBBNH9vZFCyBJ9n4Px7A4gQF07G+CNfV2jdE1yy PjzIVPhg6bBgia8nXroBFe6oteavMspo0gLGIJ63NsCbl6ckPa96grT+mnnQD0h6jk/IGtXS 09mEWRbN7zZu0x0q+SScpljG36Q+jnG0U5zQI0jAx8CcYEQQH5QOlsw1Zu35OI4lsi7ycFkz JNfbfEC4ihuw9J2L43BFGMojkhPkhVExHTCCBCEwggMJoAMCAQICAgDHMA0GCSqGSIb3DQEB BQUAMHExCzAJBgNVBAYTAkRFMRwwGgYDVQQKExNEZXV0c2NoZSBUZWxla29tIEFHMR8wHQYD VQQLExZULVRlbGVTZWMgVHJ1c3QgQ2VudGVyMSMwIQYDVQQDExpEZXV0c2NoZSBUZWxla29t IFJvb3QgQ0EgMjAeFw0wNjEyMTkxMDI5MDBaFw0xOTA2MzAyMzU5MDBaMFoxCzAJBgNVBAYT AkRFMRMwEQYDVQQKEwpERk4tVmVyZWluMRAwDgYDVQQLEwdERk4tUEtJMSQwIgYDVQQDExtE Rk4tVmVyZWluIFBDQSBHbG9iYWwgLSBHMDEwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEK AoIBAQDpm8NnhfkNrvWNVMOWUDU9YuluTO2U1wBblSJ01CDrNI/W7MAxBAuZgeKmFNJSoCgj hIt0iQReW+DieMF4yxbLKDU5ey2QRdDtoAB6fL9KDhsAw4bpXCsxEXsM84IkQ4wcOItqaACa 7txPeKvSxhObdq3u3ibo7wGvdA/BCaL2a869080UME/15eOkyGKbghoDJzANAmVgTe3RCSMq ljVYJ9N2xnG2kB3E7f81hn1vM7PbD8URwoqDoZRdQWvY0hD1TP3KUazZve+Sg7va64sWVlZD z+HVEz2mHycwzUlU28kTNJpxdcVs6qcLmPkhnSevPqM5OUhqjK3JmfvDEvK9AgMBAAGjgdkw gdYwcAYDVR0fBGkwZzBloGOgYYZfaHR0cDovL3BraS50ZWxlc2VjLmRlL2NnaS1iaW4vc2Vy dmljZS9hZl9Eb3dubG9hZEFSTC5jcmw/LWNybF9mb3JtYXQ9WF81MDkmLWlzc3Vlcj1EVF9S T09UX0NBXzIwHQYDVR0OBBYEFEm3xs/oPR9/6kR7Eyn38QpwPt5kMB8GA1UdIwQYMBaAFDHD eRu69VPXF+CJei0XbAqzK50zMA4GA1UdDwEB/wQEAwIBBjASBgNVHRMBAf8ECDAGAQH/AgEC MA0GCSqGSIb3DQEBBQUAA4IBAQA74Vp3wEgX3KkY7IGvWonwvSiSpspZGBJw7Cjy565/lizn 8l0ZMfYTK3S9vYCyufdnyTmieTvhERHua3iRM347XyYndVNljjNj7s9zw7CSI0khUHUjoR8Y 4pSFPT8z6XcgjaK95qGFKUD2P3MyWA0Ja6bahWzAP7uNZmRWJE6uDT8yNQFb6YyC2XJZT7GG hfF0hVblw/hc843uR7NTBXDn5U2KaYMo4RMJhp5eyOpYHgwf+aTUWgRo/Sg+iwK2WLX2oSw3 VwBnqyNojWOl75lrXP1LVvarQIc01BGSbOyHxQoLBzNytG8MHVQs2FHHzL8w00Ny8TK/jM5J Y6gA9/IcMYICIDCCAhwCAQEwgZkwgZAxCzAJBgNVBAYTAkRFMRgwFgYDVQQKEw9ORUMgRXVy b3BlIEx0ZC4xIDAeBgNVBAsTF05FQyBMYWJvcmF0b3JpZXMgRXVyb3BlMRIwEAYDVQQDEwlO RUNMQUItQ0ExMTAvBgkqhkiG9w0BCQEWInplcnRpZml6aWVydW5nc3N0ZWxsZUBudy5uZWNs YWIuZXUCBA0uKwcwCQYFKw4DAhoFAKBdMCMGCSqGSIb3DQEJBDEWBBQ8GvWH2o3+B1QIRpsJ yQ1x5J7BnzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wOTEw MjkxMzExMTRaMA0GCSqGSIb3DQEBAQUABIIBAFhceMEqsbeD1kX4iaubGnMpggLiAO8kaqh7 QAqC5w4Cm5Mdv+8DWN7LTTtb+HLE/8NK7XCUujlo7k4bm0dKxIFjR7I/jcPLcDfnSHveYtXY zdVzz0cPd1ymJrWaiD9wVwVibbb8fYyf7Mr3wfx9iGG0+yk8atCaXueI8dSS6SnTKXRbFF4o WSbaEjNRgjUILqcuQjBMl8jXj2TRyUaytSADZkODH1OpomZ2N1RrJFby5fqZy1yBUeAuOurn Z56rr2vx5Tk/XIPMEMPShHrq2gz4fE+uQ86XIN072kSH3A+bew2BgQwWfRhimWWSzVY+Obf2 BKRncl67rZuzWh4ox8M= --B_3339670274_18052638-- From n.brownlee@auckland.ac.nz Thu Oct 29 13:30:57 2009 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 3BFD03A6A45 for ; Thu, 29 Oct 2009 13:30:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.339 X-Spam-Level: X-Spam-Status: No, score=-6.339 tagged_above=-999 required=5 tests=[AWL=0.260, 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 E1oE7blXg9e5 for ; Thu, 29 Oct 2009 13:30:51 -0700 (PDT) Received: from mailhost.auckland.ac.nz (curly.its.auckland.ac.nz [130.216.12.33]) by core3.amsl.com (Postfix) with ESMTP id 719243A6A3F for ; Thu, 29 Oct 2009 13:30:46 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mailhost.auckland.ac.nz (Postfix) with ESMTP id 424C89EB33 for ; Fri, 30 Oct 2009 09:30:28 +1300 (NZDT) X-Virus-Scanned: by amavisd-new at mailhost.auckland.ac.nz Received: from mailhost.auckland.ac.nz ([127.0.0.1]) by localhost (curly.its.auckland.ac.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oZYFbaosnUuL for ; Fri, 30 Oct 2009 09:30:28 +1300 (NZDT) Received: from nevil-laptop.sfac.auckland.ac.nz (nevil-laptop.sfac.auckland.ac.nz [130.216.38.130]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailhost.auckland.ac.nz (Postfix) with ESMTP id 164439EAE9 for ; Fri, 30 Oct 2009 09:30:27 +1300 (NZDT) Message-ID: <4AE9FB63.2010504@auckland.ac.nz> Date: Fri, 30 Oct 2009 09:30:27 +1300 From: Nevil Brownlee User-Agent: Thunderbird 2.0.0.12 (Macintosh/20080213) MIME-Version: 1.0 To: IPFIX Working Group Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [IPFIX] 2nd draft agenda for Hiroshima 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, 29 Oct 2009 20:30:57 -0000 Hi all: Here's the next draft of our agenda for the Hiroshima IETF. Anyone with further details to add, please email me so that I can update the agenda. Also, I'll put it on the IETF Agenda page. Cheers, Nevil -- --------------------------------------------------------------------- Nevil Brownlee Computer Science Department | ITS Phone: +64 9 373 7599 x88941 The University of Auckland FAX: +64 9 373 7453 Private Bag 92019, Auckland 1142, New Zealand ====================================================== Ip Flow Information Export WG (ipfix) IETF #76, Hiroshima Wednesday, 11 November 09 at 1300-1500 ====================================================== Chairs: Juergen Quittek Nevil Brownlee AGENDA: 1. Agenda review WG Status = 5 min 2. Update from last meeting = 5 min [New charter approved. IPFIX Information Elements Registry tidied up. Two RFCs published: File Format RFC 5655, and Exporting Type Info RFC 5610 (Erratum 1822: IEs Expert Review, not FCFS, correct in Registry) ] 3. Current WG drafts = 85 min a) MIB draft draft-ietf-ipfix-mib-08, 27 Oct 09 b) Config Data Model draft-ietf-ipfix-configuration-model-04, 23 Oct 09 c) SCTP per-stream draft (Benoit Claise) draft-ietf-ipfix-export-per-sctp-stream-04, 24 Oct 09 d) Mediators Problem Statement draft-ietf-ipfix-mediators-problem-statement-06, 16 Oct 09 Finished WGLC, ready to submit? e) Mediators Framework draft-ietf-ipfix-mediators-framework-04, 16 Oct 09 Ready for WGLC? f) Export of Structured Data in IPFIX (Benoit Claise) draft-ietf-ipfix-structured-data-00, 15 Oct 09 (Claise, Dhandapani , Yates & Aitken) g) Flow Selection Techniques draft-ietf-ipfix-flow-selection-tech-00, 18 Oct 09 (Peluso, Zseby. D'Antonio & Molina) h) IP Flow Anonymisation Support draft-ietf-ipfix-anon-00, 11 Oct 09 (Boschi & Trammel) 4. Other drafts = 20 min a) Link Layer Monitoring (Shingo Kasihma) draft-kashima-ipfix-data-link-layer-monitoring-00 b) Mediation Protocol (Benoit CLaise) draft-claise-ipfix-mediation-protocol-00.txt c) Wireless Sensor Monitoring (Corinna Schmitt) draft-schmitt-6lowapp-ipfix-ws-00.txt 5. Any Other Business = 5 min - Milestones Review Presentation slides will be available at https://datatracker.ietf.org/public/meeting_materials.cgi?meeting_num=76 (search for IPFIX in the Operations and Management Area) Participation via jabber is offered at ipfix@jabber.ietf.org ------------------ From muenz@net.in.tum.de Fri Oct 30 02:53:35 2009 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 B6E503A68CE for ; Fri, 30 Oct 2009 02:53:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.048 X-Spam-Level: X-Spam-Status: No, score=-3.048 tagged_above=-999 required=5 tests=[AWL=1.201, BAYES_00=-2.599, GB_I_LETTER=-2, 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 apQJCxJwa+Q1 for ; Fri, 30 Oct 2009 02:53:32 -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 03B683A681C for ; Fri, 30 Oct 2009 02:53:31 -0700 (PDT) Received: from phoenix.net.informatik.tu-muenchen.de (phoenix.net.in.tum.de [131.159.14.1]) by services.net.informatik.tu-muenchen.de (Postix Mailer @ mail) with ESMTP id 3ACCF4859E for ; Fri, 30 Oct 2009 10:53:36 +0100 (CET) Received: from [131.159.20.108] (repulse.net.in.tum.de [131.159.20.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by phoenix.net.informatik.tu-muenchen.de (Postfix) with ESMTP id 0880054F6 for ; Fri, 30 Oct 2009 10:53:36 +0100 (CET) Message-ID: <4AEAB7D3.9090608@net.in.tum.de> Date: Fri, 30 Oct 2009 10:54:27 +0100 From: Gerhard Muenz User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: IETF IPFIX Working Group References: In-Reply-To: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms010008080203020103000109" X-Virus-Scanned: ClamAV using ClamSMTP Subject: Re: [IPFIX] WG last call on draft-ietf-ipfix-mediators-problem-statement-06 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, 30 Oct 2009 09:53:35 -0000 This is a cryptographically signed message in MIME format. --------------ms010008080203020103000109 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Hi, Here is my review of draft-ietf-ipfix-mediators-problem-statement-06. The main content is ok. Some parts of the text still need revision. I'm not sure if we need to define Mediator types like IPFIX Proxy, IPFIX = Concentrator, IPFIX Distributor, IPFIX Masquerading Proxy in the=20 terminology section. Why not just talk about IPFIX Mediators? Regards, Gerhard > Abstract >=20 > Flow-based measurement is a popular method for various network > monitoring usages. The sharing of flow-based information for > monitoring applications having different requirements raises some > open issues in terms of measurement system scalability, flow-based > measurement flexibility, and export reliability that IPFIX Mediation= > may help resolve. This document describes the IPFIX Mediation > applicability examples, along with some problems that network > administrators have been facing. Shouldn't it be the other way round: - first problems - then applicability examples ? > 1. Introduction >=20 > One advantage of Flow-based measurement results from easily offering= > the traffic monitoring of a huge amount of traffic. While the usage= > is applied to any networks and to multiple measurement applications,= > network administrators need to optimize the resource of metering > devices and of multiple measurement applications. IP traffic growth= > and a wide variety of measurement application make the optimization > further difficult. To achieve system optimization, an intermediate > device can generally be applied to the system platform. Sorry, I can only guess what this paragraph is supposed to say. Please rewrite in a better understandable and readable way. BTW, I would be careful with terms like "optimize" and "optimization". > The IPFIX requirements defined in [RFC3917] mention examples of > intermediate devices, such as IPFIX Proxies or Concentrators, there missing conjunction, such as "but", "yet", or something like that The term "intermediate" or "intermediate device" does not appear in=20 RFC3917. So, explain why you call these devices like this. (For example, because they are located between Exporters and Collectors.)= > are no documents defining a generalized concept for such intermediat= e > devices. This document addresses that issue by defining IPFIX > Mediation, a generalized intermediate device concept for IPFIX, and > examining in detail the motivations behind its application. >=20 > This document is structured as follows: section 2 describes the > terminology used in this document, section 3 gives an IPFIX/PSAMP > document overview, section 4 introduces general problems related to > flow-based measurement, section 5 describes some applicability > examples where IPFIX Mediations would be beneficial, and, finally, > section 6 describes some problems an IPFIX Mediation implementation > might face. > 2. Terminology and Definitions >=20 > The IPFIX-specific and PSAMP-specific terminology used in this > document is defined in [RFC5101] and [RFC5476], respectively. In > this document, as in [RFC5101] and [RFC5476], the first letter of > each IPFIX-specific and PSAMP-specific term is capitalized along wit= h > the IPFIX Mediation-specific term defined here. >=20 > In this document, we use the generic term "record stream" to denote = a I would not call "record stream" a "term" unless it appears in the list=20 below with capitalized first letter. > set of flow- or packet-based data records with their additional I would not say that the records are flow-based or packet-based. They=20 contain flow or packet information. > information that flows from data sources, whether encoded in IPFIX > protocol as IPFIX Data Records, or non-IPFIX protocols. In IPFIX > protocol, we use the generic term Data Records for IPFIX Flow > Records, PSAMP Packet Reports, and Data Records defined by Options > Templates, unless an explicit distinction is required. Do we need the last sentence? > Original Exporter >=20 > An Original Exporter is an IPFIX Device that hosts the Observatio= n > Points where the metered IP packets are observed. >=20 > IPFIX Mediation >=20 > IPFIX Mediation is the manipulation and conversion of a record > stream for subsequent export using the IPFIX protocol. >=20 > The following terms are used in this document to describe the > architectural entities used by IPFIX Mediation. >=20 > Intermediate Process >=20 > An Intermediate Process takes a record stream as its input from > Collecting Processes, Metering Processes, IPFIX File Readers, > other Intermediate Processes, or other record sources; performs > some transformations on this stream, based upon the content of > each record, states maintained across multiple records, or other > data sources; and passes the transformed record stream as its > output to Exporting Processes, IPFIX File Writers, or other > Intermediate Processes, in order to perform IPFIX Mediation. > Typically, an Intermediate Process is hosted by an IPFIX Mediator= =2E > Alternatively, an Intermediate Process may be hosted by an > Original Exporter. >=20 > IPFIX Mediator >=20 > An IPFIX Mediator is an IPFIX Device that provides IPFIX Mediatio= n > by receiving a record stream from some data sources, hosting one > or more Intermediate Processes to transform that stream, and > exporting the transformed record stream into IPFIX Messages via a= n > Exporting Process. In the common case, an IPFIX Mediator receive= s > a record stream from a Collecting Process, but it could also > receive a record stream from data sources not encoded using IPFIX= , > e.g., in the case of conversion from the NetFlow V9 protocol > [RFC3954] to IPFIX protocol. >=20 > Specific types of IPFIX Mediators are defined below. >=20 > IPFIX Proxy >=20 > An IPFIX Proxy is an IPFIX Mediator that converts a record stream= > for the purpose of protocol conversion. >=20 > IPFIX Concentrator >=20 > An IPFIX Concentrator is an IPFIX Mediator that receives a record= > stream from one or more Exporters and performs correlation, > aggregation, and/or modification. >=20 > IPFIX Distributor >=20 > An IPFIX Distributor is an IPFIX Mediator that receives a record > stream from one or more Exporters and exports each record to one > or more Collectors, deciding to which Collector(s) to export each= > record depending on the decision of an Intermediate Process. >=20 > IPFIX Masquerading Proxy >=20 > An IPFIX Masquerading Proxy is an IPFIX Mediator that receives a > record stream from one or more Exporters to screen out parts of > records according to configured policies in order to protect the > privacy of the network's end users or to retain sensitive data of= > the exporting organization. Do we really need these four terms? I think that they can be removed. As Brian said, it is difficult to=20 classify IPFIX Mediators according to these types. All later occurrences of these terms can be replaced by "IPFIX Mediator".= > 4. Problem Statement >=20 > Network administrators generally face the problems of measurement > system scalability, flow-based measurement flexibility, and export > reliability, even if some techniques, such as Sampling, Filtering, > Data Records aggregation and export replication, have already been > developed. The problems consist of optimizing the resources of the How can you "optimize the resources"? > measurement system while fulfilling appropriate conditions: data > accuracy, flow granularity, and export reliability. These condition= s > depend on two factors. >=20 > o measurement system capacity: > This consists of the bandwidth of the management network, the > storage capacity, and the performances of the collecting devices > and exporting devices. >=20 > o application requirements: > Different applications, such as traffic engineering, detecting > traffic anomalies, and accounting, etc., impose different Flow remove "etc." > Record granularities, and data accuracies. >=20 > The sustained growth of IP traffic has been overwhelming the > measurement system capacities. Furthermore, a large variety of > applications (e.g., QoS measurement, traffic engineering, security > monitoring) and the deployment of measurement system in heterogeneou= s > environments have been increasing the demand and complexity of IP > traffic measurements. >=20 > 4.1. Coping with IP Traffic Growth >=20 > Enterprise or service provider networks already have multiple 10 Gb/= s > links, their total traffic exceeding 100 Gb/s. In the near future, > broadband users' traffic will increase by approximately 40% every > year according to [TRAFGRW]. When operators monitor traffic of 500 > Gb/s with a packet sampling rate of 1/1000, the amount of exported > Flow Records from Exporters could exceed 50 kFlows/s. This value is= > beyond the ability of a single Collector. This paragraph describes the situation today. Are we sure that these=20 numbers are still valid next year? Maybe we are then able to process=20 50kFlows/s. I would remove all these figures. > To deal with this problem, current data reduction techniques > (Sampling and Filtering in [RFC5475], and aggregation of measurement= "packet Sampling and Filtering"? > data) have been generally implemented on Exporters. Note that > Sampling technique leads to potential loss of small Flows. With bot= h "packet Sampling leads to..." > Sampling and aggregation techniques, administrators might no longer > be able to detect and investigate subtle traffic changes and > anomalies as this requires detailed Flow information. With > Filtering, only a subset of the Data Records are exported. >=20 > Considering the potential drawbacks of Sampling, Filtering, and Data= > Records aggregation, there is a need for a large-scale collecting > infrastructure that does not rely on data reduction techniques. Hm, I do not see this problem if a Collector receives data from a single = Exporter. You should say that these problems arise if multiple Exporters = send data to a single Collector. > 4.2. Coping with Multipurpose Traffic Measurement >=20 > Different monitoring applications impose different requirements on > the monitoring infrastructure. Some of them require traffic > monitoring at a Flow level while others need information about > individual packets or just Flow aggregates. >=20 > To fulfill these divers requirements, an Exporter would need to > perform various complex metering tasks in parallel, which is a > problem due to limited resources. Hence, it can be advantageous to > run the Exporter with a much simpler setup and to perform appropriat= e > post-processing of the exported Data Records at a later stage. >=20 > 4.3. Coping with Heterogeneous Environments >=20 > Network administrators use IPFIX Devices and PSAMP Devices from > various vendors, various software versions, various device types > (router, switch, or probe) in a single network domain. Even legacy > flow export protocols are still deployed in current network. This > heterogeneous environment leads to differences in Metering Process > capabilities, Exporting Process capacity (export rate, cache memory,= > etc.), and data format. For example, probes and switches cannot > retrieve some derived packet properties in [RFC5102] from a routing > table. remove "in [RFC5102]" > To deal with this problem, the measurement system needs to mediate > the differences. However, equipping all collecting devices with thi= s > absorption function is difficult. >=20 > 4.4. Summary >=20 > In optimizing the resources of a measurement system, it is important= I still do not understand what "optimize the resources" is supposed to me= an. > to use traffic data reduction techniques as early as possible, e.g.,= > at the Exporter. However, this implementation is made difficult by > heterogeneous environment of exporting devices. Please revise the entire paragraph above. It only talks about data=20 reduction. I do not think that this is the core of mediation. > This implies that a new Mediation function is required in typical > Exporter-Collector architectures. Based on some applicability > examples, the next section shows the limitation of the typical > Exporter-Collector architecture model and the IPFIX Mediation > benefits. > 5. Mediation Applicability Examples >=20 > 5.1. Adjusting Flow Granularity >=20 > A set of common properties of simplest Flow type is a fixed 5-tuple > of protocol, source and destination IP addresses, and source and As you talk about "Flow Keys", you should use this term and not invent a = new one! > destination port numbers. A shorter set of common properties, such > as a triple, a double, or a single property, (for example network > prefix, peering autonomous system number, or BGP Next-Hop fields), > creates more aggregated Flow Records. This is especially useful for= > measuring traffic exchange in an entire network domain and for easil= y What do you mean by "traffic exchange in an entire network domain"? > adjusting the performance of Exporters and Collectors. >=20 > Implementation analysis: >=20 > Implementations for this case depend on where Flow granularity is= > adjusted. More suitable implementations use configurable Meterin= g > Processes in Original Exporters. The cache in the Metering > Process can specify its own set of common properties (Flow Keys) > and extra fields. The Original Exporter thus creates directly > aggregated Flow Records. IMO, "aggregated Flow Record" is non-sense. If you look at the=20 definition of "Flow", you see that this is a normal Flow Record. I would say that the Original Exporter generates Flow Records of the=20 desired Flow granularity. > In the case where the Original Exporter contains a Metering > Process that creates fixed tuple Flow Records (no ability to Replace "fixed tuple Flow Records" by correct IPFIX language. > change the Flow Keys), or PSAMP Packet Reports, an IPFIX > Concentrator can aggregate Data Records based on a new set of Flo= w > Keys. Even in the case where the Original Exporter contains a > Metering Process for which the Flow Keys can be configured, an > IPFIX Concentrator can further aggregate the Flow Records. >=20 > 5.2. Hierarchical Collecting Infrastructure >=20 > The increase of IPFIX Exporters, the increase of the traffic, and th= e > variety of treatments expected to be performed over the Data Records= over =3D> on > is more and more difficult to handle within a single Collector. > Hence to increase the collecting (e.g., the bandwidth capacity) and > processing capacity, distributed Collectors must be deployed. As a > possible approach, a hierarchical structure is useful for increasing= I don't understand how the collecting and processing capacity increases=20 thanks to a hierarchical structure. The capacity increases because I implement more resources in the=20 network, e.g. more Collectors. > the measurement systems capacity, both in export bandwidth capacity > and in collecting capacity. >=20 > Implementation analysis: >=20 > To cope with the increase of IPFIX Exporters and traffic, one "number of IPFIX Exporters" (only IPFIX?) > possible implementation uses IPFIX Concentrators to build a > hierarchical collection system. To cope with the variety of > treatments, one possible implementation uses IPFIX Distributors t= o > build a distributed collection system. More specific cases are > described in section 5.9. > 5.3. Correlation for Data Records >=20 > The correlation amongst Data Records or between Data Record and meta= > data provides new metrics or information, including the following. >=20 > o One-to-one correlation between Data Records >=20 > * One way delay from the correlation of PSAMP Packet Reports fro= m > different Exporters along a specific path, packet inter-arriva= l > time, etc. "packet inter-arrival times from the correlation of PSAMP Packet Reports = generated by a single Exporter, etc." > * Treatment from the correlation of Data Records with the common= remove "the" in front of "common" > properties, observed at incoming/outgoing interfaces. Example= s > are the rate-limiting ratio, the compression ratio, the > optimization ratio, etc. >=20 > o Correlation amongst Data Records >=20 > Average/maximum/minimum values from correlating multiple Data > Records. Examples are the average/maximum/minimum number of > packets of the measured Flows, the average/maximum/minimum one wa= y > delay, the average/maximum/minimum number of lost packets, etc. >=20 > o Correlation between Data Record and other meta data >=20 > Examples are some BGP attributes associated with Data Record by > looking up the routing table. >=20 > Implementation analysis: >=20 > One possible implementation for this case uses an IPFIX > Concentrator located between the Metering Processes and Exporting= IPFIX Concentrator =3D> Intermediate Process > Processes on the Original Exporter, or alternatively a separate > IPFIX Concentrator located between the Original Exporters and > IPFIX Collectors. >=20 > 5.4. Time Composition >=20 > Time composition is defined as the aggregation of consecutive Data > Records with common properties. It leads to the same output as applies to Flow Records only? common properties =3D> Flow Keys? > setting a longer active interval timer on Original Exporters with on= e active timeouts? > advantage: the creation of new metrics such as average, maximum and > minimum values from Flow Records with a shorter time interval enable= s > administrators to keep track of changes that might have happened > during the time interval. Hm, changes can be much better detected by looking at the short-lived=20 values directly instead of looking at the long-term average, maximum, or = minimum. >=20 > Implementation analysis: >=20 > One possible implementation for this case uses an IPFIX > Concentrator located between the Metering Processes and Exporting= Intermediate Process > Processes on the Original Exporter, or alternatively a separate > IPFIX Concentrator located between the Original Exporters and > IPFIX Collectors. >=20 > 5.5. Spatial Composition >=20 > Spatial composition is defined as the aggregation of Data Records in= > a set of Observation Points within an Observation Domain, across > multiple Observation Domains from a single Exporter, or even across > multiple Exporters. The spatial composition is divided into four > types. >=20 > o Case 1: Spatial Composition within one Observation Domain >=20 > For example, in the case where a link aggregation exists, Data remove "a" > Records metered at physical interfaces belonging to the same trun= k > can be merged. >=20 > o Case 2: Spatial Composition across Observation Domains, but withi= n > a single Exporter Original Exporter? > For example, in the case where a link aggregation exists, Data remove "a" > Records metered at physical interfaces belonging to a same trunk > grouping beyond the line interface module can be merged. "line card"? >=20 > o Case 3: Spatial Composition across Exporters >=20 > Data Records metered within an administrative domain, such as the= > west area and east area of an ISP network, can be merged. >=20 > o Case 4: Spatial Composition across administrative domains >=20 > Data Records metered across administrative domains, such as acros= s > different customer networks or different ISP networks, can be > merged. Are more cases thinkable? If yes, I would call the above "cases" "examples". > Implementation analysis: >=20 > One possible implementation for the cases 1 and 2 uses an IPFIX > Concentrator located between the Metering Processes and Exporting= Intermediate Process > Processes on the Original Exporter. A separate IPFIX Concentrato= r > located between the Original Exporters and IPFIX Collector is a > valid solution for the cases 1, 2, 3, and 4. >=20 >=20 > 5.6. Data Record Anonymization >=20 > IPFIX exports across administrative domains can be used to measure > traffic for wide-area traffic engineering or to analyze Internet > traffic trends, as described in the spatial composition across > administrative domains in the previous subsection. > In such a case, administrators need to adhere to privacy protection > policies and prevent access to confidential traffic measurements by > other people. Typically, anonymization techniques enables the enable > provision of traffic data to other people without violating these > policies. >=20 > Generally, anonymization modifies a data set to protect the identity= > of the people or entities described by the data set from being > disclosed. It also attempts to preserve sets of network traffic > properties useful for a given analysis while ensuring the data canno= t > be traced back to the specific networks, hosts, or users generating > the traffic. For example, IP address anonymization is particularly > important for avoiding the identification of the users, hosts, and remove second "the" > routers. As another example, when ISP provides a traffic monitoring= an ISP > service to end customers by their own Exporters, even in case of > exporting interface index fields, network administrators take care o= f > anonymizing its fields to avoid disclosing the vulnerability. Why does an interface represent a vulnerability? > Implementation analysis: >=20 > One possible implementation for this case uses an anonymization > function at the Original Exporter. However, this increases the > load on the Original Exporter. A more flexible implementation > uses a separate IPFIX Masquerading Proxy between the Original > Exporter and Collector. > 5.10. Flow-based Sampling and Selection >=20 > Generally, the distribution of the number of packets per Flow seems > to be heavy-tailed. Most types of Flow Records are likely to be > small Flows consisting of a small number of packets. The measuremen= t > system is overwhelmed with a huge amount of these small Flows. If > statistics information of small Flows is exported as merged data by > applying a policy or threshold, the load on the Exporter is reduced.= > Furthermore, if the flow distribution is known, exporting only a > subset of the Data Records might be sufficient. >=20 > Implementation analysis: >=20 > One possible implementation for this case uses an IPFIX > Concentrator located between the Metering Processes and Exporting= Intermediate Process > Processes on the Original Exporter, or alternatively a separate > IPFIX Concentrator located between the Original Exporters and > IPFIX Collectors. A set of IPFIX Mediation functions, such as > filtering, selecting and aggregation is used in the IPFIX > Concentrator. > 6. IPFIX Mediators Implementation Specific Problems >=20 > 6.1. Loss of Original Exporter Information >=20 > Both the Exporter IP address indicated by the source IP address of > the IPFIX Transport Session and the Observation Domain ID included i= n > the IPFIX Message header are likely to be lost during IPFIX > Mediation. In some cases, a IPFIX Masquerading Proxy might drop the= a =3D> an > information deliberately. In general, however, the Collector must > recognize the origin of the measurement information, such as the IP > address of the Original Exporter, the Observation Domain ID, or even= > the Observation Point ID. Note that, if an IPFIX Mediator can not cannot > communicate the Original Exporter IP address, then the IPFIX > Collector will wrongly deduce that the IP address of the IPFIX > Mediator is that of the Original Exporter. >=20 > In the following figure, a Collector can identify two IP addresses: > 10.1.1.3 (IPFIX Mediator) and 10.1.1.2 (Exporter#2), respectively. > The Collector, however, needs to somehow recognize both Exporter#1 > and Exporter#2, which are the Original Exporters. The IPFIX Mediato= r > must be able to notify the Collector about the IP address of the > Original Exporter. >=20 > .----------. .--------. > |IPFIX | |IPFIX | > |Exporter#1|--------->|Mediator|---+ > | | | | | > '----------' '--------' | .---------. > IP:10.1.1.1 IP:10.1.1.3 '----->|IPFIX | > ODID:10 ODID:0 |Collector| > +----->| | > .----------. | '---------' > |IPFIX | | > |Exporter#2|-----------------------' > | | > '----------' > IP:10.1.1.2 > ODID:20 >=20 > Figure B: Loss of Original Exporter Information. >=20 > 6.2. Loss of Base Time Information >=20 > The Export Time field included in the IPFIX Message header represent= s > a reference timestamp for Data Records. Some IPFIX Information > Elements, described in [RFC5102], carry delta timestamps that > indicate the time difference from the value of the Export Time field= =2E > If the Data Records include any delta time fields and the IPFIX > Mediator overwrites the Export Time field when sending IPFIX > Messages, the delta time fields become meaningless and, because > Collectors cannot recognize this situation, wrong time values are > propagated. >=20 > 6.3. Transport Sessions Management >=20 > Maintaining relationships between the incoming Transport Sessions an= d > the outgoing ones depends on the Mediator's implementation. If an > IPFIX Mediator relays multiple incoming Transport Sessions to a > single outgoing Transport Session, and if the IPFIX Mediators shuts > down its outgoing Transport Session, Data Records of the incoming > Transport Sessions would not be relayed any more. In the case of > resetting an incoming session, the behavior of the IPFIX Mediator Transport Session > needs to be specified. > 6.7. Exporting the Function Item >=20 > In some case, the IPFIX Collector needs to recognize which specific > function(s) the IPFIX Mediation has executed on the Data Records. remove first "the" > The IPFIX Collector cannot distinguish between time composition, > spatial composition, and Flow Key aggregation, if the IPFIX Mediator= What is "Flow Key aggregation"? Is this a good expression? Usually, some Flow Key fields are just dropped or replaced by non-key=20 fields. > does not export the applied function. Some parameters related to th= e > function also would need to be exported. For example, in case of > time composition, the active time of original Flow Records is "active timeout"? > required to interpret the minimum/maximum counter correctly. In cas= e > of spatial composition, spatial area information on which Data > Records is aggregated is required. >=20 > 6.8. Consideration for Aggregation >=20 > Whether the aggregation is based on time or spatial composition, > caution should be taken on how to aggregate non-key fields in IPFIX > Mediation. The IPFIX information model [RFC5102] specifies that the= > value of non-key fields, which are derived from fields of packets or= > from packet treatment and for which the value may change from packet= > to packet within a single Flow, is determined by the first packet > observed for the corresponding Flow, unless the description of the > Information Element explicitly specifies a different semantics. >=20 > However, this simple rule might not be appropriate when aggregating > Flow Records which have different values in a non-key field. For > example, if two Flows with identical Flow Key values are measured at= > different Observation Points, they may contain identical packets > observed at different locations in the network and at different > points in time. On their way from the first to the second > Observation Point, some of the packet fields, such as the DSCP, may > have changed. Hence, if the Information Element ipDiffServCodePoint= > is included as a non-key field, it can be useful to include the DSCP= > value observed at either the first or the second Observation Point i= n > the resulting Flow Record, depending on the application. >=20 > Other potential solutions include: removing the Information Element > ipDiffServCodePoint from the Data Record when re-exporting the > aggregate Flow Record, changing the Information Element > ipDiffServCodePoint from a non key-field to a Flow Key when re- > exporting the aggregated Flow Record, or assigning a non valid value= > for the Information Element to express to the Collector that this > Information Element is meaningless. >=20 > Furthermore, rules must be specify on how to aggregate the new > Configured Selection Fraction an IPFIX Mediator should report when What about: "If packet Sampling or Filtering is applied, the IPFIX Mediator must=20 report an adjusted PSAMP Configured Selection Fraction when aggregating..= =2E" > aggregating IPFIX Flow Records with different sampling rates. > Finally, special care must be taken when aggregating Flow Records > resulting from different Sampling techniques such as Systematic > Count-Based Sampling and Random n-out-of-N Sampling for example. >=20 >=20 > 7. Summary and Conclusion >=20 > This document described the problems that network administrators hav= e > been facing, the applicability of IPFIX Mediation to these problems,= > and the problems related to the implementation of IPFIX Mediators. > To assist the operations of the Exporters and Collectors, there are > various IPFIX Mediations from which the administrators may select. > Examples of the applicability of IPFIX Mediation are as follows. >=20 > o Regarding large-scale measurement system, IPFIX Concentrators or > IPFIX Distributors help to achieve traffic analysis with high dat= a > accuracy and fine flow granularity even as IP traffic grows. As > IPFIX Mediation capabilities, Flow sampling, aggregation, and > composition are effective. Sampling and aggregation reduce the accuracy or granularity. Correlation seems to be appropriate. > o Regarding data retention, IPFIX Mediators enhance the export > reliability, and the storage of the measurement system. >=20 > o Regarding the distribution of Data Records, IPFIX Distributors > help to achieve multipurpose traffic analysis for different > organizations, or help to achieve respective traffic analysis remove "respective"? > based on Data Record types(IPv4, IPv6, MPLS, and VPN). >=20 > o Regarding the IPFIX export across domains, IPFIX Masquerading > Proxies help administrators to anonymize or filter Data Records, > preventing privacy violations. >=20 > o Regarding interoperability, IPFIX Proxies provide interoperabilit= y > between legacy protocols and IPFIX, even during the migration even =3D> for example > period to IPFIX. >=20 > As a result, the IPFIX Mediation benefits become apparent. However,= > there are still some open issues with the use of IPFIX Mediators. >=20 > o Both Observation Point and IPFIX Message header information, such= > as the Exporter IP address, Observation Domain ID, and Export Tim= e > field, might be lost. This data should therefore be communicated= > between the Original Exporter and Collector via the IPFIX > Mediator. >=20 > o IPFIX Mediators are required to manage Transport Sessions, > Template IDs, and Observation Domain IDs. Otherwise, anomalous > IPFIX Messages could be created. >=20 > o Data Records defined by Options Templates, such as those reportin= g > the Sampling rate and Sampling algorithm used, might be lost > during IPFIX Mediation. If a Collector is not informed of curren= t > Sampling rates, traffic information might become worthless. >=20 > These problems stem from the fact that no standards regarding IPFIX > Mediation have been set. In particular, the minimum set of > information that should be communicated between Original Exporters > and Collectors, the management between different IPFIX Transport > Sessions, and the internal components of IPFIX Mediators should be > standardized. There is a lot of repetition in this section. > 8. Security Considerations >=20 > A flow-based measurement system must prevent potential security > threats: the disclosure of confidential traffic data, injection of > incorrect data, and unauthorized access to traffic data. These > security threats of the IPFIX protocol are covered by the security > considerations section in [RFC5101] and are still valid for IPFIX > Mediators. >=20 > And a measurement system must also prevent the following security remove "And" > threats related to IPFIX Mediation: >=20 > o Attacks against IPFIX Mediator >=20 > IPFIX Mediators can be considered as a prime target for attacks, > as an alternative to IPFIX Exporters and Collectors. IPFIX > Proxies or Masquerading Proxies need to prevent unauthorized > access or denial-of-service (DoS) attacks from untrusted public > networks. >=20 > o Man-in-the-middle attack by untrusted IPFIX Mediator >=20 > The Exporter-Mediator-Collector structure model would increase th= e > risk of the man-in-the-middle attack. "would increase the risk of..." =3D> "could be misused for=20 man-in-the-middle attacks" > o Configuration on IPFIX Mediation >=20 > In the case of IPFIX Distributors and IPFIX Masquerading Proxies,= > an accidental misconfiguration and unauthorized access to > configuration data could lead to the crucial problem of disclosur= e > of confidential traffic data. --=20 Dipl.-Ing. Gerhard M=FCnz Chair for Network Architectures and Services (I8) Technische Universit=E4t M=FCnchen - Department of Informatics Boltzmannstr. 3, 85748 Garching bei M=FCnchen, Germany Phone: +49 89 289-18008 Fax: +49 89 289-18033 E-mail: muenz@net.in.tum.de WWW: http://www.net.in.tum.de/~muenz --------------ms010008080203020103000109 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJ6TCC Az8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJBgNVBAYTAlpBMRUwEwYDVQQI EwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgGA1UEChMRVGhhd3RlIENv bnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMgRGl2aXNpb24xJDAi BgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3DQEJARYccGVy c29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3MTYyMzU5 NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBM dGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzAN BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9Vvy Gna9fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOC dz0Dviv+uxg+B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCB kTASBgNVHRMBAf8ECDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhh d3RlLmNvbS9UaGF3dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIBBjApBgNV HREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEFBQAD gYEASIzRUIPqCy7MDaNmrGcPf6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFi w9k6GX6EsZkbAMUaC4J0niVQlGLH2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpb NU1341YheILcIRk13iSx0x1G/11fZU8wggNPMIICuKADAgECAhAqxerdN2XVRkUZsuk5IKdP MA0GCSqGSIb3DQEBBQUAMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3Vs dGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNz dWluZyBDQTAeFw0wOTAyMTkxMDI5NDVaFw0xMDAyMTkxMDI5NDVaMIGQMQ4wDAYDVQQEEwVN dWVuejEQMA4GA1UEKhMHR2VyaGFyZDEWMBQGA1UEAxMNR2VyaGFyZCBNdWVuejEwMC4GCSqG SIb3DQEJARYhbXVlbnpAaW5mb3JtYXRpay51bmktdHVlYmluZ2VuLmRlMSIwIAYJKoZIhvcN AQkBFhNtdWVuekBuZXQuaW4udHVtLmRlMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKC AQEAxC8p+6KRpyQyKvT9LAxUB2m8azrci+c5oQUYac2A4WsjoqiCqi2k/wgCrCIHrN0USQeH LmcbtSWT5O+1kMai28KGUdZG5xmJ7PLuLejKlYIu2TkR8tI1Q4gyu1Gs45yn9Rf+EGWmqa/s ebjMV3tc/zrpEN2b1ls8U9rM2/h0NcUUU+g170e8DlXNOL7+bsQD+tLH5G3nlV9mZntMQ68t PaaLG4MtupHuS99YGoo0yB4rzuTxiWRKTJgqjboQL0eS9+6dxsrT01g7sOc2QtXbO45PBnsG Ra5CAMpGLrqGT1ISZIpqYrGuMH9Rv7HTR3rLygL81WMDtNCa6W5/PPMlSwIDAQABo1MwUTBB BgNVHREEOjA4gSFtdWVuekBpbmZvcm1hdGlrLnVuaS10dWViaW5nZW4uZGWBE211ZW56QG5l dC5pbi50dW0uZGUwDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUFAAOBgQBOkMsohjpIH4Mr 33zNnhc5PkzAi0RZ6UAOB28nTtfjVZ25UVLWqmLgYEszbloTd07y5PcUZhSuPuwGzEwn4XdX i3VWl6qk5VcPpyP7+b5XEY5CU1A8cqeaXS88qWyshu1dXm2ToqueRPv+E2b3GJHAciNt2Qfc T4SNWymkvUyPSjCCA08wggK4oAMCAQICECrF6t03ZdVGRRmy6Tkgp08wDQYJKoZIhvcNAQEF BQAwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0 ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA5 MDIxOTEwMjk0NVoXDTEwMDIxOTEwMjk0NVowgZAxDjAMBgNVBAQTBU11ZW56MRAwDgYDVQQq EwdHZXJoYXJkMRYwFAYDVQQDEw1HZXJoYXJkIE11ZW56MTAwLgYJKoZIhvcNAQkBFiFtdWVu ekBpbmZvcm1hdGlrLnVuaS10dWViaW5nZW4uZGUxIjAgBgkqhkiG9w0BCQEWE211ZW56QG5l dC5pbi50dW0uZGUwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDELyn7opGnJDIq 9P0sDFQHabxrOtyL5zmhBRhpzYDhayOiqIKqLaT/CAKsIges3RRJB4cuZxu1JZPk77WQxqLb woZR1kbnGYns8u4t6MqVgi7ZORHy0jVDiDK7UazjnKf1F/4QZaapr+x5uMxXe1z/OukQ3ZvW WzxT2szb+HQ1xRRT6DXvR7wOVc04vv5uxAP60sfkbeeVX2Zme0xDry09posbgy26ke5L31ga ijTIHivO5PGJZEpMmCqNuhAvR5L37p3GytPTWDuw5zZC1ds7jk8GewZFrkIAykYuuoZPUhJk impisa4wf1G/sdNHesvKAvzVYwO00Jrpbn888yVLAgMBAAGjUzBRMEEGA1UdEQQ6MDiBIW11 ZW56QGluZm9ybWF0aWsudW5pLXR1ZWJpbmdlbi5kZYETbXVlbnpAbmV0LmluLnR1bS5kZTAM BgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBQUAA4GBAE6QyyiGOkgfgyvffM2eFzk+TMCLRFnp QA4HbydO1+NVnblRUtaqYuBgSzNuWhN3TvLk9xRmFK4+7AbMTCfhd1eLdVaXqqTlVw+nI/v5 vlcRjkJTUDxyp5pdLzypbKyG7V1ebZOiq55E+/4TZvcYkcByI23ZB9xPhI1bKaS9TI9KMYID cTCCA20CAQEwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcg KFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3Vpbmcg Q0ECECrF6t03ZdVGRRmy6Tkgp08wCQYFKw4DAhoFAKCCAdAwGAYJKoZIhvcNAQkDMQsGCSqG SIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDkxMDMwMDk1NDI3WjAjBgkqhkiG9w0BCQQxFgQU ++DHxYdT9OElrTSxovQ0KhjGSs0wXwYJKoZIhvcNAQkPMVIwUDALBglghkgBZQMEAQIwCgYI KoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqG SIb3DQMCAgEoMIGFBgkrBgEEAYI3EAQxeDB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxU aGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwg RnJlZW1haWwgSXNzdWluZyBDQQIQKsXq3Tdl1UZFGbLpOSCnTzCBhwYLKoZIhvcNAQkQAgsx eKB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBM dGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQKsXq 3Tdl1UZFGbLpOSCnTzANBgkqhkiG9w0BAQEFAASCAQAzl+kmK86ki4JKulc9WG2KxDSjM9Oo MrQxgqP7qXpIr+MVH1+IAWe84/3ASB2dMHaxWAYRoN0FjSfdW5iwk4U2abBzPsj+OZP/kQE6 s4HImEC7ikHJtNAxA5UzR2n/vZ5WIQD5bGhOCvNf+xnyW1pYLBswv9BDqztHRLAqT7aFCXAe KciNr/lAhYGnUH2pEak59GDUzzdpdkYBuht3tgFT2NMDl8a+LSmEVx9z/gzgHZHTue+x7dZ7 6DdsIsU9+pi4FRbCzWbS1yQBe67jdqkoBdVRJHYDVW7rvbpcw5GQGvG6cXRDPHEZvvxv2crP zKyvNciKJMIVY/A8JX9pbQPMAAAAAAAA --------------ms010008080203020103000109-- From bclaise@cisco.com Fri Oct 30 03:39:17 2009 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 82F213A659B for ; Fri, 30 Oct 2009 03:39:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.435 X-Spam-Level: X-Spam-Status: No, score=-2.435 tagged_above=-999 required=5 tests=[AWL=0.163, 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 bE2+A0A-4SiK for ; Fri, 30 Oct 2009 03:39:15 -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 BE8A93A69DA for ; Fri, 30 Oct 2009 03:39:14 -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 n9UAGSNU021477; Fri, 30 Oct 2009 11:16:29 +0100 (CET) Received: from [10.55.43.53] (ams-bclaise-8714.cisco.com [10.55.43.53]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id n9UAGRKB014600; Fri, 30 Oct 2009 11:16:27 +0100 (CET) Message-ID: <4AEABCFB.70505@cisco.com> Date: Fri, 30 Oct 2009 11:16:27 +0100 From: Benoit Claise User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Brian Trammell References: <7A07131A-78E8-44DA-85A7-FF7D839A6AA8@tik.ee.ethz.ch> In-Reply-To: <7A07131A-78E8-44DA-85A7-FF7D839A6AA8@tik.ee.ethz.ch> Content-Type: multipart/alternative; boundary="------------060908050507040601060102" Cc: ipfix@ietf.org Subject: Re: [IPFIX] Fwd: I-D ACTION:draft-ietf-ipfix-export-per-sctp-stream-04.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: Fri, 30 Oct 2009 10:39:17 -0000 This is a multi-part message in MIME format. --------------060908050507040601060102 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Brian, > Hi, Benoit, all, > > I have a few comments on the -04 perstream draft. > > In general the quality of the draft has improved greatly. I'm quite > happy with the detail in section 4.5 for guaranteeing interoperability > while still allowing CPs to get the benefits of per-stream, which was > my main issue with the previous revision. I notice too the Intended > Status is now Standards Track. I presume that this Standards Track > designation is equivalent to that of e.g. 5103 (Biflow): this is an > optional specification with specific applicability; Exactly. > otherwise, it's still fine IMO as Informational, but then you have to > ditch all the 2119 language. I think it was the appearance of 2119 > language in an Informational draft that made the IESG suggest > Standards Track; Exactly. The following email was the start of this discussion, along with the "Stream Control Transmission Protocol (SCTP) Stream Reconfiguration" draft that became a working group document. -------- Original Message -------- Subject: DISCUSS: draft-ietf-ipfix-export-per-sctp-stream Date: Sat, 8 Aug 2009 07:55:58 -0700 (PDT) From: Alexey Melnikov To: iesg@ietf.org CC: ipfix-chairs@tools.ietf.org, draft-ietf-ipfix-export-per-sctp-stream@tools.ietf.org Discuss: I have 2 relatively minor issues with the document: 1). DISCUSS DISCUSS: Why is this document says "Intended Status: Informational"? It looks fairly normative to me. ... > see 5473 for an example of how to describe a mechanism with specific > applicability in a non-normative way. Of course, then there's the > problem with an Informative RFC contradicting a Standards Track one > (5101), necessary for the CP to realize the perstream advantages... In > any case, I'm not convinced the discussion is complete on this point. I agree that at this point, the situation is a little bit unclear. I applied the discussed/proposed solution. However, the formal decision from the WG/Chair/Area Director would be welcome. > > Presuming we're talking about a restricted-applicability Standards > Track draft, the applicability of the draft is now clearer in previous > versions, but I would still suggest certain changes to the language in > order to avoid confusion on this point, as follows. > > 2.2 Applicability para 1 > > OLD: The specifications are required in cases where we must know how > many data records of a certain type... > > NEW: The specifications contained in this document are applicable to > cases where application requirements include knowing how many data > records of a certain type... > > [Yes, I know that required isn't a REQUIRED, but I want implementors > to be sure they don't have to do perstream if they're not splitting > templates by app; I believe the suggested text clarifies this point] > > > 2.2 Applicability para 3 > > OLD: However, in order to benefit from the advantages, the Collecting > Process specified in [RFC5101] must implement some additional > specifications that this document introduces. > > NEW: However, Collecting Processes may implement additional support > for per-stream export specified in this document in order to realize > all the benefits of the approach specified herein. > > [Same thing. Make it clear we're not updating 5101.] > > > 3.2.1 Transmission Order within an SCTP Stream / IPFIX Protocol > Specifications Limitation paragraph 5 > > DELETE: In practice, Data Records without associated (Options) > template records will most likely be discarded by the Collecting Process. > > [Maybe true. Probably, even. Appropriate for an Informational draft or > an implementation report. But this comes too close to contradicting a > MAY in 5101 to be appropriate for a Standards Track draft.] > > > 4. Specifications para 1 > > OLD: This section introduces improvements compared to the IPFIX > specifications in [RFC5101]. > > NEW: This section specifies Exporting Process and Collecting Process > behavior different from that in [RFC5101] in order to realize the > benefits of per-stream export. Note that Exporting Processes following > these Specifications will interoperate with [RFC5101]-compliant > Collecting Processes, but that Collecting Processes will have to > follow additional non-interoperable specifications to realize the full > benefits of the technique. > > [The current text does not take applicability under consideration.] > > > 4.2 Template Management para 1 > > OLD: This section introduces some additional specifications compared > to the Template Management section 8 in [RFC 5101] > > NEW: To take advantage of per-stream export, Exporting Processes > should follow the specification in this section in addition to Section > 8, Template Management, of [RFC5101]. > > [As for 4 above.] > > > 4.3 SCTP para 1 > > OLD: This section introduces some more specific specifications > compared to the SCTP section 10.2 in [RFC 5101], in particular the > "Stream" section 10.2.4.3. > > NEW: To take advantage of per-stream export, Exporting Processes > should manage SCTP streams according to the specification in this > section, in addition to Section 10.2.4.3, Stream, of [RFC5101]. > > [As for 4 above.] > > > 4.4 Template Withdrawal Message para 1 > > OLD: This section introduces some more specific Template Withdrawal > Message-related specifications compared to [RFC 5101] > > NEW: To take advantage of per-stream export, Exporting Processes > should send Template Withdrawal Messages according to the > specification in this section, in addition to Section 8, Template > Management, of [RFC5101]. > > [As for 4 above.] > > > 4.5 The Collecting Process's Side para 1 > > OLD: This section introduces some more specific specifications to the > Collection Process compared to section 9 in [RFC5101]. However, the > new specifications are backwards compatible with RFC5101- compliant > Collecting Processes and are only needed to benefit from the > advantages offered by the per-SCTP-stream extension. > > NEW: Collecting Processes must operate slightly contrary to [RFC5101] > in order to realize the full benefits of per-stream export. However, > the specification in this section contains a mechanism which allows > per-stream-capable Collecting Processes to selectively enable > per-stream export, in order to ensure interoperability of > per-stream-capable Collecting Processes with Exporting Processes which > do not implement per-stream export. > > [As for 4. Clarified that CPs need to interoperate with EPs, not "have > backward compatibility" with other CPs.] All your new proposals above make perfect sense. > > > A suggestion not strictly limited to applicability: > > > 4.1 dataRecordsReliability Information Element > > [This information element is specified to only apply to Template ID > scopes. Could it not also be scoped to other things (SCTP Stream ID, > for instance) for a generalization of the approach? suggest the > following:] > > OLD: > dataRecordsReliability > > Description: > The Data Records reliability associated with this > Template ID. The true value means that the Data Records > are sent reliably, while the false value means that the > Data Records are not sent reliably. > > NEW: > dataRecordsReliability > > Description: > > The Data Records reliability associated with the elements in > the Options Template scope, usually a templateID. A true value > means that the Data Records are sent reliably, while a false value > means that the Data Records are not sent reliably. Great suggestion. > > > In addition, on review I found the following editorial issues: > > Subsections of 3, stylistic: The structure of this section reads a > little like a sales pitch (with the subsubsections IPFIX limitations / > perstream advantages per each subsection). Further, I don't actually > think the split into subsubsections is necessary; the text flows fine > without the headings. If you really want to keep the subsubsections, > name the 3.x.1 "IPFIX Protocol Specification Limitations" for > plurality agreement with 3.x.2. We created this structure based on Elisa's comment (http://www.ietf.org/mail-archive/web/ipfix/current/msg04325.html) General Comment: As already said during the IPFIX meeting in Philadelphia, I'd like to see a section on the limitations of this method and a few more words on its applicability. While the advantages are clearly listed, it is not clear - to which set of applications this specification is targeted (this might be added in 2.1 Applicability), - which limitations the method has. I have no strong feeling about the subsubsections. We can remove the headings. > > 3.2.1 Transmission Order within an SCTP Stream / IPFIX Protocol > Specifications Limitation paragraph 1 > > OLD: The IPFIX protocol specification foresees: > > NEW: [RFC5101] specifies: ok. > > > 3.3.2 No Transmission Order across SCTP Streams / IPFIX Export Per > SCTP Stream Advantages, general > > [This section should mention Options Templates, since 3.3.1 does.] ok. > > > 4.1 dataRecordsReliability > > [should have an IANA NOTE pointing out that IANA should change the > xxx. They'll probably figure it out anyway but why not be helpful? :) ] ok. > > > Further, I suspect you'll get a Security question asking about what > SCTP-RESET does to the SCTP-relevant bits of the 5101 security > considerations, so a paragraph exploring the potential risks (and > then, therefore, one hopes, dismissing them) would be useful here. Actually, this one passed the IESG review. Thanks for the excellent feedback. Regards, Benoit. > > hm. That seems to be about it (it was a little longer than I > originally intended). Hope this helps. :) > > Cheers, > > Brian > > On Oct 26, 2009, at 6:00 PM, Internet-Drafts@ietf.org wrote: > >> 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 : IPFIX Export per SCTP Stream >> Author(s) : B. Claise, P. Aitken, A. Johnson, G. Muenz >> Filename : draft-ietf-ipfix-export-per-sctp-stream-04.txt >> Pages : 22 >> Date : 2009-10-26 >> >> This document specifies an extension to the specifications >> in RFC5101, IP Flow Information Export (IPFIX), when using >> the Partial Reliability extension of SCTP (PR-SCTP, Partial >> Reliability Stream Control Transmission Protocol). >> When implemented at both the Exporting and Collecting Processes, >> this method offers several advantages such as the ability to >> calculate Data Record losses for PR-SCTP, immediate export of >> Template Withdrawal Messages, immediate reuse of Template IDs >> within an SCTP stream, reduced likelihood of Data Record loss, >> and reduced demands on the Collecting Process. When implemented >> in only the Collecting or Exporting Process then normal IPFIX >> behavior will be seen without these additional benefits. >> >> A URL for this Internet-Draft is: >> http://www.ietf.org/internet-drafts/draft-ietf-ipfix-export-per-sctp-stream-04.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. >> _______________________________________________ >> 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 --------------060908050507040601060102 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Brian,
Hi, Benoit, all,

I have a few comments on the -04 perstream draft.

In general the quality of the draft has improved greatly. I'm quite happy with the detail in section 4.5 for guaranteeing interoperability while still allowing CPs to get the benefits of per-stream, which was my main issue with the previous revision. I notice too the Intended Status is now Standards Track. I presume that this Standards Track designation is equivalent to that of e.g. 5103 (Biflow): this is an optional specification with specific applicability;
Exactly.
otherwise, it's still fine IMO as Informational, but then you have to ditch all the 2119 language. I think it was the appearance of 2119 language in an Informational draft that made the IESG suggest Standards Track;
Exactly.
The following email was the start of this discussion, along with the "Stream Control Transmission Protocol (SCTP) Stream Reconfiguration" draft that became a working group document.
-------- Original Message --------
Subject: DISCUSS: draft-ietf-ipfix-export-per-sctp-stream
Date: Sat, 8 Aug 2009 07:55:58 -0700 (PDT)
From: Alexey Melnikov <alexey.melnikov@isode.com>
To: iesg@ietf.org
CC: ipfix-chairs@tools.ietf.org, draft-ietf-ipfix-export-per-sctp-stream@tools.ietf.org 


Discuss:
I have 2 relatively minor issues with the document:

1). DISCUSS DISCUSS:

Why is this document says "Intended Status: Informational"? It looks fairly normative to me.
...
see 5473 for an example of how to describe a mechanism with specific applicability in a non-normative way. Of course, then there's the problem with an Informative RFC contradicting a Standards Track one (5101), necessary for the CP to realize the perstream advantages... In any case, I'm not convinced the discussion is complete on this point.
I agree that at this point, the situation is a little bit unclear.
I applied the discussed/proposed solution. However, the formal decision from the WG/Chair/Area Director would be welcome.

Presuming we're talking about a restricted-applicability Standards Track draft, the applicability of the draft is now clearer in previous versions, but I would still suggest certain changes to the language in order to avoid confusion on this point, as follows.

2.2 Applicability para 1

OLD: The specifications are required in cases where we must know how many data records of a certain type...

NEW: The specifications contained in this document are applicable to cases where application requirements include knowing how many data records of a certain type...

[Yes, I know that required isn't a REQUIRED, but I want implementors to be sure they don't have to do perstream if they're not splitting templates by app; I believe the suggested text clarifies this point]


2.2 Applicability para 3

OLD: However, in order to benefit from the advantages, the Collecting Process specified in [RFC5101] must implement some additional specifications that this document introduces.

NEW: However, Collecting Processes may implement additional support for per-stream export specified in this document in order to realize all the benefits of the approach specified herein.

[Same thing. Make it clear we're not updating 5101.]


3.2.1 Transmission Order within an SCTP Stream / IPFIX Protocol Specifications Limitation paragraph 5

DELETE: In practice, Data Records without associated (Options) template records will most likely be discarded by the Collecting Process.

[Maybe true. Probably, even. Appropriate for an Informational draft or an implementation report. But this comes too close to contradicting a MAY in 5101 to be appropriate for a Standards Track draft.]


4. Specifications para 1

OLD: This section introduces improvements compared to the IPFIX specifications in [RFC5101].

NEW: This section specifies Exporting Process and Collecting Process behavior different from that in [RFC5101] in order to realize the benefits of per-stream export. Note that Exporting Processes following these Specifications will interoperate with [RFC5101]-compliant Collecting Processes, but that Collecting Processes will have to follow additional non-interoperable specifications to realize the full benefits of the technique.

[The current text does not take applicability under consideration.]


4.2 Template Management para 1

OLD: This section introduces some additional specifications compared to the Template Management section 8 in [RFC 5101]

NEW: To take advantage of per-stream export, Exporting Processes should follow the specification in this section in addition to Section 8, Template Management, of [RFC5101].

[As for 4 above.]


4.3 SCTP para 1

OLD: This section introduces some more specific specifications compared to the SCTP section 10.2 in [RFC 5101], in particular the "Stream" section 10.2.4.3.

NEW: To take advantage of per-stream export, Exporting Processes should manage SCTP streams according to the specification in this section, in addition to Section 10.2.4.3, Stream, of [RFC5101].

[As for 4 above.]


4.4 Template Withdrawal Message para 1

OLD: This section introduces some more specific Template Withdrawal Message-related specifications compared to  [RFC 5101]

NEW: To take advantage of per-stream export, Exporting Processes should send Template Withdrawal Messages according to the specification in this section, in addition to Section 8, Template Management, of [RFC5101].

[As for 4 above.]


4.5 The Collecting Process's Side para 1

OLD: This section introduces some more specific specifications to the Collection Process compared to section 9 in [RFC5101]. However, the new specifications are backwards compatible with RFC5101- compliant Collecting Processes and are only needed to benefit from the advantages offered by the per-SCTP-stream extension.

NEW: Collecting Processes must operate slightly contrary to [RFC5101] in order to realize the full benefits of per-stream export. However, the specification in this section contains a mechanism which allows per-stream-capable Collecting Processes to selectively enable per-stream export, in order to ensure interoperability of per-stream-capable Collecting Processes with Exporting Processes which do not implement per-stream export.

[As for 4. Clarified that CPs need to interoperate with EPs, not "have backward compatibility" with other CPs.]
All your new proposals above make perfect sense.


A suggestion not strictly limited to applicability:


4.1 dataRecordsReliability Information Element

[This information element is specified to only apply to Template ID scopes. Could it not also be scoped to other things (SCTP Stream ID, for instance) for a generalization of the approach? suggest the following:]

OLD:
   dataRecordsReliability

         Description:
              The Data Records reliability associated with this
              Template ID.  The true value means that the Data Records
              are sent reliably, while the false value means that the
              Data Records are not sent reliably.

NEW:
  dataRecordsReliability

    Description:

      The Data Records reliability associated with the elements in
       the Options Template scope, usually a templateID. A true value
       means that the Data Records are sent reliably, while a false value
       means that the Data Records are not sent reliably.
Great suggestion.


In addition, on review I found the following editorial issues:

Subsections of 3, stylistic: The structure of this section reads a little like a sales pitch (with the subsubsections IPFIX limitations / perstream advantages per each subsection). Further, I don't actually think the split into subsubsections is necessary; the text flows fine without the headings. If you really want to keep the subsubsections, name the 3.x.1 "IPFIX Protocol Specification Limitations" for plurality agreement with 3.x.2.
We created this structure based on Elisa's comment (http://www.ietf.org/mail-archive/web/ipfix/current/msg04325.html)
General Comment:
As already said during the IPFIX meeting in Philadelphia, I'd like to see a section on the limitations of this method and a few more words on its applicability.
While the advantages are clearly listed, it is not clear
- to which set of applications this specification is targeted (this might be added in 2.1 Applicability),
- which limitations the method has.
I have no strong feeling about the subsubsections. We can remove the headings.

3.2.1 Transmission Order within an SCTP Stream / IPFIX Protocol Specifications Limitation paragraph 1

OLD: The IPFIX protocol specification foresees:

NEW: [RFC5101] specifies:
ok.


3.3.2 No Transmission Order across SCTP Streams / IPFIX Export Per SCTP Stream Advantages, general

[This section should mention Options Templates, since 3.3.1 does.]
ok.


4.1 dataRecordsReliability

[should have an IANA NOTE pointing out that IANA should change the xxx. They'll probably figure it out anyway but why not be helpful? :) ]
ok.


Further, I suspect you'll get a Security question asking about what SCTP-RESET does to the SCTP-relevant bits of the 5101 security considerations, so a paragraph exploring the potential risks (and then, therefore, one hopes, dismissing them) would be useful here.
Actually, this one passed the IESG review.

Thanks for the excellent feedback.

Regards, Benoit.

hm. That seems to be about it (it was a little longer than I originally intended). Hope this helps. :)

Cheers,

Brian

On Oct 26, 2009, at 6:00 PM, Internet-Drafts@ietf.org wrote:

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        : IPFIX Export per SCTP Stream
    Author(s)    : B. Claise, P. Aitken, A. Johnson, G. Muenz
    Filename    : draft-ietf-ipfix-export-per-sctp-stream-04.txt
    Pages        : 22
    Date        : 2009-10-26
    
This document specifies an extension to the specifications
      in RFC5101, IP Flow Information Export (IPFIX), when using
      the Partial Reliability extension of SCTP (PR-SCTP, Partial
      Reliability Stream Control Transmission Protocol).
      When implemented at both the Exporting and Collecting Processes,
      this method offers several advantages such as the ability to
      calculate Data Record losses for PR-SCTP, immediate export of
      Template Withdrawal Messages, immediate reuse of Template IDs
      within an SCTP stream, reduced likelihood of Data Record loss,
      and reduced demands on the Collecting Process.  When implemented
      in only the Collecting or Exporting Process then normal IPFIX
      behavior will be seen without these additional benefits.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ipfix-export-per-sctp-stream-04.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.
<mime-attachment>_______________________________________________
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

--------------060908050507040601060102-- From sujay.ietf@gmail.com Sat Oct 31 00:27:27 2009 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 81A4F3A66B4 for ; Sat, 31 Oct 2009 00:27:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 5vOIk37lyxnW for ; Sat, 31 Oct 2009 00:27:26 -0700 (PDT) Received: from mail-px0-f171.google.com (mail-px0-f171.google.com [209.85.216.171]) by core3.amsl.com (Postfix) with ESMTP id 98D8C3A63C9 for ; Sat, 31 Oct 2009 00:27:26 -0700 (PDT) Received: by pxi1 with SMTP id 1so2487474pxi.32 for ; Sat, 31 Oct 2009 00:27:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=Dyd116mcW3ugDxEO6+3+ChlNeovfs6p+ggmI8+/foRY=; b=orqNHwm5CVrqBXdqf2+d9K0pq2WpLyeM7k9zw+4cjrsHwcBE1R6nHEFBvo4WF6ATyy tYbalV2fCDyDg2mOoJntheQwNQ3Ppq7PphaBP6UeFNUVME5ApbT8GgNXMpYs5g3KvSxg nlNCMUsG7uLGcahajFdGg3QLKSKcaDMsUN4uY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=Lt8DRqpI+9VN2HiEzgFuo565tO4zwMmYWm6YxOIGuZUPRPCA2UqplCaGhmQXHXeN4h ScY19BAfPKKAo27a6jN2GGcv4HdCutXofGzJEyqcXwB6S3PBrQ0ewRTU0iNd4SnXXUf9 IZBIZx6Km43CX7ZMLwmnA323jbHqKbW4rGpew= MIME-Version: 1.0 Received: by 10.142.195.13 with SMTP id s13mr250258wff.3.1256974061604; Sat, 31 Oct 2009 00:27:41 -0700 (PDT) In-Reply-To: References: Date: Sat, 31 Oct 2009 12:57:41 +0530 Message-ID: From: sujay gupta To: Juergen Quittek Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: IETF IPFIX Working Group Subject: Re: [IPFIX] WG last call on draft-ietf-ipfix-mediators-problem-statement-06 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: Sat, 31 Oct 2009 07:27:27 -0000 Hi, A few comments. 1) I have a slight problem overall with the language structuring especially from section 1 to 4. It could be made simple. 2) IPFIX mediation as a service or device? is intermixed, can we differentiate that? also can we call the different type of mediators as services? 3) Is there any line of thought of having the mediation device incorporate record compression to reduce b/w?( draft-muenz-ipfix-compression) as another service, or deal with compressed data from the original exporter? BR, -Sujay On Mon, Oct 19, 2009 at 10:32 AM, Juergen Quittek wr= ote: > Dear all, > > At our session in Stockholm we agreed to start the 2nd working group > last call on the mediation problem state as soon as a new version > of it would be available. The new version is > > http://www.ietf.org/internet-drafts/draft-ietf-ipfix-mediators-problem-st= ate > ment-06.txt > > The call starts today and will last until Friday October 30. > > Please read the draft! > Please send your comments to this mailing list! > Please also send a message if you are fine with the draft as it is! > > Thank you, > > =A0 =A0Juergen > > _______________________________________________ > IPFIX mailing list > IPFIX@ietf.org > https://www.ietf.org/mailman/listinfo/ipfix > >