From n.brownlee@auckland.ac.nz Wed Feb 1 01:39:46 2012 Return-Path: X-Original-To: ipfix@ietfa.amsl.com Delivered-To: ipfix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D2BE321F85AD for ; Wed, 1 Feb 2012 01:39:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.74 X-Spam-Level: X-Spam-Status: No, score=-100.74 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Kxw-IrGVxn1l for ; Wed, 1 Feb 2012 01:39:45 -0800 (PST) Received: from mx2.auckland.ac.nz (mx2.auckland.ac.nz [130.216.12.44]) by ietfa.amsl.com (Postfix) with ESMTP id 66F3B21F855B for ; Wed, 1 Feb 2012 01:39:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=n.brownlee@auckland.ac.nz; q=dns/txt; s=uoa; t=1328089186; x=1359625186; h=message-id:date:from:mime-version:to:subject: content-transfer-encoding; bh=8nq7XPjuOINK/vIaNMi7st4LholmLNjnpxIwKWa5js0=; b=h6C/YAUyv4d9ybyu9Gz7Gg7fQ7R+vfBy7ifWjhRVD0x8CcesRonHIGtF 6jenZA/z5kRLBcS5pYK7ERdmIjdE8+szv1naZeSncnTL8fJ4837lHhah3 6rtYMP4B5Mkzamqq82sgSoCVopUHLLFJiuF2RNs7jYag7ROs5KApnNN/3 I=; X-IronPort-AV: E=Sophos;i="4.71,601,1320577200"; d="scan'208";a="100774671" X-Ironport-HAT: None - $RELAY-AUTH X-Ironport-Source: 158.38.40.197 - Outgoing - Outgoing-SSL Received: from unigjest-dhcp197.uninett.no (HELO [158.38.40.197]) ([158.38.40.197]) by mx2-int.auckland.ac.nz with ESMTP; 01 Feb 2012 22:39:33 +1300 Message-ID: <4F29084B.8000200@auckland.ac.nz> Date: Wed, 01 Feb 2012 01:39:23 -0800 From: Nevil Brownlee User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.24) Gecko/20111108 Thunderbird/3.1.16 MIME-Version: 1.0 To: IPFIX list Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [IPFIX] Flow Selection Techniques draft X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Feb 2012 09:39:46 -0000 Hi all: The Flow Selection Techniques discussed in Quebec (IETF 81) last year (-07) generated considerable discussion. Versions -08 and -09 include many changes, which I believe greatly improve the draft. However, since Quebec there's been very little discussion of this draft. We're at the point where I'd like to get it submitted; please would some of you have a look at the changes, and send some comments to the list [easiest way to see them is to use the diff2 view of version -08]. Also, there was some earlier discussion of IPR issues for this draft. Nick Duffield pointed out that "PSAMP addressed this issue by making all the selection methods optional." The way I read the draft, it has a long list of selection algorithms, and it's up to an implementor to choose which to implement, however I didn't spot any definite statement that all of them are optional. I'd like to hear comments about this too - do we feel that it's OK as it is, or should there be a more definite statement on this? 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 Zeala From n.brownlee@auckland.ac.nz Wed Feb 1 02:03:48 2012 Return-Path: X-Original-To: ipfix@ietfa.amsl.com Delivered-To: ipfix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 88BBC21F865D for ; Wed, 1 Feb 2012 02:03:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.669 X-Spam-Level: X-Spam-Status: No, score=-101.669 tagged_above=-999 required=5 tests=[AWL=0.930, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qoZu46sH1E2S for ; Wed, 1 Feb 2012 02:03:48 -0800 (PST) Received: from mx2.auckland.ac.nz (mx2.auckland.ac.nz [130.216.12.44]) by ietfa.amsl.com (Postfix) with ESMTP id AB91621F865B for ; Wed, 1 Feb 2012 02:03:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=n.brownlee@auckland.ac.nz; q=dns/txt; s=uoa; t=1328090628; x=1359626628; h=message-id:date:from:mime-version:to:subject: content-transfer-encoding; bh=LhC14s1jVzG+k1jXMQxHj7P8hZAGhPOCwzKqzoxHuHU=; b=lLcd+5DML2PLKTEYcA4x7/hvSMxBWoZJ35qNvRnM7ChzAELVBHYiEO+y VD6RLyemXcus50s3g/cqYp41AvcD+Klt5kXfujtSKWUB6DQEQbou0blkp ypKxxFbO1iCGCNhHtwbI/de2zE2XeGoe4r7vHOB/KQsEcTZLfHiyWnSxO g=; X-IronPort-AV: E=Sophos;i="4.71,601,1320577200"; d="scan'208";a="100776562" X-Ironport-HAT: None - $RELAY-AUTH X-Ironport-Source: 158.38.40.197 - Outgoing - Outgoing-SSL Received: from unigjest-dhcp197.uninett.no (HELO [158.38.40.197]) ([158.38.40.197]) by mx2-int.auckland.ac.nz with ESMTP; 01 Feb 2012 23:03:45 +1300 Message-ID: <4F290DFF.9090002@auckland.ac.nz> Date: Wed, 01 Feb 2012 02:03:43 -0800 From: Nevil Brownlee User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.24) Gecko/20111108 Thunderbird/3.1.16 MIME-Version: 1.0 To: IPFIX list Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [IPFIX] Start of new WGLC for Flow Selection Techniques draft X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Feb 2012 10:03:48 -0000 Hi again all: I should have said this in my last post - In Taipei we said "this needs a new WGLC," this is the notice that it starts today, and will finish on Wednesday, 15 February. I need at least two emails supporting it, so do please have a look, even if you only say "looks OK now!" 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 From paitken@cisco.com Wed Feb 1 07:33:53 2012 Return-Path: X-Original-To: ipfix@ietfa.amsl.com Delivered-To: ipfix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C85E011E8112 for ; Wed, 1 Feb 2012 07:33:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.451 X-Spam-Level: X-Spam-Status: No, score=-9.451 tagged_above=-999 required=5 tests=[AWL=-0.652, BAYES_00=-2.599, J_CHICKENPOX_31=0.6, J_CHICKENPOX_37=0.6, J_CHICKENPOX_71=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zokpTY1y+xnF for ; Wed, 1 Feb 2012 07:33:53 -0800 (PST) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by ietfa.amsl.com (Postfix) with ESMTP id C6DB711E810B for ; Wed, 1 Feb 2012 07:33:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=paitken@cisco.com; l=3033; q=dns/txt; s=iport; t=1328110432; x=1329320032; h=message-id:date:from:mime-version:to:subject: content-transfer-encoding; bh=KLVxBpG9eV5ly5eEaIYHJX96PC6Pj3abaezxSXDKSSQ=; b=W7/ClzxP3YXDkNdjYLqg3Lwfsi+nn7i3URWRqktWoLVwv4vPm3LdLFaG 9zM5ygrXF6O2t4EDi/5YIb+g/VPYc1HZgV3uGKeiUJdd9XoV3EY6vWoS9 552hXAEijDlUTtAoVWznUzalNfVc8ul6AFf0nsHReUI+CiIGU4wvpWkob E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAGNaKU+Q/khM/2dsb2JhbABDrn2BBYILASVAPRYYAwIBAgFLDQYCAQEeoCqBJwGeTIsyAQQCAQICCQQBDQQGAQsBCAUDAwmDERkEAwwDFAVXDQEEBINXBJUhhVeMfQ X-IronPort-AV: E=Sophos;i="4.71,602,1320624000"; d="scan'208";a="65152309" Received: from ams-core-3.cisco.com ([144.254.72.76]) by ams-iport-2.cisco.com with ESMTP; 01 Feb 2012 15:33:51 +0000 Received: from [144.254.153.49] (dhcp-144-254-153-49.cisco.com [144.254.153.49]) by ams-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id q11FXpFf028106 for ; Wed, 1 Feb 2012 15:33:51 GMT Message-ID: <4F295B61.1030606@cisco.com> Date: Wed, 01 Feb 2012 15:33:53 +0000 From: Paul Aitken User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.24) Gecko/20111108 Lightning/1.0b2 Thunderbird/3.1.16 MIME-Version: 1.0 To: IETF IPFIX Working Group Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [IPFIX] exporting VLANs in IPFIX X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Feb 2012 15:33:53 -0000 Dear all, IANA's IPFIX registry contains some nearly-identical fields for exporting VLAN IDs: 58 vlanId unsigned16 identifier current The IEEE 802.1Q VLAN identifier (VID) extracted from the Tag Control Information field that was attached to the IP packet. See IEEE.802-1Q.2003. [RFC5102] 243 dot1qVlanId unsigned16 identifier current The value of the 12-bit VLAN Identifier portion of the Tag Control Information field of an Ethernet frame as described in section 3.5.5 of [IEEE.802-3.2005]. The structure and semantics within the Tag Control Information field are defined in IEEE P802.1Q. In case of a QinQ frame, it represents the outer tag's VLAN identifier and in case of an IEEE 802.1ad frame it represents the Service VLAN identifier in the S-TAG Tag Control Information (TCI) field as described in [IEEE.802-1ad.2005]. Units = octets [IEEE.802-3.2005] [ipfix-iana@cisco.com] 59 postVlanId unsigned16 identifier current The definition of this Information Element is identical to the definition of Information Element 'vlanId', except that it reports a potentially modified value caused by a middlebox function after the packet passed the Observation Point. See IEEE.802-1Q.2003. [RFC5102] 254 postDot1q VlanId unsigned16 identifier current The definition of this Information Element is identical to the definition of Information Element 'dot1qVlanId', except that it reports a potentially modified value caused by a middlebox function after the packet passed the Observation Point. [IEEE.802-3.2005] [IEEE.802-1ad.2005] [ipfix-iana@cisco.com] The reason for requesting 243 and 254 was that in NFv9 (RFC 3954), the definitions of 58 and 59 were much more generic: Virtual LAN identifier SRC_VLAN 58 2 associated with ingress interface Virtual LAN identifier DST_VLAN 59 2 associated with egress interface These definitions do not convey to the collector whether the observed packets had an 802.1Q vlan tag, were from a static VLAN assignment to a port, from a dynamic VLAN assignment based on user or mac, from a policy based VLAN assignment, from a tunnel termination, from an ISL tag, or from some other means. To avoid confusion over whether to use 58 or 243, 59 or 254, and to preserve backwards compatibility, I propose that IPFIX fields 58 and 59 are reverted to their generic NFv9 definitions. ie, any VLAN ID can be exported in 58/59, while only dot1q can be exported in 243/254. Feedback? Thanks, P. From trammell@tik.ee.ethz.ch Wed Feb 1 07:35:56 2012 Return-Path: X-Original-To: ipfix@ietfa.amsl.com Delivered-To: ipfix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DEB5411E80F7 for ; Wed, 1 Feb 2012 07:35:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.699 X-Spam-Level: X-Spam-Status: No, score=-5.699 tagged_above=-999 required=5 tests=[AWL=-0.900, BAYES_00=-2.599, J_CHICKENPOX_31=0.6, J_CHICKENPOX_37=0.6, J_CHICKENPOX_71=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tk-ZfsFLOeP3 for ; Wed, 1 Feb 2012 07:35:56 -0800 (PST) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) by ietfa.amsl.com (Postfix) with ESMTP id 01FC311E8071 for ; Wed, 1 Feb 2012 07:35:56 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id 2F281D9321; Wed, 1 Feb 2012 16:35:55 +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 fhhFnQM-+MZK; Wed, 1 Feb 2012 16:35:55 +0100 (MET) Received: from pb-10243.ethz.ch (pb-10243.ethz.ch [82.130.102.152]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: briant) by smtp.ee.ethz.ch (Postfix) with ESMTPSA id DD0CFD9302; Wed, 1 Feb 2012 16:35:54 +0100 (MET) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Brian Trammell In-Reply-To: <4F295B61.1030606@cisco.com> Date: Wed, 1 Feb 2012 16:35:54 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4F295B61.1030606@cisco.com> To: Paul Aitken X-Mailer: Apple Mail (2.1084) Cc: IETF IPFIX Working Group Subject: Re: [IPFIX] exporting VLANs in IPFIX X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Feb 2012 15:35:57 -0000 Hi, Paul, This seems like a reasonable thing to do. Cheers, Brian On Feb 1, 2012, at 4:33 PM, Paul Aitken wrote: > Dear all, >=20 > IANA's IPFIX registry contains some nearly-identical fields for = exporting VLAN IDs: >=20 >=20 > 58 vlanId unsigned16 identifier current >=20 > The IEEE 802.1Q VLAN identifier (VID) extracted from the Tag > Control Information field that was attached to the IP packet. > See IEEE.802-1Q.2003. > [RFC5102] >=20 >=20 > 243 dot1qVlanId unsigned16 identifier current >=20 > The value of the 12-bit VLAN Identifier portion of the Tag > Control Information field of an Ethernet frame as described in > section 3.5.5 of [IEEE.802-3.2005]. The structure and = semantics > within the Tag Control Information field are defined in IEEE > P802.1Q. In case of a QinQ frame, it represents the outer = tag's > VLAN identifier and in case of an IEEE 802.1ad frame it > represents the Service VLAN identifier in the S-TAG Tag Control > Information (TCI) field as described in [IEEE.802-1ad.2005]. > Units =3D octets > [IEEE.802-3.2005] > [ipfix-iana@cisco.com] >=20 >=20 > 59 postVlanId unsigned16 identifier current >=20 > The definition of this Information Element is identical > to the definition of Information Element > 'vlanId', except that it reports a > potentially modified value caused by a middlebox > function after the packet passed the Observation Point. > See IEEE.802-1Q.2003. > [RFC5102] >=20 >=20 > 254 postDot1q VlanId unsigned16 identifier current >=20 > The definition of this Information Element is identical to the > definition of Information Element 'dot1qVlanId', except that it > reports a potentially modified value caused by a middlebox > function after the packet passed the Observation Point. > [IEEE.802-3.2005] > [IEEE.802-1ad.2005] > [ipfix-iana@cisco.com] >=20 >=20 > The reason for requesting 243 and 254 was that in NFv9 (RFC 3954), the = definitions of 58 and 59 were much more generic: >=20 > Virtual LAN identifier > SRC_VLAN 58 2 associated with ingress > interface >=20 > Virtual LAN identifier > DST_VLAN 59 2 associated with egress > interface >=20 >=20 > These definitions do not convey to the collector whether the observed = packets had an 802.1Q vlan tag, were from a static VLAN assignment to a = port, from a dynamic VLAN assignment based on user or mac, from a policy = based VLAN assignment, from a tunnel termination, from an ISL tag, or = from some other means. >=20 >=20 > To avoid confusion over whether to use 58 or 243, 59 or 254, and to = preserve backwards compatibility, I propose that IPFIX fields 58 and 59 = are reverted to their generic NFv9 definitions. >=20 > ie, any VLAN ID can be exported in 58/59, while only dot1q can be = exported in 243/254. >=20 >=20 > Feedback? >=20 > Thanks, > P. >=20 >=20 > _______________________________________________ > IPFIX mailing list > IPFIX@ietf.org > https://www.ietf.org/mailman/listinfo/ipfix From paitken@cisco.com Wed Feb 1 07:37:30 2012 Return-Path: X-Original-To: ipfix@ietfa.amsl.com Delivered-To: ipfix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D838B21F88E4 for ; Wed, 1 Feb 2012 07:37:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.285 X-Spam-Level: X-Spam-Status: No, score=-10.285 tagged_above=-999 required=5 tests=[AWL=0.313, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RPEBMJ1LtQQA for ; Wed, 1 Feb 2012 07:37:30 -0800 (PST) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by ietfa.amsl.com (Postfix) with ESMTP id A62CE21F88E3 for ; Wed, 1 Feb 2012 07:37:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=paitken@cisco.com; l=3708; q=dns/txt; s=iport; t=1328110648; x=1329320248; h=message-id:date:from:mime-version:to:subject; bh=t5p49p+XUxH49VLwRR+wnRRSyb8SM6kH3qgWEEfeW1E=; b=StF5q+Lvw93455DQrgJvwU0kKxedQEvjRxTJ+ylsnBQHLOzTWT4/1rDW mBZLKE0aIFVOIcSQ649EZs/zdpz6d2lUakq8aBCcUvzc+SmhddZjgY6VY AfNE2lfso9U+bzkcuYTvldq705h2LE4fk+PonBkoahFxGm0aV49lIgFWX Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFAIpbKU+Q/khL/2dsb2JhbABDhQupcoEFgXIBAQEWARBUAQ0TDQMBAgoWCwILAwIBAgE7Ag4NBgIBAR6gLYEnAYxlkWeLXQYBCwEIBQMDCR+CchkEAwwDFAVXDQEEBIJBgRYElSGFV4x9 X-IronPort-AV: E=Sophos;i="4.71,602,1320624000"; d="scan'208,217";a="65152879" Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-2.cisco.com with ESMTP; 01 Feb 2012 15:37:27 +0000 Received: from [144.254.153.49] (dhcp-144-254-153-49.cisco.com [144.254.153.49]) by ams-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id q11FbRtl030501 for ; Wed, 1 Feb 2012 15:37:27 GMT Message-ID: <4F295C39.3030505@cisco.com> Date: Wed, 01 Feb 2012 15:37:29 +0000 From: Paul Aitken User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.24) Gecko/20111108 Lightning/1.0b2 Thunderbird/3.1.16 MIME-Version: 1.0 To: IETF IPFIX Working Group Content-Type: multipart/alternative; boundary="------------030906060001020800090104" Subject: [IPFIX] Fwd: New Version Notification for draft-aitken-ipfix-unobserved-fields-00.txt X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Feb 2012 15:37:31 -0000 This is a multi-part message in MIME format. --------------030906060001020800090104 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit FYI: -------- Original Message -------- Subject: New Version Notification for draft-aitken-ipfix-unobserved-fields-00.txt Date: Mon, 30 Jan 2012 08:48:26 -0800 From: internet-drafts@ietf.org To: paitken@cisco.com CC: paitken@cisco.com A new version of I-D, draft-aitken-ipfix-unobserved-fields-00.txt has been successfully submitted by Paul Aitken and posted to the IETF repository. Filename: draft-aitken-ipfix-unobserved-fields Revision: 00 Title: Reporting Unobserved Fields in IPFIX Creation date: 2012-01-30 WG ID: Individual Submission Number of pages: 13 Abstract: The IPFIX protocol is designed to export information about observations, and lacks a method for reporting that observations are unavailable. This document discusses several methods for reporting when fields are unavailable, reviews the advantages and disadvantage of each, and recommends methods which should be used. The IETF Secretariat --------------030906060001020800090104 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit FYI:

-------- Original Message --------
Subject: New Version Notification for draft-aitken-ipfix-unobserved-fields-00.txt
Date: Mon, 30 Jan 2012 08:48:26 -0800
From: internet-drafts@ietf.org
To: paitken@cisco.com
CC: paitken@cisco.com 


A new version of I-D, draft-aitken-ipfix-unobserved-fields-00.txt has been successfully submitted by Paul Aitken and posted to the IETF repository.

Filename:	 draft-aitken-ipfix-unobserved-fields
Revision:	 00
Title:		 Reporting Unobserved Fields in IPFIX
Creation date:	 2012-01-30
WG ID:		 Individual Submission
Number of pages: 13

Abstract:
        The IPFIX protocol is designed to export information about
        observations, and lacks a method for reporting that observations
        are unavailable. This document discusses several methods for
        reporting when fields are unavailable, reviews the advantages
        and disadvantage of each, and recommends methods which should be
        used.


     
                                                                                  


The IETF Secretariat
--------------030906060001020800090104-- From trammell@tik.ee.ethz.ch Fri Feb 3 09:44:54 2012 Return-Path: X-Original-To: ipfix@ietfa.amsl.com Delivered-To: ipfix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C80D121F8594 for ; Fri, 3 Feb 2012 09:44:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.524 X-Spam-Level: X-Spam-Status: No, score=-6.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CbpkSXnA0uAc for ; Fri, 3 Feb 2012 09:44:54 -0800 (PST) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) by ietfa.amsl.com (Postfix) with ESMTP id 3458621F8591 for ; Fri, 3 Feb 2012 09:44:53 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id 4BEF5D930B; Fri, 3 Feb 2012 18:44:52 +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 TLzcjpWjqPHr; Fri, 3 Feb 2012 18:44:52 +0100 (MET) Received: from pb-10243.ethz.ch (pb-10243.ethz.ch [82.130.102.152]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: briant) by smtp.ee.ethz.ch (Postfix) with ESMTPSA id 1DC34D9305; Fri, 3 Feb 2012 18:44:52 +0100 (MET) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Brian Trammell In-Reply-To: <4F26FADF.8070900@cisco.com> Date: Fri, 3 Feb 2012 18:44:51 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <91EF4772-7031-43C6-BBA1-0051F40FB029@tik.ee.ethz.ch> References: <4F26FADF.8070900@cisco.com> To: Paul Aitken X-Mailer: Apple Mail (2.1084) Cc: IETF IPFIX Working Group Subject: Re: [IPFIX] RFC 5101bis - UDP checksum X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Feb 2012 17:44:54 -0000 Hi, Paul, This seems reasonable, and I see no problem at all with adding it, but = I'm not really sure if there's a win... A couple of comments on that = point. First, practically, I'm not aware of a UDP stack that doesn't do = checksums by default (though I have limited experience with embedded = systems and none at all on routers), so I would assume an implementor = would have to go out of their way to switch UDP checksum calculation = off.=20 Second, given all the various (unavoidable) issues with respect to IPFIX = over UDP (mainly related to template management) which would seem to = have occurrence probabilities on the order of magnitude of that of a = transmission error that would be caught by the UDP checksum (at least = over MAC layers with which I have experience), it's not clear why we'd = want to say, hey, you can use UDP if you can't afford anything else, but = you can't make it a (very) little bit faster and a (very) little bit = less reliable by dropping checksums. Cheers, Brian On Jan 30, 2012, at 9:17 PM, Paul Aitken wrote: > Dear all, >=20 > Per RFC 768 and RFC 1122, UDP checksums are not mandatory. >=20 > Since the IPv4 checksum is only calculated over the header (not the = data) and there is no IPv6 checksum, 5101bis should include a line = recommending that UDP checksums are enabled when exporting over UDP. >=20 > P. > _______________________________________________ > IPFIX mailing list > IPFIX@ietf.org > https://www.ietf.org/mailman/listinfo/ipfix From internet-drafts@ietf.org Fri Feb 3 10:01:29 2012 Return-Path: X-Original-To: ipfix@ietfa.amsl.com Delivered-To: ipfix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A21D21F858E; Fri, 3 Feb 2012 10:01:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.59 X-Spam-Level: X-Spam-Status: No, score=-102.59 tagged_above=-999 required=5 tests=[AWL=0.009, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UCcxMtO8hDai; Fri, 3 Feb 2012 10:01:28 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A5BCA21F8552; Fri, 3 Feb 2012 10:01:28 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.64p1 Message-ID: <20120203180128.3335.60030.idtracker@ietfa.amsl.com> Date: Fri, 03 Feb 2012 10:01:28 -0800 Cc: ipfix@ietf.org Subject: [IPFIX] I-D Action: draft-ietf-ipfix-a9n-01.txt X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Feb 2012 18:01:29 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the IP Flow Information Export Working Gr= oup of the IETF. Title : Flow Aggregation for the IP Flow Information Export (IPF= IX) Protocol Author(s) : Brian Trammell Arno Wagner Benoit Claise Filename : draft-ietf-ipfix-a9n-01.txt Pages : 46 Date : 2012-02-03 This document describes the export of aggregated Flow information using IPFIX. An Aggregated Flow is essentially an IPFIX Flow representing packets from multiple Original Flows sharing some set of common properties. The document describes Aggregated Flow export within the framework of IPFIX Mediators and defines an interoperable, implementation-independent method for Aggregated Flow export. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipfix-a9n-01.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-ipfix-a9n-01.txt From trammell@tik.ee.ethz.ch Fri Feb 3 10:02:50 2012 Return-Path: X-Original-To: ipfix@ietfa.amsl.com Delivered-To: ipfix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E53DF21F851B for ; Fri, 3 Feb 2012 10:02:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.53 X-Spam-Level: X-Spam-Status: No, score=-6.53 tagged_above=-999 required=5 tests=[AWL=0.069, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N4rQx6BLUDC7 for ; Fri, 3 Feb 2012 10:02:50 -0800 (PST) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) by ietfa.amsl.com (Postfix) with ESMTP id C241921F8516 for ; Fri, 3 Feb 2012 10:02:49 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id 2A422D9309 for ; Fri, 3 Feb 2012 19:02:49 +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 GfGVDsqHaevW for ; Fri, 3 Feb 2012 19:02:48 +0100 (MET) Received: from pb-10243.ethz.ch (pb-10243.ethz.ch [82.130.102.152]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: briant) by smtp.ee.ethz.ch (Postfix) with ESMTPSA id E8862D9305 for ; Fri, 3 Feb 2012 19:02:48 +0100 (MET) From: Brian Trammell Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Fri, 3 Feb 2012 19:02:48 +0100 References: <20120203180128.3335.49055.idtracker@ietfa.amsl.com> To: IETF IPFIX Working Group Message-Id: <6CED0EFA-E276-4CFE-AD30-F75C699D0DE9@tik.ee.ethz.ch> Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Subject: [IPFIX] Fwd: New Version Notification for draft-ietf-ipfix-a9n-01.txt X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Feb 2012 18:02:51 -0000 Greetings, all, This is a minor revision of the aggregation draft to point to 5101bis = instead of 5101; there are no substantive content changes.=20 I believe this draft is ready for WGLC, as discussed in Taipei. Thanks, and best regards, Brian Begin forwarded message: > From: internet-drafts@ietf.org > Date: February 3, 2012 7:01:28 PM GMT+01:00 > To: trammell@tik.ee.ethz.ch > Cc: bclaise@cisco.com, arno@wagner.name, trammell@tik.ee.ethz.ch > Subject: New Version Notification for draft-ietf-ipfix-a9n-01.txt >=20 > A new version of I-D, draft-ietf-ipfix-a9n-01.txt has been = successfully submitted by Brian Trammell and posted to the IETF = repository. >=20 > Filename: draft-ietf-ipfix-a9n > Revision: 01 > Title: Flow Aggregation for the IP Flow Information = Export (IPFIX) Protocol > Creation date: 2012-02-04 > WG ID: ipfix > Number of pages: 46 >=20 > Abstract: > This document describes the export of aggregated Flow information > using IPFIX. An Aggregated Flow is essentially an IPFIX Flow > representing packets from multiple Original Flows sharing some set = of > common properties. The document describes Aggregated Flow export > within the framework of IPFIX Mediators and defines an = interoperable, > implementation-independent method for Aggregated Flow export. >=20 >=20 >=20 >=20 > The IETF Secretariat From paitken@cisco.com Fri Feb 3 13:04:50 2012 Return-Path: X-Original-To: ipfix@ietfa.amsl.com Delivered-To: ipfix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9901111E807F for ; Fri, 3 Feb 2012 13:04:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.314 X-Spam-Level: X-Spam-Status: No, score=-10.314 tagged_above=-999 required=5 tests=[AWL=0.285, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vH6USyZ4s5-q for ; Fri, 3 Feb 2012 13:04:49 -0800 (PST) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by ietfa.amsl.com (Postfix) with ESMTP id 50E2621F854B for ; Fri, 3 Feb 2012 13:04:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=paitken@cisco.com; l=1758; q=dns/txt; s=iport; t=1328303089; x=1329512689; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=n9FVCNAic3kawTh2nMR3e4OzDOPCI/OXG1Dx3Eqaips=; b=CsrimOlpwSEGslTADN5XjQr29fPKdF4+O8J6Mm2hbaU2PtclqWR1Akib wGik7b2UfGDNBuld7xbuFiiQbqW5UDLyi/ZJo5NPFeTB2YCrmlBAUbqWe HaIlKwyLy1YEUsNTBE32hQcDn7IxUNXAnq2hjC4U5ZyF1ql6I4uDFHOAo 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AsMHABZKLE+Q/khL/2dsb2JhbABEgxGsG4EFgXIBAQEEAQEBDwElNgoBEAsYCRYPCQMCAQIBFTAGDQEFAgEBGgSHY5pYAZZ8BItXAQQCAQICCQQBDQQGAQsBCAUDAwkfgnIZBAMMAxQFVw0BBAQegzkElSeFWI0B X-IronPort-AV: E=Sophos;i="4.73,353,1325462400"; d="scan'208";a="65359854" Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-2.cisco.com with ESMTP; 03 Feb 2012 21:04:48 +0000 Received: from [10.55.90.112] (dhcp-10-55-90-112.cisco.com [10.55.90.112]) by ams-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id q13L4m9Y000794; Fri, 3 Feb 2012 21:04:48 GMT Message-ID: <4F2C4BEF.7090904@cisco.com> Date: Fri, 03 Feb 2012 21:04:47 +0000 From: Paul Aitken User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.24) Gecko/20111108 Lightning/1.0b2 Thunderbird/3.1.16 MIME-Version: 1.0 To: Brian Trammell References: <4F26FADF.8070900@cisco.com> <91EF4772-7031-43C6-BBA1-0051F40FB029@tik.ee.ethz.ch> In-Reply-To: <91EF4772-7031-43C6-BBA1-0051F40FB029@tik.ee.ethz.ch> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: IETF IPFIX Working Group Subject: Re: [IPFIX] RFC 5101bis - UDP checksum X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Feb 2012 21:04:50 -0000 Brian, The reason for mentioning it is that someone contacted us last week with a proposal not to checksum UDP. So it'd be great to cover this in an RFC in case it comes up again. P. On 03/02/12 17:44, Brian Trammell wrote: > Hi, Paul, > > This seems reasonable, and I see no problem at all with adding it, but I'm not really sure if there's a win... A couple of comments on that point. > > First, practically, I'm not aware of a UDP stack that doesn't do checksums by default (though I have limited experience with embedded systems and none at all on routers), so I would assume an implementor would have to go out of their way to switch UDP checksum calculation off. > > Second, given all the various (unavoidable) issues with respect to IPFIX over UDP (mainly related to template management) which would seem to have occurrence probabilities on the order of magnitude of that of a transmission error that would be caught by the UDP checksum (at least over MAC layers with which I have experience), it's not clear why we'd want to say, hey, you can use UDP if you can't afford anything else, but you can't make it a (very) little bit faster and a (very) little bit less reliable by dropping checksums. > > Cheers, > > Brian > > > On Jan 30, 2012, at 9:17 PM, Paul Aitken wrote: > >> Dear all, >> >> Per RFC 768 and RFC 1122, UDP checksums are not mandatory. >> >> Since the IPv4 checksum is only calculated over the header (not the data) and there is no IPv6 checksum, 5101bis should include a line recommending that UDP checksums are enabled when exporting over UDP. >> >> P. >> _______________________________________________ >> IPFIX mailing list >> IPFIX@ietf.org >> https://www.ietf.org/mailman/listinfo/ipfix From n.brownlee@auckland.ac.nz Sun Feb 5 06:08:53 2012 Return-Path: X-Original-To: ipfix@ietfa.amsl.com Delivered-To: ipfix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5347021F84DC for ; Sun, 5 Feb 2012 06:08:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.999 X-Spam-Level: X-Spam-Status: No, score=-99.999 tagged_above=-999 required=5 tests=[BAYES_50=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Tm-40Gqm6tI2 for ; Sun, 5 Feb 2012 06:08:51 -0800 (PST) Received: from mx2.auckland.ac.nz (mx2.auckland.ac.nz [130.216.12.44]) by ietfa.amsl.com (Postfix) with ESMTP id 6029721F846C for ; Sun, 5 Feb 2012 06:08:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=n.brownlee@auckland.ac.nz; q=dns/txt; s=uoa; t=1328450931; x=1359986931; h=message-id:date:from:mime-version:to:subject: content-transfer-encoding; bh=f6kYdtBL75ScW2NyxuU+zR7cRV9NRsyBBJmdsO1JnA0=; b=GRLc1xy9KENrX8MQidk0a8gMPL9lmM+IRYkbROIocF48LA6XnnMsW/o/ s9hMqLTYj8TjlkSTPwF/VfFOdeyhsEpE3v/mqooROs99jxQKKxhcXoMU4 4npprDZm6ZiJPbwMN3z/VN8uKXbxmpXKhObuJaOTlZP7a6jO6+zZdGfEU Q=; X-IronPort-AV: E=Sophos;i="4.73,364,1325415600"; d="scan'208";a="101326296" X-Ironport-HAT: None - $RELAY-AUTH X-Ironport-Source: 82.194.219.180 - Outgoing - Outgoing-SSL Received: from reverse-82-194-219-180.loqal.no (HELO [82.194.219.180]) ([82.194.219.180]) by mx2-int.auckland.ac.nz with ESMTP; 06 Feb 2012 03:08:49 +1300 Message-ID: <4F2E8D66.2020002@auckland.ac.nz> Date: Sun, 05 Feb 2012 06:08:38 -0800 From: Nevil Brownlee User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.24) Gecko/20111108 Thunderbird/3.1.16 MIME-Version: 1.0 To: IPFIX list Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [IPFIX] WG Last Call for Aggregation and IE-Doctors drafts X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Feb 2012 14:08:53 -0000 Hi all: As reported in the minutes of our Taipei meeting, the WG Last Call for draft-ietf-ipfix-a9n-01 draft-ietf-ipfix-ie-doctors-00 starts today, and will end on Monday, 20 February. As always, we *need* your feedback - please read these and post your comments to the list, even if you only say "this looks good to me!" 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 From trammell@tik.ee.ethz.ch Sun Feb 5 11:46:15 2012 Return-Path: X-Original-To: ipfix@ietfa.amsl.com Delivered-To: ipfix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A87D21F8530 for ; Sun, 5 Feb 2012 11:46:15 -0800 (PST) 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=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lhP+r-ebDdgs for ; Sun, 5 Feb 2012 11:46:14 -0800 (PST) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) by ietfa.amsl.com (Postfix) with ESMTP id C6D3221F8489 for ; Sun, 5 Feb 2012 11:46:14 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id D0FABD9312; Sun, 5 Feb 2012 20:46:12 +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 8LL8ofjFecd6; Sun, 5 Feb 2012 20:46:12 +0100 (MET) Received: from [10.0.1.2] (cust-integra-121-161.antanet.ch [80.75.121.161]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: briant) by smtp.ee.ethz.ch (Postfix) with ESMTPSA id 7D6FFD9314; Sun, 5 Feb 2012 20:46:12 +0100 (MET) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Brian Trammell In-Reply-To: <4F2E8D66.2020002@auckland.ac.nz> Date: Sun, 5 Feb 2012 20:46:11 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4F2E8D66.2020002@auckland.ac.nz> To: Nevil Brownlee X-Mailer: Apple Mail (2.1084) Cc: IPFIX list Subject: Re: [IPFIX] WG Last Call for Aggregation and IE-Doctors drafts X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Feb 2012 19:46:15 -0000 Hi, Nevil, all, Actually, looking at ie-doctors-00, there are still two missing = sections: Section 6 on tool support and Appendix A containing examples. = We'd like to submit a -01 this week to add these sections before a last = call; would it be possible to postpone the start of the last call until = then? Thanks, cheers, Brian On Feb 5, 2012, at 3:08 PM, Nevil Brownlee wrote: >=20 > Hi all: >=20 > As reported in the minutes of our Taipei meeting, the WG Last Call > for > draft-ietf-ipfix-a9n-01 > draft-ietf-ipfix-ie-doctors-00 > starts today, and will end on Monday, 20 February. >=20 > As always, we *need* your feedback - please read these and post your > comments to the list, even if you only say "this looks good to me!" >=20 > Cheers, Nevil >=20 > --=20 > --------------------------------------------------------------------- > 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 >=20 > _______________________________________________ > IPFIX mailing list > IPFIX@ietf.org > https://www.ietf.org/mailman/listinfo/ipfix From n.brownlee@auckland.ac.nz Mon Feb 6 01:00:40 2012 Return-Path: X-Original-To: ipfix@ietfa.amsl.com Delivered-To: ipfix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C28321F85EF for ; Mon, 6 Feb 2012 01:00:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.134 X-Spam-Level: X-Spam-Status: No, score=-102.134 tagged_above=-999 required=5 tests=[AWL=0.465, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ViKwVqGMEPXo for ; Mon, 6 Feb 2012 01:00:39 -0800 (PST) Received: from mx2.auckland.ac.nz (mx2.auckland.ac.nz [130.216.12.44]) by ietfa.amsl.com (Postfix) with ESMTP id C99C821F85ED for ; Mon, 6 Feb 2012 01:00:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=n.brownlee@auckland.ac.nz; q=dns/txt; s=uoa; t=1328518839; x=1360054839; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=2Zr8aT87RsvkLlG+09/QJHv4685VB6p6KdVMkFnRVcU=; b=DBCuW4D3ewwAJhXBr7NT4+rw+SlRz57Z0Cvguqm8rvq7NiXvwEb31ojg j1dduYenqkRI+HU3AJOOReSBo4sOpF6mt9aw1PLNIteC4zf0k8Jg6kDag mYCVSlDWuWW/dYBgP83BUJ/sQBjXhcqZlRPzfjDFBI+hVIPKWyBTcb0hB o=; X-IronPort-AV: E=Sophos;i="4.73,369,1325415600"; d="scan'208";a="101482671" X-Ironport-HAT: None - $RELAY-AUTH X-Ironport-Source: 158.38.40.197 - Outgoing - Outgoing-SSL Received: from unigjest-dhcp197.uninett.no (HELO [158.38.40.197]) ([158.38.40.197]) by mx2-int.auckland.ac.nz with ESMTP; 06 Feb 2012 22:00:34 +1300 Message-ID: <4F2F96AF.7050109@auckland.ac.nz> Date: Mon, 06 Feb 2012 01:00:31 -0800 From: Nevil Brownlee User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.24) Gecko/20111108 Thunderbird/3.1.16 MIME-Version: 1.0 To: Brian Trammell References: <4F2E8D66.2020002@auckland.ac.nz> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: IPFIX list Subject: Re: [IPFIX] WG Last Call for Aggregation and IE-Doctors drafts X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Feb 2012 09:00:40 -0000 Hi Brian: Ah, I did wonder about that. Yes, of course we can pause the ie-doctors WGLC, just let me know when to restart it. And, of course, the WGLC for the Aggregation draft continues. Please post your reviews/comments asap! Cheers, Nevil On 02/05/2012 11:46 AM, Brian Trammell wrote: > Hi, Nevil, all, > > Actually, looking at ie-doctors-00, there are still two missing sections: Section 6 on tool support and Appendix A containing examples. We'd like to submit a -01 this week to add these sections before a last call; would it be possible to postpone the start of the last call until then? > > Thanks, cheers, > > Brian > > On Feb 5, 2012, at 3:08 PM, Nevil Brownlee wrote: > >> >> Hi all: >> >> As reported in the minutes of our Taipei meeting, the WG Last Call >> for >> draft-ietf-ipfix-a9n-01 >> draft-ietf-ipfix-ie-doctors-00 >> starts today, and will end on Monday, 20 February. >> >> As always, we *need* your feedback - please read these and post your >> comments to the list, even if you only say "this looks good to me!" >> >> 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 >> >> _______________________________________________ >> IPFIX mailing list >> IPFIX@ietf.org >> https://www.ietf.org/mailman/listinfo/ipfix > -- --------------------------------------------------------------------- Nevil Brownlee Computer Science Department | ITS Phone: +64 9 373 7599 x88941 The University of Auckland FAX: +64 9 373 7453 Private Bag 92019, Auckland 1142, New Zealand From trammell@tik.ee.ethz.ch Fri Feb 10 05:12:59 2012 Return-Path: X-Original-To: ipfix@ietfa.amsl.com Delivered-To: ipfix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 60F8221F8575 for ; Fri, 10 Feb 2012 05:12:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.546 X-Spam-Level: X-Spam-Status: No, score=-6.546 tagged_above=-999 required=5 tests=[AWL=0.053, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M3eZHHkHjdGc for ; Fri, 10 Feb 2012 05:12:58 -0800 (PST) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) by ietfa.amsl.com (Postfix) with ESMTP id 0C16421F85EA for ; Fri, 10 Feb 2012 05:12:58 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id 52974D9309; Fri, 10 Feb 2012 14:12:57 +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 sTUEfZ7pOx2a; Fri, 10 Feb 2012 14:12:56 +0100 (MET) Received: from pb-10243.ethz.ch (pb-10243.ethz.ch [82.130.102.152]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: briant) by smtp.ee.ethz.ch (Postfix) with ESMTPSA id E6159D9300; Fri, 10 Feb 2012 14:12:56 +0100 (MET) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=iso-8859-1 From: Brian Trammell In-Reply-To: <4F290DFF.9090002@auckland.ac.nz> Date: Fri, 10 Feb 2012 14:12:56 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <88D854E9-2DAC-487A-94A8-32D79297E5AD@tik.ee.ethz.ch> References: <4F290DFF.9090002@auckland.ac.nz> To: Nevil Brownlee X-Mailer: Apple Mail (2.1251.1) Cc: IPFIX list Subject: Re: [IPFIX] Start of new WGLC for Flow Selection Techniques draft X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Feb 2012 13:12:59 -0000 Hi, Nevil, all, This is my WGLC review for the flow selection techniques draft (revision = 09). I have not performed a full editorial review; the comments here go = primarily to content. The document will need an editorial pass. = Capitalization, above all, seems arbitrary, especially with respect to = defined terminology. The diffs from -07 look good, in general. There seems to be no = difference at all between -08 and -09 aside from the revision number. I = have the following specific concerns, however: First, I'm still of two minds on the intended status of the document = (see my message to the list of 1 March 2011 for my first rant on this = topic: = http://www.ietf.org/mail-archive/web/ipfix/current/msg05775.html). It = still reads much like what it is: a port of PSAMP to the flow domain. It = doesn't address in sufficient depth other aspects of what I would take = to be the main point of flow selection at a mediator.=20 The following may be more indicative of my experience than anything = else. I pretty much only work with non-sampled flows built from = non-sampled packets (discounting the reliability of capture, metering, = and export), which I know makes me kind of weird. So the only flow = selection criterion presented within the document which interests me at = all is property match filtering, and what's there is rather anemic. It = doesn't provide an easy way to express 1. negated intervals,=20 2. disjoint intervals,=20 3. interval sets, 4. partial matches on flags IEs (i.e., "all ECN CE packets" which = requires masking the ToS byte), 5. properties made up as a combination of IEs (e.g., "all packets with a = source on the two main ETH Z=FCrich netblocks, 129.132.0.0/16 + = 82.130.0.0/16", which requires source address as well as source prefix = length), 6. general boolean expressions (e.g. "all TCP flows with less than three = packets plus all one packet UDP flows") ... These are just examples off the top of my head relating to things I've = had to do in the past few months. I think there are more in my message = of last March. Again, I think that trying to do full property-match filtering in a = non-restrictive, implementation-independent, and acceptably flexible way = is really, really hard. So I'm okay if this document doesn't attempt to = do it. But I would be a bit concerned with a statement that came out of = the IPFIX WG that endorsed this rather limited approach as The Way to = select flows based solely on their properties. Remedies, as before, = include reducing the document to Informational status or explicitly = restricting its scope to clarify that the purpose is solely data = reduction for operational purposes and not data analysis.=20 This has gone on long enough, though, so if my case is a corner case and = the rest of the WG is okay with it, I won't object; I just won't = implement it or claim compliance.=20 Second, The IPR issue is still a bit troubling. Without reference to the = merits of the claim itself, I concur with your suggestion to follow the = PSAMP route of making all flow selection methods explicitly optional. = This would require a new revision before sending it up to the IESG. Third, I'm a little confused as to why you're hardcoding a set of hash = functions (BOB, IPSX, CRC) into an Information Element definition, = though I notice the same thing was done in PSAMP. What if I want to use = another hash function? It is not clear to me that this set of flow = selector algorithms is sufficiently general that it will never be added = to in the future. If this is the case, the values of = flowSelectorAlgorithm should be backed by an IANA subregistry. If it is = exhaustive not counting the hash functions, then the = flowSelectorAlgorithm IE should have a Hash Function code point, and a = flowSelectorHashFunction IE backed by an IANA subregistry should be used = for hash functions. Fourth, samplingFlowInterval and samplingFlowSpace are defined as = unsigned32; why? Especially for space, I could see wanting to wait more = than 2^32 flows for certain applications. Similarly for = flowSamplingTimeInterval and flowSamplingTimeSpace, unsigned32 = microseconds will only give you the ability to express intervals up to = 4,300 seconds, or about an hour and twelve minutes. This seems = arbitrarily restrictive. I would suggest that if these remain expressed = as they are, they should be defined as unsigned64; RLE can always be = used if the common cases only need 32 (or even 16) bits. Fifth, Please review the references for whether they are normative or = informative. I'm pretty sure that 5101, 5470, and 6183 are normative. = Also, as the document is still in the WG process, it makes sense to = replace the 5101 and 5102 references with their -bis counterparts. Nits:=20 Check the capitalization of information element names (e.g., section 7.1 = should be flowSelectorAlgorithm; capitalization is inconsistent in = section 8.1). I'm not sure that a table is the best way to present the information in = section 8.1. You can refer back to the subsections of section 7 instead. Best regards, Brian On Feb 1, 2012, at 11:03 AM, Nevil Brownlee wrote: >=20 > Hi again all: >=20 > I should have said this in my last post - In Taipei we said "this > needs a new WGLC," this is the notice that it starts today, and > will finish on Wednesday, 15 February. >=20 > I need at least two emails supporting it, so do please have a look, > even if you only say "looks OK now!" >=20 > Cheers, Nevil >=20 > --=20 > --------------------------------------------------------------------- > 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 >=20 > _______________________________________________ > IPFIX mailing list > IPFIX@ietf.org > https://www.ietf.org/mailman/listinfo/ipfix From internet-drafts@ietf.org Fri Feb 10 07:58:36 2012 Return-Path: X-Original-To: ipfix@ietfa.amsl.com Delivered-To: ipfix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F3D6B21E8011; Fri, 10 Feb 2012 07:58:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.583 X-Spam-Level: X-Spam-Status: No, score=-102.583 tagged_above=-999 required=5 tests=[AWL=0.016, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vzYomZUpMmtY; Fri, 10 Feb 2012 07:58:34 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7202C21E800F; Fri, 10 Feb 2012 07:58:14 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.64p1 Message-ID: <20120210155814.20182.97887.idtracker@ietfa.amsl.com> Date: Fri, 10 Feb 2012 07:58:14 -0800 Cc: ipfix@ietf.org Subject: [IPFIX] I-D Action: draft-ietf-ipfix-ie-doctors-01.txt X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Feb 2012 15:58:36 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the IP Flow Information Export Working Gr= oup of the IETF. Title : Guidelines for Authors and Reviewers of IPFIX Informatio= n Elements Author(s) : Brian Trammell Benoit Claise Filename : draft-ietf-ipfix-ie-doctors-01.txt Pages : 33 Date : 2012-02-10 This document provides guidelines for the definition of IPFIX Information Elements for addition to the IANA IPFIX Information Element registry, in order to extend the applicability of the IPFIX protocol to new operations and management areas. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipfix-ie-doctors-01.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-ipfix-ie-doctors-01.txt From trammell@tik.ee.ethz.ch Fri Feb 10 08:00:21 2012 Return-Path: X-Original-To: ipfix@ietfa.amsl.com Delivered-To: ipfix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D24021E800F for ; Fri, 10 Feb 2012 08:00:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.549 X-Spam-Level: X-Spam-Status: No, score=-6.549 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MYAYRzUfiP8T for ; Fri, 10 Feb 2012 08:00:19 -0800 (PST) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) by ietfa.amsl.com (Postfix) with ESMTP id 291D821E8020 for ; Fri, 10 Feb 2012 08:00:19 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id 4E127D930B; Fri, 10 Feb 2012 17:00:18 +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 Tmlfka3vE+yD; Fri, 10 Feb 2012 17:00:18 +0100 (MET) Received: from pb-10243.ethz.ch (pb-10243.ethz.ch [82.130.102.152]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: briant) by smtp.ee.ethz.ch (Postfix) with ESMTPSA id 1B83ED9300; Fri, 10 Feb 2012 17:00:18 +0100 (MET) From: Brian Trammell Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Fri, 10 Feb 2012 17:00:17 +0100 References: <20120210155814.20182.97887.idtracker@ietfa.amsl.com> To: Nevil Brownlee , IPFIX list Message-Id: <9D4A1B21-0A4D-431C-BA0C-A8DBB730A470@tik.ee.ethz.ch> Mime-Version: 1.0 (Apple Message framework v1251.1) X-Mailer: Apple Mail (2.1251.1) Subject: [IPFIX] Fwd: I-D Action: draft-ietf-ipfix-ie-doctors-01.txt X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Feb 2012 16:00:21 -0000 Hi, Nevil, all, Rev -01 of the ie-doctors draft is now available; this contains the = final pending edits, and this revision is ready for WGLC. Many thanks, best regards, Brian Begin forwarded message: > From: internet-drafts@ietf.org > Subject: [IPFIX] I-D Action: draft-ietf-ipfix-ie-doctors-01.txt > Date: February 10, 2012 4:58:14 PM GMT+01:00 > To: i-d-announce@ietf.org > Cc: ipfix@ietf.org >=20 >=20 > 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. >=20 > Title : Guidelines for Authors and Reviewers of IPFIX = Information Elements > Author(s) : Brian Trammell > Benoit Claise > Filename : draft-ietf-ipfix-ie-doctors-01.txt > Pages : 33 > Date : 2012-02-10 >=20 > This document provides guidelines for the definition of IPFIX > Information Elements for addition to the IANA IPFIX Information > Element registry, in order to extend the applicability of the IPFIX > protocol to new operations and management areas. >=20 >=20 > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-ipfix-ie-doctors-01.txt >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > This Internet-Draft can be retrieved at: > ftp://ftp.ietf.org/internet-drafts/draft-ietf-ipfix-ie-doctors-01.txt >=20 > _______________________________________________ > IPFIX mailing list > IPFIX@ietf.org > https://www.ietf.org/mailman/listinfo/ipfix From n.brownlee@auckland.ac.nz Tue Feb 14 04:04:22 2012 Return-Path: X-Original-To: ipfix@ietfa.amsl.com Delivered-To: ipfix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 66D0221F87BF for ; Tue, 14 Feb 2012 04:04:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.289 X-Spam-Level: X-Spam-Status: No, score=-102.289 tagged_above=-999 required=5 tests=[AWL=0.310, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PAoahK0RhA5q for ; Tue, 14 Feb 2012 04:04:21 -0800 (PST) Received: from mx2.auckland.ac.nz (mx2.auckland.ac.nz [130.216.12.44]) by ietfa.amsl.com (Postfix) with ESMTP id EB14B21F86F1 for ; Tue, 14 Feb 2012 04:04:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=n.brownlee@auckland.ac.nz; q=dns/txt; s=uoa; t=1329221061; x=1360757061; h=message-id:date:from:mime-version:to:subject:references: in-reply-to:content-transfer-encoding; bh=rb4k0SHMrhLl9WNJSjIs7yZfiBzqPgAUWIeOSzpD6Sc=; b=d8oJMU9s2U1w9D6TW1yRpbAXG9QP2eOgJZUomLiw4Zwpt7W9ND9AwmuH KA6VjNJ1B3N4DyETvP7PgE40PVJtjvl1rdvO1hQdUQExBXwyWCcfUyDG+ Ab8vhPJ5h5arg5etVzQ30i75rPnjcWjza3t8Bn9qsyrw73L7DK+FjCWaP w=; X-IronPort-AV: E=Sophos;i="4.73,416,1325415600"; d="scan'208";a="102969766" X-Ironport-HAT: None - $RELAY-AUTH X-Ironport-Source: 158.38.40.197 - Outgoing - Outgoing-SSL Received: from unigjest-dhcp197.uninett.no (HELO [158.38.40.197]) ([158.38.40.197]) by mx2-int.auckland.ac.nz with ESMTP; 15 Feb 2012 01:04:16 +1300 Message-ID: <4F3A4DB8.4010205@auckland.ac.nz> Date: Tue, 14 Feb 2012 04:04:08 -0800 From: Nevil Brownlee User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.26) Gecko/20120131 Thunderbird/3.1.18 MIME-Version: 1.0 To: IPFIX list References: <20120210155814.20182.97887.idtracker@ietfa.amsl.com> <9D4A1B21-0A4D-431C-BA0C-A8DBB730A470@tik.ee.ethz.ch> In-Reply-To: <9D4A1B21-0A4D-431C-BA0C-A8DBB730A470@tik.ee.ethz.ch> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [IPFIX] WGLC for draft-ietf-ipfix-ie-doctors-01.txt X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Feb 2012 12:04:22 -0000 On 02/10/2012 08:00 AM, Brian Trammell wrote: > Hi, Nevil, all, > > Rev -01 of the ie-doctors draft is now available; this contains the final pending edits, and this revision is ready for WGLC. > > Many thanks, best regards, > > Brian > > Begin forwarded message: > >> From: internet-drafts@ietf.org >> Subject: [IPFIX] I-D Action: draft-ietf-ipfix-ie-doctors-01.txt >> Date: February 10, 2012 4:58:14 PM GMT+01:00 >> To: i-d-announce@ietf.org >> Cc: ipfix@ietf.org >> >> Hi all: OK, this time for sure! this WGLC starts now, and finishes Wednesday, 1 March. Please post your comments ! Cheers, Nevil >> 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 : Guidelines for Authors and Reviewers of IPFIX Information Elements >> Author(s) : Brian Trammell >> Benoit Claise >> Filename : draft-ietf-ipfix-ie-doctors-01.txt >> Pages : 33 >> Date : 2012-02-10 >> >> This document provides guidelines for the definition of IPFIX >> Information Elements for addition to the IANA IPFIX Information >> Element registry, in order to extend the applicability of the IPFIX >> protocol to new operations and management areas. >> >> >> A URL for this Internet-Draft is: >> http://www.ietf.org/internet-drafts/draft-ietf-ipfix-ie-doctors-01.txt >> >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >> >> This Internet-Draft can be retrieved at: >> ftp://ftp.ietf.org/internet-drafts/draft-ietf-ipfix-ie-doctors-01.txt >> >> _______________________________________________ >> IPFIX mailing list >> IPFIX@ietf.org >> https://www.ietf.org/mailman/listinfo/ipfix > -- --------------------------------------------------------------------- Nevil Brownlee Computer Science Department | ITS Phone: +64 9 373 7599 x88941 The University of Auckland FAX: +64 9 373 7453 Private Bag 92019, Auckland 1142, New Zealand From paitken@cisco.com Fri Feb 17 03:35:28 2012 Return-Path: X-Original-To: ipfix@ietfa.amsl.com Delivered-To: ipfix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0620A21F8773 for ; Fri, 17 Feb 2012 03:35:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.338 X-Spam-Level: X-Spam-Status: No, score=-10.338 tagged_above=-999 required=5 tests=[AWL=0.261, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9WSDUXj4J6+F for ; Fri, 17 Feb 2012 03:35:27 -0800 (PST) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id CFA0C21F876F for ; Fri, 17 Feb 2012 03:35:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=paitken@cisco.com; l=315; q=dns/txt; s=iport; t=1329478527; x=1330688127; h=message-id:date:from:mime-version:to:subject: content-transfer-encoding; bh=0tJU/BJnkVRQfempAXQ0ek+Z/RbrvuAvl8cr4d+s3OE=; b=C/DWSqYd4tzX5YRTpGd2OTC00XqyjJwgWt8E2iq5f/iH9GeBeY1FKOqJ x6HpZ7mnKZ1ZtLygfumYyKXzKwtqMcRmImwFXtPdL8+1cR8/K7Y/pbFss I7afXSbSULdBZl0QgIWI9K5gf4K7zAPMDQ2cR40DOsgXZJ/Zr8SqTrt/o A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AugRAEA6Pk+Q/khM/2dsb2JhbAAqGoMPggWqbAWBAIEHgg4BEBUzAwo2AgUWCwILAwIBAgFLDQgBAQUZh2cpmCCBJwGMZZIAgS+IEWiBSRcnAgIFAwUDBQMEAgIDCQEKAwECAQKBQoF9JgsKCoIXgRYElTeFXY0LbHA X-IronPort-AV: E=Sophos;i="4.73,437,1325462400"; d="scan'208";a="129736883" Received: from ams-core-3.cisco.com ([144.254.72.76]) by ams-iport-1.cisco.com with ESMTP; 17 Feb 2012 11:35:25 +0000 Received: from [10.55.88.183] (dhcp-10-55-88-183.cisco.com [10.55.88.183]) by ams-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id q1HBZPvC014051 for ; Fri, 17 Feb 2012 11:35:25 GMT Message-ID: <4F3E3B7E.5000704@cisco.com> Date: Fri, 17 Feb 2012 11:35:26 +0000 From: Paul Aitken User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.26) Gecko/20120131 Lightning/1.0b2 Thunderbird/3.1.18 MIME-Version: 1.0 To: IETF IPFIX Working Group Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: [IPFIX] IPFIX: errata 2052 enacted X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Feb 2012 11:35:28 -0000 Dear IPFIX experts, FYI, IANA has enacted errata 2052 by changing selectorId from 16 bits to 64 bits in the IPFIX IE registry, per discussion on the IPFIX mailing list: http://www.ietf.org/mail-archive/web/ipfix/current/msg05133.html http://www.rfc-editor.org/errata_search.php?eid=2052 P. From n.brownlee@auckland.ac.nz Sat Feb 18 05:50:07 2012 Return-Path: X-Original-To: ipfix@ietfa.amsl.com Delivered-To: ipfix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A241D21F84F1 for ; Sat, 18 Feb 2012 05:50:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.555 X-Spam-Level: X-Spam-Status: No, score=-100.555 tagged_above=-999 required=5 tests=[AWL=0.555, BAYES_05=-1.11, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XEFi-DGRzb6n for ; Sat, 18 Feb 2012 05:50:06 -0800 (PST) Received: from mx2.auckland.ac.nz (mx2.auckland.ac.nz [130.216.12.44]) by ietfa.amsl.com (Postfix) with ESMTP id A651A21F84EF for ; Sat, 18 Feb 2012 05:50:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=n.brownlee@auckland.ac.nz; q=dns/txt; s=uoa; t=1329573006; x=1361109006; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=0hc1xol97r5M8RqqmVPLbjDLaBCtaOlGtWic+4MDyZY=; b=nWn2LCdcZjNoUgcLZ3NM2zJuMwFvjrS9l6ISkHXOa41fE+ryph3+mjqc vFdNjzw+vPl9OEWrUcfCKyQD9J2bogQDU2oiU/EOrw6/A/QJzPX6BVvIX dlorudQd0Q4xCRLhtI/MUFJ64bc8wqY7dvfU0Q+rJkXxiGSHHMft5WCt9 Y=; X-IronPort-AV: E=Sophos;i="4.73,442,1325415600"; d="scan'208";a="104194316" X-Ironport-HAT: None - $RELAY-AUTH X-Ironport-Source: 82.194.219.180 - Outgoing - Outgoing-SSL Received: from reverse-82-194-219-180.loqal.no (HELO [82.194.219.180]) ([82.194.219.180]) by mx2-int.auckland.ac.nz with ESMTP; 19 Feb 2012 02:50:00 +1300 Message-ID: <4F3FAC7F.8090408@auckland.ac.nz> Date: Sat, 18 Feb 2012 05:49:51 -0800 From: Nevil Brownlee User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.27) Gecko/20120216 Thunderbird/3.1.19 MIME-Version: 1.0 To: Salvatore D'Antonio References: <4EC5C8A4.1040104@auckland.ac.nz> <4EC5E307.8080203@auckland.ac.nz> <003201ccdf47$f3f9fae0$dbedf0a0$@dantonio@uniparthenope.it> <4F29092D.5090003@auckland.ac.nz> <003201cce4ed$cd2f8f50$678eadf0$@dantonio@uniparthenope.it> In-Reply-To: <003201cce4ed$cd2f8f50$678eadf0$@dantonio@uniparthenope.it> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: "Henke, Christian" , lorenzo.peluso@fokus.fraunhofer.de, Tanja Zseby , IPFIX list Subject: Re: [IPFIX] Flow Selection Techniques draft - remaining issues X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Feb 2012 13:50:07 -0000 Hi Salvatore et al: The WGLC for the Selection Techniques draft finished last Wednesday, with one review from Brian Trammel. Brian felt the the Property Match Filtering section "seems pretty anaemic," but I see that section refers to RFC 5475. However 5475 seems to define it as "A packet is selected if a specific field in the packet equals a predefined value;" Brian wants to use a set of values for several fields, which sounds a lot like using a template to select flows. Could you add a paragraph to the Property Match Filter section, please, pointing out that using sets of fields/values to select flows is possible, preferable with an example to make it clear? My only other concern is the IPR question, we have consensus that making all the filtering methods optional would be OK. To do that, 5475 says "In order to be compliant with PSAMP, at least one of proposed schemes MUST be implemented." so that would be OK with 'this document' instead of 'PSAMP.' Another possibility, which I've just thought of, and I think I like better, would be to say "In order to be compliant with this document, at least the Property Match Filtering MUST be implemented." Which of these two sentences do you think would be best? With these two issues fixed, I believe we'd have WG consensus (at last)! Cheers, Nevil On 02/06/2012 08:38 AM, Salvatore D'Antonio wrote: > Dear Nevil, > > In section 5.2.2 of the Draft we reference to the size-dependent sampling > mechanism presented in Nick Duffield's paper "Charging from Sampled Network > Usage" as a possible method for flow record selection. Since patent n. > 7080136 "Method and apparatus for size-dependent sampling for managing a > data network" is on this sampling mechanism, we added an IPR disclosure from > AT&T on this. The IPR disclosure is related to version -05 of the Draft. > Other techniques/algorithms are presented in the Draft, but as far as I know > they are not covered by patents. My feeling is that there is no need for > other IPR disclosures. > Anyways, to remove any doubts, we might add a definite statement on the > optional use of such techniques for an implementor. > > What do you think? > > Kind regards, > > Salvatore > > > > > -----Messaggio originale----- > Da: Nevil Brownlee [mailto:n.brownlee@auckland.ac.nz] > Inviato: mercoledì 1 febbraio 2012 10:43 > A: Salvatore D'Antonio > Cc: tanja.zseby@fokus.fraunhofer.de; Nevil Brownlee > Oggetto: Re: R: [IPFIX] DRAFT minutes for Thursday's IPFIX meeting > > > Hi Salvatore& Tanja: > > Thanks for your email; I'm now on sabbatical leave in Norway, so I have > more time free to catch up on IPFIX - you'll have seen my note to the list > about the flow selection draft. > > How do you feel about the draft's IPR situation? > > Cheers, Nevil > > > On 01/30/2012 04:09 AM, Salvatore D'Antonio wrote: >> Dear Nevil, >> >> We have not received any comment yet from the IPFIXers on the latest > version >> of the Draft on Flow Selection Techniques. The document is now in WGLC > since >> the current version contains many changes with respect to the version >> presented at Quebec meeting. >> I would be very grateful to you if you could send a reminder to the list > in >> order to invite the reviewers to provide us with their feedback on the >> latest changes. >> >> Thanks in advance. >> >> Best regards, >> >> >> Salvatore >> >> >> -----Messaggio originale----- >> Da: ipfix-bounces@ietf.org [mailto:ipfix-bounces@ietf.org] Per conto di >> Nevil Brownlee >> Inviato: venerdì 18 novembre 2011 05:46 >> A: Romascanu, Dan (Dan) >> Cc: ipfix@ietf.org >> Oggetto: Re: [IPFIX] DRAFT minutes for Thursday's IPFIX meeting >> >> >> Oops, too quick to hit send. Here they are ... >> >> Cheers, Nevil >> >> >> On 18/11/11 15:53, Nevil Brownlee wrote: >>> >>> Hi Dan et al: >>> >>> Here are our draft minutes, and a one-para summary of them. >>> >>> WG members: please send any corrections or improvements to me. >>> >>> 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 From n.brownlee@auckland.ac.nz Mon Feb 20 11:24:17 2012 Return-Path: X-Original-To: ipfix@ietfa.amsl.com Delivered-To: ipfix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D4DF21F85C9 for ; Mon, 20 Feb 2012 11:24:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.577 X-Spam-Level: X-Spam-Status: No, score=-101.577 tagged_above=-999 required=5 tests=[AWL=1.022, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qmlw6Gra91UZ for ; Mon, 20 Feb 2012 11:24:12 -0800 (PST) Received: from mx2.auckland.ac.nz (mx2.auckland.ac.nz [130.216.12.44]) by ietfa.amsl.com (Postfix) with ESMTP id 4FE1821F8572 for ; Mon, 20 Feb 2012 11:24:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=n.brownlee@auckland.ac.nz; q=dns/txt; s=uoa; t=1329765852; x=1361301852; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=Dyw7VMbGrvBaIYPaGzgcj4GZPhyt5DnODMQK2eBvUKM=; b=reHiUz2+Ujh4UM8WpkArXz+4O3WxXpgEjbYeZRrPpqUaUTVmOGetF6GU G1XWmZxCAQ3eSX4WWpY73W9elBJh8Ye5Yq4et+YQnVE+DOYjoAM7kkwYi VCix7AlXjUDh4j8C6hTyd/NYjceCLh9pAIeKLnXEqVLzQKBUnVmQWpPaq c=; X-IronPort-AV: E=Sophos;i="4.73,452,1325415600"; d="scan'208";a="104501755" X-Ironport-HAT: None - $RELAY-AUTH X-Ironport-Source: 82.194.219.180 - Outgoing - Outgoing-SSL Received: from reverse-82-194-219-180.loqal.no (HELO [82.194.219.180]) ([82.194.219.180]) by mx2-int.auckland.ac.nz with ESMTP; 21 Feb 2012 08:24:09 +1300 Message-ID: <4F429DD6.8030305@auckland.ac.nz> Date: Mon, 20 Feb 2012 11:24:06 -0800 From: Nevil Brownlee User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.27) Gecko/20120216 Thunderbird/3.1.19 MIME-Version: 1.0 To: Brian Trammell References: <20120210155814.20182.97887.idtracker@ietfa.amsl.com> <9D4A1B21-0A4D-431C-BA0C-A8DBB730A470@tik.ee.ethz.ch> In-Reply-To: <9D4A1B21-0A4D-431C-BA0C-A8DBB730A470@tik.ee.ethz.ch> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: IPFIX list Subject: Re: [IPFIX] Fwd: I-D Action: draft-ietf-ipfix-ie-doctors-01.txt X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Feb 2012 19:24:17 -0000 Hi all: Oops, I'm catching up on things. It's now 20 Feb, so the WGLC for IE-Doctors starts now, and will end on Monday, 5 Mar 12. We *need* you reviews or comments, do please have a look at this draft and post to the IPFIX list. And if you haven't done that for the Aggregation draft, it's not too late - do it now! Cheers, Nevil On 02/10/2012 08:00 AM, Brian Trammell wrote: > Hi, Nevil, all, > > Rev -01 of the ie-doctors draft is now available; this contains the final pending edits, and this revision is ready for WGLC. > > Many thanks, best regards, > > Brian > > Begin forwarded message: > >> From: internet-drafts@ietf.org >> Subject: [IPFIX] I-D Action: draft-ietf-ipfix-ie-doctors-01.txt >> Date: February 10, 2012 4:58:14 PM GMT+01:00 >> To: i-d-announce@ietf.org >> Cc: ipfix@ietf.org >> >> >> A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Flow Information Export Working Group of the IETF. >> >> Title : Guidelines for Authors and Reviewers of IPFIX Information Elements >> Author(s) : Brian Trammell >> Benoit Claise >> Filename : draft-ietf-ipfix-ie-doctors-01.txt >> Pages : 33 >> Date : 2012-02-10 >> >> This document provides guidelines for the definition of IPFIX >> Information Elements for addition to the IANA IPFIX Information >> Element registry, in order to extend the applicability of the IPFIX >> protocol to new operations and management areas. >> >> >> A URL for this Internet-Draft is: >> http://www.ietf.org/internet-drafts/draft-ietf-ipfix-ie-doctors-01.txt >> >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >> >> This Internet-Draft can be retrieved at: >> ftp://ftp.ietf.org/internet-drafts/draft-ietf-ipfix-ie-doctors-01.txt >> >> _______________________________________________ >> IPFIX mailing list >> IPFIX@ietf.org >> https://www.ietf.org/mailman/listinfo/ipfix > -- --------------------------------------------------------------------- Nevil Brownlee Computer Science Department | ITS Phone: +64 9 373 7599 x88941 The University of Auckland FAX: +64 9 373 7453 Private Bag 92019, Auckland 1142, New Zealand From bclaise@cisco.com Mon Feb 20 12:44:58 2012 Return-Path: X-Original-To: ipfix@ietfa.amsl.com Delivered-To: ipfix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B1CDE21F8618 for ; Mon, 20 Feb 2012 12:44:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.452 X-Spam-Level: X-Spam-Status: No, score=-2.452 tagged_above=-999 required=5 tests=[AWL=0.147, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uS7jRMS3Hek3 for ; Mon, 20 Feb 2012 12:44:56 -0800 (PST) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by ietfa.amsl.com (Postfix) with ESMTP id 83E4721F85F8 for ; Mon, 20 Feb 2012 12:44:52 -0800 (PST) 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 q1KKippF022847; Mon, 20 Feb 2012 21:44:51 +0100 (CET) Received: from [10.60.67.84] (ams-bclaise-8913.cisco.com [10.60.67.84]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id q1KKion7016184; Mon, 20 Feb 2012 21:44:50 +0100 (CET) Message-ID: <4F42B0C3.4030605@cisco.com> Date: Mon, 20 Feb 2012 21:44:51 +0100 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: Rahul Patel References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: draft-ietf-ipfix-a9n@tools.ietf.org, "ipfix@ietf.org" Subject: Re: [IPFIX] draft-ietf-ipfix-a9n X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Feb 2012 20:44:58 -0000 Forwarding to the IPFIX mailing list for visibility. Thanks Rahul Regards, Benoit. > Hi, > > Here are my comments. > > I think correlation is important part of aggregation and this draft should > include a section on it. > There are different cases of correlation which the draft should touch. > > 1. Key fields of Aggregated Flow is same or the subset of all original > Flows > * In this case the correlation is straight forward. The values from > the original flows are simply merged (added/replaced/etc) into matching > aggregated flow. > 2. Key fields of Aggregated Flow is larger than at least one original flow. > * An example is best to describe this case. One original flow contain > (5-tuple, src-interface, byte) and another original flow contains > (5-tuple, transaction-delay). Now the aggregated flow has the key fields > of srcip, dstip and src-interface). One of the flow doesn't have > information on per source-interface basis. So the aggregator will perform > aggregation at two level and represent that data in ipfix-structured > format. The above data would look like > > Srcip, dstip, transaction_delay, { List of {src-interface, byte } } > ===== ===== ================= ================================== > A, B, 200, { (Ethernet0/0, 1500), > (Ethernet1/0, 1600) .. } > A, C, 300, { (Ethernet0/0, 1500) } > > > > Section 5.1.1 Distributing values across Interval > ------------------------------------------------- > * should add 'synchronized expiry of Original Flows' - Under this method > Flow C would be exported three times with start-time/end-time matching the > aggregation interval start-time/end-time. > > * There will always going to some original flows which will arrive late > and will not be accounted. It will be good have a cumulative counter of > such late arrivals on per template id (aggregated flow) basis. This > cumulative count should be periodically exported along with end-time > (time-of-snapshot). The counter will provide a degree of confidence in the > data exported by the aggregator for each template. > > Section 5.2 Spatial aggregation > ------------------------------- > * Is it a good idea to add an example of deriving a key in aggregate flow > from multiple keys or non-keys or combination of Original keys. E.g > 5-tuple translated to a session-id from metadata table. > * Along similar line, derivation of aggregate flow key from multiple keys > from different Original flows. One flow reports 5-tuple and byte-count. > The other flow reports 5-tuple and the user-id. The aggregated flow has > the user-id as key and byte-count as collect. I guess this can be > considered a correlation. > > > Thanks, > -Rahul > > > From trammell@tik.ee.ethz.ch Tue Feb 21 02:23:12 2012 Return-Path: X-Original-To: ipfix@ietfa.amsl.com Delivered-To: ipfix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B604F21F8674 for ; Tue, 21 Feb 2012 02:23:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.558 X-Spam-Level: X-Spam-Status: No, score=-6.558 tagged_above=-999 required=5 tests=[AWL=0.041, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OrttpSyX6JMm for ; Tue, 21 Feb 2012 02:23:11 -0800 (PST) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) by ietfa.amsl.com (Postfix) with ESMTP id 6995421F866D for ; Tue, 21 Feb 2012 02:23:10 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id 5FAF4D930D; Tue, 21 Feb 2012 11:23:09 +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 ur0ZRLRCic6I; Tue, 21 Feb 2012 11:23:09 +0100 (MET) Received: from pb-10243.ethz.ch (pb-10243.ethz.ch [82.130.102.152]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: briant) by smtp.ee.ethz.ch (Postfix) with ESMTPSA id 279D5D9304; Tue, 21 Feb 2012 11:23:09 +0100 (MET) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: Brian Trammell In-Reply-To: Date: Tue, 21 Feb 2012 11:23:08 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Rahul Patel X-Mailer: Apple Mail (2.1257) Cc: IPFIX list Subject: Re: [IPFIX] draft-ietf-ipfix-a9n X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Feb 2012 10:23:12 -0000 Hi, Rahul, Thank you very much for the comments! Comments thereon inline. On Feb 20, 2012, at 9:07 PM, Rahul Patel wrote: > Hi, >=20 > Here are my comments. >=20 > I think correlation is important part of aggregation and this draft = should > include a section on it. > There are different cases of correlation which the draft should touch. I'm not sure I agree, but it depends on what you mean by correlation. = More details below. > 1. Key fields of Aggregated Flow is same or the subset of all original > Flows > * In this case the correlation is straight forward. The values = from > the original flows are simply merged (added/replaced/etc) into = matching > aggregated flow. There is a _lot_ of complexity hiding in that "added/replaced/etc". For = "added" (that is, the reduced flow key as per section 5.2 of -a9n = represents a different Original Flow, i.e., a completely different set = of observed packets from the point of view of the sockets at the = endpoints) it is so straightforward it's already covered: this isn't = really correlation, but spatial aggregation, in the terminology of this = document. For "replaced" this requires the correlation process to know the = configuration of the Original Exporters so that it can differentiate = Original Flows representing different observed packets from the endpoint = POV from Original Flows representing the same packets. This is where = correlation gets interesting, and it's my opinion that it's also out of = scope for this document. For "etc" -- here's where it gets interesting, because there might be = significant analysis behind trying to figure out what you should do with = a set/cluster of N flows that look like each other. And now we're out of = scope for the WG, IMO. > 2. Key fields of Aggregated Flow is larger than at least one original = flow. > * An example is best to describe this case. One original flow = contain > (5-tuple, src-interface, byte) and another original flow contains > (5-tuple, transaction-delay). Now the aggregated flow has the key = fields > of srcip, dstip and src-interface). One of the flow doesn't have > information on per source-interface basis. So the aggregator will = perform > aggregation at two level and represent that data in ipfix-structured > format. The above data would look like >=20 > Srcip, dstip, transaction_delay, { List of {src-interface, byte } } > =3D=3D=3D=3D=3D =3D=3D=3D=3D=3D =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > A, B, 200, { (Ethernet0/0, 1500), > (Ethernet1/0, 1600) .. } > A, C, 300, { (Ethernet0/0, 1500) } Correlating {5-tuple, src-interface, octet-count} and {5-tuple, delay} = into {5-tuple, src-interface, octet-count, delay} is a completely = different operation than aggregating {5-tuple, src-interface, = octet-count, delay} into {src address, delay}, for example, and it = really doesn't make any sense to me to try to wedge these into the same = framework. Sure, it makes sense for a lot of applications to correlate = before aggregating (and the document touches on this already) but that = doesn't mean they're the same operation. I will note that this second example (tweaked; see next para) would be a = good basis for a new draft on an intermediate correlation process. But I = don't think that draft is this draft. (As an aside, I find this example scary because it hides a key flow = attribute, byte count, behind 6313 structured data, without any = particular reason to do so. I am concerned that such overuse of 6313 = poses a serious threat to the interoperability and adoption of IPFIX. = But that is out of scope for this email.) So, with respect to the inclusion of these comments in the draft, I am = strongly disinclined to do so. As author, I'll note that we decided = that correlation was explicitly out of scope for this draft (paragraph 4 = of section 3). As a WG contributor, I'll note that correlation is = explicitly not mentioned in the charter item for this draft, and that = correlation and aggregation are treated separately in 5982 and 6183. So = repurposing this draft at this point would go against what I believe is = the sense of the WG to date with respect to the relationship between = correlation and aggregation, so I wouldn't be comfortable creeping the = scope of the draft without a recharter. > Section 5.1.1 Distributing values across Interval > ------------------------------------------------- > * should add 'synchronized expiry of Original Flows' - Under this = method > Flow C would be exported three times with start-time/end-time matching = the > aggregation interval start-time/end-time. I don't see how the result of that flow is an Aggregated Flow as per = section 2. > * There will always going to some original flows which will arrive = late > and will not be accounted. It will be good have a cumulative counter = of > such late arrivals on per template id (aggregated flow) basis. This > cumulative count should be periodically exported along with end-time > (time-of-snapshot). The counter will provide a degree of confidence in = the > data exported by the aggregator for each template. You can always keep this from happening by lengthening the time you are = willing to wait for aggregation for active + idle + export queue delay + = 0.5RTT + collector queue delay; in most sane cases the active timeout = should dominate this.=20 It probably makes sense to note this in section 6 though. > Section 5.2 Spatial aggregation > ------------------------------- > * Is it a good idea to add an example of deriving a key in aggregate = flow > from multiple keys or non-keys or combination of Original keys. E.g > 5-tuple translated to a session-id from metadata table. > * Along similar line, derivation of aggregate flow key from multiple = keys > from different Original flows. One flow reports 5-tuple and = byte-count. > The other flow reports 5-tuple and the user-id. The aggregated flow = has > the user-id as key and byte-count as collect. I guess this can be > considered a correlation. Interesting suggestions, but I didn't (and can't now) see any way to = apply them without inventing new Information Elements to hold the = combined keys; the idea was to keep the examples as simple and = understandable as possible without confusing the issue by adding = additional irrelevant detail. However, it does make it difficult to=20 Let me think a bit and see if I can come up with a good combined-key = example. Best regards, Brian From Quittek@neclab.eu Tue Feb 21 04:11:32 2012 Return-Path: X-Original-To: ipfix@ietfa.amsl.com Delivered-To: ipfix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0706C21F85D2; Tue, 21 Feb 2012 04:11:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.299 X-Spam-Level: X-Spam-Status: No, score=-102.299 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Cbl-4POVUMHA; Tue, 21 Feb 2012 04:11:03 -0800 (PST) Received: from mailer1.neclab.eu (mailer1.neclab.eu [195.37.70.40]) by ietfa.amsl.com (Postfix) with ESMTP id C416A21F855D; Tue, 21 Feb 2012 04:10:56 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by mailer1.neclab.eu (Postfix) with ESMTP id 1B0FA28000085; Tue, 21 Feb 2012 13:10:56 +0100 (CET) X-Virus-Scanned: Amavisd on Debian GNU/Linux (netlab.nec.de) Received: from mailer1.neclab.eu ([127.0.0.1]) by localhost (atlas1.office.hd [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fJffZSdd0moc; Tue, 21 Feb 2012 13:10:56 +0100 (CET) Received: from ENCELADUS.office.hd (ENCELADUS.office.hd [192.168.24.52]) by mailer1.neclab.eu (Postfix) with ESMTP id F091E280001D9; Tue, 21 Feb 2012 13:10:35 +0100 (CET) Received: from DAPHNIS.office.hd ([169.254.2.41]) by ENCELADUS.office.hd ([192.168.24.52]) with mapi id 14.01.0323.003; Tue, 21 Feb 2012 13:10:30 +0100 From: Juergen Quittek To: Dan Romascanu , IESG Secretary , IETF IPFIX Working Group Thread-Topic: Write-up for draft-ietf-ipfix-rfc5815bis-01 Thread-Index: AQHM8JHKMvrGTrlb60K+qfwXI+Pk5w== Date: Tue, 21 Feb 2012 12:10:29 +0000 Message-ID: Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.14.0.111121 x-originating-ip: [10.1.2.219] Content-Type: text/plain; charset="us-ascii" Content-ID: <1882FE54E67EE24EAB406E2FE93F63B8@office.hd> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Ronald Bonica Subject: [IPFIX] Write-up for draft-ietf-ipfix-rfc5815bis-01 X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Feb 2012 12:11:32 -0000 Write-up for draft-ietf-ipfix-rfc5815bis-01 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D (1.a) Who is the Document Shepherd for this document? Has the Document Shepherd personally reviewed this version of the document and, in particular, does he or she believe this version is ready for forwarding to the IESG for publication? Juergen Quittek is the document shepherd. He has reviewed it personally and believes that this version is ready for forwarding to the IESG for publication. (1.b) Has the document had adequate review both from key WG members and from key non-WG members? Does the Document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? The document was sufficiently reviewed during WG last call. Comments from reviews have been addressed by an update after WGLC. The shepherd has no concern about the depth or breadth of the reviews. (1.c) Does the Document Shepherd have concerns that the document needs more review from a particular or broader perspective, e.g., security, operational complexity, someone familiar with AAA, internationalization, or XML? The document updates a MIB module. Although applied changes are rather small, a MIB doctor review is recommendable. (1.d) Does the Document Shepherd have any specific concerns or issues with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here. Has an IPR disclosure related to this document been filed? If so, please include a reference to the disclosure and summarize the WG discussion and conclusion on this issue. There is no such concern. (1.e) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it? There is a strong consensus in the IPFIX WG to publish this version of the document. There are no particular issues in the document without strong consensus in the IPFIX WG. (1.f) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarize the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is entered into the ID Tracker.) There was no appeal. (1.g) Has the Document Shepherd personally verified that the document satisfies all ID nits? (See http://www.ietf.org/ID-Checklist.html and http://tools.ietf.org/tools/idnits/.) Boilerplate checks are not enough; this check needs to be thorough. Has the document met all formal review criteria it needs to, such as the MIB Doctor, media type, and URI type reviews? If the document does not already indicate its intended status at the top of the first page, please indicate the intended status here. The document shepherd checked for ID nits. There is one in the last paragraph of section 1: '"RECOMMENDED"' -> '"RECOMMENDED", "NOT RECOMMENDED"' This can be fixed by the next update after IETF last call. (1.h) Has the document split its references into normative and informative? Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the strategy for their completion? Are there normative references that are downward references, as described in [RFC3967]? If so, list these downward references to support the Area Director in the Last Call procedure for them [RFC3967]. References are arranged correctly. (1.i) Has the Document Shepherd verified that the document's IANA Considerations section exists and is consistent with the body of the document? If the document specifies protocol extensions, are reservations requested in appropriate IANA registries? Are the IANA registries clearly identified? If the document creates a new registry, does it define the proposed initial contents of the registry and an allocation procedure for future registrations? Does it suggest a reasonable name for the new registry? See [RFC2434]. If the document describes an Expert Review process, has the Document Shepherd conferred with the Responsible Area Director so that the IESG can appoint the needed Expert during IESG Evaluation? The document defines actions for IANA in an appropriate way. (1.j) Has the Document Shepherd verified that sections of the document that are written in a formal language, such as XML code, BNF rules, MIB definitions, etc., validate correctly in an automated checker? The document contains two MIB modules in section 8. Both have been validated. (1.k) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections: Technical Summary 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.. Working Group Summary This is a minor update of RFC 5815. Changes concern the registration method of IPFIX packet selector functions by IANA and the Integration of errata filed for RFC 5815. The update is included in the current WG charter. The update was discussed at several WG meetings and on the mailing list. Document Quality The document is a minor updates of RFC5815. The document underwent a WG last call in the IPFIX WG in order to maintain the quality that RFC 5815 already has. Personnel Juergen Quittek is shepherding this document. Dan Romascanu is the responsible area director. From Quittek@neclab.eu Tue Feb 21 04:17:55 2012 Return-Path: X-Original-To: ipfix@ietfa.amsl.com Delivered-To: ipfix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0651321F8795 for ; Tue, 21 Feb 2012 04:17:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.399 X-Spam-Level: X-Spam-Status: No, score=-102.399 tagged_above=-999 required=5 tests=[AWL=0.200, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z4n6DWGNPl9c for ; Tue, 21 Feb 2012 04:17:54 -0800 (PST) Received: from mailer1.neclab.eu (mailer1.neclab.eu [195.37.70.40]) by ietfa.amsl.com (Postfix) with ESMTP id 7DDE121F876F for ; Tue, 21 Feb 2012 04:17:54 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by mailer1.neclab.eu (Postfix) with ESMTP id D0C98280004C3; Tue, 21 Feb 2012 13:17:53 +0100 (CET) X-Virus-Scanned: Amavisd on Debian GNU/Linux (netlab.nec.de) Received: from mailer1.neclab.eu ([127.0.0.1]) by localhost (atlas1.office.hd [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WIrHM7DZZDq3; Tue, 21 Feb 2012 13:17:53 +0100 (CET) Received: by mailer1.neclab.eu (Postfix, from userid 1001) id B2971280004C2; Tue, 21 Feb 2012 13:17:53 +0100 (CET) Received: from ENCELADUS.office.hd (ENCELADUS.office.hd [192.168.24.52]) by mailer1.neclab.eu (Postfix) with ESMTP id 81E11280004C3; Tue, 21 Feb 2012 13:17:28 +0100 (CET) Received: from DAPHNIS.office.hd ([169.254.2.41]) by ENCELADUS.office.hd ([192.168.24.52]) with mapi id 14.01.0323.003; Tue, 21 Feb 2012 13:17:28 +0100 From: Juergen Quittek To: Thomas Dietz , Benoit Claise , Atsushi Kobayashi , Gerhard Muenz Thread-Topic: nits in draft-ietf-ipfix-rfc5815bis-01 Thread-Index: AQHM8JLEqVSCrlycUkiltxN156PmIw== Date: Tue, 21 Feb 2012 12:17:28 +0000 Message-ID: Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.14.0.111121 x-originating-ip: [10.1.2.219] Content-Type: text/plain; charset="us-ascii" Content-ID: <432D4CCFB7FAD84CB6D89F859CA4045B@office.hd> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: IETF IPFIX Working Group Subject: [IPFIX] nits in draft-ietf-ipfix-rfc5815bis-01 X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Feb 2012 12:17:55 -0000 Dear authors of draft-ietf-ipfix-rfc5815bis-01, I just sent out the write-up for your draft. Thank you very much for creating and updating it. In the write-up you will find one nit to be fixed in the next version that you will probably post after AD review or IETF last call: In Section 9 (security considerations) you use the term "NOT RECOMMENDED". This term is not listed at the end of section 1 where you refer to RFC 2119 terminology. Please add it there: '"RECOMMENDED"' -> '"RECOMMENDED", "NOT RECOMMENDED"' Thanks, Juergen From Quittek@neclab.eu Tue Feb 21 04:19:56 2012 Return-Path: X-Original-To: ipfix@ietfa.amsl.com Delivered-To: ipfix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 62C9B21F87A7 for ; Tue, 21 Feb 2012 04:19:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.449 X-Spam-Level: X-Spam-Status: No, score=-102.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5Dr9G6Y9X6Ez for ; Tue, 21 Feb 2012 04:19:55 -0800 (PST) Received: from mailer1.neclab.eu (mailer1.neclab.eu [195.37.70.40]) by ietfa.amsl.com (Postfix) with ESMTP id 663C421F873D for ; Tue, 21 Feb 2012 04:19:55 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by mailer1.neclab.eu (Postfix) with ESMTP id BB107280004C3; Tue, 21 Feb 2012 13:19:54 +0100 (CET) X-Virus-Scanned: Amavisd on Debian GNU/Linux (netlab.nec.de) Received: from mailer1.neclab.eu ([127.0.0.1]) by localhost (atlas1.office.hd [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N4K7sV6iF5j8; Tue, 21 Feb 2012 13:19:54 +0100 (CET) Received: from METHONE.office.hd (Methone.office.hd [192.168.24.54]) by mailer1.neclab.eu (Postfix) with ESMTP id 9EE7A280004C2; Tue, 21 Feb 2012 13:19:44 +0100 (CET) Received: from DAPHNIS.office.hd ([169.254.2.41]) by METHONE.office.hd ([192.168.24.54]) with mapi id 14.01.0323.003; Tue, 21 Feb 2012 13:19:40 +0100 From: Juergen Quittek To: Dan Romascanu Thread-Topic: MIB doctor review for draft-ietf-ipfix-rfc5815bis-01 Thread-Index: AQHM8JMVifIpHwaYMESjTU6nuZZbtA== Date: Tue, 21 Feb 2012 12:19:44 +0000 Message-ID: Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.14.0.111121 x-originating-ip: [10.1.2.219] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: IETF IPFIX Working Group Subject: [IPFIX] MIB doctor review for draft-ietf-ipfix-rfc5815bis-01 X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Feb 2012 12:19:56 -0000 Dear Dan, draft-ietf-ipfix-rfc5815bis-01 needs a MIB doctor review. Although only small changes have been applied, the two contained MIB modules should be checked again by a MIB doctor. Will you organize this review or shall I take care of it? Thanks, Juergen From dromasca@avaya.com Tue Feb 21 04:24:40 2012 Return-Path: X-Original-To: ipfix@ietfa.amsl.com Delivered-To: ipfix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB89721F8593 for ; Tue, 21 Feb 2012 04:24:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.86 X-Spam-Level: X-Spam-Status: No, score=-102.86 tagged_above=-999 required=5 tests=[AWL=-0.261, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 59ScILustOiB for ; Tue, 21 Feb 2012 04:24:40 -0800 (PST) Received: from p-us1-iereast-outbound.us1.avaya.com (p-us1-iereast-outbound.us1.avaya.com [135.11.29.13]) by ietfa.amsl.com (Postfix) with ESMTP id E975321F853A for ; Tue, 21 Feb 2012 04:24:39 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Au0MAEKMQ0+HCzI1/2dsb2JhbABDqyiGdIEHgXMBAQEBAxIeCj8MBAIBCA0EBAEBCwYMCwEGAUUJCAIEEwgaqwOUM4wlLRADAoNbAYMZYwSbN4xv X-IronPort-AV: E=Sophos;i="4.73,457,1325480400"; d="scan'208";a="233098946" Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by p-us1-iereast-outbound.us1.avaya.com with ESMTP; 21 Feb 2012 07:24:39 -0500 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.13]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 21 Feb 2012 07:10:03 -0500 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: Tue, 21 Feb 2012 13:24:37 +0100 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: MIB doctor review for draft-ietf-ipfix-rfc5815bis-01 Thread-Index: AQHM8JMVifIpHwaYMESjTU6nuZZbtJZHRYAQ References: From: "Romascanu, Dan (Dan)" To: "Juergen Quittek" Cc: IETF IPFIX Working Group Subject: Re: [IPFIX] MIB doctor review for draft-ietf-ipfix-rfc5815bis-01 X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Feb 2012 12:24:41 -0000 Hi Juergen, There is no need for a MIB doctor review at this phase. Documents containing MIB modules get a MIB doctor review after the WG submitted them to the IESG, before or during the IETF Last Call. Early reviews (i.e. while the document is still in the hands of the WG) are an exception, and they are performed only if the MIB module is complex, with either data modeling issues, or raises SMI-related questions. This does not seem to be the case here. Regards, Dan > -----Original Message----- > From: Juergen Quittek [mailto:Quittek@neclab.eu] > Sent: Tuesday, February 21, 2012 2:20 PM > To: Romascanu, Dan (Dan) > Cc: IETF IPFIX Working Group > Subject: MIB doctor review for draft-ietf-ipfix-rfc5815bis-01 >=20 > Dear Dan, >=20 > draft-ietf-ipfix-rfc5815bis-01 needs a MIB doctor review. Although > only > small changes have been applied, the two contained MIB modules should > be > checked again by a MIB doctor. Will you organize this review or shall > I > take care of it? >=20 > Thanks, > Juergen From rahulp@cisco.com Tue Feb 21 07:34:25 2012 Return-Path: X-Original-To: ipfix@ietfa.amsl.com Delivered-To: ipfix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 539A221F8736 for ; Tue, 21 Feb 2012 07:34:25 -0800 (PST) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ILXiSrEE5FI4 for ; Tue, 21 Feb 2012 07:34:21 -0800 (PST) Received: from mtv-iport-3.cisco.com (mtv-iport-3.cisco.com [173.36.130.14]) by ietfa.amsl.com (Postfix) with ESMTP id 803A321F875C for ; Tue, 21 Feb 2012 07:34:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=rahulp@cisco.com; l=8868; q=dns/txt; s=iport; t=1329838458; x=1331048058; h=date:subject:from:to:cc:message-id:in-reply-to: mime-version:content-transfer-encoding; bh=ygglKvVX/dqqbLdQX8Zp1GSWBbNY7DhV6mUdldTQxXg=; b=Dr/j+ak2w8xUiuZCRq0NLxfkxy9jtH4U3hIiAOCbzM/FbIZITy2fb6kg fkmWcjHlniPZc4QNLM9dKjVobdRbkcHf+HzC+MQperT0zs4m69ctY/cMa BBBrrOH/cVpnSWhkM9mHfpfcrRE7xD8OKntlVx5B3xIP/e3RMRI8aNwad w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EAJa4Q0+rRDoI/2dsb2JhbABDshiBB4FzAQEBAwESARQTAgE1BxMIGIEFBg4FIodemXcBnwuLdgUDAQIBAQMKBAoIAQEoBQEGg2k8gz4EiE+MaYVdjS6BPg X-IronPort-AV: E=Sophos;i="4.73,458,1325462400"; d="scan'208";a="31631264" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-3.cisco.com with ESMTP; 21 Feb 2012 15:34:18 +0000 Received: from [161.44.71.234] ([161.44.71.234]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id q1LFYGwD013983; Tue, 21 Feb 2012 15:34:17 GMT User-Agent: Microsoft-MacOutlook/14.14.0.111121 Date: Tue, 21 Feb 2012 10:34:13 -0500 From: Rahul Patel To: Brian Trammell Message-ID: Thread-Topic: draft-ietf-ipfix-a9n In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Cc: IPFIX list Subject: Re: [IPFIX] draft-ietf-ipfix-a9n X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Feb 2012 15:34:25 -0000 Hi Brian, Comments inline..[RP] On 2/21/12 5:23 AM, "Brian Trammell" wrote: >Hi, Rahul, > >Thank you very much for the comments! Comments thereon inline. > >On Feb 20, 2012, at 9:07 PM, Rahul Patel wrote: > >> Hi, >> >> Here are my comments. >> >> I think correlation is important part of aggregation and this draft >>should >> include a section on it. >> There are different cases of correlation which the draft should touch. > >I'm not sure I agree, but it depends on what you mean by correlation. >More details below. > >> 1. Key fields of Aggregated Flow is same or the subset of all original >> Flows >> * In this case the correlation is straight forward. The values from >> the original flows are simply merged (added/replaced/etc) into matching >> aggregated flow. > >There is a _lot_ of complexity hiding in that "added/replaced/etc". For >"added" (that is, the reduced flow key as per section 5.2 of -a9n >represents a different Original Flow, i.e., a completely different set of >observed packets from the point of view of the sockets at the endpoints) >it is so straightforward it's already covered: this isn't really >correlation, but spatial aggregation, in the terminology of this document. > >For "replaced" this requires the correlation process to know the >configuration of the Original Exporters so that it can differentiate >Original Flows representing different observed packets from the endpoint >POV from Original Flows representing the same packets. This is where >correlation gets interesting, and it's my opinion that it's also out of >scope for this document. > >For "etc" -- here's where it gets interesting, because there might be >significant analysis behind trying to figure out what you should do with >a set/cluster of N flows that look like each other. And now we're out of >scope for the WG, IMO. [RP] 'added/replaced/etc' referred to non-key fields operation during aggregation. Counters will be added, min and max values may be replaced, averages would be recalculated, etc. > >> 2. Key fields of Aggregated Flow is larger than at least one original >>flow. >> * An example is best to describe this case. One original flow >>contain >> (5-tuple, src-interface, byte) and another original flow contains >> (5-tuple, transaction-delay). Now the aggregated flow has the key fields >> of srcip, dstip and src-interface). One of the flow doesn't have >> information on per source-interface basis. So the aggregator will >>perform >> aggregation at two level and represent that data in ipfix-structured >> format. The above data would look like >> >> Srcip, dstip, transaction_delay, { List of {src-interface, byte } } >> ===== ===== ================= ================================== >> A, B, 200, { (Ethernet0/0, 1500), >> (Ethernet1/0, 1600) .. } >> A, C, 300, { (Ethernet0/0, 1500) } > >Correlating {5-tuple, src-interface, octet-count} and {5-tuple, delay} >into {5-tuple, src-interface, octet-count, delay} is a completely >different operation than aggregating {5-tuple, src-interface, >octet-count, delay} into {src address, delay}, for example, and it really >doesn't make any sense to me to try to wedge these into the same >framework. Sure, it makes sense for a lot of applications to correlate >before aggregating (and the document touches on this already) but that >doesn't mean they're the same operation. > >I will note that this second example (tweaked; see next para) would be a >good basis for a new draft on an intermediate correlation process. But I >don't think that draft is this draft. > >(As an aside, I find this example scary because it hides a key flow >attribute, byte count, behind 6313 structured data, without any >particular reason to do so. I am concerned that such overuse of 6313 >poses a serious threat to the interoperability and adoption of IPFIX. But >that is out of scope for this email.) > >So, with respect to the inclusion of these comments in the draft, I am >strongly disinclined to do so. As author, I'll note that we decided that >correlation was explicitly out of scope for this draft (paragraph 4 of >section 3). As a WG contributor, I'll note that correlation is explicitly >not mentioned in the charter item for this draft, and that correlation >and aggregation are treated separately in 5982 and 6183. So repurposing >this draft at this point would go against what I believe is the sense of >the WG to date with respect to the relationship between correlation and >aggregation, so I wouldn't be comfortable creeping the scope of the draft >without a recharter. [RP] I am fine with a different draft and reference it in this draft. > >> Section 5.1.1 Distributing values across Interval >> ------------------------------------------------- >> * should add 'synchronized expiry of Original Flows' - Under this method >> Flow C would be exported three times with start-time/end-time matching >>the >> aggregation interval start-time/end-time. > >I don't see how the result of that flow is an Aggregated Flow as per >section 2. [RP] It is an aggregated flow. It is very similar to Proportional Uniform Distribution (section 5.1.1) but it is more accurate | | | | | |<--Flow A-->| | | | | 10 | | | | | | | | |<--Flow B-->| | | | 6 | 2 | | <== Bytes in each interval | | | | | |<-------------Flow C-------------->| | | 4 | 32 | 10 | <== Bytes in each interval | | | | | interval 0 | interval 1 | interval 2 | Using Synchronized method ========================= Aggregated Flow will have following bytes Interval 0 = (10 + 6 + 4) = 20 Interval 1 = (0 + 2 + 32) = 34 Interval 2 = (0 + 0 + 10) = 10 Using Proportional Uniform Distribution, ======================================== (assuming Interval is 30 seconds Flow B overlapped 15 secs of interval 0, 7.5 secs interval 1) Flow C overlapped 10 secs of interval 0, 30 secs of interval 1, 20 secs interval 2) Aggregate Flow will have following bytes Interval 0 = (10 + (6+2)*(15/22.5) + 46*(10/60)) = 10+5.33+7.66 = 23 Interval 1 = (0 + (6+2)*(7.5/22.5) + 46*(30/60)) = 0+2.66+23 = 25.66 Interval 0 = (0 + 0 + 46*(20/60)) = 0+0+15.33 = 15.33 > >> * There will always going to some original flows which will arrive late >> and will not be accounted. It will be good have a cumulative counter of >> such late arrivals on per template id (aggregated flow) basis. This >> cumulative count should be periodically exported along with end-time >> (time-of-snapshot). The counter will provide a degree of confidence in >>the >> data exported by the aggregator for each template. > >You can always keep this from happening by lengthening the time you are >willing to wait for aggregation for active + idle + export queue delay + >0.5RTT + collector queue delay; in most sane cases the active timeout >should dominate this. > >It probably makes sense to note this in section 6 though. [RP] Some device may not want hold the data for longer to avoid larger memory foot print. In those case it may be desired to have such counters. I guess one could say that it is implementation detail. Thanks, -Rahul > >> Section 5.2 Spatial aggregation >> ------------------------------- >> * Is it a good idea to add an example of deriving a key in aggregate >>flow >> from multiple keys or non-keys or combination of Original keys. E.g >> 5-tuple translated to a session-id from metadata table. >> * Along similar line, derivation of aggregate flow key from multiple >>keys >> from different Original flows. One flow reports 5-tuple and byte-count. >> The other flow reports 5-tuple and the user-id. The aggregated flow has >> the user-id as key and byte-count as collect. I guess this can be >> considered a correlation. > >Interesting suggestions, but I didn't (and can't now) see any way to >apply them without inventing new Information Elements to hold the >combined keys; the idea was to keep the examples as simple and >understandable as possible without confusing the issue by adding >additional irrelevant detail. However, it does make it difficult to > >Let me think a bit and see if I can come up with a good combined-key >example. > >Best regards, > >Brian > From trammell@tik.ee.ethz.ch Tue Feb 21 07:55:31 2012 Return-Path: X-Original-To: ipfix@ietfa.amsl.com Delivered-To: ipfix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 53FC021F85AD for ; Tue, 21 Feb 2012 07:55:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.56 X-Spam-Level: X-Spam-Status: No, score=-6.56 tagged_above=-999 required=5 tests=[AWL=0.039, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cnxG0AoIJEcy for ; Tue, 21 Feb 2012 07:55:30 -0800 (PST) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) by ietfa.amsl.com (Postfix) with ESMTP id C10BF21F856A for ; Tue, 21 Feb 2012 07:55:29 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id E5EC7D930A; Tue, 21 Feb 2012 16:55:28 +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 wj-ldspP1js3; Tue, 21 Feb 2012 16:55:28 +0100 (MET) Received: from pb-10243.ethz.ch (pb-10243.ethz.ch [82.130.102.152]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: briant) by smtp.ee.ethz.ch (Postfix) with ESMTPSA id AB9B0D9304; Tue, 21 Feb 2012 16:55:28 +0100 (MET) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: Brian Trammell In-Reply-To: Date: Tue, 21 Feb 2012 16:55:28 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <9F806D2C-944A-4E38-B386-63B670CD1913@tik.ee.ethz.ch> References: To: Rahul Patel X-Mailer: Apple Mail (2.1257) Cc: IPFIX list Subject: Re: [IPFIX] draft-ietf-ipfix-a9n X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Feb 2012 15:55:31 -0000 Hi, Rahul, Comments on comments on comments... :) On Feb 21, 2012, at 4:34 PM, Rahul Patel wrote: > Hi Brian, >=20 > Comments inline..[RP] >=20 > On 2/21/12 5:23 AM, "Brian Trammell" wrote: >=20 >> Hi, Rahul, >>=20 >> Thank you very much for the comments! Comments thereon inline. >>=20 >> On Feb 20, 2012, at 9:07 PM, Rahul Patel wrote: >>=20 >>> Hi, >>>=20 >>> Here are my comments. >>>=20 >>> I think correlation is important part of aggregation and this draft >>> should >>> include a section on it. >>> There are different cases of correlation which the draft should = touch. >>=20 >> I'm not sure I agree, but it depends on what you mean by correlation. >> More details below. >>=20 >>> 1. Key fields of Aggregated Flow is same or the subset of all = original >>> Flows >>> * In this case the correlation is straight forward. The values = from >>> the original flows are simply merged (added/replaced/etc) into = matching >>> aggregated flow. >>=20 >> There is a _lot_ of complexity hiding in that "added/replaced/etc". = For >> "added" (that is, the reduced flow key as per section 5.2 of -a9n >> represents a different Original Flow, i.e., a completely different = set of >> observed packets from the point of view of the sockets at the = endpoints) >> it is so straightforward it's already covered: this isn't really >> correlation, but spatial aggregation, in the terminology of this = document. >>=20 >> For "replaced" this requires the correlation process to know the >> configuration of the Original Exporters so that it can differentiate >> Original Flows representing different observed packets from the = endpoint >> POV from Original Flows representing the same packets. This is where >> correlation gets interesting, and it's my opinion that it's also out = of >> scope for this document. >>=20 >> For "etc" -- here's where it gets interesting, because there might be >> significant analysis behind trying to figure out what you should do = with >> a set/cluster of N flows that look like each other. And now we're out = of >> scope for the WG, IMO. >=20 > [RP] 'added/replaced/etc' referred to non-key fields operation during > aggregation. Counters will be added, min and max values may be = replaced, > averages would be recalculated, etc. >=20 >>=20 >>> 2. Key fields of Aggregated Flow is larger than at least one = original >>> flow. >>> * An example is best to describe this case. One original flow >>> contain >>> (5-tuple, src-interface, byte) and another original flow contains >>> (5-tuple, transaction-delay). Now the aggregated flow has the key = fields >>> of srcip, dstip and src-interface). One of the flow doesn't have >>> information on per source-interface basis. So the aggregator will >>> perform >>> aggregation at two level and represent that data in ipfix-structured >>> format. The above data would look like >>>=20 >>> Srcip, dstip, transaction_delay, { List of {src-interface, byte } } >>> =3D=3D=3D=3D=3D =3D=3D=3D=3D=3D =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>> A, B, 200, { (Ethernet0/0, 1500), >>> (Ethernet1/0, 1600) .. } >>> A, C, 300, { (Ethernet0/0, 1500) } >>=20 >> Correlating {5-tuple, src-interface, octet-count} and {5-tuple, = delay} >> into {5-tuple, src-interface, octet-count, delay} is a completely >> different operation than aggregating {5-tuple, src-interface, >> octet-count, delay} into {src address, delay}, for example, and it = really >> doesn't make any sense to me to try to wedge these into the same >> framework. Sure, it makes sense for a lot of applications to = correlate >> before aggregating (and the document touches on this already) but = that >> doesn't mean they're the same operation. >>=20 >> I will note that this second example (tweaked; see next para) would = be a >> good basis for a new draft on an intermediate correlation process. = But I >> don't think that draft is this draft. >>=20 >> (As an aside, I find this example scary because it hides a key flow >> attribute, byte count, behind 6313 structured data, without any >> particular reason to do so. I am concerned that such overuse of 6313 >> poses a serious threat to the interoperability and adoption of IPFIX. = But >> that is out of scope for this email.) >>=20 >> So, with respect to the inclusion of these comments in the draft, I = am >> strongly disinclined to do so. As author, I'll note that we decided = that >> correlation was explicitly out of scope for this draft (paragraph 4 = of >> section 3). As a WG contributor, I'll note that correlation is = explicitly >> not mentioned in the charter item for this draft, and that = correlation >> and aggregation are treated separately in 5982 and 6183. So = repurposing >> this draft at this point would go against what I believe is the sense = of >> the WG to date with respect to the relationship between correlation = and >> aggregation, so I wouldn't be comfortable creeping the scope of the = draft >> without a recharter. >=20 > [RP] I am fine with a different draft and reference it in this draft. This draft already makes a forward reference to a future correlation = draft. Given that a correlation draft would at the earliest be ready for = publication in the late 2013-2014 timeframe, it is IMO unrealistic to = hold the aggregation draft up waiting for it by referencing it = normatively. >>> Section 5.1.1 Distributing values across Interval >>> ------------------------------------------------- >>> * should add 'synchronized expiry of Original Flows' - Under this = method >>> Flow C would be exported three times with start-time/end-time = matching >>> the >>> aggregation interval start-time/end-time. >>=20 >> I don't see how the result of that flow is an Aggregated Flow as per >> section 2. >=20 > [RP] It is an aggregated flow. It is very similar to Proportional = Uniform > Distribution (section 5.1.1) but it is more accurate >=20 > | | | | > | |<--Flow A-->| | | | > | 10 | | | > | | | | > | |<--Flow B-->| | | > | 6 | 2 | | <=3D=3D Bytes = in each > interval > | | | | > | |<-------------Flow C-------------->| | > | 4 | 32 | 10 | <=3D=3D Bytes = in each > interval > | | | | > | interval 0 | interval 1 | interval 2 | >=20 >=20 >=20 > Using Synchronized method > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D > Aggregated Flow will have following bytes > Interval 0 =3D (10 + 6 + 4) =3D 20 > Interval 1 =3D (0 + 2 + 32) =3D 34 > Interval 2 =3D (0 + 0 + 10) =3D 10 >=20 >=20 > Using Proportional Uniform Distribution, > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > (assuming Interval is 30 seconds > Flow B overlapped 15 secs of interval 0, 7.5 secs interval 1) > Flow C overlapped 10 secs of interval 0, 30 secs of interval 1, 20 = secs > interval 2) >=20 > Aggregate Flow will have following bytes > Interval 0 =3D (10 + (6+2)*(15/22.5) + 46*(10/60)) =3D 10+5.33+7.66 =3D = 23 > Interval 1 =3D (0 + (6+2)*(7.5/22.5) + 46*(30/60)) =3D 0+2.66+23 =3D = 25.66 >=20 > Interval 0 =3D (0 + 0 + 46*(20/60)) =3D 0+0+15.33 =3D = 15.33 Ah. Okay. I see what you mean. Since in this case the Aggregation = Process has access to the original packet timings from the packets = making up the Original Flow, is this not covered by Direct distribution? >>> * There will always going to some original flows which will arrive = late >>> and will not be accounted. It will be good have a cumulative counter = of >>> such late arrivals on per template id (aggregated flow) basis. This >>> cumulative count should be periodically exported along with end-time >>> (time-of-snapshot). The counter will provide a degree of confidence = in >>> the >>> data exported by the aggregator for each template. >>=20 >> You can always keep this from happening by lengthening the time you = are >> willing to wait for aggregation for active + idle + export queue = delay + >> 0.5RTT + collector queue delay; in most sane cases the active timeout >> should dominate this. >>=20 >> It probably makes sense to note this in section 6 though. >=20 > [RP] Some device may not want hold the data for longer to avoid larger > memory foot print. In those case it may be desired to have such = counters. > I guess one could say that it is implementation detail. Yes, but not holding the data for longer is basically equivalent to = having a shorter active timeout, no? Best regards, Brian= From rahulp@cisco.com Tue Feb 21 08:26:21 2012 Return-Path: X-Original-To: ipfix@ietfa.amsl.com Delivered-To: ipfix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD92021F868A for ; Tue, 21 Feb 2012 08:26:21 -0800 (PST) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z+7yie3QOC6p for ; Tue, 21 Feb 2012 08:26:18 -0800 (PST) Received: from mtv-iport-4.cisco.com (mtv-iport-4.cisco.com [173.36.130.15]) by ietfa.amsl.com (Postfix) with ESMTP id 51CF621F86BA for ; Tue, 21 Feb 2012 08:26:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=rahulp@cisco.com; l=9770; q=dns/txt; s=iport; t=1329841578; x=1331051178; h=date:subject:from:to:cc:message-id:in-reply-to: mime-version:content-transfer-encoding; bh=4YG42lJgk++fJSElbk6ZjieTJghIO7j5eQcwlTy8g/k=; b=iksvSvDoUHzp8tRsOwbHBjiGEbEW3MKOuvib/RQmqpRBI+V/S2WAGi+T E4gaf+jpN71KiJmKHHuQjL0jA8DX+mg7CvcT/jOhyNQoOLyx6u0pozbrK m9ipApoEipTp933ytuN+29U61NXxYKhxw4PP+/nijW/ke+WB9LTz6oCsf 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EAFHEQ0+rRDoH/2dsb2JhbABDskOBB4FsBwEBAQQSARQTAgE1BxMIGIEFBg4FIoUmSJttAZ8Hi3YFBAIBBAoECggBASgFAQaDaTyDPgSIT4xphV2NLoE+ X-IronPort-AV: E=Sophos;i="4.73,458,1325462400"; d="scan'208";a="31429967" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-4.cisco.com with ESMTP; 21 Feb 2012 16:26:11 +0000 Received: from [161.44.71.234] ([161.44.71.234]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id q1LGQ5IU007581; Tue, 21 Feb 2012 16:26:10 GMT User-Agent: Microsoft-MacOutlook/14.14.0.111121 Date: Tue, 21 Feb 2012 11:26:03 -0500 From: Rahul Patel To: Brian Trammell Message-ID: Thread-Topic: draft-ietf-ipfix-a9n In-Reply-To: <9F806D2C-944A-4E38-B386-63B670CD1913@tik.ee.ethz.ch> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Cc: IPFIX list Subject: Re: [IPFIX] draft-ietf-ipfix-a9n X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Feb 2012 16:26:21 -0000 Hi Brain, "This draft already makes a forward reference to a future correlation draft. Given that a correlation draft would at the earliest be ready for publication in the late 2013-2014 timeframe, it is IMO unrealistic to hold the aggregation draft up waiting for it by referencing it normatively." [RP] agree. Regarding Direct distribution - I am not sure if it covers the synchronized method. The description in direct distribution is not enough. May be an example would help. Regarding the late counter/active timeout - In most cases shorter active timeout would work. Thanks -Rahul On 2/21/12 10:55 AM, "Brian Trammell" wrote: >Hi, Rahul, > >Comments on comments on comments... :) > >On Feb 21, 2012, at 4:34 PM, Rahul Patel wrote: > >> Hi Brian, >> >> Comments inline..[RP] >> >> On 2/21/12 5:23 AM, "Brian Trammell" wrote: >> >>> Hi, Rahul, >>> >>> Thank you very much for the comments! Comments thereon inline. >>> >>> On Feb 20, 2012, at 9:07 PM, Rahul Patel wrote: >>> >>>> Hi, >>>> >>>> Here are my comments. >>>> >>>> I think correlation is important part of aggregation and this draft >>>> should >>>> include a section on it. >>>> There are different cases of correlation which the draft should touch. >>> >>> I'm not sure I agree, but it depends on what you mean by correlation. >>> More details below. >>> >>>> 1. Key fields of Aggregated Flow is same or the subset of all original >>>> Flows >>>> * In this case the correlation is straight forward. The values from >>>> the original flows are simply merged (added/replaced/etc) into >>>>matching >>>> aggregated flow. >>> >>> There is a _lot_ of complexity hiding in that "added/replaced/etc". For >>> "added" (that is, the reduced flow key as per section 5.2 of -a9n >>> represents a different Original Flow, i.e., a completely different set >>>of >>> observed packets from the point of view of the sockets at the >>>endpoints) >>> it is so straightforward it's already covered: this isn't really >>> correlation, but spatial aggregation, in the terminology of this >>>document. >>> >>> For "replaced" this requires the correlation process to know the >>> configuration of the Original Exporters so that it can differentiate >>> Original Flows representing different observed packets from the >>>endpoint >>> POV from Original Flows representing the same packets. This is where >>> correlation gets interesting, and it's my opinion that it's also out of >>> scope for this document. >>> >>> For "etc" -- here's where it gets interesting, because there might be >>> significant analysis behind trying to figure out what you should do >>>with >>> a set/cluster of N flows that look like each other. And now we're out >>>of >>> scope for the WG, IMO. >> >> [RP] 'added/replaced/etc' referred to non-key fields operation during >> aggregation. Counters will be added, min and max values may be replaced, >> averages would be recalculated, etc. >> >>> >>>> 2. Key fields of Aggregated Flow is larger than at least one original >>>> flow. >>>> * An example is best to describe this case. One original flow >>>> contain >>>> (5-tuple, src-interface, byte) and another original flow contains >>>> (5-tuple, transaction-delay). Now the aggregated flow has the key >>>>fields >>>> of srcip, dstip and src-interface). One of the flow doesn't have >>>> information on per source-interface basis. So the aggregator will >>>> perform >>>> aggregation at two level and represent that data in ipfix-structured >>>> format. The above data would look like >>>> >>>> Srcip, dstip, transaction_delay, { List of {src-interface, byte } } >>>> ===== ===== ================= ================================== >>>> A, B, 200, { (Ethernet0/0, 1500), >>>> (Ethernet1/0, 1600) .. } >>>> A, C, 300, { (Ethernet0/0, 1500) } >>> >>> Correlating {5-tuple, src-interface, octet-count} and {5-tuple, delay} >>> into {5-tuple, src-interface, octet-count, delay} is a completely >>> different operation than aggregating {5-tuple, src-interface, >>> octet-count, delay} into {src address, delay}, for example, and it >>>really >>> doesn't make any sense to me to try to wedge these into the same >>> framework. Sure, it makes sense for a lot of applications to correlate >>> before aggregating (and the document touches on this already) but that >>> doesn't mean they're the same operation. >>> >>> I will note that this second example (tweaked; see next para) would be >>>a >>> good basis for a new draft on an intermediate correlation process. But >>>I >>> don't think that draft is this draft. >>> >>> (As an aside, I find this example scary because it hides a key flow >>> attribute, byte count, behind 6313 structured data, without any >>> particular reason to do so. I am concerned that such overuse of 6313 >>> poses a serious threat to the interoperability and adoption of IPFIX. >>>But >>> that is out of scope for this email.) >>> >>> So, with respect to the inclusion of these comments in the draft, I am >>> strongly disinclined to do so. As author, I'll note that we decided >>>that >>> correlation was explicitly out of scope for this draft (paragraph 4 of >>> section 3). As a WG contributor, I'll note that correlation is >>>explicitly >>> not mentioned in the charter item for this draft, and that correlation >>> and aggregation are treated separately in 5982 and 6183. So repurposing >>> this draft at this point would go against what I believe is the sense >>>of >>> the WG to date with respect to the relationship between correlation and >>> aggregation, so I wouldn't be comfortable creeping the scope of the >>>draft >>> without a recharter. >> >> [RP] I am fine with a different draft and reference it in this draft. > >This draft already makes a forward reference to a future correlation >draft. Given that a correlation draft would at the earliest be ready for >publication in the late 2013-2014 timeframe, it is IMO unrealistic to >hold the aggregation draft up waiting for it by referencing it >normatively. > >>>> Section 5.1.1 Distributing values across Interval >>>> ------------------------------------------------- >>>> * should add 'synchronized expiry of Original Flows' - Under this >>>>method >>>> Flow C would be exported three times with start-time/end-time matching >>>> the >>>> aggregation interval start-time/end-time. >>> >>> I don't see how the result of that flow is an Aggregated Flow as per >>> section 2. >> >> [RP] It is an aggregated flow. It is very similar to Proportional >>Uniform >> Distribution (section 5.1.1) but it is more accurate >> >> | | | | >> | |<--Flow A-->| | | | >> | 10 | | | >> | | | | >> | |<--Flow B-->| | | >> | 6 | 2 | | <== Bytes in >>each >> interval >> | | | | >> | |<-------------Flow C-------------->| | >> | 4 | 32 | 10 | <== Bytes in >>each >> interval >> | | | | >> | interval 0 | interval 1 | interval 2 | >> >> >> >> Using Synchronized method >> ========================= >> Aggregated Flow will have following bytes >> Interval 0 = (10 + 6 + 4) = 20 >> Interval 1 = (0 + 2 + 32) = 34 >> Interval 2 = (0 + 0 + 10) = 10 >> >> >> Using Proportional Uniform Distribution, >> ======================================== >> (assuming Interval is 30 seconds >> Flow B overlapped 15 secs of interval 0, 7.5 secs interval 1) >> Flow C overlapped 10 secs of interval 0, 30 secs of interval 1, 20 secs >> interval 2) >> >> Aggregate Flow will have following bytes >> Interval 0 = (10 + (6+2)*(15/22.5) + 46*(10/60)) = 10+5.33+7.66 = 23 >> Interval 1 = (0 + (6+2)*(7.5/22.5) + 46*(30/60)) = 0+2.66+23 = 25.66 >> >> Interval 0 = (0 + 0 + 46*(20/60)) = 0+0+15.33 = 15.33 > >Ah. Okay. I see what you mean. Since in this case the Aggregation Process >has access to the original packet timings from the packets making up the >Original Flow, is this not covered by Direct distribution? > >>>> * There will always going to some original flows which will arrive >>>>late >>>> and will not be accounted. It will be good have a cumulative counter >>>>of >>>> such late arrivals on per template id (aggregated flow) basis. This >>>> cumulative count should be periodically exported along with end-time >>>> (time-of-snapshot). The counter will provide a degree of confidence in >>>> the >>>> data exported by the aggregator for each template. >>> >>> You can always keep this from happening by lengthening the time you are >>> willing to wait for aggregation for active + idle + export queue delay >>>+ >>> 0.5RTT + collector queue delay; in most sane cases the active timeout >>> should dominate this. >>> >>> It probably makes sense to note this in section 6 though. >> >> [RP] Some device may not want hold the data for longer to avoid larger >> memory foot print. In those case it may be desired to have such >>counters. >> I guess one could say that it is implementation detail. > >Yes, but not holding the data for longer is basically equivalent to >having a shorter active timeout, no? > >Best regards, > >Brian From salvatore.dantonio@uniparthenope.it Tue Feb 21 08:56:31 2012 Return-Path: X-Original-To: ipfix@ietfa.amsl.com Delivered-To: ipfix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD02521F888A for ; Tue, 21 Feb 2012 08:56:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.144 X-Spam-Level: *** X-Spam-Status: No, score=3.144 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, MSGID_MULTIPLE_AT=1.449] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pfzCJG82Unm8 for ; Tue, 21 Feb 2012 08:56:27 -0800 (PST) Received: from mail.uniparthenope.it (mail.uniparthenope.it [192.167.9.244]) by ietfa.amsl.com (Postfix) with ESMTP id 8E3AB21F8889 for ; Tue, 21 Feb 2012 08:56:27 -0800 (PST) Received: from mail2.uniparthenope.it (unknown [10.1.2.108]) by mail.uniparthenope.it (Postfix) with SMTP id B3C9810A51; Tue, 21 Feb 2012 16:56:24 +0000 (UTC) Received: from (unknown [192.168.241.108]) by mail2.uniparthenope.it with smtp id 1dd2_fce45d34_5cac_11e1_a0f7_001372515a5c; Tue, 21 Feb 2012 17:56:23 +0100 Received: from spamk.uniparthenope.it (localhost [127.0.0.1]) by spamk.uniparthenope.it (Postfix) with ESMTP id 4A552C42EE; Tue, 21 Feb 2012 18:53:57 +0100 (CET) Received: by spamk.uniparthenope.it (Postfix, from userid 500) id 45AACC432D; Tue, 21 Feb 2012 18:53:57 +0100 (CET) Received: from mail.uniparthenope.it (mail.uniparthenope.it [192.167.9.244]) by spamk.uniparthenope.it (Postfix) with ESMTP id 3D5C1C42EE; Tue, 21 Feb 2012 18:53:44 +0100 (CET) Received: from saldantoPC (unknown [192.168.162.11]) (Authenticated sender: salvatore.dantonio@uniparthenope.it) by mail.uniparthenope.it (Postfix) with ESMTPA id D9E1813B16; Tue, 21 Feb 2012 17:56:10 +0100 (CET) From: "Salvatore D'Antonio" To: "'Nevil Brownlee'" References: <4EC5C8A4.1040104@auckland.ac.nz> <4EC5E307.8080203@auckland.ac.nz> <003201ccdf47$f3f9fae0$dbedf0a0$@dantonio@uniparthenope.it> <4F29092D.5090003@auckland.ac.nz> <003201cce4ed$cd2f8f50$678eadf0$@dantonio@uniparthenope.it> <4F3FAC7F.8090408@auckland.ac.nz> In-Reply-To: <4F3FAC7F.8090408@auckland.ac.nz> Date: Tue, 21 Feb 2012 17:56:14 +0100 MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AczuRFNSqGb+VsZmQSeig5qcp5MzjACdG6vg Content-Language: it Message-ID: <005c01ccf0b9$b899b980$29cd2c80$@dantonio@uniparthenope.it> Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Anti-Virus: Kaspersky Anti-Virus for Linux Mail Server 5.6.42/RELEASE, bases: 20120221 #7043251, check: 20120221 clean Cc: "'Henke, Christian'" , lorenzo.peluso@fokus.fraunhofer.de, 'Tanja Zseby' , 'IPFIX list' Subject: [IPFIX] R: Flow Selection Techniques draft - remaining issues X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Feb 2012 16:56:32 -0000 Dear Nevil, My answers inline. -----Messaggio originale----- Da: Nevil Brownlee [mailto:n.brownlee@auckland.ac.nz]=20 Inviato: sabato 18 febbraio 2012 14:50 A: Salvatore D'Antonio Cc: Tanja Zseby; Henke, Christian; lorenzo.peluso@fokus.fraunhofer.de; = IPFIX list Oggetto: Re: Flow Selection Techniques draft - remaining issues Hi Salvatore et al: The WGLC for the Selection Techniques draft finished last Wednesday, = with one review from Brian Trammel. Brian felt the the Property Match Filtering section "seems pretty = anaemic," but I see that section refers to RFC 5475. However 5475 seems to define = it as "A packet is selected if a specific field in the packet equals a predefined value;" Brian wants to use a set of values for several = fields, which sounds a lot like using a template to select flows. Could you add a paragraph to the Property Match Filter section, please, pointing out that using sets of fields/values to select flows is possible, preferable with an example to make it clear? Ok, I will do that. My only other concern is the IPR question, we have consensus that making all the filtering methods optional would be OK. To do that, 5475 says "In order to be compliant with PSAMP, at least one of proposed schemes = MUST be implemented." so that would be OK with 'this document' instead of 'PSAMP.' Another possibility, which I've just thought of, and I think I like = better, would be to say "In order to be compliant with this document, at least the Property Match Filtering MUST be implemented." Which of these two sentences do you think would be best? I agree with you. The second sentence is fine to me. With these two issues fixed, I believe we'd have WG consensus (at last)! Cheers, Nevil Thanks a lot for your support. Cheers, Salvatore On 02/06/2012 08:38 AM, Salvatore D'Antonio wrote: > Dear Nevil, > > In section 5.2.2 of the Draft we reference to the size-dependent = sampling > mechanism presented in Nick Duffield's paper "Charging from Sampled Network > Usage" as a possible method for flow record selection. Since patent n. > 7080136 "Method and apparatus for size-dependent sampling for managing = a > data network" is on this sampling mechanism, we added an IPR = disclosure from > AT&T on this. The IPR disclosure is related to version -05 of the = Draft. > Other techniques/algorithms are presented in the Draft, but as far as = I know > they are not covered by patents. My feeling is that there is no need = for > other IPR disclosures. > Anyways, to remove any doubts, we might add a definite statement on = the > optional use of such techniques for an implementor. > > What do you think? > > Kind regards, > > Salvatore > > > > > -----Messaggio originale----- > Da: Nevil Brownlee [mailto:n.brownlee@auckland.ac.nz] > Inviato: mercoled=EC 1 febbraio 2012 10:43 > A: Salvatore D'Antonio > Cc: tanja.zseby@fokus.fraunhofer.de; Nevil Brownlee > Oggetto: Re: R: [IPFIX] DRAFT minutes for Thursday's IPFIX meeting > > > Hi Salvatore& Tanja: > > Thanks for your email; I'm now on sabbatical leave in Norway, so I = have > more time free to catch up on IPFIX - you'll have seen my note to the = list > about the flow selection draft. > > How do you feel about the draft's IPR situation? > > Cheers, Nevil > > > On 01/30/2012 04:09 AM, Salvatore D'Antonio wrote: >> Dear Nevil, >> >> We have not received any comment yet from the IPFIXers on the latest > version >> of the Draft on Flow Selection Techniques. The document is now in = WGLC > since >> the current version contains many changes with respect to the version >> presented at Quebec meeting. >> I would be very grateful to you if you could send a reminder to the = list > in >> order to invite the reviewers to provide us with their feedback on = the >> latest changes. >> >> Thanks in advance. >> >> Best regards, >> >> >> Salvatore >> >> >> -----Messaggio originale----- >> Da: ipfix-bounces@ietf.org [mailto:ipfix-bounces@ietf.org] Per conto = di >> Nevil Brownlee >> Inviato: venerd=EC 18 novembre 2011 05:46 >> A: Romascanu, Dan (Dan) >> Cc: ipfix@ietf.org >> Oggetto: Re: [IPFIX] DRAFT minutes for Thursday's IPFIX meeting >> >> >> Oops, too quick to hit send. Here they are ... >> >> Cheers, Nevil >> >> >> On 18/11/11 15:53, Nevil Brownlee wrote: >>> >>> Hi Dan et al: >>> >>> Here are our draft minutes, and a one-para summary of them. >>> >>> WG members: please send any corrections or improvements to me. >>> >>> Cheers, Nevil >> > > --=20 --------------------------------------------------------------------- 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 ----- Nessun virus nel messaggio. Controllato da AVG - www.avg.com Versione: 2012.0.1913 / Database dei virus: 2112/4815 - Data di = rilascio: 17/02/2012 From bclaise@cisco.com Tue Feb 21 08:57:19 2012 Return-Path: X-Original-To: ipfix@ietfa.amsl.com Delivered-To: ipfix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF41021F8888 for ; Tue, 21 Feb 2012 08:57:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.455 X-Spam-Level: X-Spam-Status: No, score=-2.455 tagged_above=-999 required=5 tests=[AWL=0.144, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bKKWpfZNmGnq for ; Tue, 21 Feb 2012 08:57:15 -0800 (PST) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by ietfa.amsl.com (Postfix) with ESMTP id 7BC0C21F8881 for ; Tue, 21 Feb 2012 08:57:15 -0800 (PST) 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 q1LGvEjq003607 for ; Tue, 21 Feb 2012 17:57:14 +0100 (CET) Received: from [10.60.67.84] (ams-bclaise-8913.cisco.com [10.60.67.84]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id q1LGvD6a019139 for ; Tue, 21 Feb 2012 17:57:14 +0100 (CET) Message-ID: <4F43CCE9.1040006@cisco.com> Date: Tue, 21 Feb 2012 17:57:13 +0100 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: "ipfix@ietf.org" References: <4EC4F028.2040201@cisco.com> In-Reply-To: <4EC4F028.2040201@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [IPFIX] draft-ietf-tls-dtls-heartbeat X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Feb 2012 16:57:19 -0000 Dear all, FYI. This is now a RFC "Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS) Heartbeat Extension", RFC 6520 Regards, Benoit. > Dear all, > > As Chris mentioned during the meeting. > https://datatracker.ietf.org/doc/draft-ietf-tls-dtls-heartbeat/ > Note the 3 DISCUSS. > > Regards, Benoit. > _______________________________________________ > IPFIX mailing list > IPFIX@ietf.org > https://www.ietf.org/mailman/listinfo/ipfix > > From iesg-secretary@ietf.org Thu Feb 23 07:38:04 2012 Return-Path: X-Original-To: ipfix@ietfa.amsl.com Delivered-To: ipfix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3974321F8817; Thu, 23 Feb 2012 07:38:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.466 X-Spam-Level: X-Spam-Status: No, score=-102.466 tagged_above=-999 required=5 tests=[AWL=0.133, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4Ib2Tl6KMFnE; Thu, 23 Feb 2012 07:38:03 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 298DD21F87D8; Thu, 23 Feb 2012 07:38:03 -0800 (PST) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 3.64p2 Message-ID: <20120223153803.14088.17319.idtracker@ietfa.amsl.com> Date: Thu, 23 Feb 2012 07:38:03 -0800 Cc: ipfix@ietf.org Subject: [IPFIX] Last Call: (Definitions of Managed Objects for IP Flow Information Export) to Proposed Standard X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: ietf@ietf.org List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Feb 2012 15:38:04 -0000 The IESG has received a request from the IP Flow Information Export WG (ipfix) to consider the following document: - 'Definitions of Managed Objects for IP Flow Information Export' as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2012-03-08. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract 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. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-ipfix-rfc5815bis/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-ipfix-rfc5815bis/ No IPR declarations have been submitted directly on this I-D. From Christopher.White@riverbed.com Wed Feb 22 08:44:00 2012 Return-Path: X-Original-To: ipfix@ietfa.amsl.com Delivered-To: ipfix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E9FFB21F88B7 for ; Wed, 22 Feb 2012 08:43:59 -0800 (PST) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hT31HbW0hevi for ; Wed, 22 Feb 2012 08:43:55 -0800 (PST) Received: from smtp2.riverbed.com (eng.riverbed.com [208.70.196.44]) by ietfa.amsl.com (Postfix) with ESMTP id BE0EF21F88C0 for ; Wed, 22 Feb 2012 08:43:54 -0800 (PST) Received: from unknown (HELO 365EXCH-HUB-P2.nbttech.com) ([10.16.4.1]) by smtp2.riverbed.com with ESMTP; 22 Feb 2012 08:43:53 -0800 Received: from 365EXCH-MBX-P1.nbttech.com ([fe80::fd90:c034:9ba7:e0a3]) by 365EXCH-HUB-P2.nbttech.com ([fe80::4998:6c24:821c:b3e1%16]) with mapi id 14.01.0339.001; Wed, 22 Feb 2012 08:43:53 -0800 From: Christopher White To: Benoit Claise , Brian Trammell Thread-Topic: [IPFIX] Flow in IPFIX -> not only IP Flows Thread-Index: Act1CjbvJx7XOFYyRVOGjjtY4AX/SF8dPZWw Date: Wed, 22 Feb 2012 16:43:52 +0000 Message-ID: References: <4C80CBE8.2080708@cisco.com> <4C83F0E6.8050106@net.in.tum.de> <88A72F0E-DCD8-44B9-A7C2-FE29BF684B93@tik.ee.ethz.ch> <4C86AAFF.9050008@cisco.com> <4CC6CAE4.8090605@cisco.com> In-Reply-To: <4CC6CAE4.8090605@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.16.205.253] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailman-Approved-At: Thu, 23 Feb 2012 08:09:12 -0800 Cc: "ipfix@ietf.org" Subject: Re: [IPFIX] Flow in IPFIX -> not only IP Flows X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Feb 2012 16:44:53 -0000 Hello Benoit and others, I came across this old thread and was curious if there was any further outc= ome. This is the last message I see in the thread, and there is indication= that it might have been discussed more in person. I have been through so= me, but not all IPFIX documents and could not find and other references. Thanks ...cj -----Original Message----- From: ipfix-bounces@ietf.org [mailto:ipfix-bounces@ietf.org] On Behalf Of B= enoit Claise Sent: Tuesday, October 26, 2010 8:35 AM To: Brian Trammell Cc: ipfix@ietf.org Subject: Re: [IPFIX] Flow in IPFIX -> not only IP Flows Dear all, Thinking some more about this one. It seems that there is an agreement for changing "IP packets" to "packets" = in the definition Let me summarize the options. The first three come from Brian's proposal be= low 1. Do nothing -> not ideal 2. Define a new category of data records which IPFIX can be used to export -> Brian: not a big fan of this. -> Same for me 3. Drastically expand the definition of Flow so that it covers everything y= ou might want to represent with IPFIX 4. Errata on RFC5101: "IP Traffic Flo= w or Flow" to "Traffic Flow or Flow", and from "IP packets" to "packets -> this is not really an errata -> could be done, but we have to check all the implications 5. Change = the definition from "IP Traffic Flow or Flow" to "Traffic Flow or Flow", an= d from "IP packets" to "packets" when RFC5101 will go from Proposed Standar= d to Draft Standard. 6. Have an applicability version 2, next to http://tools.ietf.org/html/rfc5472 -> expressing that it's used also for non IP packets, among other thin= gs. -> it's good, but I don't think this solution is complete. For example= , the ITU-T would still see the definition as being IP... I'm in favor of 5. and 6., even though 4 would solve the problem now. Feedback? Do we want to discuss this in Beijing? Regards, Benoit. > Brian, >> Benoit, Gerhard, all, >> >> I agree with Gerhard here; call it a packet, leave the definition of=20 >> packet ambiguous, so that it applies to any commonly accepted=20 >> definition thereof. >> >> However, we have two separate problems here. The _other_ problem is=20 >> how to handle the expansion of IPFIX as a generic flexible data=20 >> representation into areas which are not directly related to flow=20 >> measurement as originally envisioned. The prototype here is SIPCLF. >> >> As I see it, this problem should be solved separately from the=20 >> problem of redefining flows for non-IP monitoring, and there are=20 >> three separate general solution areas: >> >> 1. Do nothing, keep the (slightly expanded) definition of Flow. Here,=20 >> we limit the applicibility of IPFIX to network management area, and=20 >> exploit the fact that basically everything in the network management=20 >> area is at the base of it going to involve packets going from=20 >> somewhere to somewhere. In this case, every record represented using=20 >> IPFIX is going to _somehow_ have a relationship back to _some_ set of=20 >> packets which can be wedged into the present definition (the "packet=20 >> treatment" clause in the 5101 definition affords us significant=20 >> flexibility here). This works for SIPCLF as presently defined. >> Non-flow information can still be exported using Options, so it works=20 >> for expanding IPFIX to decidedly non-flow things (e.g., physical=20 >> monitoring scenarios, think periodic temperature reporting) as well,=20 >> as long as all of these records can be represented as scoped to=20 >> something (which I believe they can). In this case, we would probably=20 >> want to mention this in the soon-forthcoming I > E-Doctors draft. >> >> 2. Define a new category of data records which IPFIX can be used to=20 >> export. These non-flow records would be represented as flow records=20 >> (i.e., not Options), and would be equivalent to Flow records, except=20 >> that the flow-specific provisions (uniqueness of flow keys,=20 >> reversibility of non-key fields, etc., etc.) would not apply. The way=20 >> to do this would be, I think, with another RFC which would present=20 >> the expanded definition, and devices exporting/handling this non-flow=20 >> data would therefore state compliance with this _new_ RFC. I'm not a=20 >> big fan of this, personally, because it seems a little complicated,=20 >> but it does allow us to segregate IPFIX-for-flow and=20 >> IPFIX-for-not-really-flow better than (1) above. >> >> 3. Drastically expand the definition of Flow so that it covers=20 >> everything you might want to represent with IPFIX. This strikes me as=20 >> though it would take a great deal of effort, and break a lot of=20 >> assumptions, basically as noted by Gerhard below. I mention it here=20 >> only for completeness. >> >> My preference would be (1) (do nothing, note applicability). Thoughts? > Right, as briefly discussed in the past, we would need an=20 > applicability version 2 > > Regards, Benoit. >> Best regards, >> >> Brian >> >> On Sep 5, 2010, at 9:35 PM, Gerhard Muenz wrote: >> >>> Benoit, >>> >>> I agree: "IP packet" can be replace by "packet". >>> >>> However, replacing "packet" by something like "packet, frame, or=20 >>> cell" would probably cause inconsistencies in this and other=20 >>> IPFIX/PSAMP documents. So, I would not go that far. >>> >>> Regards, >>> Gerhard >>> >>> >>> On 03.09.2010 12:20, Benoit Claise wrote: >>>> Dear all, >>>> >>>> Here is one problem that was anticipated... >>>> >>>> For whatever reasons at that point in time, RFC 5101 limits the=20 >>>> Flow definition to IP packets >>>> >>>> IP Traffic Flow or Flow >>>> >>>> There are several definitions of the term 'flow' being used=20 >>>> by the >>>> Internet community. Within the context of IPFIX we use the >>>> following definition: >>>> >>>> A Flow is defined as a set of IP packets passing an Observation >>>> Point in the network during a certain time interval. All=20 >>>> packets >>>> belonging to a particular Flow have a set of common properties. >>>> Each property is defined as the result of applying a=20 >>>> function to >>>> the values of: >>>> >>>> 1. one or more packet header fields (e.g., destination IP >>>> address), transport header fields (e.g., destination port >>>> number), or application header fields (e.g., RTP header >>>> fields [RFC3550]). >>>> >>>> 2. one or more characteristics of the packet itself (e.g., >>>> number of MPLS labels, etc...). >>>> >>>> 3. one or more of fields derived from packet treatment=20 >>>> (e.g., >>>> next hop IP address, the output interface, etc...). >>>> >>>> A packet is defined as belonging to a Flow if it completely >>>> satisfies all the defined properties of the Flow. >>>> >>>> This definition covers the range from a Flow containing all >>>> packets observed at a network interface to a Flow consisting of >>>> just a single packet between two applications. It includes >>>> packets selected by a sampling mechanism. >>>> >>>> However, we know that IPFIX cover more than IP. >>>> http://www.iana.org/assignments/ipfix/ipfix.xhtml mentions=20 >>>> sourceMacAddress, ethernetPayloadLength, etc... >>>> And we know that IPFIX became a kind of generic streaming protocol. >>>> >>>> Talking in the context of the NGN networks at the ITU, there are=20 >>>> some reluctance to adopt this Flow definition limited to IP packets. >>>> Isn't it time to do something about this definition? >>>> >>>> Regards, Benoit. >>> _______________________________________________ >>> IPFIX mailing list >>> IPFIX@ietf.org >>> https://www.ietf.org/mailman/listinfo/ipfix > > > _______________________________________________ > IPFIX mailing list > IPFIX@ietf.org > https://www.ietf.org/mailman/listinfo/ipfix _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www.ietf.org/mailman/listinfo/ipfix From bclaise@cisco.com Fri Feb 24 01:21:14 2012 Return-Path: X-Original-To: ipfix@ietfa.amsl.com Delivered-To: ipfix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C0E421F87DC for ; Fri, 24 Feb 2012 01:21:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.458 X-Spam-Level: X-Spam-Status: No, score=-2.458 tagged_above=-999 required=5 tests=[AWL=0.140, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Cko9NHC0pfpu for ; Fri, 24 Feb 2012 01:21:13 -0800 (PST) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by ietfa.amsl.com (Postfix) with ESMTP id C563A21F87B9 for ; Fri, 24 Feb 2012 01:21:08 -0800 (PST) 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 q1O9L5A7019982; Fri, 24 Feb 2012 10:21:05 +0100 (CET) Received: from [10.60.67.84] (ams-bclaise-8913.cisco.com [10.60.67.84]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id q1O9L46m018322; Fri, 24 Feb 2012 10:21:04 +0100 (CET) Message-ID: <4F475680.9060501@cisco.com> Date: Fri, 24 Feb 2012 10:21:04 +0100 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: Christopher White References: <4C80CBE8.2080708@cisco.com> <4C83F0E6.8050106@net.in.tum.de> <88A72F0E-DCD8-44B9-A7C2-FE29BF684B93@tik.ee.ethz.ch> <4C86AAFF.9050008@cisco.com> <4CC6CAE4.8090605@cisco.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------090205050308080809080506" Cc: "ipfix@ietf.org" Subject: Re: [IPFIX] Flow in IPFIX -> not only IP Flows X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Feb 2012 09:21:14 -0000 This is a multi-part message in MIME format. --------------090205050308080809080506 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi Christopher, Thanks for bringing our attention to this forgotten issue. As you can see from the diff between RFC5101 and the RFC5101bis draft, http://tools.ietf.org/rfcdiff?url2=draft-ietf-ipfix-protocol-rfc5101bis-00.txt, the definition has not been changed. Out of the 6 proposals, which I will repeat with correct alignment Let me summarize the options. The first three come from Brian's proposal below 1. Do nothing -> not ideal 2. Define a new category of data records which IPFIX can be used to export -> Brian: not a big fan of this. -> Same for me 3. Drastically expand the definition of Flow so that it covers everything you might want to represent with IPFIX 4. Errata on RFC5101: "IP Traffic Flow or Flow" to "Traffic Flow or Flow", and from "IP packets" to "packets -> this is not really an errata -> could be done, but we have to check all the implications 5. Change the definition from "IP Traffic Flow or Flow" to "Traffic Flow or Flow", and from "IP packets" to "packets" when RFC5101 will go from Proposed Standard to Draft Standard. 6. Have an applicability version 2, next to http://tools.ietf.org/html/rfc5472 -> expressing that it's used also for non IP packets, among other things. -> it's good, but I don't think this solution is complete. For example, the ITU-T would still see the definition as being IP... I'm in favor of 5. and 6., even though 4 would solve the problem now. Since we have the RFC5101bis, we should change the "IP Traffic Flow" definition. Regards, Benoit. > Hello Benoit and others, > > I came across this old thread and was curious if there was any further outcome. This is the last message I see in the thread, and there is indication that it might have been discussed more in person. I have been through some, but not all IPFIX documents and could not find and other references. > > Thanks > ...cj > > -----Original Message----- > From: ipfix-bounces@ietf.org [mailto:ipfix-bounces@ietf.org] On Behalf Of Benoit Claise > Sent: Tuesday, October 26, 2010 8:35 AM > To: Brian Trammell > Cc: ipfix@ietf.org > Subject: Re: [IPFIX] Flow in IPFIX -> not only IP Flows > > Dear all, > > Thinking some more about this one. > It seems that there is an agreement for changing "IP packets" to "packets" in the definition > > Let me summarize the options. The first three come from Brian's proposal below 1. Do nothing > -> not ideal > 2. Define a new category of data records which IPFIX can be used to export > -> Brian: not a big fan of this. > -> Same for me > 3. Drastically expand the definition of Flow so that it covers everything you might want to represent with IPFIX 4. Errata on RFC5101: "IP Traffic Flow or Flow" to "Traffic Flow or Flow", and from "IP packets" to "packets > -> this is not really an errata > -> could be done, but we have to check all the implications 5. Change the definition from "IP Traffic Flow or Flow" to "Traffic Flow or Flow", and from "IP packets" to "packets" when RFC5101 will go from Proposed Standard to Draft Standard. > 6. Have an applicability version 2, next to > http://tools.ietf.org/html/rfc5472 > -> expressing that it's used also for non IP packets, among other things. > -> it's good, but I don't think this solution is complete. For example, the ITU-T would still see the definition as being IP... > > > I'm in favor of 5. and 6., even though 4 would solve the problem now. > > Feedback? > Do we want to discuss this in Beijing? > > Regards, Benoit. > >> Brian, >>> Benoit, Gerhard, all, >>> >>> I agree with Gerhard here; call it a packet, leave the definition of >>> packet ambiguous, so that it applies to any commonly accepted >>> definition thereof. >>> >>> However, we have two separate problems here. The _other_ problem is >>> how to handle the expansion of IPFIX as a generic flexible data >>> representation into areas which are not directly related to flow >>> measurement as originally envisioned. The prototype here is SIPCLF. >>> >>> As I see it, this problem should be solved separately from the >>> problem of redefining flows for non-IP monitoring, and there are >>> three separate general solution areas: >>> >>> 1. Do nothing, keep the (slightly expanded) definition of Flow. Here, >>> we limit the applicibility of IPFIX to network management area, and >>> exploit the fact that basically everything in the network management >>> area is at the base of it going to involve packets going from >>> somewhere to somewhere. In this case, every record represented using >>> IPFIX is going to _somehow_ have a relationship back to _some_ set of >>> packets which can be wedged into the present definition (the "packet >>> treatment" clause in the 5101 definition affords us significant >>> flexibility here). This works for SIPCLF as presently defined. >>> Non-flow information can still be exported using Options, so it works >>> for expanding IPFIX to decidedly non-flow things (e.g., physical >>> monitoring scenarios, think periodic temperature reporting) as well, >>> as long as all of these records can be represented as scoped to >>> something (which I believe they can). In this case, we would probably >>> want to mention this in the soon-forthcoming I >> E-Doctors draft. >>> 2. Define a new category of data records which IPFIX can be used to >>> export. These non-flow records would be represented as flow records >>> (i.e., not Options), and would be equivalent to Flow records, except >>> that the flow-specific provisions (uniqueness of flow keys, >>> reversibility of non-key fields, etc., etc.) would not apply. The way >>> to do this would be, I think, with another RFC which would present >>> the expanded definition, and devices exporting/handling this non-flow >>> data would therefore state compliance with this _new_ RFC. I'm not a >>> big fan of this, personally, because it seems a little complicated, >>> but it does allow us to segregate IPFIX-for-flow and >>> IPFIX-for-not-really-flow better than (1) above. >>> >>> 3. Drastically expand the definition of Flow so that it covers >>> everything you might want to represent with IPFIX. This strikes me as >>> though it would take a great deal of effort, and break a lot of >>> assumptions, basically as noted by Gerhard below. I mention it here >>> only for completeness. >>> >>> My preference would be (1) (do nothing, note applicability). Thoughts? >> Right, as briefly discussed in the past, we would need an >> applicability version 2 >> >> Regards, Benoit. >>> Best regards, >>> >>> Brian >>> >>> On Sep 5, 2010, at 9:35 PM, Gerhard Muenz wrote: >>> >>>> Benoit, >>>> >>>> I agree: "IP packet" can be replace by "packet". >>>> >>>> However, replacing "packet" by something like "packet, frame, or >>>> cell" would probably cause inconsistencies in this and other >>>> IPFIX/PSAMP documents. So, I would not go that far. >>>> >>>> Regards, >>>> Gerhard >>>> >>>> >>>> On 03.09.2010 12:20, Benoit Claise wrote: >>>>> Dear all, >>>>> >>>>> Here is one problem that was anticipated... >>>>> >>>>> For whatever reasons at that point in time, RFC 5101 limits the >>>>> Flow definition to IP packets >>>>> >>>>> IP Traffic Flow or Flow >>>>> >>>>> There are several definitions of the term 'flow' being used >>>>> by the >>>>> Internet community. Within the context of IPFIX we use the >>>>> following definition: >>>>> >>>>> A Flow is defined as a set of IP packets passing an Observation >>>>> Point in the network during a certain time interval. All >>>>> packets >>>>> belonging to a particular Flow have a set of common properties. >>>>> Each property is defined as the result of applying a >>>>> function to >>>>> the values of: >>>>> >>>>> 1. one or more packet header fields (e.g., destination IP >>>>> address), transport header fields (e.g., destination port >>>>> number), or application header fields (e.g., RTP header >>>>> fields [RFC3550]). >>>>> >>>>> 2. one or more characteristics of the packet itself (e.g., >>>>> number of MPLS labels, etc...). >>>>> >>>>> 3. one or more of fields derived from packet treatment >>>>> (e.g., >>>>> next hop IP address, the output interface, etc...). >>>>> >>>>> A packet is defined as belonging to a Flow if it completely >>>>> satisfies all the defined properties of the Flow. >>>>> >>>>> This definition covers the range from a Flow containing all >>>>> packets observed at a network interface to a Flow consisting of >>>>> just a single packet between two applications. It includes >>>>> packets selected by a sampling mechanism. >>>>> >>>>> However, we know that IPFIX cover more than IP. >>>>> http://www.iana.org/assignments/ipfix/ipfix.xhtml mentions >>>>> sourceMacAddress, ethernetPayloadLength, etc... >>>>> And we know that IPFIX became a kind of generic streaming protocol. >>>>> >>>>> Talking in the context of the NGN networks at the ITU, there are >>>>> some reluctance to adopt this Flow definition limited to IP packets. >>>>> Isn't it time to do something about this definition? >>>>> >>>>> Regards, Benoit. >>>> _______________________________________________ >>>> IPFIX mailing list >>>> IPFIX@ietf.org >>>> https://www.ietf.org/mailman/listinfo/ipfix >> >> _______________________________________________ >> IPFIX mailing list >> IPFIX@ietf.org >> https://www.ietf.org/mailman/listinfo/ipfix > _______________________________________________ > IPFIX mailing list > IPFIX@ietf.org > https://www.ietf.org/mailman/listinfo/ipfix > > --------------090205050308080809080506 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi Christopher,

Thanks for bringing our attention to this forgotten issue.
As you can see from the diff between RFC5101 and the RFC5101bis draft, http://tools.ietf.org/rfcdiff?url2=draft-ietf-ipfix-protocol-rfc5101bis-00.txt, the definition has not been changed. Out of the 6 proposals, which I will repeat with correct alignment
Let me summarize the options. The first three come from Brian's proposal below 
1. Do nothing
     -> not ideal
2. Define a new category of data records which IPFIX can be used to export
     -> Brian: not a big fan of this.
     -> Same for me
3. Drastically expand the definition of Flow so that it covers everything you might want to represent with IPFIX 
4. Errata on RFC5101: "IP Traffic Flow or Flow" to "Traffic Flow or Flow", and from "IP packets" to "packets
     -> this is not really an errata
     -> could be done, but we have to check all the implications 
5. Change the definition from "IP Traffic Flow or Flow" to "Traffic Flow or Flow", and from "IP packets" to "packets" when RFC5101 will go from Proposed Standard to Draft Standard.
6. Have an applicability version 2, next to
http://tools.ietf.org/html/rfc5472
     -> expressing that it's used also for non IP packets, among other things.
     -> it's good, but I don't think this solution is complete. For example, the ITU-T would still see the definition as being IP...

I'm in favor of 5. and 6., even though 4 would solve the problem now.
Since we have the RFC5101bis, we should change the "IP Traffic Flow" definition.

Regards, Benoit.


Hello Benoit and others,

I came across this old thread and was curious if there was any further outcome.  This is the last message I see in the thread, and there is indication that it might have been discussed more in person.   I have been through some, but not all IPFIX documents and could not find and other references.

Thanks
...cj

-----Original Message-----
From: ipfix-bounces@ietf.org [mailto:ipfix-bounces@ietf.org] On Behalf Of Benoit Claise
Sent: Tuesday, October 26, 2010 8:35 AM
To: Brian Trammell
Cc: ipfix@ietf.org
Subject: Re: [IPFIX] Flow in IPFIX -> not only IP Flows

Dear all,

Thinking some more about this one.
It seems that there is an agreement for changing "IP packets" to "packets" in the definition

Let me summarize the options. The first three come from Brian's proposal below 1. Do nothing
     -> not ideal
2. Define a new category of data records which IPFIX can be used to export
     -> Brian: not a big fan of this.
     -> Same for me
3. Drastically expand the definition of Flow so that it covers everything you might want to represent with IPFIX 4. Errata on RFC5101: "IP Traffic Flow or Flow" to "Traffic Flow or Flow", and from "IP packets" to "packets
     -> this is not really an errata
     -> could be done, but we have to check all the implications 5. Change the definition from "IP Traffic Flow or Flow" to "Traffic Flow or Flow", and from "IP packets" to "packets" when RFC5101 will go from Proposed Standard to Draft Standard.
6. Have an applicability version 2, next to
http://tools.ietf.org/html/rfc5472
     -> expressing that it's used also for non IP packets, among other things.
     -> it's good, but I don't think this solution is complete. For example, the ITU-T would still see the definition as being IP...


I'm in favor of 5. and 6., even though 4 would solve the problem now.

Feedback?
Do we want to discuss this in Beijing?

Regards, Benoit.


 Brian,

Benoit, Gerhard, all,

I agree with Gerhard here; call it a packet, leave the definition of 
packet ambiguous, so that it applies to any commonly accepted 
definition thereof.

However, we have two separate problems here. The _other_ problem is 
how to handle the expansion of IPFIX as a generic flexible data 
representation into areas which are not directly related to flow 
measurement as originally envisioned. The prototype here is SIPCLF.

As I see it, this problem should be solved separately from the 
problem of redefining flows for non-IP monitoring, and there are 
three separate general solution areas:

1. Do nothing, keep the (slightly expanded) definition of Flow. Here, 
we limit the applicibility of IPFIX to network management area, and 
exploit the fact that basically everything in the network management 
area is at the base of it going to involve packets going from 
somewhere to somewhere. In this case, every record represented using 
IPFIX is going to _somehow_ have a relationship back to _some_ set of 
packets which can be wedged into the present definition (the "packet 
treatment" clause in the 5101 definition affords us significant 
flexibility here). This works for SIPCLF as presently defined.
Non-flow information can still be exported using Options, so it works 
for expanding IPFIX to decidedly non-flow things (e.g., physical 
monitoring scenarios, think periodic temperature reporting) as well, 
as long as all of these records can be represented as scoped to 
something (which I believe they can). In this case, we would probably 
want to mention this in the soon-forthcoming I

E-Doctors draft.

2. Define a new category of data records which IPFIX can be used to 
export. These non-flow records would be represented as flow records 
(i.e., not Options), and would be equivalent to Flow records, except 
that the flow-specific provisions (uniqueness of flow keys, 
reversibility of non-key fields, etc., etc.) would not apply. The way 
to do this would be, I think, with another RFC which would present 
the expanded definition, and devices exporting/handling this non-flow 
data would therefore state compliance with this _new_ RFC. I'm not a 
big fan of this, personally, because it seems a little complicated, 
but it does allow us to segregate IPFIX-for-flow and 
IPFIX-for-not-really-flow better than (1) above.

3. Drastically expand the definition of Flow so that it covers 
everything you might want to represent with IPFIX. This strikes me as 
though it would take a great deal of effort, and break a lot of 
assumptions, basically as noted by Gerhard below. I mention it here 
only for completeness.

My preference would be (1) (do nothing, note applicability). Thoughts?

Right, as briefly discussed in the past, we would need an 
applicability  version 2

Regards, Benoit.

Best regards,

Brian

On Sep 5, 2010, at 9:35 PM, Gerhard Muenz wrote:


Benoit,

I agree: "IP packet" can be replace by "packet".

However, replacing "packet" by something like "packet, frame, or 
cell" would probably cause inconsistencies in this and other 
IPFIX/PSAMP documents. So, I would not go that far.

Regards,
Gerhard


On 03.09.2010 12:20, Benoit Claise wrote:

  Dear all,

Here is one problem that was anticipated...

For whatever reasons at that point in time, RFC 5101 limits the 
Flow definition to IP packets

    IP Traffic Flow or Flow

       There are several definitions of the term 'flow' being used 
by the
       Internet community.  Within the context of IPFIX we use the
       following definition:

       A Flow is defined as a set of IP packets passing an Observation
       Point in the network during a certain time interval.  All 
packets
       belonging to a particular Flow have a set of common properties.
       Each property is defined as the result of applying a 
function to
       the values of:

          1. one or more packet header fields (e.g., destination IP
             address), transport header fields (e.g., destination port
             number), or application header fields (e.g., RTP header
             fields [RFC3550<http://tools.ietf.org/html/rfc3550>]).

          2. one or more characteristics of the packet itself (e.g.,
             number of MPLS labels, etc...).

          3. one or more of fields derived from packet treatment 
(e.g.,
             next hop IP address, the output interface, etc...).

       A packet is defined as belonging to a Flow if it completely
       satisfies all the defined properties of the Flow.

       This definition covers the range from a Flow containing all
       packets observed at a network interface to a Flow consisting of
       just a single packet between two applications.  It includes
       packets selected by a sampling mechanism.

However, we know that IPFIX cover more than IP.
http://www.iana.org/assignments/ipfix/ipfix.xhtml mentions 
sourceMacAddress, ethernetPayloadLength, etc...
And we know that IPFIX became a kind of generic streaming protocol.

Talking in the context of the NGN networks at the ITU, there are 
some reluctance to adopt this Flow definition limited to IP packets.
Isn't it time to do something about this definition?

Regards, Benoit.

_______________________________________________
IPFIX mailing list
IPFIX@ietf.org
https://www.ietf.org/mailman/listinfo/ipfix


_______________________________________________
IPFIX mailing list
IPFIX@ietf.org
https://www.ietf.org/mailman/listinfo/ipfix

_______________________________________________
IPFIX mailing list
IPFIX@ietf.org
https://www.ietf.org/mailman/listinfo/ipfix

--------------090205050308080809080506-- From trammell@tik.ee.ethz.ch Fri Feb 24 01:41:38 2012 Return-Path: X-Original-To: ipfix@ietfa.amsl.com Delivered-To: ipfix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F38D021F88F2 for ; Fri, 24 Feb 2012 01:41:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.563 X-Spam-Level: X-Spam-Status: No, score=-7.563 tagged_above=-999 required=5 tests=[AWL=1.036, BAYES_00=-2.599, GB_I_LETTER=-2, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MGLh0gB+athg for ; Fri, 24 Feb 2012 01:41:36 -0800 (PST) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) by ietfa.amsl.com (Postfix) with ESMTP id 27D4F21F88F3 for ; Fri, 24 Feb 2012 01:41:35 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id 05D04D930A; Fri, 24 Feb 2012 10:41:34 +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 lmk3nhnsz8ER; Fri, 24 Feb 2012 10:41:34 +0100 (MET) Received: from pb-10243.ethz.ch (pb-10243.ethz.ch [82.130.102.152]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: briant) by smtp.ee.ethz.ch (Postfix) with ESMTPSA id AC305D930B; Fri, 24 Feb 2012 10:41:34 +0100 (MET) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=iso-8859-1 From: Brian Trammell In-Reply-To: <4F475680.9060501@cisco.com> Date: Fri, 24 Feb 2012 10:41:34 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <1450F2CB-ECB5-4597-9CB7-A01FA8071A7B@tik.ee.ethz.ch> References: <4C80CBE8.2080708@cisco.com> <4C83F0E6.8050106@net.in.tum.de> <88A72F0E-DCD8-44B9-A7C2-FE29BF684B93@tik.ee.ethz.ch> <4C86AAFF.9050008@cisco.com> <4CC6CAE4.8090605@cisco.com> <4F475680.9060501@cisco.com> To: Benoit Claise X-Mailer: Apple Mail (2.1257) Cc: "ipfix@ietf.org" , Christopher White Subject: Re: [IPFIX] Flow in IPFIX -> not only IP Flows X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Feb 2012 09:41:38 -0000 Hi, Benoit, all, I believe that there's enough interest in layer 2 export that we've kind = of already started applying IPFIX to non-IP packets, so to some extent = both 4. and 5. would be simply a matter of aligning the 5101bis draft = (perhaps as well as its shadow, 5101 + errata) with current reality. = Both carry the caveat that we have to think about all the implications. = But I think there is nothing about the present definition that breaks = when you remove 'IP' from it. Indeed, I think the only thing to do is to = remove "IP" from a couple of places, as follows, from 5101bis.=20 OLD: IP Traffic Flow or Flow=20 =20 There are several definitions of the term \'flow' being used by the=20 Internet community. Within the context of IPFIX we use the=20 following definition:=20 =20 A Flow is defined as a set of IP packets passing an Observation=20 Point in the network during a certain time interval. All packets=20 belonging to a particular Flow have a set of common properties. =20 Each property is defined as the result of applying a function to the=20 values of:=20 1. one or more packet header fields (e.g., destination IP =20 address), transport header fields (e.g., destination port number),=20 or application header fields (e.g., RTP header fields [RFC3550]).=20 2. one or more characteristics of the packet itself (e.g., number=20 of MPLS labels, etc...).=20 3. one or more of fields derived from packet treatment (e.g., next=20 hop IP address, the output interface, etc...).=20 A packet is defined as belonging to a Flow if it completely satisfies=20 all the defined properties of the Flow.=20 =20 This definition covers the range from a Flow containing all packets=20 observed at a network interface to a Flow consisting of just a=20 single packet between two applications. It includes packets=20 selected by a sampling mechanism.=20 NEW: Traffic Flow or Flow=20 =20 There are several definitions of the term \'flow' being used by the=20 Internet community. Within the context of IPFIX we use the=20 following definition:=20 =20 A Flow is defined as a set of packets passing an Observation=20 Point in the network during a certain time interval. All packets=20 belonging to a particular Flow have a set of common properties. =20 Each property is defined as the result of applying a function to the=20 values of:=20 1. one or more packet header fields (e.g., destination IP =20 address), transport header fields (e.g., destination port number),=20 or application header fields (e.g., RTP header fields [RFC3550]).=20 2. one or more characteristics of the packet itself (e.g., number=20 of MPLS labels, etc...).=20 3. one or more of fields derived from packet treatment (e.g., next=20 hop IP address, the output interface, etc...).=20 A packet is defined as belonging to a Flow if it completely satisfies=20 all the defined properties of the Flow.=20 =20 This definition covers the range from a Flow containing all packets=20 observed at a network interface to a Flow consisting of just a=20 single packet between two applications. It includes packets=20 selected by a sampling mechanism.=20 Even the ancillary definitions (e.g. Flow Key) already work in the = context of non-IP flows. Observation Point would also have to be = changed: OLD: An Observation Point is a location in the network where IP packets=20 can be observed. Examples include: a line to which a probe is=20 attached, a shared medium, such as an Ethernet-based LAN, a single=20 port of a router, or a set of interfaces (physical or logical) of a=20 router.=20 NEW: An Observation Point is a location in the network where packets=20 can be observed. Examples include: a line to which a probe is=20 attached, a shared medium, such as an Ethernet-based LAN, a single=20 port of a router, or a set of interfaces (physical or logical) of a=20 router.=20 These are pretty simple changes and I don't see any problem just making = them. Honestly, I think the larger problem we have on this point is with = the name of the protocol: with the IP right up front in the first two = letters, it'll be hard to sell as a layer 2 measurement protocol. :) Cheers, Brian On Feb 24, 2012, at 10:21 AM, Benoit Claise wrote: > Hi Christopher, >=20 > Thanks for bringing our attention to this forgotten issue. > As you can see from the diff between RFC5101 and the RFC5101bis draft, = http://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-ipfix-protocol-rfc5101bis-= 00.txt, the definition has not been changed. Out of the 6 proposals, = which I will repeat with correct alignment > Let me summarize the options. The first three come from Brian's = proposal below=20 > 1. Do nothing > -> not ideal > 2. Define a new category of data records which IPFIX can be used to = export > -> Brian: not a big fan of this. > -> Same for me > 3. Drastically expand the definition of Flow so that it covers = everything you might want to represent with IPFIX=20 > 4. Errata on RFC5101: "IP Traffic Flow or Flow" to "Traffic Flow or = Flow", and from "IP packets" to "packets > -> this is not really an errata > -> could be done, but we have to check all the implications=20 > 5. Change the definition from "IP Traffic Flow or Flow" to "Traffic = Flow or Flow", and from "IP packets" to "packets" when RFC5101 will go = from Proposed Standard to Draft Standard. > 6. Have an applicability version 2, next to >=20 > http://tools.ietf.org/html/rfc5472 >=20 > -> expressing that it's used also for non IP packets, among other = things. > -> it's good, but I don't think this solution is complete. For = example, the ITU-T would still see the definition as being IP... >=20 > I'm in favor of 5. and 6., even though 4 would solve the problem now. >=20 > Since we have the RFC5101bis, we should change the "IP Traffic Flow" = definition. >=20 > Regards, Benoit. >=20 >=20 >> Hello Benoit and others, >>=20 >> I came across this old thread and was curious if there was any = further outcome. This is the last message I see in the thread, and = there is indication that it might have been discussed more in person. = I have been through some, but not all IPFIX documents and could not find = and other references. >>=20 >> Thanks >> ...cj >>=20 >> -----Original Message----- >> From:=20 >> ipfix-bounces@ietf.org [mailto:ipfix-bounces@ietf.org >> ] On Behalf Of Benoit Claise >> Sent: Tuesday, October 26, 2010 8:35 AM >> To: Brian Trammell >> Cc:=20 >> ipfix@ietf.org >>=20 >> Subject: Re: [IPFIX] Flow in IPFIX -> not only IP Flows >>=20 >> Dear all, >>=20 >> Thinking some more about this one. >> It seems that there is an agreement for changing "IP packets" to = "packets" in the definition >>=20 >> Let me summarize the options. The first three come from Brian's = proposal below 1. Do nothing >> -> not ideal >> 2. Define a new category of data records which IPFIX can be used to = export >> -> Brian: not a big fan of this. >> -> Same for me >> 3. Drastically expand the definition of Flow so that it covers = everything you might want to represent with IPFIX 4. Errata on RFC5101: = "IP Traffic Flow or Flow" to "Traffic Flow or Flow", and from "IP = packets" to "packets >> -> this is not really an errata >> -> could be done, but we have to check all the implications 5. = Change the definition from "IP Traffic Flow or Flow" to "Traffic Flow or = Flow", and from "IP packets" to "packets" when RFC5101 will go from = Proposed Standard to Draft Standard. >> 6. Have an applicability version 2, next to >>=20 >> http://tools.ietf.org/html/rfc5472 >>=20 >> -> expressing that it's used also for non IP packets, among = other things. >> -> it's good, but I don't think this solution is complete. For = example, the ITU-T would still see the definition as being IP... >>=20 >>=20 >> I'm in favor of 5. and 6., even though 4 would solve the problem now. >>=20 >> Feedback? >> Do we want to discuss this in Beijing? >>=20 >> Regards, Benoit. >>=20 >>=20 >>> Brian, >>>=20 >>>> Benoit, Gerhard, all, >>>>=20 >>>> I agree with Gerhard here; call it a packet, leave the definition = of=20 >>>> packet ambiguous, so that it applies to any commonly accepted=20 >>>> definition thereof. >>>>=20 >>>> However, we have two separate problems here. The _other_ problem is=20= >>>> how to handle the expansion of IPFIX as a generic flexible data=20 >>>> representation into areas which are not directly related to flow=20 >>>> measurement as originally envisioned. The prototype here is SIPCLF. >>>>=20 >>>> As I see it, this problem should be solved separately from the=20 >>>> problem of redefining flows for non-IP monitoring, and there are=20 >>>> three separate general solution areas: >>>>=20 >>>> 1. Do nothing, keep the (slightly expanded) definition of Flow. = Here,=20 >>>> we limit the applicibility of IPFIX to network management area, and=20= >>>> exploit the fact that basically everything in the network = management=20 >>>> area is at the base of it going to involve packets going from=20 >>>> somewhere to somewhere. In this case, every record represented = using=20 >>>> IPFIX is going to _somehow_ have a relationship back to _some_ set = of=20 >>>> packets which can be wedged into the present definition (the = "packet=20 >>>> treatment" clause in the 5101 definition affords us significant=20 >>>> flexibility here). This works for SIPCLF as presently defined. >>>> Non-flow information can still be exported using Options, so it = works=20 >>>> for expanding IPFIX to decidedly non-flow things (e.g., physical=20 >>>> monitoring scenarios, think periodic temperature reporting) as = well,=20 >>>> as long as all of these records can be represented as scoped to=20 >>>> something (which I believe they can). In this case, we would = probably=20 >>>> want to mention this in the soon-forthcoming I >>>>=20 >>> E-Doctors draft. >>>=20 >>>> 2. Define a new category of data records which IPFIX can be used to=20= >>>> export. These non-flow records would be represented as flow records=20= >>>> (i.e., not Options), and would be equivalent to Flow records, = except=20 >>>> that the flow-specific provisions (uniqueness of flow keys,=20 >>>> reversibility of non-key fields, etc., etc.) would not apply. The = way=20 >>>> to do this would be, I think, with another RFC which would present=20= >>>> the expanded definition, and devices exporting/handling this = non-flow=20 >>>> data would therefore state compliance with this _new_ RFC. I'm not = a=20 >>>> big fan of this, personally, because it seems a little complicated,=20= >>>> but it does allow us to segregate IPFIX-for-flow and=20 >>>> IPFIX-for-not-really-flow better than (1) above. >>>>=20 >>>> 3. Drastically expand the definition of Flow so that it covers=20 >>>> everything you might want to represent with IPFIX. This strikes me = as=20 >>>> though it would take a great deal of effort, and break a lot of=20 >>>> assumptions, basically as noted by Gerhard below. I mention it here=20= >>>> only for completeness. >>>>=20 >>>> My preference would be (1) (do nothing, note applicability). = Thoughts? >>>>=20 >>> Right, as briefly discussed in the past, we would need an=20 >>> applicability version 2 >>>=20 >>> Regards, Benoit. >>>=20 >>>> Best regards, >>>>=20 >>>> Brian >>>>=20 >>>> On Sep 5, 2010, at 9:35 PM, Gerhard Muenz wrote: >>>>=20 >>>>=20 >>>>> Benoit, >>>>>=20 >>>>> I agree: "IP packet" can be replace by "packet". >>>>>=20 >>>>> However, replacing "packet" by something like "packet, frame, or=20= >>>>> cell" would probably cause inconsistencies in this and other=20 >>>>> IPFIX/PSAMP documents. So, I would not go that far. >>>>>=20 >>>>> Regards, >>>>> Gerhard >>>>>=20 >>>>>=20 >>>>> On 03.09.2010 12:20, Benoit Claise wrote: >>>>>=20 >>>>>> Dear all, >>>>>>=20 >>>>>> Here is one problem that was anticipated... >>>>>>=20 >>>>>> For whatever reasons at that point in time, RFC 5101 limits the=20= >>>>>> Flow definition to IP packets >>>>>>=20 >>>>>> IP Traffic Flow or Flow >>>>>>=20 >>>>>> There are several definitions of the term 'flow' being = used=20 >>>>>> by the >>>>>> Internet community. Within the context of IPFIX we use = the >>>>>> following definition: >>>>>>=20 >>>>>> A Flow is defined as a set of IP packets passing an = Observation >>>>>> Point in the network during a certain time interval. All=20= >>>>>> packets >>>>>> belonging to a particular Flow have a set of common = properties. >>>>>> Each property is defined as the result of applying a=20 >>>>>> function to >>>>>> the values of: >>>>>>=20 >>>>>> 1. one or more packet header fields (e.g., destination = IP >>>>>> address), transport header fields (e.g., destination = port >>>>>> number), or application header fields (e.g., RTP = header >>>>>> fields [RFC3550 >>>>>> >>>>>> ]). >>>>>>=20 >>>>>> 2. one or more characteristics of the packet itself = (e.g., >>>>>> number of MPLS labels, etc...). >>>>>>=20 >>>>>> 3. one or more of fields derived from packet treatment=20= >>>>>> (e.g., >>>>>> next hop IP address, the output interface, etc...). >>>>>>=20 >>>>>> A packet is defined as belonging to a Flow if it = completely >>>>>> satisfies all the defined properties of the Flow. >>>>>>=20 >>>>>> This definition covers the range from a Flow containing = all >>>>>> packets observed at a network interface to a Flow = consisting of >>>>>> just a single packet between two applications. It = includes >>>>>> packets selected by a sampling mechanism. >>>>>>=20 >>>>>> However, we know that IPFIX cover more than IP. >>>>>>=20 >>>>>> http://www.iana.org/assignments/ipfix/ipfix.xhtml >>>>>> mentions=20 >>>>>> sourceMacAddress, ethernetPayloadLength, etc... >>>>>> And we know that IPFIX became a kind of generic streaming = protocol. >>>>>>=20 >>>>>> Talking in the context of the NGN networks at the ITU, there are=20= >>>>>> some reluctance to adopt this Flow definition limited to IP = packets. >>>>>> Isn't it time to do something about this definition? >>>>>>=20 >>>>>> Regards, Benoit. >>>>>>=20 >>>>> _______________________________________________ >>>>> IPFIX mailing list >>>>>=20 >>>>> IPFIX@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/ipfix >>>=20 >>> _______________________________________________ >>> IPFIX mailing list >>>=20 >>> IPFIX@ietf.org >>> https://www.ietf.org/mailman/listinfo/ipfix >> _______________________________________________ >> IPFIX mailing list >>=20 >> IPFIX@ietf.org >> https://www.ietf.org/mailman/listinfo/ipfix >>=20 >>=20 >>=20 >>=20 >=20 From paitken@cisco.com Fri Feb 24 02:23:38 2012 Return-Path: X-Original-To: ipfix@ietfa.amsl.com Delivered-To: ipfix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1618821F8919 for ; Fri, 24 Feb 2012 02:23:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -11.358 X-Spam-Level: X-Spam-Status: No, score=-11.358 tagged_above=-999 required=5 tests=[AWL=1.241, BAYES_00=-2.599, GB_I_LETTER=-2, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qwOBTk8B4J10 for ; Fri, 24 Feb 2012 02:23:37 -0800 (PST) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by ietfa.amsl.com (Postfix) with ESMTP id 4B61B21F8917 for ; Fri, 24 Feb 2012 02:23:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=paitken@cisco.com; l=403; q=dns/txt; s=iport; t=1330079017; x=1331288617; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=4pOz3fZRGr7mIxlhHHzXrnwxVtbMPSYo/IBwVDSLUZE=; b=FLjw1s0v2c5/fI/7RYOd7zPPPtwkC7lnzVrXPseVLKOCsZVmzlrmZjU1 cmTfKdFi2O6ZP16jwMdNNMJnRRHJO6JZe3hIjW8dwfXpd8oiAlGcAjA0z fdRG+d983XxkYtQ4rwB/xHpN1m0ZYAD+qsEORdvrR1MiRQch3w8x8HF6g k=; X-IronPort-AV: E=Sophos;i="4.73,475,1325462400"; d="scan'208";a="66971217" Received: from ams-core-1.cisco.com ([144.254.72.81]) by ams-iport-2.cisco.com with ESMTP; 24 Feb 2012 10:23:36 +0000 Received: from [10.55.91.117] (dhcp-10-55-91-117.cisco.com [10.55.91.117]) by ams-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id q1OANaDB022502; Fri, 24 Feb 2012 10:23:36 GMT Message-ID: <4F476528.3010201@cisco.com> Date: Fri, 24 Feb 2012 10:23:36 +0000 From: Paul Aitken User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.26) Gecko/20120131 Lightning/1.0b2 Thunderbird/3.1.18 MIME-Version: 1.0 To: Brian Trammell References: <4C80CBE8.2080708@cisco.com> <4C83F0E6.8050106@net.in.tum.de> <88A72F0E-DCD8-44B9-A7C2-FE29BF684B93@tik.ee.ethz.ch> <4C86AAFF.9050008@cisco.com> <4CC6CAE4.8090605@cisco.com> <4F475680.9060501@cisco.com> <1450F2CB-ECB5-4597-9CB7-A01FA8071A7B@tik.ee.ethz.ch> In-Reply-To: <1450F2CB-ECB5-4597-9CB7-A01FA8071A7B@tik.ee.ethz.ch> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Christopher White , "ipfix@ietf.org" Subject: Re: [IPFIX] Flow in IPFIX -> not only IP Flows X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Feb 2012 10:23:38 -0000 Brian, > Honestly, I think the larger problem we have on this point is with the name of the protocol: with the IP right up front in the first two letters, it'll be hard to sell as a layer 2 measurement protocol. :) The existing IANA elements show that it can measure metrics at any layer. Even "flow" isn't so relevant these days. So IPFIX isn't export _of_ IP, it's export _over_ IP. P. From trammell@tik.ee.ethz.ch Fri Feb 24 02:27:45 2012 Return-Path: X-Original-To: ipfix@ietfa.amsl.com Delivered-To: ipfix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C00E21F8921 for ; Fri, 24 Feb 2012 02:27:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.603 X-Spam-Level: X-Spam-Status: No, score=-7.603 tagged_above=-999 required=5 tests=[AWL=0.996, BAYES_00=-2.599, GB_I_LETTER=-2, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VzzBcNrWORaJ for ; Fri, 24 Feb 2012 02:27:44 -0800 (PST) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) by ietfa.amsl.com (Postfix) with ESMTP id 4482C21F88CC for ; Fri, 24 Feb 2012 02:27:44 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id A0890D930B; Fri, 24 Feb 2012 11:27:43 +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 sbo0AnRd+OmD; Fri, 24 Feb 2012 11:27:43 +0100 (MET) Received: from pb-10243.ethz.ch (pb-10243.ethz.ch [82.130.102.152]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: briant) by smtp.ee.ethz.ch (Postfix) with ESMTPSA id 692B7D930A; Fri, 24 Feb 2012 11:27:43 +0100 (MET) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=iso-8859-1 From: Brian Trammell In-Reply-To: <4F476528.3010201@cisco.com> Date: Fri, 24 Feb 2012 11:27:43 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <5B1C86E3-E002-41ED-861C-279AF67A95D6@tik.ee.ethz.ch> References: <4C80CBE8.2080708@cisco.com> <4C83F0E6.8050106@net.in.tum.de> <88A72F0E-DCD8-44B9-A7C2-FE29BF684B93@tik.ee.ethz.ch> <4C86AAFF.9050008@cisco.com> <4CC6CAE4.8090605@cisco.com> <4F475680.9060501@cisco.com> <1450F2CB-ECB5-4597-9CB7-A01FA8071A7B@tik.ee.ethz.ch> <4F476528.3010201@cisco.com> To: Paul Aitken X-Mailer: Apple Mail (2.1257) Cc: Christopher White , "ipfix@ietf.org" Subject: Re: [IPFIX] Flow in IPFIX -> not only IP Flows X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Feb 2012 10:27:45 -0000 Hi, Paul. Of course, if you get rid of IP and Flow out of the title, you're just = left with IX, and now we're colliding with entirely different acronyms. = :) But this is a good point, and I'll use it in the future. Cheers, Brian On Feb 24, 2012, at 11:23 AM, Paul Aitken wrote: > Brian, >=20 >> Honestly, I think the larger problem we have on this point is with = the name of the protocol: with the IP right up front in the first two = letters, it'll be hard to sell as a layer 2 measurement protocol. :) >=20 > The existing IANA elements show that it can measure metrics at any = layer. Even "flow" isn't so relevant these days. >=20 > So IPFIX isn't export _of_ IP, it's export _over_ IP. >=20 > P. From paitken@cisco.com Fri Feb 24 02:36:37 2012 Return-Path: X-Original-To: ipfix@ietfa.amsl.com Delivered-To: ipfix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F19B621F884D for ; Fri, 24 Feb 2012 02:36:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -11.447 X-Spam-Level: X-Spam-Status: No, score=-11.447 tagged_above=-999 required=5 tests=[AWL=1.152, BAYES_00=-2.599, GB_I_LETTER=-2, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aRkSRWZqmfPB for ; Fri, 24 Feb 2012 02:36:36 -0800 (PST) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id 4DBF521F86DF for ; Fri, 24 Feb 2012 02:36:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=paitken@cisco.com; l=931; q=dns/txt; s=iport; t=1330079795; x=1331289395; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=Db7vke6eYolKc5ARkO+eZF5y6280gvyhDd3PP7PgKxk=; b=YW1kVbMv8O2JQHKgynP0ISV3QILlkNDeBBXNEiUtGbhDf4VMcFqkneD9 6OjsiZ41+ftnqpjNpBWpbiTa2+QiQmnYbcIrB8xJsCwTXvNLT5F4KFvIt HoaiM1pCSiMcr3UZJzS5eAobNpjhH/B9/1jmBroKETvK0GBypLh1XamQl s=; X-IronPort-AV: E=Sophos;i="4.73,475,1325462400"; d="scan'208";a="130464582" Received: from ams-core-4.cisco.com ([144.254.72.77]) by ams-iport-1.cisco.com with ESMTP; 24 Feb 2012 10:36:34 +0000 Received: from [10.55.91.117] (dhcp-10-55-91-117.cisco.com [10.55.91.117]) by ams-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id q1OAaYYt003668; Fri, 24 Feb 2012 10:36:34 GMT Message-ID: <4F476833.4080107@cisco.com> Date: Fri, 24 Feb 2012 10:36:35 +0000 From: Paul Aitken User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.27) Gecko/20120216 Lightning/1.0b2 Thunderbird/3.1.19 MIME-Version: 1.0 To: Brian Trammell References: <4C80CBE8.2080708@cisco.com> <4C83F0E6.8050106@net.in.tum.de> <88A72F0E-DCD8-44B9-A7C2-FE29BF684B93@tik.ee.ethz.ch> <4C86AAFF.9050008@cisco.com> <4CC6CAE4.8090605@cisco.com> <4F475680.9060501@cisco.com> <1450F2CB-ECB5-4597-9CB7-A01FA8071A7B@tik.ee.ethz.ch> <4F476528.3010201@cisco.com> <5B1C86E3-E002-41ED-861C-279AF67A95D6@tik.ee.ethz.ch> In-Reply-To: <5B1C86E3-E002-41ED-861C-279AF67A95D6@tik.ee.ethz.ch> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Christopher White , "ipfix@ietf.org" Subject: Re: [IPFIX] Flow in IPFIX -> not only IP Flows X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Feb 2012 10:36:37 -0000 Brian, Considering 5101, structured data, and export of mib objects, I suggest "Export of Information Elements and Irregular Objects", EIEIO. P. On 24/02/12 10:27, Brian Trammell wrote: > Hi, Paul. > > Of course, if you get rid of IP and Flow out of the title, you're just left with IX, and now we're colliding with entirely different acronyms. :) > > But this is a good point, and I'll use it in the future. > > Cheers, > > Brian > > On Feb 24, 2012, at 11:23 AM, Paul Aitken wrote: > >> Brian, >> >>> Honestly, I think the larger problem we have on this point is with the name of the protocol: with the IP right up front in the first two letters, it'll be hard to sell as a layer 2 measurement protocol. :) >> The existing IANA elements show that it can measure metrics at any layer. Even "flow" isn't so relevant these days. >> >> So IPFIX isn't export _of_ IP, it's export _over_ IP. >> >> P. From bclaise@cisco.com Fri Feb 24 02:40:41 2012 Return-Path: X-Original-To: ipfix@ietfa.amsl.com Delivered-To: ipfix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 35F2621F88F0 for ; Fri, 24 Feb 2012 02:40:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.461 X-Spam-Level: X-Spam-Status: No, score=-3.461 tagged_above=-999 required=5 tests=[AWL=1.137, BAYES_00=-2.599, GB_I_LETTER=-2, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fKzajXvdJWdx for ; Fri, 24 Feb 2012 02:40:39 -0800 (PST) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by ietfa.amsl.com (Postfix) with ESMTP id 76CF821F88E0 for ; Fri, 24 Feb 2012 02:40:37 -0800 (PST) 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 q1OAZaKA029832; Fri, 24 Feb 2012 11:35:36 +0100 (CET) Received: from [10.60.67.84] (ams-bclaise-8913.cisco.com [10.60.67.84]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id q1OAZYa9024618; Fri, 24 Feb 2012 11:35:35 +0100 (CET) Message-ID: <4F4767F6.8040901@cisco.com> Date: Fri, 24 Feb 2012 11:35:34 +0100 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: Brian Trammell References: <4C80CBE8.2080708@cisco.com> <4C83F0E6.8050106@net.in.tum.de> <88A72F0E-DCD8-44B9-A7C2-FE29BF684B93@tik.ee.ethz.ch> <4C86AAFF.9050008@cisco.com> <4CC6CAE4.8090605@cisco.com> <4F475680.9060501@cisco.com> <1450F2CB-ECB5-4597-9CB7-A01FA8071A7B@tik.ee.ethz.ch> In-Reply-To: <1450F2CB-ECB5-4597-9CB7-A01FA8071A7B@tik.ee.ethz.ch> Content-Type: multipart/alternative; boundary="------------020608010502010103010401" Cc: "ipfix@ietf.org" , Christopher White Subject: Re: [IPFIX] Flow in IPFIX -> not only IP Flows X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Feb 2012 10:40:41 -0000 This is a multi-part message in MIME format. --------------020608010502010103010401 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Brian, Agreed to your changes. Agreed that there is no impact changing those definitions. On this point: These are pretty simple changes and I don't see any problem just making them. Honestly, I think the larger problem we have on this point is with the name of the protocol: with the IP right up front in the first two letters, it'll be hard to sell as a layer 2 measurement protocol. :) IPFIX is exporting non IP flows, this is happening. Full stop. IPFIX became a generic PUSH mechanism. Do we want to change the name. Too late I would say. However, I still believe that an applicability version 2 document will be required at some point in time in the future. Regards, Benoit. > Hi, Benoit, all, > > I believe that there's enough interest in layer 2 export that we've kind of already started applying IPFIX to non-IP packets, so to some extent both 4. and 5. would be simply a matter of aligning the 5101bis draft (perhaps as well as its shadow, 5101 + errata) with current reality. Both carry the caveat that we have to think about all the implications. But I think there is nothing about the present definition that breaks when you remove 'IP' from it. Indeed, I think the only thing to do is to remove "IP" from a couple of places, as follows, from 5101bis. > > OLD: > > IP Traffic Flow or Flow > > There are several definitions of the term \'flow' being used by the > Internet community. Within the context of IPFIX we use the > following definition: > > A Flow is defined as a set of IP packets passing an Observation > Point in the network during a certain time interval. All packets > belonging to a particular Flow have a set of common properties. > Each property is defined as the result of applying a function to the > values of: > > 1. one or more packet header fields (e.g., destination IP > address), transport header fields (e.g., destination port number), > or application header fields (e.g., RTP header fields [RFC3550]). > > 2. one or more characteristics of the packet itself (e.g., number > of MPLS labels, etc...). > > 3. one or more of fields derived from packet treatment (e.g., next > hop IP address, the output interface, etc...). > > A packet is defined as belonging to a Flow if it completely satisfies > all the defined properties of the Flow. > > This definition covers the range from a Flow containing all packets > observed at a network interface to a Flow consisting of just a > single packet between two applications. It includes packets > selected by a sampling mechanism. > > > NEW: > > > Traffic Flow or Flow > > There are several definitions of the term \'flow' being used by the > Internet community. Within the context of IPFIX we use the > following definition: > > A Flow is defined as a set of packets passing an Observation > Point in the network during a certain time interval. All packets > belonging to a particular Flow have a set of common properties. > Each property is defined as the result of applying a function to the > values of: > > 1. one or more packet header fields (e.g., destination IP > address), transport header fields (e.g., destination port number), > or application header fields (e.g., RTP header fields [RFC3550]). > > 2. one or more characteristics of the packet itself (e.g., number > of MPLS labels, etc...). > > 3. one or more of fields derived from packet treatment (e.g., next > hop IP address, the output interface, etc...). > > A packet is defined as belonging to a Flow if it completely satisfies > all the defined properties of the Flow. > > This definition covers the range from a Flow containing all packets > observed at a network interface to a Flow consisting of just a > single packet between two applications. It includes packets > selected by a sampling mechanism. > > > Even the ancillary definitions (e.g. Flow Key) already work in the context of non-IP flows. Observation Point would also have to be changed: > > > OLD: > > An Observation Point is a location in the network where IP packets > can be observed. Examples include: a line to which a probe is > attached, a shared medium, such as an Ethernet-based LAN, a single > port of a router, or a set of interfaces (physical or logical) of a > router. > > NEW: > > An Observation Point is a location in the network where packets > can be observed. Examples include: a line to which a probe is > attached, a shared medium, such as an Ethernet-based LAN, a single > port of a router, or a set of interfaces (physical or logical) of a > router. > > > These are pretty simple changes and I don't see any problem just making them. Honestly, I think the larger problem we have on this point is with the name of the protocol: with the IP right up front in the first two letters, it'll be hard to sell as a layer 2 measurement protocol. :) > > Cheers, > > Brian > > > > > On Feb 24, 2012, at 10:21 AM, Benoit Claise wrote: > >> Hi Christopher, >> >> Thanks for bringing our attention to this forgotten issue. >> As you can see from the diff between RFC5101 and the RFC5101bis draft, http://tools.ietf.org/rfcdiff?url2=draft-ietf-ipfix-protocol-rfc5101bis-00.txt, the definition has not been changed. Out of the 6 proposals, which I will repeat with correct alignment >> Let me summarize the options. The first three come from Brian's proposal below >> 1. Do nothing >> -> not ideal >> 2. Define a new category of data records which IPFIX can be used to export >> -> Brian: not a big fan of this. >> -> Same for me >> 3. Drastically expand the definition of Flow so that it covers everything you might want to represent with IPFIX >> 4. Errata on RFC5101: "IP Traffic Flow or Flow" to "Traffic Flow or Flow", and from "IP packets" to "packets >> -> this is not really an errata >> -> could be done, but we have to check all the implications >> 5. Change the definition from "IP Traffic Flow or Flow" to "Traffic Flow or Flow", and from "IP packets" to "packets" when RFC5101 will go from Proposed Standard to Draft Standard. >> 6. Have an applicability version 2, next to >> >> http://tools.ietf.org/html/rfc5472 >> >> -> expressing that it's used also for non IP packets, among other things. >> -> it's good, but I don't think this solution is complete. For example, the ITU-T would still see the definition as being IP... >> >> I'm in favor of 5. and 6., even though 4 would solve the problem now. >> >> Since we have the RFC5101bis, we should change the "IP Traffic Flow" definition. >> >> Regards, Benoit. >> >> >>> Hello Benoit and others, >>> >>> I came across this old thread and was curious if there was any further outcome. This is the last message I see in the thread, and there is indication that it might have been discussed more in person. I have been through some, but not all IPFIX documents and could not find and other references. >>> >>> Thanks >>> ...cj >>> >>> -----Original Message----- >>> From: >>> ipfix-bounces@ietf.org [mailto:ipfix-bounces@ietf.org >>> ] On Behalf Of Benoit Claise >>> Sent: Tuesday, October 26, 2010 8:35 AM >>> To: Brian Trammell >>> Cc: >>> ipfix@ietf.org >>> >>> Subject: Re: [IPFIX] Flow in IPFIX -> not only IP Flows >>> >>> Dear all, >>> >>> Thinking some more about this one. >>> It seems that there is an agreement for changing "IP packets" to "packets" in the definition >>> >>> Let me summarize the options. The first three come from Brian's proposal below 1. Do nothing >>> -> not ideal >>> 2. Define a new category of data records which IPFIX can be used to export >>> -> Brian: not a big fan of this. >>> -> Same for me >>> 3. Drastically expand the definition of Flow so that it covers everything you might want to represent with IPFIX 4. Errata on RFC5101: "IP Traffic Flow or Flow" to "Traffic Flow or Flow", and from "IP packets" to "packets >>> -> this is not really an errata >>> -> could be done, but we have to check all the implications 5. Change the definition from "IP Traffic Flow or Flow" to "Traffic Flow or Flow", and from "IP packets" to "packets" when RFC5101 will go from Proposed Standard to Draft Standard. >>> 6. Have an applicability version 2, next to >>> >>> http://tools.ietf.org/html/rfc5472 >>> >>> -> expressing that it's used also for non IP packets, among other things. >>> -> it's good, but I don't think this solution is complete. For example, the ITU-T would still see the definition as being IP... >>> >>> >>> I'm in favor of 5. and 6., even though 4 would solve the problem now. >>> >>> Feedback? >>> Do we want to discuss this in Beijing? >>> >>> Regards, Benoit. >>> >>> >>>> Brian, >>>> >>>>> Benoit, Gerhard, all, >>>>> >>>>> I agree with Gerhard here; call it a packet, leave the definition of >>>>> packet ambiguous, so that it applies to any commonly accepted >>>>> definition thereof. >>>>> >>>>> However, we have two separate problems here. The _other_ problem is >>>>> how to handle the expansion of IPFIX as a generic flexible data >>>>> representation into areas which are not directly related to flow >>>>> measurement as originally envisioned. The prototype here is SIPCLF. >>>>> >>>>> As I see it, this problem should be solved separately from the >>>>> problem of redefining flows for non-IP monitoring, and there are >>>>> three separate general solution areas: >>>>> >>>>> 1. Do nothing, keep the (slightly expanded) definition of Flow. Here, >>>>> we limit the applicibility of IPFIX to network management area, and >>>>> exploit the fact that basically everything in the network management >>>>> area is at the base of it going to involve packets going from >>>>> somewhere to somewhere. In this case, every record represented using >>>>> IPFIX is going to _somehow_ have a relationship back to _some_ set of >>>>> packets which can be wedged into the present definition (the "packet >>>>> treatment" clause in the 5101 definition affords us significant >>>>> flexibility here). This works for SIPCLF as presently defined. >>>>> Non-flow information can still be exported using Options, so it works >>>>> for expanding IPFIX to decidedly non-flow things (e.g., physical >>>>> monitoring scenarios, think periodic temperature reporting) as well, >>>>> as long as all of these records can be represented as scoped to >>>>> something (which I believe they can). In this case, we would probably >>>>> want to mention this in the soon-forthcoming I >>>>> >>>> E-Doctors draft. >>>> >>>>> 2. Define a new category of data records which IPFIX can be used to >>>>> export. These non-flow records would be represented as flow records >>>>> (i.e., not Options), and would be equivalent to Flow records, except >>>>> that the flow-specific provisions (uniqueness of flow keys, >>>>> reversibility of non-key fields, etc., etc.) would not apply. The way >>>>> to do this would be, I think, with another RFC which would present >>>>> the expanded definition, and devices exporting/handling this non-flow >>>>> data would therefore state compliance with this _new_ RFC. I'm not a >>>>> big fan of this, personally, because it seems a little complicated, >>>>> but it does allow us to segregate IPFIX-for-flow and >>>>> IPFIX-for-not-really-flow better than (1) above. >>>>> >>>>> 3. Drastically expand the definition of Flow so that it covers >>>>> everything you might want to represent with IPFIX. This strikes me as >>>>> though it would take a great deal of effort, and break a lot of >>>>> assumptions, basically as noted by Gerhard below. I mention it here >>>>> only for completeness. >>>>> >>>>> My preference would be (1) (do nothing, note applicability). Thoughts? >>>>> >>>> Right, as briefly discussed in the past, we would need an >>>> applicability version 2 >>>> >>>> Regards, Benoit. >>>> >>>>> Best regards, >>>>> >>>>> Brian >>>>> >>>>> On Sep 5, 2010, at 9:35 PM, Gerhard Muenz wrote: >>>>> >>>>> >>>>>> Benoit, >>>>>> >>>>>> I agree: "IP packet" can be replace by "packet". >>>>>> >>>>>> However, replacing "packet" by something like "packet, frame, or >>>>>> cell" would probably cause inconsistencies in this and other >>>>>> IPFIX/PSAMP documents. So, I would not go that far. >>>>>> >>>>>> Regards, >>>>>> Gerhard >>>>>> >>>>>> >>>>>> On 03.09.2010 12:20, Benoit Claise wrote: >>>>>> >>>>>>> Dear all, >>>>>>> >>>>>>> Here is one problem that was anticipated... >>>>>>> >>>>>>> For whatever reasons at that point in time, RFC 5101 limits the >>>>>>> Flow definition to IP packets >>>>>>> >>>>>>> IP Traffic Flow or Flow >>>>>>> >>>>>>> There are several definitions of the term 'flow' being used >>>>>>> by the >>>>>>> Internet community. Within the context of IPFIX we use the >>>>>>> following definition: >>>>>>> >>>>>>> A Flow is defined as a set of IP packets passing an Observation >>>>>>> Point in the network during a certain time interval. All >>>>>>> packets >>>>>>> belonging to a particular Flow have a set of common properties. >>>>>>> Each property is defined as the result of applying a >>>>>>> function to >>>>>>> the values of: >>>>>>> >>>>>>> 1. one or more packet header fields (e.g., destination IP >>>>>>> address), transport header fields (e.g., destination port >>>>>>> number), or application header fields (e.g., RTP header >>>>>>> fields [RFC3550 >>>>>>> >>>>>>> ]). >>>>>>> >>>>>>> 2. one or more characteristics of the packet itself (e.g., >>>>>>> number of MPLS labels, etc...). >>>>>>> >>>>>>> 3. one or more of fields derived from packet treatment >>>>>>> (e.g., >>>>>>> next hop IP address, the output interface, etc...). >>>>>>> >>>>>>> A packet is defined as belonging to a Flow if it completely >>>>>>> satisfies all the defined properties of the Flow. >>>>>>> >>>>>>> This definition covers the range from a Flow containing all >>>>>>> packets observed at a network interface to a Flow consisting of >>>>>>> just a single packet between two applications. It includes >>>>>>> packets selected by a sampling mechanism. >>>>>>> >>>>>>> However, we know that IPFIX cover more than IP. >>>>>>> >>>>>>> http://www.iana.org/assignments/ipfix/ipfix.xhtml >>>>>>> mentions >>>>>>> sourceMacAddress, ethernetPayloadLength, etc... >>>>>>> And we know that IPFIX became a kind of generic streaming protocol. >>>>>>> >>>>>>> Talking in the context of the NGN networks at the ITU, there are >>>>>>> some reluctance to adopt this Flow definition limited to IP packets. >>>>>>> Isn't it time to do something about this definition? >>>>>>> >>>>>>> Regards, Benoit. >>>>>>> >>>>>> _______________________________________________ >>>>>> IPFIX mailing list >>>>>> >>>>>> IPFIX@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/ipfix >>>> _______________________________________________ >>>> IPFIX mailing list >>>> >>>> IPFIX@ietf.org >>>> https://www.ietf.org/mailman/listinfo/ipfix >>> _______________________________________________ >>> IPFIX mailing list >>> >>> IPFIX@ietf.org >>> https://www.ietf.org/mailman/listinfo/ipfix >>> >>> >>> >>> > > --------------020608010502010103010401 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Brian,

Agreed to your changes.
Agreed that there is no impact changing those definitions.

On this point:
These are pretty simple changes and I don't see any problem just making them. Honestly, I think the larger problem we have on this point is with the name of the protocol: with the IP right up front in the first two letters, it'll be hard to sell as a layer 2 measurement protocol. :)
IPFIX is exporting non IP flows, this is happening. Full stop.
IPFIX became a generic PUSH mechanism.
Do we want to change the name. Too late I would say.
However, I still believe that an applicability version 2 document will be required at some point in time in the future.

Regards, Benoit.

Hi, Benoit, all,

I believe that there's enough interest in layer 2 export that we've kind of already started applying IPFIX to non-IP packets, so to some extent both 4. and 5. would be simply a matter of aligning the 5101bis draft (perhaps as well as its shadow, 5101 + errata) with current reality. Both carry the caveat that we have to think about all the implications. But I think there is nothing about the present definition that breaks when you remove 'IP' from it. Indeed, I think the only thing to do is to remove "IP" from a couple of places, as follows, from 5101bis. 

OLD:

IP Traffic Flow or Flow 
 
There are several definitions of the term \'flow' being used by the 
Internet community.  Within the context of IPFIX we use the 
following definition: 
 
A Flow is defined as a set of IP packets passing an Observation 
Point in the network during a certain time interval.  All packets 
belonging to a particular Flow have a set of common properties.  
Each property is defined as the result of applying a function to the 
values of: 

1. one or more packet header fields (e.g., destination IP  
address), transport header fields (e.g., destination port number), 
or application header fields (e.g., RTP header fields [RFC3550]). 

2. one or more characteristics of the packet itself (e.g., number 
of MPLS labels, etc...). 

3. one or more of fields derived from packet treatment (e.g., next 
hop IP address, the output interface, etc...). 

A packet is defined as belonging to a Flow if it completely satisfies 
all the defined properties of the Flow. 
 
This definition covers the range from a Flow containing all packets 
observed at a network interface to a Flow consisting of just a 
single packet between two applications.  It includes packets 
selected by a sampling mechanism. 


NEW:


Traffic Flow or Flow 
 
There are several definitions of the term \'flow' being used by the 
Internet community.  Within the context of IPFIX we use the 
following definition: 
 
A Flow is defined as a set of packets passing an Observation 
Point in the network during a certain time interval.  All packets 
belonging to a particular Flow have a set of common properties.  
Each property is defined as the result of applying a function to the 
values of: 

1. one or more packet header fields (e.g., destination IP  
address), transport header fields (e.g., destination port number), 
or application header fields (e.g., RTP header fields [RFC3550]). 

2. one or more characteristics of the packet itself (e.g., number 
of MPLS labels, etc...). 

3. one or more of fields derived from packet treatment (e.g., next 
hop IP address, the output interface, etc...). 

A packet is defined as belonging to a Flow if it completely satisfies 
all the defined properties of the Flow. 
 
This definition covers the range from a Flow containing all packets 
observed at a network interface to a Flow consisting of just a 
single packet between two applications.  It includes packets 
selected by a sampling mechanism. 


Even the ancillary definitions (e.g. Flow Key) already work in the context of non-IP flows. Observation Point would also have to be changed:


OLD:

An Observation Point is a location in the network where IP packets 
can be observed.  Examples include: a line to which a probe is 
attached, a shared medium, such as an Ethernet-based LAN, a single 
port of a router, or a set of interfaces (physical or logical) of a 
router. 

NEW:

An Observation Point is a location in the network where packets 
can be observed.  Examples include: a line to which a probe is 
attached, a shared medium, such as an Ethernet-based LAN, a single 
port of a router, or a set of interfaces (physical or logical) of a 
router. 


These are pretty simple changes and I don't see any problem just making them. Honestly, I think the larger problem we have on this point is with the name of the protocol: with the IP right up front in the first two letters, it'll be hard to sell as a layer 2 measurement protocol. :)

Cheers,

Brian




On Feb 24, 2012, at 10:21 AM, Benoit Claise wrote:


Hi Christopher,

Thanks for bringing our attention to this forgotten issue.
As you can see from the diff between RFC5101 and the RFC5101bis draft, http://tools.ietf.org/rfcdiff?url2=draft-ietf-ipfix-protocol-rfc5101bis-00.txt, the definition has not been changed. Out of the 6 proposals, which I will repeat with correct alignment
Let me summarize the options. The first three come from Brian's proposal below 
1. Do nothing
     -> not ideal
2. Define a new category of data records which IPFIX can be used to export
     -> Brian: not a big fan of this.
     -> Same for me
3. Drastically expand the definition of Flow so that it covers everything you might want to represent with IPFIX 
4. Errata on RFC5101: "IP Traffic Flow or Flow" to "Traffic Flow or Flow", and from "IP packets" to "packets
     -> this is not really an errata
     -> could be done, but we have to check all the implications 
5. Change the definition from "IP Traffic Flow or Flow" to "Traffic Flow or Flow", and from "IP packets" to "packets" when RFC5101 will go from Proposed Standard to Draft Standard.
6. Have an applicability version 2, next to

http://tools.ietf.org/html/rfc5472

     -> expressing that it's used also for non IP packets, among other things.
     -> it's good, but I don't think this solution is complete. For example, the ITU-T would still see the definition as being IP...

I'm in favor of 5. and 6., even though 4 would solve the problem now.

Since we have the RFC5101bis, we should change the "IP Traffic Flow" definition.

Regards, Benoit.



Hello Benoit and others,

I came across this old thread and was curious if there was any further outcome.  This is the last message I see in the thread, and there is indication that it might have been discussed more in person.   I have been through some, but not all IPFIX documents and could not find and other references.

Thanks
...cj

-----Original Message-----
From: 
ipfix-bounces@ietf.org [mailto:ipfix-bounces@ietf.org
] On Behalf Of Benoit Claise
Sent: Tuesday, October 26, 2010 8:35 AM
To: Brian Trammell
Cc: 
ipfix@ietf.org

Subject: Re: [IPFIX] Flow in IPFIX -> not only IP Flows

Dear all,

Thinking some more about this one.
It seems that there is an agreement for changing "IP packets" to "packets" in the definition

Let me summarize the options. The first three come from Brian's proposal below 1. Do nothing
     -> not ideal
2. Define a new category of data records which IPFIX can be used to export
     -> Brian: not a big fan of this.
     -> Same for me
3. Drastically expand the definition of Flow so that it covers everything you might want to represent with IPFIX 4. Errata on RFC5101: "IP Traffic Flow or Flow" to "Traffic Flow or Flow", and from "IP packets" to "packets
     -> this is not really an errata
     -> could be done, but we have to check all the implications 5. Change the definition from "IP Traffic Flow or Flow" to "Traffic Flow or Flow", and from "IP packets" to "packets" when RFC5101 will go from Proposed Standard to Draft Standard.
6. Have an applicability version 2, next to

http://tools.ietf.org/html/rfc5472

     -> expressing that it's used also for non IP packets, among other things.
     -> it's good, but I don't think this solution is complete. For example, the ITU-T would still see the definition as being IP...


I'm in favor of 5. and 6., even though 4 would solve the problem now.

Feedback?
Do we want to discuss this in Beijing?

Regards, Benoit.



 Brian,


Benoit, Gerhard, all,

I agree with Gerhard here; call it a packet, leave the definition of 
packet ambiguous, so that it applies to any commonly accepted 
definition thereof.

However, we have two separate problems here. The _other_ problem is 
how to handle the expansion of IPFIX as a generic flexible data 
representation into areas which are not directly related to flow 
measurement as originally envisioned. The prototype here is SIPCLF.

As I see it, this problem should be solved separately from the 
problem of redefining flows for non-IP monitoring, and there are 
three separate general solution areas:

1. Do nothing, keep the (slightly expanded) definition of Flow. Here, 
we limit the applicibility of IPFIX to network management area, and 
exploit the fact that basically everything in the network management 
area is at the base of it going to involve packets going from 
somewhere to somewhere. In this case, every record represented using 
IPFIX is going to _somehow_ have a relationship back to _some_ set of 
packets which can be wedged into the present definition (the "packet 
treatment" clause in the 5101 definition affords us significant 
flexibility here). This works for SIPCLF as presently defined.
Non-flow information can still be exported using Options, so it works 
for expanding IPFIX to decidedly non-flow things (e.g., physical 
monitoring scenarios, think periodic temperature reporting) as well, 
as long as all of these records can be represented as scoped to 
something (which I believe they can). In this case, we would probably 
want to mention this in the soon-forthcoming I


E-Doctors draft.


2. Define a new category of data records which IPFIX can be used to 
export. These non-flow records would be represented as flow records 
(i.e., not Options), and would be equivalent to Flow records, except 
that the flow-specific provisions (uniqueness of flow keys, 
reversibility of non-key fields, etc., etc.) would not apply. The way 
to do this would be, I think, with another RFC which would present 
the expanded definition, and devices exporting/handling this non-flow 
data would therefore state compliance with this _new_ RFC. I'm not a 
big fan of this, personally, because it seems a little complicated, 
but it does allow us to segregate IPFIX-for-flow and 
IPFIX-for-not-really-flow better than (1) above.

3. Drastically expand the definition of Flow so that it covers 
everything you might want to represent with IPFIX. This strikes me as 
though it would take a great deal of effort, and break a lot of 
assumptions, basically as noted by Gerhard below. I mention it here 
only for completeness.

My preference would be (1) (do nothing, note applicability). Thoughts?


Right, as briefly discussed in the past, we would need an 
applicability  version 2

Regards, Benoit.


Best regards,

Brian

On Sep 5, 2010, at 9:35 PM, Gerhard Muenz wrote:



Benoit,

I agree: "IP packet" can be replace by "packet".

However, replacing "packet" by something like "packet, frame, or 
cell" would probably cause inconsistencies in this and other 
IPFIX/PSAMP documents. So, I would not go that far.

Regards,
Gerhard


On 03.09.2010 12:20, Benoit Claise wrote:


  Dear all,

Here is one problem that was anticipated...

For whatever reasons at that point in time, RFC 5101 limits the 
Flow definition to IP packets

    IP Traffic Flow or Flow

       There are several definitions of the term 'flow' being used 
by the
       Internet community.  Within the context of IPFIX we use the
       following definition:

       A Flow is defined as a set of IP packets passing an Observation
       Point in the network during a certain time interval.  All 
packets
       belonging to a particular Flow have a set of common properties.
       Each property is defined as the result of applying a 
function to
       the values of:

          1. one or more packet header fields (e.g., destination IP
             address), transport header fields (e.g., destination port
             number), or application header fields (e.g., RTP header
             fields [RFC3550
<http://tools.ietf.org/html/rfc3550>
]).

          2. one or more characteristics of the packet itself (e.g.,
             number of MPLS labels, etc...).

          3. one or more of fields derived from packet treatment 
(e.g.,
             next hop IP address, the output interface, etc...).

       A packet is defined as belonging to a Flow if it completely
       satisfies all the defined properties of the Flow.

       This definition covers the range from a Flow containing all
       packets observed at a network interface to a Flow consisting of
       just a single packet between two applications.  It includes
       packets selected by a sampling mechanism.

However, we know that IPFIX cover more than IP.

http://www.iana.org/assignments/ipfix/ipfix.xhtml
 mentions 
sourceMacAddress, ethernetPayloadLength, etc...
And we know that IPFIX became a kind of generic streaming protocol.

Talking in the context of the NGN networks at the ITU, there are 
some reluctance to adopt this Flow definition limited to IP packets.
Isn't it time to do something about this definition?

Regards, Benoit.


_______________________________________________
IPFIX mailing list

IPFIX@ietf.org
https://www.ietf.org/mailman/listinfo/ipfix

_______________________________________________
IPFIX mailing list

IPFIX@ietf.org
https://www.ietf.org/mailman/listinfo/ipfix

_______________________________________________
IPFIX mailing list

IPFIX@ietf.org
https://www.ietf.org/mailman/listinfo/ipfix






      

      




    

    

  


--------------020608010502010103010401--

From bclaise@cisco.com  Fri Feb 24 02:48:37 2012
Return-Path: 
X-Original-To: ipfix@ietfa.amsl.com
Delivered-To: ipfix@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE66D21F891F for ; Fri, 24 Feb 2012 02:48:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.484
X-Spam-Level: 
X-Spam-Status: No, score=-2.484 tagged_above=-999 required=5 tests=[AWL=0.115,  BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cuaajqLPyyOf for ; Fri, 24 Feb 2012 02:48:37 -0800 (PST)
Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by ietfa.amsl.com (Postfix) with ESMTP id E1CDD21F8920 for ; Fri, 24 Feb 2012 02:48:36 -0800 (PST)
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 q1OAmZgI001419; Fri, 24 Feb 2012 11:48:36 +0100 (CET)
Received: from [10.60.67.84] (ams-bclaise-8913.cisco.com [10.60.67.84]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id q1OAmZlP004754; Fri, 24 Feb 2012 11:48:35 +0100 (CET)
Message-ID: <4F476B03.9020607@cisco.com>
Date: Fri, 24 Feb 2012 11:48:35 +0100
From: Benoit Claise 
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:9.0) Gecko/20111222 Thunderbird/9.0.1
MIME-Version: 1.0
To: Rahul Patel 
References:  <4F42B0C3.4030605@cisco.com>
In-Reply-To: <4F42B0C3.4030605@cisco.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: draft-ietf-ipfix-a9n@tools.ietf.org, "ipfix@ietf.org" 
Subject: Re: [IPFIX] draft-ietf-ipfix-a9n
X-BeenThere: ipfix@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IPFIX WG discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 24 Feb 2012 10:48:38 -0000

Rahul,

Thanks for your review.
>
>> Hi,
>>
>> Here are my comments.
>>
>> I think correlation is important part of aggregation and this draft 
>> should
>> include a section on it.
>> There are different cases of correlation which the draft should touch.
>>
>> 1. Key fields of Aggregated Flow is same or the subset of all original
>> Flows
>>       * In this case the correlation is straight forward. The values 
>> from
>> the original flows are simply merged (added/replaced/etc) into matching
>> aggregated flow.
>> 2. Key fields of Aggregated Flow is larger than at least one original 
>> flow.
>>       * An example is best to describe this case. One original flow 
>> contain
>> (5-tuple, src-interface, byte) and another original flow contains
>> (5-tuple, transaction-delay). Now the aggregated flow has the key fields
>> of srcip, dstip and src-interface). One of the flow doesn't have
>> information on per source-interface basis. So the aggregator will 
>> perform
>> aggregation at two level and represent that data in ipfix-structured
>> format. The above data would look like
>>
>> Srcip, dstip, transaction_delay, { List of {src-interface, byte } }
>> =====  =====  =================  ==================================
>> A,     B,     200,               { (Ethernet0/0, 1500),
>>                                     (Ethernet1/0, 1600) .. }
>> A,     C,     300,               { (Ethernet0/0, 1500) }
>>
Maybe we can point to RFC6313 as a potential solution, but not specify 
the rules in this draft.
Btw, the rules would be very difficult to specify.
So, some generic text.
>>
>>
>> Section 5.1.1 Distributing values across Interval
>> -------------------------------------------------
>> * should add 'synchronized expiry of Original Flows' - Under this method
>> Flow C would be exported three times with start-time/end-time 
>> matching the
>> aggregation interval start-time/end-time.
Make sense to me.
>>
>> * There will always going to some original flows which will arrive late
>> and will not be accounted. It will be good have a cumulative counter of
>> such late arrivals on per template id (aggregated flow) basis. This
>> cumulative count should be periodically exported along with end-time
>> (time-of-snapshot). The counter will provide a degree of confidence 
>> in the
>> data exported by the aggregator for each template.
So you want something similar to "The Metering Process Statistics Option 
Template" from RFC5101, http://tools.ietf.org/html/rfc5101#page-23, but 
for the Aggregation Intermediate Aggregation Process, right?

Regards, Benoit.
>>
>> Section 5.2 Spatial aggregation
>> -------------------------------
>> * Is it a good idea to add an example of deriving a key in aggregate 
>> flow
>> from multiple keys or non-keys or combination of Original keys. E.g
>> 5-tuple translated to a session-id from metadata table.
>> * Along similar line, derivation of aggregate flow key from multiple 
>> keys
>> from different Original flows. One flow reports 5-tuple and byte-count.
>> The other flow reports 5-tuple and the user-id. The aggregated flow has
>> the user-id as key and byte-count as collect. I guess this can be
>> considered a correlation.
>>
>>
>> Thanks,
>> -Rahul
>>
>>
>>
>
> _______________________________________________
> IPFIX mailing list
> IPFIX@ietf.org
> https://www.ietf.org/mailman/listinfo/ipfix
>
>


From rahulp@cisco.com  Fri Feb 24 07:08:13 2012
Return-Path: 
X-Original-To: ipfix@ietfa.amsl.com
Delivered-To: ipfix@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2CF2E21F8811 for ; Fri, 24 Feb 2012 07:08:13 -0800 (PST)
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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p7lDrLPbOdgc for ; Fri, 24 Feb 2012 07:08:12 -0800 (PST)
Received: from mtv-iport-2.cisco.com (mtv-iport-2.cisco.com [173.36.130.13]) by ietfa.amsl.com (Postfix) with ESMTP id 23C2C21F87E9 for ; Fri, 24 Feb 2012 07:08:01 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=rahulp@cisco.com; l=3694; q=dns/txt; s=iport; t=1330096081; x=1331305681; h=date:subject:from:to:cc:message-id:in-reply-to: mime-version:content-transfer-encoding; bh=iLRmuSJHdwfOS/hdrF2uhHWLVvvI/lTwYyhgiuG40aM=; b=VcDQTBVNHZ/lhVOC2jje2adnTS0HTeFyhEey2rhsQQnzpVfms7MxHd5r VZuuy8BYB8ETLG6TdpMiNUvnugR4Qo7zTZLnWft8KwafvD3nwUrj/h5yM 5li1zy857BU8uLZa7gaQE5BRoMme3RcYGMhIk4yodE8xy7mUS7jW2OnnZ I=;
X-IronPort-AV: E=Sophos;i="4.73,476,1325462400"; d="scan'208";a="32266467"
Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-2.cisco.com with ESMTP; 24 Feb 2012 15:08:01 +0000
Received: from [161.44.71.234] ([161.44.71.234]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id q1OF7qic009478; Fri, 24 Feb 2012 15:07:58 GMT
User-Agent: Microsoft-MacOutlook/14.14.0.111121
Date: Fri, 24 Feb 2012 10:07:50 -0500
From: Rahul Patel 
To: Benoit Claise 
Message-ID: 
Thread-Topic: [IPFIX] draft-ietf-ipfix-a9n
In-Reply-To: <4F476B03.9020607@cisco.com>
Mime-version: 1.0
Content-type: text/plain; charset="US-ASCII"
Content-transfer-encoding: 7bit
Cc: draft-ietf-ipfix-a9n@tools.ietf.org, "ipfix@ietf.org" 
Subject: Re: [IPFIX] draft-ietf-ipfix-a9n
X-BeenThere: ipfix@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IPFIX WG discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 24 Feb 2012 15:08:13 -0000

Hi Benoit,


On 2/24/12 5:48 AM, "Benoit Claise"  wrote:

>Rahul,
>
>Thanks for your review.
>>
>>> Hi,
>>>
>>> Here are my comments.
>>>
>>> I think correlation is important part of aggregation and this draft
>>> should
>>> include a section on it.
>>> There are different cases of correlation which the draft should touch.
>>>
>>> 1. Key fields of Aggregated Flow is same or the subset of all original
>>> Flows
>>>       * In this case the correlation is straight forward. The values
>>> from
>>> the original flows are simply merged (added/replaced/etc) into matching
>>> aggregated flow.
>>> 2. Key fields of Aggregated Flow is larger than at least one original
>>> flow.
>>>       * An example is best to describe this case. One original flow
>>> contain
>>> (5-tuple, src-interface, byte) and another original flow contains
>>> (5-tuple, transaction-delay). Now the aggregated flow has the key
>>>fields
>>> of srcip, dstip and src-interface). One of the flow doesn't have
>>> information on per source-interface basis. So the aggregator will
>>> perform
>>> aggregation at two level and represent that data in ipfix-structured
>>> format. The above data would look like
>>>
>>> Srcip, dstip, transaction_delay, { List of {src-interface, byte } }
>>> =====  =====  =================  ==================================
>>> A,     B,     200,               { (Ethernet0/0, 1500),
>>>                                     (Ethernet1/0, 1600) .. }
>>> A,     C,     300,               { (Ethernet0/0, 1500) }
>>>
>Maybe we can point to RFC6313 as a potential solution, but not specify
>the rules in this draft.
>Btw, the rules would be very difficult to specify.
>So, some generic text.

[RP] That would be good.

>>>
>>>
>>> Section 5.1.1 Distributing values across Interval
>>> -------------------------------------------------
>>> * should add 'synchronized expiry of Original Flows' - Under this
>>>method
>>> Flow C would be exported three times with start-time/end-time
>>> matching the
>>> aggregation interval start-time/end-time.
>Make sense to me.
>>>
>>> * There will always going to some original flows which will arrive late
>>> and will not be accounted. It will be good have a cumulative counter of
>>> such late arrivals on per template id (aggregated flow) basis. This
>>> cumulative count should be periodically exported along with end-time
>>> (time-of-snapshot). The counter will provide a degree of confidence
>>> in the
>>> data exported by the aggregator for each template.
>So you want something similar to "The Metering Process Statistics Option
>Template" from RFC5101, http://tools.ietf.org/html/rfc5101#page-23, but
>for the Aggregation Intermediate Aggregation Process, right?

[RP] exactly.

-Rahul

>
>Regards, Benoit.
>>>
>>> Section 5.2 Spatial aggregation
>>> -------------------------------
>>> * Is it a good idea to add an example of deriving a key in aggregate
>>> flow
>>> from multiple keys or non-keys or combination of Original keys. E.g
>>> 5-tuple translated to a session-id from metadata table.
>>> * Along similar line, derivation of aggregate flow key from multiple
>>> keys
>>> from different Original flows. One flow reports 5-tuple and byte-count.
>>> The other flow reports 5-tuple and the user-id. The aggregated flow has
>>> the user-id as key and byte-count as collect. I guess this can be
>>> considered a correlation.
>>>
>>>
>>> Thanks,
>>> -Rahul
>>>
>>>
>>>
>>
>> _______________________________________________
>> IPFIX mailing list
>> IPFIX@ietf.org
>> https://www.ietf.org/mailman/listinfo/ipfix
>>
>>
>



From Christopher.White@riverbed.com  Fri Feb 24 12:33:21 2012
Return-Path: 
X-Original-To: ipfix@ietfa.amsl.com
Delivered-To: ipfix@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A6EB721F8673 for ; Fri, 24 Feb 2012 12:33:21 -0800 (PST)
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=[AWL=1.000,  BAYES_00=-2.599, GB_I_LETTER=-2]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1L55ZdFySQu9 for ; Fri, 24 Feb 2012 12:33:20 -0800 (PST)
Received: from smtp2.riverbed.com (smtp2.riverbed.com [208.70.196.44]) by ietfa.amsl.com (Postfix) with ESMTP id CBA3D21F8668 for ; Fri, 24 Feb 2012 12:33:20 -0800 (PST)
Received: from unknown (HELO 365EXCH-HUB-P2.nbttech.com) ([10.16.4.1]) by smtp2.riverbed.com with ESMTP; 24 Feb 2012 12:33:20 -0800
Received: from 365EXCH-MBX-P1.nbttech.com ([fe80::fd90:c034:9ba7:e0a3]) by 365EXCH-HUB-P2.nbttech.com ([fe80::4998:6c24:821c:b3e1%16]) with mapi id 14.01.0339.001; Fri, 24 Feb 2012 12:33:20 -0800
From: Christopher White 
To: Paul Aitken , Brian Trammell 
Thread-Topic: [IPFIX] Flow in IPFIX -> not only IP Flows
Thread-Index: Act1CjbvJx7XOFYyRVOGjjtY4AX/SF8dPZWwAGZgngAAALdJAAABd84AAAQDvVA=
Date: Fri, 24 Feb 2012 20:33:19 +0000
Message-ID: 
References: <4C80CBE8.2080708@cisco.com>	<4C83F0E6.8050106@net.in.tum.de> <88A72F0E-DCD8-44B9-A7C2-FE29BF684B93@tik.ee.ethz.ch> <4C86AAFF.9050008@cisco.com> <4CC6CAE4.8090605@cisco.com>  <4F475680.9060501@cisco.com> <1450F2CB-ECB5-4597-9CB7-A01FA8071A7B@tik.ee.ethz.ch> <4F476528.3010201@cisco.com>
In-Reply-To: <4F476528.3010201@cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.16.205.251]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "ipfix@ietf.org" 
Subject: Re: [IPFIX] Flow in IPFIX -> not only IP Flows
X-BeenThere: ipfix@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IPFIX WG discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 24 Feb 2012 20:33:21 -0000

Hi Paul and Brian,

> From: Paul Aitken [mailto:paitken@cisco.com]
> > Honestly, I think the larger problem we have on this point is with the
> > name of the protocol: with the IP right up front in the first two
> > letters, it'll be hard to sell as a layer 2 measurement protocol. :)
>=20
> The existing IANA elements show that it can measure metrics at any layer.
> Even "flow" isn't so relevant these days.
>=20
> So IPFIX isn't export _of_ IP, it's export _over_ IP.

[Christopher White]=20

Yes, I'm actually even thinking a bit more broadly as well, such as export =
of other statistics:

 * Per Interface utilization
 * Server stats (cpu/memory per process)
 * Queuing stats (queue len, loss)

As such it may not even be IP or flow related, it's just a nice well define=
d mechanism for the regular export of statistics.  I certainly understand t=
his takes the scope of IPFIX way beyond where it is now, but I find it part=
icularly intriguing, because once a product has support for export IP/flow =
based statistics via netflow, there's a lot of infrastructure already in pl=
ace that one would like to reuse for exporting other non-IP/flow stats. =20

It's all pretty much doable using the existing IPFIX language, if you simpl=
y allow for other records with different key fields.  For flows, the key fi=
elds are based generally on the 5-tuple, and thus all flows are pretty much=
 expected to have those or some subset.  If you monitor some other class su=
ch as server stats, you simply need to define new fields and be able to fla=
g which fields are the key fields (process / thread, for example). =20

It seems this would merely require some common field across all flows to in=
dicate what class of item this is.    This might be indirectly discovered b=
ased on the fields in the flow (presence of IP src/dst indicates an IP flow=
, presence of process/thread is server stats), but such indirect logic is a=
lways problematic.

...cj


From trammell@tik.ee.ethz.ch  Fri Feb 24 13:24:35 2012
Return-Path: 
X-Original-To: ipfix@ietfa.amsl.com
Delivered-To: ipfix@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8216A21F8595 for ; Fri, 24 Feb 2012 13:24:35 -0800 (PST)
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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DWSsklpUXWzA for ; Fri, 24 Feb 2012 13:24:34 -0800 (PST)
Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) by ietfa.amsl.com (Postfix) with ESMTP id 9E5BD21F8593 for ; Fri, 24 Feb 2012 13:24:34 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id C4091D9321; Fri, 24 Feb 2012 22:24:33 +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 sWPkTGG5-Vaa; Fri, 24 Feb 2012 22:24:33 +0100 (MET)
Received: from [10.0.1.2] (cust-integra-121-161.antanet.ch [80.75.121.161]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: briant) by smtp.ee.ethz.ch (Postfix) with ESMTPSA id 5F5CBD930B; Fri, 24 Feb 2012 22:24:33 +0100 (MET)
Mime-Version: 1.0 (Apple Message framework v1257)
Content-Type: text/plain; charset=us-ascii
From: Brian Trammell 
In-Reply-To: 
Date: Fri, 24 Feb 2012 22:24:31 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <3FC6273A-2FB1-4FE3-A3F7-DE658E1336C1@tik.ee.ethz.ch>
References: 
To: Rahul Patel 
X-Mailer: Apple Mail (2.1257)
Cc: draft-ietf-ipfix-a9n@tools.ietf.org, "ipfix@ietf.org" 
Subject: Re: [IPFIX] draft-ietf-ipfix-a9n
X-BeenThere: ipfix@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IPFIX WG discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 24 Feb 2012 21:24:35 -0000

On Feb 24, 2012, at 4:07 PM, Rahul Patel wrote:

>>>> Section 5.1.1 Distributing values across Interval
>>>> -------------------------------------------------
>>>> * should add 'synchronized expiry of Original Flows' - Under this
>>>> method
>>>> Flow C would be exported three times with start-time/end-time
>>>> matching the
>>>> aggregation interval start-time/end-time.
>> Make sense to me.
>>>>=20
>>>> * There will always going to some original flows which will arrive =
late
>>>> and will not be accounted. It will be good have a cumulative =
counter of
>>>> such late arrivals on per template id (aggregated flow) basis. This
>>>> cumulative count should be periodically exported along with =
end-time
>>>> (time-of-snapshot). The counter will provide a degree of confidence
>>>> in the
>>>> data exported by the aggregator for each template.
>> So you want something similar to "The Metering Process Statistics =
Option
>> Template" from RFC5101, http://tools.ietf.org/html/rfc5101#page-23, =
but
>> for the Aggregation Intermediate Aggregation Process, right?
>=20
> [RP] exactly.

Still not convinced this is needed given the nature of active timeouts; =
however, that may well be an implementation-specific (or =
application-specific) opinion.=20

In that case, I agree we should add it but I'm not convinced that this =
is an aggregation-specific thing. If you're going to count records that =
were dropped at an intermediate process due to missing a time window, =
couldn't this affect non-aggregation intermediate processes as well? How =
about adding this to MEDPROTO instead?

Best regards,

Brian=

From trammell@tik.ee.ethz.ch  Fri Feb 24 13:24:36 2012
Return-Path: 
X-Original-To: ipfix@ietfa.amsl.com
Delivered-To: ipfix@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F7F521F8595 for ; Fri, 24 Feb 2012 13:24:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.599
X-Spam-Level: 
X-Spam-Status: No, score=-7.599 tagged_above=-999 required=5 tests=[AWL=1.000,  BAYES_00=-2.599, GB_I_LETTER=-2, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SnDqk4zJjF63 for ; Fri, 24 Feb 2012 13:24:35 -0800 (PST)
Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) by ietfa.amsl.com (Postfix) with ESMTP id 99F4021F8593 for ; Fri, 24 Feb 2012 13:24:35 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id D594FD949D; Fri, 24 Feb 2012 22:24:34 +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 8c1CMwGBIgoo; Fri, 24 Feb 2012 22:24:34 +0100 (MET)
Received: from [10.0.1.2] (cust-integra-121-161.antanet.ch [80.75.121.161]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: briant) by smtp.ee.ethz.ch (Postfix) with ESMTPSA id 6DE45D930B; Fri, 24 Feb 2012 22:24:34 +0100 (MET)
Mime-Version: 1.0 (Apple Message framework v1257)
Content-Type: text/plain; charset=us-ascii
From: Brian Trammell 
In-Reply-To: 
Date: Fri, 24 Feb 2012 22:24:34 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <4C80CBE8.2080708@cisco.com>	<4C83F0E6.8050106@net.in.tum.de> <88A72F0E-DCD8-44B9-A7C2-FE29BF684B93@tik.ee.ethz.ch> <4C86AAFF.9050008@cisco.com> <4CC6CAE4.8090605@cisco.com>  <4F475680.9060501@cisco.com> <1450F2CB-ECB5-4597-9CB7-A01FA8071A7B@tik.ee.ethz.ch> <4F476528.3010201@cisco.com> 
To: Christopher White 
X-Mailer: Apple Mail (2.1257)
Cc: "ipfix@ietf.org" 
Subject: Re: [IPFIX] Flow in IPFIX -> not only IP Flows
X-BeenThere: ipfix@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IPFIX WG discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 24 Feb 2012 21:24:36 -0000

On Feb 24, 2012, at 9:33 PM, Christopher White wrote:

> Hi Paul and Brian,
>=20
>> From: Paul Aitken [mailto:paitken@cisco.com]
>>> Honestly, I think the larger problem we have on this point is with =
the
>>> name of the protocol: with the IP right up front in the first two
>>> letters, it'll be hard to sell as a layer 2 measurement protocol. :)
>>=20
>> The existing IANA elements show that it can measure metrics at any =
layer.
>> Even "flow" isn't so relevant these days.
>>=20
>> So IPFIX isn't export _of_ IP, it's export _over_ IP.
>=20
> [Christopher White]=20
>=20
> Yes, I'm actually even thinking a bit more broadly as well, such as =
export of other statistics:
>=20
> * Per Interface utilization
> * Server stats (cpu/memory per process)
> * Queuing stats (queue len, loss)
>=20
> As such it may not even be IP or flow related, it's just a nice well =
defined mechanism for the regular export of statistics.  I certainly =
understand this takes the scope of IPFIX way beyond where it is now, but =
I find it particularly intriguing, because once a product has support =
for export IP/flow based statistics via netflow, there's a lot of =
infrastructure already in place that one would like to reuse for =
exporting other non-IP/flow stats. =20

I wouldn't call this "way beyond" where IPFIX is now. Have a look at =
draft-ietf-ipfix-ie-doctors, which specifies (in section 8) how to =
"design" new applications for IPFIX which are not strictly-speaking Flow =
based.=20

All of the examples above pretty much apply to the "notional Flow" =
approach outlined there.

> It's all pretty much doable using the existing IPFIX language, if you =
simply allow for other records with different key fields.  For flows, =
the key fields are based generally on the 5-tuple, and thus all flows =
are pretty much expected to have those or some subset.  If you monitor =
some other class such as server stats, you simply need to define new =
fields and be able to flag which fields are the key fields (process / =
thread, for example). =20
>=20
> It seems this would merely require some common field across all flows =
to indicate what class of item this is.    This might be indirectly =
discovered based on the fields in the flow (presence of IP src/dst =
indicates an IP flow, presence of process/thread is server stats), but =
such indirect logic is always problematic.

If you've designed your templates correctly (i.e., such that each =
template or group of templates really does represent a separate data =
type), the type of a record can be very easily deduced at the collector =
side based on the presence of a set of Information Elements (and perhaps =
the absence of a different set of Information Elements) in the template, =
allowing you to keep a SetID/type map. See draft-trammell-ipfix-sip-msg =
for an _explicit_ example of how to do this. I'd recommend against =
defining a "type" information element, as you can run into some pretty =
silly inconsistencies.

(6313 as published breaks the ability to determine type from the =
template in the general case; see my slides on this in Taipei for more, =
so for applications where data typing is important, either don't use =
6313 or come help us design a fix :) )

Cheers,

Brian


From n.brownlee@auckland.ac.nz  Sun Feb 26 11:15:36 2012
Return-Path: 
X-Original-To: ipfix@ietfa.amsl.com
Delivered-To: ipfix@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 81B5E21F8542 for ; Sun, 26 Feb 2012 11:15:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.173
X-Spam-Level: 
X-Spam-Status: No, score=-102.173 tagged_above=-999 required=5 tests=[AWL=0.937, BAYES_05=-1.11, GB_I_LETTER=-2, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EJ4vzrxMkQDX for ; Sun, 26 Feb 2012 11:15:35 -0800 (PST)
Received: from mx2.auckland.ac.nz (mx2.auckland.ac.nz [130.216.12.44]) by ietfa.amsl.com (Postfix) with ESMTP id F219421F84C3 for ; Sun, 26 Feb 2012 11:15:33 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=n.brownlee@auckland.ac.nz; q=dns/txt; s=uoa; t=1330283735; x=1361819735; h=message-id:date:from:mime-version:to:subject:references: in-reply-to:content-transfer-encoding; bh=MavxfwEdZ0FqAqPwx/d2sIUzOc9pBAZsvSMRnqtyvos=; b=PHufOXRvAzc3TwNSPJ8F/anPkcE7vt3+YX3MBB0VWf4B9lZ5qlOBl+3d dN+1zzgDtebhBXHXVKxHurpSWHfSSntgMo0O1RN8WO/3T82DSLvMgEuyf NwIPBOKEObNJ4WaXMgoGL0ZMMoOOSzFbJ0gCzQtJHetpfjRoLw5w7qpdA 8=;
X-IronPort-AV: E=Sophos;i="4.73,486,1325415600"; d="scan'208";a="105529760"
X-Ironport-HAT: None - $RELAY-AUTH
X-Ironport-Source: 82.194.219.180 - Outgoing - Outgoing-SSL
Received: from reverse-82-194-219-180.loqal.no (HELO [82.194.219.180]) ([82.194.219.180]) by mx2-int.auckland.ac.nz with ESMTP; 27 Feb 2012 08:15:30 +1300
Message-ID: <4F4A84C6.7010101@auckland.ac.nz>
Date: Sun, 26 Feb 2012 11:15:18 -0800
From: Nevil Brownlee 
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.27) Gecko/20120216 Thunderbird/3.1.19
MIME-Version: 1.0
To: ipfix@ietf.org
References: <4C80CBE8.2080708@cisco.com>	<4C83F0E6.8050106@net.in.tum.de>	<88A72F0E-DCD8-44B9-A7C2-FE29BF684B93@tik.ee.ethz.ch>	<4C86AAFF.9050008@cisco.com> <4CC6CAE4.8090605@cisco.com>		<4F475680.9060501@cisco.com>	<1450F2CB-ECB5-4597-9CB7-A01FA8071A7B@tik.ee.ethz.ch>	<4F476528.3010201@cisco.com>	 
In-Reply-To: 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [IPFIX] 'not only IP Flows'
X-BeenThere: ipfix@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IPFIX WG discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 26 Feb 2012 19:15:36 -0000

Hi all:

At this stage IPFIX is out there and being used - it's certainly too late
to change the name (even to EIEIO!).

However, I like Paul's answer to the 'why have IP in the name?' question -
it really is a protocol for exporting information *over* IP, using SCTP,
TCP or UDP for transport.

Maybe that notion needs to get into our *bis* drafts ?

Cheers, Nevil


On 02/24/2012 01:24 PM, Brian Trammell wrote:
>
> On Feb 24, 2012, at 9:33 PM, Christopher White wrote:
>
>> Hi Paul and Brian,
>>
>>> From: Paul Aitken [mailto:paitken@cisco.com]
>>>> Honestly, I think the larger problem we have on this point is with the
>>>> name of the protocol: with the IP right up front in the first two
>>>> letters, it'll be hard to sell as a layer 2 measurement protocol. :)
>>>
>>> The existing IANA elements show that it can measure metrics at any layer.
>>> Even "flow" isn't so relevant these days.
>>>
>>> So IPFIX isn't export _of_ IP, it's export _over_ IP.
>>
>> [Christopher White]
>>
>> Yes, I'm actually even thinking a bit more broadly as well, such as export of other statistics:
>>
>> * Per Interface utilization
>> * Server stats (cpu/memory per process)
>> * Queuing stats (queue len, loss)
>>
>> As such it may not even be IP or flow related, it's just a nice well defined mechanism for the regular export of statistics.  I certainly understand this takes the scope of IPFIX way beyond where it is now, but I find it particularly intriguing, because once a product has support for export IP/flow based statistics via netflow, there's a lot of infrastructure already in place that one would like to reuse for exporting other non-IP/flow stats.
>
> I wouldn't call this "way beyond" where IPFIX is now. Have a look at draft-ietf-ipfix-ie-doctors, which specifies (in section 8) how to "design" new applications for IPFIX which are not strictly-speaking Flow based.
>
> All of the examples above pretty much apply to the "notional Flow" approach outlined there.
>
>> It's all pretty much doable using the existing IPFIX language, if you simply allow for other records with different key fields.  For flows, the key fields are based generally on the 5-tuple, and thus all flows are pretty much expected to have those or some subset.  If you monitor some other class such as server stats, you simply need to define new fields and be able to flag which fields are the key fields (process / thread, for example).
>>
>> It seems this would merely require some common field across all flows to indicate what class of item this is.    This might be indirectly discovered based on the fields in the flow (presence of IP src/dst indicates an IP flow, presence of process/thread is server stats), but such indirect logic is always problematic.
>
> If you've designed your templates correctly (i.e., such that each template or group of templates really does represent a separate data type), the type of a record can be very easily deduced at the collector side based on the presence of a set of Information Elements (and perhaps the absence of a different set of Information Elements) in the template, allowing you to keep a SetID/type map. See draft-trammell-ipfix-sip-msg for an _explicit_ example of how to do this. I'd recommend against defining a "type" information element, as you can run into some pretty silly inconsistencies.
>
> (6313 as published breaks the ability to determine type from the template in the general case; see my slides on this in Taipei for more, so for applications where data typing is important, either don't use 6313 or come help us design a fix :) )
>
> Cheers,
>
> Brian
>
> _______________________________________________
> IPFIX mailing list
> IPFIX@ietf.org
> https://www.ietf.org/mailman/listinfo/ipfix


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


From trammell@tik.ee.ethz.ch  Sun Feb 26 22:52:33 2012
Return-Path: 
X-Original-To: ipfix@ietfa.amsl.com
Delivered-To: ipfix@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EEAE721F8527 for ; Sun, 26 Feb 2012 22:52:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.641
X-Spam-Level: 
X-Spam-Status: No, score=-7.641 tagged_above=-999 required=5 tests=[AWL=0.958,  BAYES_00=-2.599, GB_I_LETTER=-2, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8GtZVw8cAeM7 for ; Sun, 26 Feb 2012 22:52:33 -0800 (PST)
Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) by ietfa.amsl.com (Postfix) with ESMTP id E4A3B21F8526 for ; Sun, 26 Feb 2012 22:52:32 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id E2E46D9494; Mon, 27 Feb 2012 07:52:28 +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 mnO2U2PVthBR; Mon, 27 Feb 2012 07:52:28 +0100 (MET)
Received: from [10.0.1.2] (cust-integra-121-161.antanet.ch [80.75.121.161]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: briant) by smtp.ee.ethz.ch (Postfix) with ESMTPSA id 9949AD93A2; Mon, 27 Feb 2012 07:52:28 +0100 (MET)
Mime-Version: 1.0 (Apple Message framework v1257)
Content-Type: text/plain; charset=us-ascii
From: Brian Trammell 
In-Reply-To: <4F4A84C6.7010101@auckland.ac.nz>
Date: Mon, 27 Feb 2012 07:52:25 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <8AFF72DA-D3EF-4C9C-A453-79BB4099B21F@tik.ee.ethz.ch>
References: <4C80CBE8.2080708@cisco.com>	<4C83F0E6.8050106@net.in.tum.de>	<88A72F0E-DCD8-44B9-A7C2-FE29BF684B93@tik.ee.ethz.ch>	<4C86AAFF.9050008@cisco.com> <4CC6CAE4.8090605@cisco.com>		<4F475680.9060501@cisco.com>	<1450F2CB-ECB5-4597-9CB7-A01FA8071A7B@tik.ee.ethz.ch>	<4F476528.3010201@cisco.com>	  <4F4A84C6.7010101@auckland.ac.nz>
To: Nevil Brownlee 
X-Mailer: Apple Mail (2.1257)
Cc: ipfix@ietf.org
Subject: Re: [IPFIX] 'not only IP Flows'
X-BeenThere: ipfix@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IPFIX WG discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 27 Feb 2012 06:52:34 -0000

Hi, Nevil, all,=20

In the current working copy of the -bis drafts, "IP" has been dropped as =
a condition of the definition of "Flow". Again, I think this is not so =
much proscriptive as merely a reflection of reality. We could consider a =
"historical note" about the name of the protocol if we want to make that =
more explicit.

Cheers,

Brian

On Feb 26, 2012, at 8:15 PM, Nevil Brownlee wrote:

>=20
> Hi all:
>=20
> At this stage IPFIX is out there and being used - it's certainly too =
late
> to change the name (even to EIEIO!).
>=20
> However, I like Paul's answer to the 'why have IP in the name?' =
question -
> it really is a protocol for exporting information *over* IP, using =
SCTP,
> TCP or UDP for transport.
>=20
> Maybe that notion needs to get into our *bis* drafts ?
>=20
> Cheers, Nevil
>=20
>=20
> On 02/24/2012 01:24 PM, Brian Trammell wrote:
>>=20
>> On Feb 24, 2012, at 9:33 PM, Christopher White wrote:
>>=20
>>> Hi Paul and Brian,
>>>=20
>>>> From: Paul Aitken [mailto:paitken@cisco.com]
>>>>> Honestly, I think the larger problem we have on this point is with =
the
>>>>> name of the protocol: with the IP right up front in the first two
>>>>> letters, it'll be hard to sell as a layer 2 measurement protocol. =
:)
>>>>=20
>>>> The existing IANA elements show that it can measure metrics at any =
layer.
>>>> Even "flow" isn't so relevant these days.
>>>>=20
>>>> So IPFIX isn't export _of_ IP, it's export _over_ IP.
>>>=20
>>> [Christopher White]
>>>=20
>>> Yes, I'm actually even thinking a bit more broadly as well, such as =
export of other statistics:
>>>=20
>>> * Per Interface utilization
>>> * Server stats (cpu/memory per process)
>>> * Queuing stats (queue len, loss)
>>>=20
>>> As such it may not even be IP or flow related, it's just a nice well =
defined mechanism for the regular export of statistics.  I certainly =
understand this takes the scope of IPFIX way beyond where it is now, but =
I find it particularly intriguing, because once a product has support =
for export IP/flow based statistics via netflow, there's a lot of =
infrastructure already in place that one would like to reuse for =
exporting other non-IP/flow stats.
>>=20
>> I wouldn't call this "way beyond" where IPFIX is now. Have a look at =
draft-ietf-ipfix-ie-doctors, which specifies (in section 8) how to =
"design" new applications for IPFIX which are not strictly-speaking Flow =
based.
>>=20
>> All of the examples above pretty much apply to the "notional Flow" =
approach outlined there.
>>=20
>>> It's all pretty much doable using the existing IPFIX language, if =
you simply allow for other records with different key fields.  For =
flows, the key fields are based generally on the 5-tuple, and thus all =
flows are pretty much expected to have those or some subset.  If you =
monitor some other class such as server stats, you simply need to define =
new fields and be able to flag which fields are the key fields (process =
/ thread, for example).
>>>=20
>>> It seems this would merely require some common field across all =
flows to indicate what class of item this is.    This might be =
indirectly discovered based on the fields in the flow (presence of IP =
src/dst indicates an IP flow, presence of process/thread is server =
stats), but such indirect logic is always problematic.
>>=20
>> If you've designed your templates correctly (i.e., such that each =
template or group of templates really does represent a separate data =
type), the type of a record can be very easily deduced at the collector =
side based on the presence of a set of Information Elements (and perhaps =
the absence of a different set of Information Elements) in the template, =
allowing you to keep a SetID/type map. See draft-trammell-ipfix-sip-msg =
for an _explicit_ example of how to do this. I'd recommend against =
defining a "type" information element, as you can run into some pretty =
silly inconsistencies.
>>=20
>> (6313 as published breaks the ability to determine type from the =
template in the general case; see my slides on this in Taipei for more, =
so for applications where data typing is important, either don't use =
6313 or come help us design a fix :) )
>>=20
>> Cheers,
>>=20
>> Brian
>>=20
>> _______________________________________________
>> IPFIX mailing list
>> IPFIX@ietf.org
>> https://www.ietf.org/mailman/listinfo/ipfix
>=20
>=20
> --=20
> ---------------------------------------------------------------------
> 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
>=20
> _______________________________________________
> IPFIX mailing list
> IPFIX@ietf.org
> https://www.ietf.org/mailman/listinfo/ipfix


From Quittek@neclab.eu  Sun Feb 26 23:55:28 2012
Return-Path: 
X-Original-To: ipfix@ietfa.amsl.com
Delivered-To: ipfix@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C88A21F853D for ; Sun, 26 Feb 2012 23:55:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.499
X-Spam-Level: 
X-Spam-Status: No, score=-103.499 tagged_above=-999 required=5 tests=[AWL=1.100, BAYES_00=-2.599, GB_I_LETTER=-2, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v1pyMJ9dMSGx for ; Sun, 26 Feb 2012 23:55:27 -0800 (PST)
Received: from mailer1.neclab.eu (mailer1.neclab.eu [195.37.70.40]) by ietfa.amsl.com (Postfix) with ESMTP id DF4A221F8527 for ; Sun, 26 Feb 2012 23:55:26 -0800 (PST)
Received: from localhost (localhost.localdomain [127.0.0.1]) by mailer1.neclab.eu (Postfix) with ESMTP id CE155280001D0; Mon, 27 Feb 2012 08:55:25 +0100 (CET)
X-Virus-Scanned: Amavisd on Debian GNU/Linux (netlab.nec.de)
Received: from mailer1.neclab.eu ([127.0.0.1]) by localhost (atlas1.office.hd [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6G60V4jw56Ch; Mon, 27 Feb 2012 08:55:25 +0100 (CET)
Received: from ENCELADUS.office.hd (ENCELADUS.office.hd [192.168.24.52]) by mailer1.neclab.eu (Postfix) with ESMTP id AF39C28000084; Mon, 27 Feb 2012 08:55:10 +0100 (CET)
Received: from DAPHNIS.office.hd ([169.254.2.41]) by ENCELADUS.office.hd ([192.168.24.52]) with mapi id 14.01.0323.003; Mon, 27 Feb 2012 08:55:10 +0100
From: Juergen Quittek 
To: Brian Trammell , Nevil Brownlee 
Thread-Topic: [IPFIX] 'not only IP Flows'
Thread-Index: AQHM9SUfoq9akBVF2UKAbGZhCAz3Kw==
Date: Mon, 27 Feb 2012 07:55:10 +0000
Message-ID: 
In-Reply-To: <8AFF72DA-D3EF-4C9C-A453-79BB4099B21F@tik.ee.ethz.ch>
Accept-Language: de-DE, en-US
Content-Language: de-DE
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.14.0.111121
x-originating-ip: [10.1.2.219]
Content-Type: text/plain; charset="us-ascii"
Content-ID: <378A7DE3A05F8C43B8EA9E966E39E22A@office.hd>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: IETF IPFIX Working Group 
Subject: Re: [IPFIX] 'not only IP Flows'
X-BeenThere: ipfix@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IPFIX WG discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 27 Feb 2012 07:55:28 -0000

Hi all,

As long as the focus is on monitoring IP flows, I see no problem with the
name if we use IPFIX also for non-IP flows.

Thanks,
    Juergen

On 27.02.12 07:52, "Brian Trammell"  wrote:

>Hi, Nevil, all,=20
>
>In the current working copy of the -bis drafts, "IP" has been dropped as
>a condition of the definition of "Flow". Again, I think this is not so
>much proscriptive as merely a reflection of reality. We could consider a
>"historical note" about the name of the protocol if we want to make that
>more explicit.
>
>Cheers,
>
>Brian
>
>On Feb 26, 2012, at 8:15 PM, Nevil Brownlee wrote:
>
>>=20
>> Hi all:
>>=20
>> At this stage IPFIX is out there and being used - it's certainly too
>>late
>> to change the name (even to EIEIO!).
>>=20
>> However, I like Paul's answer to the 'why have IP in the name?'
>>question -
>> it really is a protocol for exporting information *over* IP, using SCTP,
>> TCP or UDP for transport.
>>=20
>> Maybe that notion needs to get into our *bis* drafts ?
>>=20
>> Cheers, Nevil
>>=20
>>=20
>> On 02/24/2012 01:24 PM, Brian Trammell wrote:
>>>=20
>>> On Feb 24, 2012, at 9:33 PM, Christopher White wrote:
>>>=20
>>>> Hi Paul and Brian,
>>>>=20
>>>>> From: Paul Aitken [mailto:paitken@cisco.com]
>>>>>> Honestly, I think the larger problem we have on this point is with
>>>>>>the
>>>>>> name of the protocol: with the IP right up front in the first two
>>>>>> letters, it'll be hard to sell as a layer 2 measurement protocol. :)
>>>>>=20
>>>>> The existing IANA elements show that it can measure metrics at any
>>>>>layer.
>>>>> Even "flow" isn't so relevant these days.
>>>>>=20
>>>>> So IPFIX isn't export _of_ IP, it's export _over_ IP.
>>>>=20
>>>> [Christopher White]
>>>>=20
>>>> Yes, I'm actually even thinking a bit more broadly as well, such as
>>>>export of other statistics:
>>>>=20
>>>> * Per Interface utilization
>>>> * Server stats (cpu/memory per process)
>>>> * Queuing stats (queue len, loss)
>>>>=20
>>>> As such it may not even be IP or flow related, it's just a nice well
>>>>defined mechanism for the regular export of statistics.  I certainly
>>>>understand this takes the scope of IPFIX way beyond where it is now,
>>>>but I find it particularly intriguing, because once a product has
>>>>support for export IP/flow based statistics via netflow, there's a lot
>>>>of infrastructure already in place that one would like to reuse for
>>>>exporting other non-IP/flow stats.
>>>=20
>>> I wouldn't call this "way beyond" where IPFIX is now. Have a look at
>>>draft-ietf-ipfix-ie-doctors, which specifies (in section 8) how to
>>>"design" new applications for IPFIX which are not strictly-speaking
>>>Flow based.
>>>=20
>>> All of the examples above pretty much apply to the "notional Flow"
>>>approach outlined there.
>>>=20
>>>> It's all pretty much doable using the existing IPFIX language, if you
>>>>simply allow for other records with different key fields.  For flows,
>>>>the key fields are based generally on the 5-tuple, and thus all flows
>>>>are pretty much expected to have those or some subset.  If you monitor
>>>>some other class such as server stats, you simply need to define new
>>>>fields and be able to flag which fields are the key fields (process /
>>>>thread, for example).
>>>>=20
>>>> It seems this would merely require some common field across all flows
>>>>to indicate what class of item this is.    This might be indirectly
>>>>discovered based on the fields in the flow (presence of IP src/dst
>>>>indicates an IP flow, presence of process/thread is server stats), but
>>>>such indirect logic is always problematic.
>>>=20
>>> If you've designed your templates correctly (i.e., such that each
>>>template or group of templates really does represent a separate data
>>>type), the type of a record can be very easily deduced at the collector
>>>side based on the presence of a set of Information Elements (and
>>>perhaps the absence of a different set of Information Elements) in the
>>>template, allowing you to keep a SetID/type map. See
>>>draft-trammell-ipfix-sip-msg for an _explicit_ example of how to do
>>>this. I'd recommend against defining a "type" information element, as
>>>you can run into some pretty silly inconsistencies.
>>>=20
>>> (6313 as published breaks the ability to determine type from the
>>>template in the general case; see my slides on this in Taipei for more,
>>>so for applications where data typing is important, either don't use
>>>6313 or come help us design a fix :) )
>>>=20
>>> Cheers,
>>>=20
>>> Brian
>>>=20
>>> _______________________________________________
>>> IPFIX mailing list
>>> IPFIX@ietf.org
>>> https://www.ietf.org/mailman/listinfo/ipfix
>>=20
>>=20
>> --=20
>> ---------------------------------------------------------------------
>> 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
>>=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


From bclaise@cisco.com  Mon Feb 27 01:53:35 2012
Return-Path: 
X-Original-To: ipfix@ietfa.amsl.com
Delivered-To: ipfix@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB7A721F861C for ; Mon, 27 Feb 2012 01:53:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.476
X-Spam-Level: 
X-Spam-Status: No, score=-2.476 tagged_above=-999 required=5 tests=[AWL=0.123,  BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8fXl05iRdQ62 for ; Mon, 27 Feb 2012 01:53:33 -0800 (PST)
Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by ietfa.amsl.com (Postfix) with ESMTP id 4C87E21F863B for ; Mon, 27 Feb 2012 01:53:32 -0800 (PST)
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 q1R9rUkn002461; Mon, 27 Feb 2012 10:53:30 +0100 (CET)
Received: from [10.60.67.85] (ams-bclaise-8914.cisco.com [10.60.67.85]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id q1R9rU08001759; Mon, 27 Feb 2012 10:53:30 +0100 (CET)
Message-ID: <4F4B529A.8030004@cisco.com>
Date: Mon, 27 Feb 2012 10:53:30 +0100
From: Benoit Claise 
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:9.0) Gecko/20111222 Thunderbird/9.0.1
MIME-Version: 1.0
To: Brian Trammell 
References:  <3FC6273A-2FB1-4FE3-A3F7-DE658E1336C1@tik.ee.ethz.ch>
In-Reply-To: <3FC6273A-2FB1-4FE3-A3F7-DE658E1336C1@tik.ee.ethz.ch>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: draft-ietf-ipfix-a9n@tools.ietf.org, "ipfix@ietf.org" 
Subject: Re: [IPFIX] draft-ietf-ipfix-a9n
X-BeenThere: ipfix@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IPFIX WG discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 27 Feb 2012 09:53:35 -0000

Brian, Rahul,
> On Feb 24, 2012, at 4:07 PM, Rahul Patel wrote:
>
>>>>> Section 5.1.1 Distributing values across Interval
>>>>> -------------------------------------------------
>>>>> * should add 'synchronized expiry of Original Flows' - Under this
>>>>> method
>>>>> Flow C would be exported three times with start-time/end-time
>>>>> matching the
>>>>> aggregation interval start-time/end-time.
>>> Make sense to me.
>>>>> * There will always going to some original flows which will arrive late
>>>>> and will not be accounted. It will be good have a cumulative counter of
>>>>> such late arrivals on per template id (aggregated flow) basis. This
>>>>> cumulative count should be periodically exported along with end-time
>>>>> (time-of-snapshot). The counter will provide a degree of confidence
>>>>> in the
>>>>> data exported by the aggregator for each template.
>>> So you want something similar to "The Metering Process Statistics Option
>>> Template" from RFC5101, http://tools.ietf.org/html/rfc5101#page-23, but
>>> for the Aggregation Intermediate Aggregation Process, right?
>> [RP] exactly.
> Still not convinced this is needed given the nature of active timeouts; however, that may well be an implementation-specific (or application-specific) opinion.
>
> In that case, I agree we should add it but I'm not convinced that this is an aggregation-specific thing. If you're going to count records that were dropped at an intermediate process due to missing a time window, couldn't this affect non-aggregation intermediate processes as well? How about adding this to MEDPROTO instead?
That makes sense in the MEDPROTO  
(http://tools.ietf.org/html/draft-ietf-ipfix-mediation-protocol-00)
We would need to take as a basis the  "The Metering Process Reliability 
Statistics Options Template" from 
http://tools.ietf.org/html/draft-ietf-ipfix-protocol-rfc5101bis-00#page-26, 
which solves already one issue compared to RC5101, by inserting the 
"meteringProcessId".
See my comments in UPPER CASE.

    (scope) observationDomainId
                            An identifier of an Observation Domain that
                            is locally unique to the Exporting Process.
                            This Information Element MUST be defined as a
                            Scope Field.

    (scope) meteringProcessId  =>  NEED IAPPROCESSID
                            The identifier of the Metering Process for
                            which lack of reliability is reported. This
                            Information Element MUST be defined as a
                            Scope Field.

    ignoredPacketTotalCount  =>  NEED SOMETHING SUCH AS IGNOREDFLOW..
                            The total number of IP packets that the
                            Metering Process did not process.

    ignoredOctetTotalCount  =>  DON'T NEED THIS ONE
                            The total number of octets in observed  IP
                            packets that the Metering Process did not
                            process.

    time first packet ignored  =>  THIS RELATES TO THE FLOW, BUT THE IE MIGHT
                            BE THE SAME
                            The timestamp of the first IP packet that was
                            ignored by the Metering  Process.  For this
                            timestamp, any of the following timestamp can
                            be used: observationTimeSeconds,
                            observationTimeMilliseconds,
                            observationTimeMicroseconds, or
                            observationTimeNanoseconds.

    time last packet ignored
                            The timestamp of the last IP packet that was
                            ignored by the Metering  Process.  For this
                            timestamp, any of the following timestamp can
                            be used: observationTimeSeconds,
                            observationTimeMilliseconds,
                            observationTimeMicroseconds, or
                            observationTimeNanoseconds.


would this work?

Regards, Benoit.
>
> Best regards,
>
> Brian
>
>


From internet-drafts@ietf.org  Mon Feb 27 03:15:54 2012
Return-Path: 
X-Original-To: ipfix@ietfa.amsl.com
Delivered-To: ipfix@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D1ED921F86BB; Mon, 27 Feb 2012 03:15:54 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.426
X-Spam-Level: 
X-Spam-Status: No, score=-102.426 tagged_above=-999 required=5 tests=[AWL=0.173, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oqENnN1rg1jW; Mon, 27 Feb 2012 03:15:54 -0800 (PST)
Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6DD4021F8697; Mon, 27 Feb 2012 03:15:54 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
From: internet-drafts@ietf.org
To: i-d-announce@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 4.00
Message-ID: <20120227111554.3892.9693.idtracker@ietfa.amsl.com>
Date: Mon, 27 Feb 2012 03:15:54 -0800
Cc: ipfix@ietf.org
Subject: [IPFIX] I-D Action: draft-ietf-ipfix-a9n-02.txt
X-BeenThere: ipfix@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IPFIX WG discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 27 Feb 2012 11:15:55 -0000

A New Internet-Draft is available from the on-line Internet-Drafts director=
ies. This draft is a work item of the IP Flow Information Export Working Gr=
oup of the IETF.

	Title           : Flow Aggregation for the IP Flow Information Export (IPF=
IX) Protocol
	Author(s)       : Brian Trammell
                          Arno Wagner
                          Benoit Claise
	Filename        : draft-ietf-ipfix-a9n-02.txt
	Pages           : 47
	Date            : 2012-02-27

   This document describes the export of aggregated Flow information
   using IPFIX.  An Aggregated Flow is essentially an IPFIX Flow
   representing packets from multiple Original Flows sharing some set of
   common properties.  The document describes Aggregated Flow export
   within the framework of IPFIX Mediators and defines an interoperable,
   implementation-independent method for Aggregated Flow export.


A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ipfix-a9n-02.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

This Internet-Draft can be retrieved at:
ftp://ftp.ietf.org/internet-drafts/draft-ietf-ipfix-a9n-02.txt


From trammell@tik.ee.ethz.ch  Mon Feb 27 03:20:44 2012
Return-Path: 
X-Original-To: ipfix@ietfa.amsl.com
Delivered-To: ipfix@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0703721F86B9 for ; Mon, 27 Feb 2012 03:20:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.679
X-Spam-Level: 
X-Spam-Status: No, score=-6.679 tagged_above=-999 required=5 tests=[AWL=-0.080, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6PhwO51FDhtG for ; Mon, 27 Feb 2012 03:20:42 -0800 (PST)
Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) by ietfa.amsl.com (Postfix) with ESMTP id 0810B21F86A8 for ; Mon, 27 Feb 2012 03:20:42 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id 65890D9314 for ; Mon, 27 Feb 2012 12:20:41 +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 tJwPO9+NwsNF for ; Mon, 27 Feb 2012 12:20:41 +0100 (MET)
Received: from [10.0.1.2] (cust-integra-121-161.antanet.ch [80.75.121.161]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: briant) by smtp.ee.ethz.ch (Postfix) with ESMTPSA id 1CDF0D930D for ; Mon, 27 Feb 2012 12:20:41 +0100 (MET)
From: Brian Trammell 
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Date: Mon, 27 Feb 2012 12:20:39 +0100
References: <20120227111554.3892.89281.idtracker@ietfa.amsl.com>
To: ipfix@ietf.org
Message-Id: <9E599B7D-38B1-4778-B978-0AB8F43C7F03@tik.ee.ethz.ch>
Mime-Version: 1.0 (Apple Message framework v1257)
X-Mailer: Apple Mail (2.1257)
Subject: [IPFIX] Fwd: New Version Notification for draft-ietf-ipfix-a9n-02.txt
X-BeenThere: ipfix@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IPFIX WG discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 27 Feb 2012 11:20:44 -0000

Greetings, all,

The -02 revision of the aggregation draft is the result of discussion =
among the authors to address certain comments from Rahul Patel (thanks, =
Rahul!) on the nature of the interaction of correlation and aggregation =
in the specific case that aggregation is applied to multiple views of =
the same "essential Flows". It introduces a new correlation and =
normalization operation, in order to not rely on an (as yet unspecified) =
Intermediate Correlation Process. It also adds a new section 6.2 =
addressing potential delay and loss caused by an IAP.

Though the WGLC ended on February 20, the relative of commentary to date =
means that this is _not_ the revision intended by the authors to be =
submitted to the IESG following WGLC; please review and comment on this =
draft!!

Many thanks, best regards,

Brian

Begin forwarded message:

> From: internet-drafts@ietf.org
> Subject: New Version Notification for draft-ietf-ipfix-a9n-02.txt
> Date: February 27, 2012 12:15:54 PM GMT+01:00
> To: trammell@tik.ee.ethz.ch
> Cc: bclaise@cisco.com, arno@wagner.name
>=20
> A new version of I-D, draft-ietf-ipfix-a9n-02.txt has been =
successfully submitted by Brian Trammell and posted to the IETF =
repository.
>=20
> Filename:	 draft-ietf-ipfix-a9n
> Revision:	 02
> Title:		 Flow Aggregation for the IP Flow Information =
Export (IPFIX) Protocol
> Creation date:	 2012-02-27
> WG ID:		 ipfix
> Number of pages: 47
>=20
> Abstract:
>   This document describes the export of aggregated Flow information
>   using IPFIX.  An Aggregated Flow is essentially an IPFIX Flow
>   representing packets from multiple Original Flows sharing some set =
of
>   common properties.  The document describes Aggregated Flow export
>   within the framework of IPFIX Mediators and defines an =
interoperable,
>   implementation-independent method for Aggregated Flow export.
>=20
>=20
>=20
>=20
> The IETF Secretariat


From internet-drafts@ietf.org  Mon Feb 27 04:13:43 2012
Return-Path: 
X-Original-To: ipfix@ietfa.amsl.com
Delivered-To: ipfix@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4818A21F86C5; Mon, 27 Feb 2012 04:13:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.438
X-Spam-Level: 
X-Spam-Status: No, score=-102.438 tagged_above=-999 required=5 tests=[AWL=0.161, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ApwjPaKDpTBx; Mon, 27 Feb 2012 04:13:42 -0800 (PST)
Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D4B4A21F86BA; Mon, 27 Feb 2012 04:13:42 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
From: internet-drafts@ietf.org
To: i-d-announce@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 4.00
Message-ID: <20120227121342.19513.99539.idtracker@ietfa.amsl.com>
Date: Mon, 27 Feb 2012 04:13:42 -0800
Cc: ipfix@ietf.org
Subject: [IPFIX] I-D Action: draft-ietf-ipfix-a9n-03.txt
X-BeenThere: ipfix@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IPFIX WG discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 27 Feb 2012 12:13:43 -0000

A New Internet-Draft is available from the on-line Internet-Drafts director=
ies. This draft is a work item of the IP Flow Information Export Working Gr=
oup of the IETF.

	Title           : Flow Aggregation for the IP Flow Information Export (IPF=
IX) Protocol
	Author(s)       : Brian Trammell
                          Arno Wagner
                          Benoit Claise
	Filename        : draft-ietf-ipfix-a9n-03.txt
	Pages           : 47
	Date            : 2012-02-27

   This document describes the export of aggregated Flow information
   using IPFIX.  An Aggregated Flow is essentially an IPFIX Flow
   representing packets from multiple Original Flows sharing some set of
   common properties.  The document describes Aggregated Flow export
   within the framework of IPFIX Mediators and defines an interoperable,
   implementation-independent method for Aggregated Flow export.


A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ipfix-a9n-03.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

This Internet-Draft can be retrieved at:
ftp://ftp.ietf.org/internet-drafts/draft-ietf-ipfix-a9n-03.txt


From trammell@tik.ee.ethz.ch  Mon Feb 27 04:16:18 2012
Return-Path: 
X-Original-To: ipfix@ietfa.amsl.com
Delivered-To: ipfix@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA03F21F86D6 for ; Mon, 27 Feb 2012 04:16:18 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.676
X-Spam-Level: 
X-Spam-Status: No, score=-6.676 tagged_above=-999 required=5 tests=[AWL=-0.077, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8i7LVzb-hQez for ; Mon, 27 Feb 2012 04:16:18 -0800 (PST)
Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) by ietfa.amsl.com (Postfix) with ESMTP id 4F7AD21F86C9 for ; Mon, 27 Feb 2012 04:16:18 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id 48C4FD930D for ; Mon, 27 Feb 2012 13:16:17 +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 87DOrulwikAX for ; Mon, 27 Feb 2012 13:16:17 +0100 (MET)
Received: from [10.0.1.2] (cust-integra-121-161.antanet.ch [80.75.121.161]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: briant) by smtp.ee.ethz.ch (Postfix) with ESMTPSA id D7DD3D9307 for ; Mon, 27 Feb 2012 13:16:16 +0100 (MET)
From: Brian Trammell 
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Date: Mon, 27 Feb 2012 13:16:15 +0100
References: <20120227121342.19513.63757.idtracker@ietfa.amsl.com>
To: ipfix@ietf.org
Message-Id: <7D50F551-EDFD-4E5C-84A0-8C1285572DB3@tik.ee.ethz.ch>
Mime-Version: 1.0 (Apple Message framework v1257)
X-Mailer: Apple Mail (2.1257)
Subject: [IPFIX] Fwd: New Version Notification for draft-ietf-ipfix-a9n-03.txt
X-BeenThere: ipfix@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IPFIX WG discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 27 Feb 2012 12:16:19 -0000

Greetings, all,

Another new aggregation revision; this adds section 5.1.3 on direct =
external interval aggregation in response to Rahul Patel's (missed in =
the -02 revision) comment.=20

Please review -03 instead. :)

Nevil, Juergen,

Process question: given the ongoing work here to address comments, would =
it make sense to extend the WGLC period on -a9n?

Thanks,

Brian

Begin forwarded message:

> From: internet-drafts@ietf.org
> Subject: New Version Notification for draft-ietf-ipfix-a9n-03.txt
> Date: February 27, 2012 1:13:42 PM GMT+01:00
> To: trammell@tik.ee.ethz.ch
> Cc: bclaise@cisco.com, arno@wagner.name
>=20
> A new version of I-D, draft-ietf-ipfix-a9n-03.txt has been =
successfully submitted by Brian Trammell and posted to the IETF =
repository.
>=20
> Filename:	 draft-ietf-ipfix-a9n
> Revision:	 03
> Title:		 Flow Aggregation for the IP Flow Information =
Export (IPFIX) Protocol
> Creation date:	 2012-02-27
> WG ID:		 ipfix
> Number of pages: 47
>=20
> Abstract:
>   This document describes the export of aggregated Flow information
>   using IPFIX.  An Aggregated Flow is essentially an IPFIX Flow
>   representing packets from multiple Original Flows sharing some set =
of
>   common properties.  The document describes Aggregated Flow export
>   within the framework of IPFIX Mediators and defines an =
interoperable,
>   implementation-independent method for Aggregated Flow export.
>=20
>=20
>=20
>=20
> The IETF Secretariat


From rahulp@cisco.com  Mon Feb 27 07:16:29 2012
Return-Path: 
X-Original-To: ipfix@ietfa.amsl.com
Delivered-To: ipfix@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 344AC21F879C; Mon, 27 Feb 2012 07:16:29 -0800 (PST)
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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mnl3E++wUaX4; Mon, 27 Feb 2012 07:16:28 -0800 (PST)
Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id 0AFCA21F87A3; Mon, 27 Feb 2012 07:16:27 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=rahulp@cisco.com; l=1510; q=dns/txt; s=iport; t=1330355788; x=1331565388; h=date:subject:from:to:cc:message-id:in-reply-to: mime-version:content-transfer-encoding; bh=0uze+r6AEnlROs8Ts1hEBeG1kk0WXfXyACM9QZ9sWhY=; b=U6FB9yig1rViGi+0tKLNjrgo6v9nSNKHO7ry1BDxHuCh86Je8sc+rNY9 9YpnRgQXb/07NRsQOtNo5xN1B1RhzbnG58LMM8LkDJD5IxnX7tQ2btr8p QMeu6gHqaJLyRA3v/JFInzLwqxhl27n96zhoLaoF8mfEryu4zmGYCX0lL w=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Av4EAN6dS0+tJXG9/2dsb2JhbABCsyaBB4F1AQQBAQEPAScCATELEwhtMAYBDQUJGYdkC5kHAZ5ijHg0AgI5DgEJAQYDAoUKOQENBwQGGoMsBIhPjG6FXY0v
X-IronPort-AV: E=Sophos;i="4.73,491,1325462400"; d="scan'208";a="62082806"
Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-4.cisco.com with ESMTP; 27 Feb 2012 15:16:27 +0000
Received: from [161.44.113.215] (dhcp-161-44-113-215.cisco.com [161.44.113.215]) by rcdn-core2-2.cisco.com (8.14.3/8.14.3) with ESMTP id q1RFGIcZ014658;  Mon, 27 Feb 2012 15:16:27 GMT
User-Agent: Microsoft-MacOutlook/14.14.0.111121
Date: Mon, 27 Feb 2012 10:16:18 -0500
From: Rahul Patel 
To: , 
Message-ID: 
Thread-Topic: [IPFIX] I-D Action: draft-ietf-ipfix-a9n-02.txt
In-Reply-To: <20120227111554.3892.9693.idtracker@ietfa.amsl.com>
Mime-version: 1.0
Content-type: text/plain; charset="US-ASCII"
Content-transfer-encoding: 7bit
Cc: ipfix@ietf.org
Subject: Re: [IPFIX] I-D Action: draft-ietf-ipfix-a9n-02.txt
X-BeenThere: ipfix@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IPFIX WG discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 27 Feb 2012 15:16:29 -0000

Hi Brian/Benoit,

Looks good.

-Rahul


On 2/27/12 6:15 AM, "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           : Flow Aggregation for the IP Flow Information Export
>(IPFIX) Protocol
>	Author(s)       : Brian Trammell
>                          Arno Wagner
>                          Benoit Claise
>	Filename        : draft-ietf-ipfix-a9n-02.txt
>	Pages           : 47
>	Date            : 2012-02-27
>
>   This document describes the export of aggregated Flow information
>   using IPFIX.  An Aggregated Flow is essentially an IPFIX Flow
>   representing packets from multiple Original Flows sharing some set of
>   common properties.  The document describes Aggregated Flow export
>   within the framework of IPFIX Mediators and defines an interoperable,
>   implementation-independent method for Aggregated Flow export.
>
>
>A URL for this Internet-Draft is:
>http://www.ietf.org/internet-drafts/draft-ietf-ipfix-a9n-02.txt
>
>Internet-Drafts are also available by anonymous FTP at:
>ftp://ftp.ietf.org/internet-drafts/
>
>This Internet-Draft can be retrieved at:
>ftp://ftp.ietf.org/internet-drafts/draft-ietf-ipfix-a9n-02.txt
>
>_______________________________________________
>IPFIX mailing list
>IPFIX@ietf.org
>https://www.ietf.org/mailman/listinfo/ipfix



From carter@qosient.com  Mon Feb 27 11:37:25 2012
Return-Path: 
X-Original-To: ipfix@ietfa.amsl.com
Delivered-To: ipfix@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 94B2621F87DB for ; Mon, 27 Feb 2012 11:37:25 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.398
X-Spam-Level: 
X-Spam-Status: No, score=0.398 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kQo-GEDsx77K for ; Mon, 27 Feb 2012 11:37:24 -0800 (PST)
Received: from mail1.g1.pair.com (mail1.g1.pair.com [66.39.3.162]) by ietfa.amsl.com (Postfix) with ESMTP id 4D95B21F87B9 for ; Mon, 27 Feb 2012 11:37:24 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by mail1.g1.pair.com (Postfix) with SMTP id 30D3B284AA; Mon, 27 Feb 2012 14:37:20 -0500 (EST)
Received: from thoth.newyork.qosient.com (207-237-36-98.c3-0.avec-ubr1.nyr-avec.ny.static.cable.rcn.com [207.237.36.98]) by mail1.g1.pair.com (Postfix) with ESMTPSA id 704AC28499; Mon, 27 Feb 2012 14:37:19 -0500 (EST)
From: Carter Bullard 
Content-Type: multipart/signed; boundary="Apple-Mail=_B0DE8D2F-330A-4D0D-80CC-6463E7985D85"; protocol="application/pkcs7-signature"; micalg=sha1
Date: Mon, 27 Feb 2012 14:37:18 -0500
Message-Id: <91C99130-A66C-4E6A-AE93-BA005CE6C792@qosient.com>
To: Argus , ipfix@ietf.org
Mime-Version: 1.0 (Apple Message framework v1257)
X-Mailer: Apple Mail (2.1257)
Subject: [IPFIX] recent ipfix drafts and argus
X-BeenThere: ipfix@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IPFIX WG discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 27 Feb 2012 19:37:25 -0000

--Apple-Mail=_B0DE8D2F-330A-4D0D-80CC-6463E7985D85
Content-Type: multipart/alternative;
	boundary="Apple-Mail=_349FD8EF-CA5E-4231-A9B4-2113FAFC045F"


--Apple-Mail=_349FD8EF-CA5E-4231-A9B4-2113FAFC045F
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=windows-1252

Gentle people,
I'm generally pretty quiet when it comes to IPFIX and its efforts.  But =
as the first
person to develop IP flow records in the 1980's, first to present the =
idea to the
community in 1992, the first to provide open source flow technology in =
1995,
and the author of the longest lived open source flow system, argus; I =
feel that
I have to say something about the recent wave of IPFIX drafts.

The drafts on flow aggregation describe functionality that the Argus =
project started=20
over 20 years ago.  The ideas of key modification, conversion of non-key =
attributes
to key members, aggregation operators, interval distribution and the =
architecture for it,
were all developed in argus a long long time ago.  draft-ietf-ipfix-a9n =
is basically
describing the functionality of argus's racluster(), rasplit(), and =
rabins() programs,
and every example given in the text of draft-ietf-ipfix-a9n can be =
generated using
argus's rabins(), with only a few gyrations of its command-line, today.

I personally would expect that if the IETF was going to describe =
something that is
"Standards Track", that there would be dozen's of implementations of =
this kind of
technology available, and that the WG is condensing years of experience =
to
arrive at a "Standards Track", but, this is not the case.  There is only =
one current
implementation of the complete capabilities of the features of =
draft-ietf-ipfix-a9n
that I am aware of, and that is in argus.

Taking just one of the technical descriptions in the draft, "interval =
distribution", I
am not aware of any description of this issue, or implementation of this =
type
of technology in the literature, outside of argus.  No Google search =
results for "flow
interval distribution".   In Argus we call it flow splitting.  The first =
line from a
Google search for "argus flow splitting" return:

Scholarly articles for argus flow splitting
=85 and prediction of flow statistics from sampled packet =85 - Duffield =
- Cited by 217

I'm not saying that Nick knows much about argus's support for flow =
splitting, but
its still pretty scary that the first hit is from a paper that is used =
in IPFIX documents.
One would have to assume that the IPFIX community should be aware.

My problem is that most of  draft-ietf-ipfix-a9n is prior work that is =
not widely
implemented, some of the features are still unique to argus.   While =
IETF support
of technology is a good thing, descriptions of technology without =
reference
is a difficult thing to interpret.  Is the IPFIX WG describing what they =
think is new
technology? Does the IPFIX WG think that many companies have implemented
this type of technology, and now its time to standardize it ?  Well, I'm =
not aware
of any implementation, open or closed, that does the complete set of =
what the
draft is recommending, other than argus.  So I don't think its new, nor =
widely
implemented.  I would say its a form of technology plagiarism.

IPFIX is considering adding non-IP flows to their definitions.  Argus is =
the only available
flow technology that has significant non-IP flow data models and =
support.  argus-1.2 had
flow generation, transport, analytics and storage of non-IP flows 20 =
years ago, with its
support for bi-directional ethernet, apple-talk and ARP transaction =
tracking and reporting.
In the last 10 years, argus has added MPLS, VLAN, ISO addresses, and =
Infiniband flow
models.  Not attributes, but true flow key elements.   This work is =
non-trivial.

The concept that the WG would consider dropping the IP from IPFIX and =
think that is
all that is needed, is really so completely wrong, that its laughable, =
and a dis-service
to those that have done the hard work to bring situational awareness and =
analytics
to non-IP traffic.   The same applies to bi-directional flows, but that =
is another story.

I would love to think that IPFIX could focus back on flow information =
exchange.
Multicast, non-template based connectionless transport strategies, say =
over UDT
as an example, rather than getting into areas for which the WG is =
unprepared to
do even a reasonable job, without resorting to dubious techniques.

Just a few comments, I hope that anyone finds it useful.

Carter

Carter Bullard
CEO/President
QoSient, LLC
150 E. 57th Street Suite 12D
New York, New York 10022

+1 212 588-9133 Phone
+1 212 588-9134 Fax




--Apple-Mail=_349FD8EF-CA5E-4231-A9B4-2113FAFC045F
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=windows-1252


technology available, and that =
the WG is condensing years of experience to
arrive at a =
"Standards Track", but, this is not the case.  There is only =
one current
implementation of the complete capabilities =
of the features of draft-ietf-ipfix-a9n
that I am aware =
of, and that is in argus.

Taking just =
one of the technical descriptions in the draft, "interval =
distribution", I
am not aware of any description of =
this issue, or implementation of this type
of technology =
in the literature, outside of argus.  No Google search results =
for "flow
interval distribution".   In Argus we call it =
flow splitting.  The first line from a
Google search =
for "argus flow splitting" return:

Scholarly articles for argus flow =
splitting
=85 and prediction =
of flow statistics from sampled packet =85 - 
Carter Bullard
CEO/President
QoSient, =
LLC
150 E. 57th Street Suite =
12D
New York, New York =
10022

+1 212 588-9133 Phone
+1 212 588-9134 =
Fax






=

--Apple-Mail=_349FD8EF-CA5E-4231-A9B4-2113FAFC045F--

--Apple-Mail=_B0DE8D2F-330A-4D0D-80CC-6463E7985D85
Content-Disposition: attachment;
	filename=smime.p7s
Content-Type: application/pkcs7-signature;
	name=smime.p7s
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMRjCCBVAw
ggQ4oAMCAQICEE/C1XPaEv5Xc80XjVqbwwowDQYJKoZIhvcNAQEFBQAwgd0xCzAJBgNVBAYTAlVT
MRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y
azE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEg
KGMpMDkxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuVmVyaVNpZ24g
Q2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMzAeFw0xMTA0MTQwMDAwMDBaFw0x
MjA0MTMyMzU5NTlaMIIBEzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT
aWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9S
UEEgSW5jb3JwLiBieSBSZWYuLExJQUIuTFREKGMpOTgxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZh
bGlkYXRlZDEzMDEGA1UECxMqRGlnaXRhbCBJRCBDbGFzcyAxIC0gTmV0c2NhcGUgRnVsbCBTZXJ2
aWNlMRcwFQYDVQQDFA5DYXJ0ZXIgQnVsbGFyZDEhMB8GCSqGSIb3DQEJARYSY2FydGVyQHFvc2ll
bnQuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAnUsVMagrR+kSPj9tNNsMP6ZO
CRf4x70f3vT5OerV6rikEAz4XYJ+iv5Y6FiY5wjr2ez4BTrEuKwhAJN+aPSXHBW4cBZgB0J7mHwF
yJpY/vhhy2RrfugdCXjotFySXzevQHCfON4htlh+I3DYhN6LXmeBnnPtGz+J4mNZqdimZVlcdXqV
h0m7ysvdFkClht66vEvF+WObwLEpg3LIaFzTZBWpAiQ1FPIDJJd6uU//96grDvRy+D0oNjCkxmBp
bCkG0w1jaOuay6o62xRh7H41CxCRljzYjy3H4SwRYlYBwtqZuXg0YOI0OHdSuie6UyrUgmT+3S1U
FPiGz9yP9hninQIDAQABo4HSMIHPMAkGA1UdEwQCMAAwRAYDVR0gBD0wOzA5BgtghkgBhvhFAQcX
ATAqMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhMAsGA1UdDwQEAwIF
oDAdBgNVHSUEFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIwUAYDVR0fBEkwRzBFoEOgQYY/aHR0cDov
L2luZGMxZGlnaXRhbGlkLWczLWNybC52ZXJpc2lnbi5jb20vSW5kQzFEaWdpdGFsSUQtRzMuY3Js
MA0GCSqGSIb3DQEBBQUAA4IBAQBSg1+LGDk7EKu1hYCrpHEZVHY3I+850erL2DxLtfgzldWZPLYr
NpVa8wH5XTDhaFNLQgWwLMGfs8sJPkqXm2TfZfG7BkJWLtubW3Jw5jZ//Eygbae2IOU0bm1tAaG2
uoreBROJ5PU1ykK8aTnbNZxN772otsdHQ54gXd2wpPUoDoT740WzsdTeSI0ZXU+3J7RPbC0VHNfI
E88GgkTYBD5Xk3Ro+BSCBOh4XAA1ypHBZh2OX8C4syhPp6yfGWvwvqJ+oV5lkbAcO6FkeBlvb/Fi
XPa35ynGIIpntzpqOvr+0XJs8xq7hE8KU/QUNE6fa0gZyjxBVcbw89mv4lQx4FSOMIIG7jCCBdag
AwIBAgIQcRVmBUrkkSFN6bxE+azT3DANBgkqhkiG9w0BAQUFADCByjELMAkGA1UEBhMCVVMxFzAV
BgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTow
OAYDVQQLEzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVkIHVzZSBvbmx5
MUUwQwYDVQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRpZmljYXRpb24g
QXV0aG9yaXR5IC0gRzMwHhcNMDkwNTAxMDAwMDAwWhcNMTkwNDMwMjM1OTU5WjCB3TELMAkGA1UE
BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBO
ZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29t
L3JwYSAoYykwOTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJp
U2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEczMIIBIjANBgkqhkiG9w0B
AQEFAAOCAQ8AMIIBCgKCAQEA7cRH3yooHXwGa7vXITLJbBOP6bGNQU4099oL42r6ZYggCxET6Zvg
SU6Lb9UB0F8NR5GKWkx0Pj/GkQm7TDSejW6hglFi92l2WJYHr54UGAdPWr2f0jGyVBlzRmoZQhHs
EnMhjfXcMM3l2VYKMcU2bSkUl70t2olHGYjYSwQ967Y8Zx50ABMN0Ibak2f4MwOuGjxraXj2wCyO
4YM/d/mZ//6fUlrCtIcK2GypR8FUKWVDPkrAlh/Brfd3r2yxBF6+wbaULZeQLSfSux7pg2qE9sSy
riMGZSalJ1grByK0b6ZiSBp38tVQJ5op05b7KPW6JHZi44xZ6/tu1ULEvkHH9QIDAQABo4ICuTCC
ArUwNAYIKwYBBQUHAQEEKDAmMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC52ZXJpc2lnbi5jb20w
EgYDVR0TAQH/BAgwBgEB/wIBADBwBgNVHSAEaTBnMGUGC2CGSAGG+EUBBxcBMFYwKAYIKwYBBQUH
AgEWHGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9jcHMwKgYIKwYBBQUHAgIwHhocaHR0cHM6Ly93
d3cudmVyaXNpZ24uY29tL3JwYTA0BgNVHR8ELTArMCmgJ6AlhiNodHRwOi8vY3JsLnZlcmlzaWdu
LmNvbS9wY2ExLWczLmNybDAOBgNVHQ8BAf8EBAMCAQYwbgYIKwYBBQUHAQwEYjBgoV6gXDBaMFgw
VhYJaW1hZ2UvZ2lmMCEwHzAHBgUrDgMCGgQUS2u5KJYGDLvQUjibKaxLB4shBRgwJhYkaHR0cDov
L2xvZ28udmVyaXNpZ24uY29tL3ZzbG9nbzEuZ2lmMC4GA1UdEQQnMCWkIzAhMR8wHQYDVQQDExZQ
cml2YXRlTGFiZWw0LTIwNDgtMTE4MB0GA1UdDgQWBBR5R2EIQf04BKJL57XM9UP2SSsR+DCB8QYD
VR0jBIHpMIHmoYHQpIHNMIHKMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4x
HzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOjA4BgNVBAsTMShjKSAxOTk5IFZlcmlT
aWduLCBJbmMuIC0gRm9yIGF1dGhvcml6ZWQgdXNlIG9ubHkxRTBDBgNVBAMTPFZlcmlTaWduIENs
YXNzIDEgUHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgLSBHM4IRAItbdVaE
VIULAM+vOEjOsaQwDQYJKoZIhvcNAQEFBQADggEBADlNz0GZgbWpBbVSOOk5hIls5DSoWufYbAlM
JBq6WaSHO3Mh8ZOBz79oY1pn/jWFK6HDXaNKwjoZ3TDWzE3v8dKBl8pUWkO/N4t6jhmND0OojPKv
YLMVirOVnDzgnrMnmKQ1chfl/Cpdh9OKDcLRRSr4wPSsKpM61a4ScAjr+zvid+zoK2Q1ds262uDR
yxTWcVibvtU+fbbZ6CTFJGZMXZEfdrMXPn8NxiGJL7M3uKH/XLJtSd5lUkL7DojS7Uodv0vj+Mxy
+kgOZY5JyNb4mZg7t5Q+MXEGh/psWVMu198r7V9jAKwV7QO4VRaMxmgD5yKocwuxvKDaUljdCg5/
wYIxggSLMIIEhwIBATCB8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMu
MR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2Ug
YXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwOTEeMBwGA1UECxMVUGVyc29uYSBO
b3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2Ny
aWJlciBDQSAtIEczAhBPwtVz2hL+V3PNF41am8MKMAkGBSsOAwIaBQCgggJtMBgGCSqGSIb3DQEJ
AzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEyMDIyNzE5MzcxOVowIwYJKoZIhvcNAQkE
MRYEFPkCHdbYbiw4kH2oVX5R3QgcoJnKMIIBAwYJKwYBBAGCNxAEMYH1MIHyMIHdMQswCQYDVQQG
EwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5l
dHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20v
cnBhIChjKTA5MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMTLlZlcmlT
aWduIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzMCEE/C1XPaEv5Xc80XjVqb
wwowggEFBgsqhkiG9w0BCRACCzGB9aCB8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlT
aWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJt
cyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwOTEeMBwGA1UECxMV
UGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1
YWwgU3Vic2NyaWJlciBDQSAtIEczAhBPwtVz2hL+V3PNF41am8MKMA0GCSqGSIb3DQEBAQUABIIB
AJFLk3R96EFxIJLAIcAImXcF++BSUaDAO/NIDMKPzhtaUolB6krV8rSFLcpW7ZWyiq6CW42Q/UDk
bOP2rbG+lIxiy9eucKXU0MOBPjK+rpSzRG9E/Kn8h5DoUadpXTL5gJwUHz5sdalApY5wSu1jZp6e
wAohNkC0F8cpYPH4kxBDocyyythph+zp5syARDkuC0NlechCQncIAIO/QVS6v/Gbu2efwpqDrpQn
a6pLKP9nOQIYVn/eDCdR2uhe1xWJzzJhevPO0zvpHaJ8dfHnyfG8VDSCYTA7avJ6eqVyCw9oDR4c
qss6zsmbW85VcGNz+8GUCIqS6x6MPbTMod5wYX4AAAAAAAA=

--Apple-Mail=_B0DE8D2F-330A-4D0D-80CC-6463E7985D85--

From bclaise@cisco.com  Mon Feb 27 14:53:06 2012
Return-Path: 
X-Original-To: ipfix@ietfa.amsl.com
Delivered-To: ipfix@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE10721E8014 for ; Mon, 27 Feb 2012 14:53:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.486
X-Spam-Level: 
X-Spam-Status: No, score=-2.486 tagged_above=-999 required=5 tests=[AWL=0.112,  BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zYDFKfcIm7zs for ; Mon, 27 Feb 2012 14:53:04 -0800 (PST)
Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by ietfa.amsl.com (Postfix) with ESMTP id D137921F8684 for ; Mon, 27 Feb 2012 14:53:03 -0800 (PST)
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 q1RMr0jA001864; Mon, 27 Feb 2012 23:53:00 +0100 (CET)
Received: from [10.60.67.84] (ams-bclaise-8913.cisco.com [10.60.67.84]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id q1RMqurT002062; Mon, 27 Feb 2012 23:52:57 +0100 (CET)
Message-ID: <4F4C0948.5090709@cisco.com>
Date: Mon, 27 Feb 2012 23:52:56 +0100
From: Benoit Claise 
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:9.0) Gecko/20111222 Thunderbird/9.0.1
MIME-Version: 1.0
To: Carter Bullard 
References: <91C99130-A66C-4E6A-AE93-BA005CE6C792@qosient.com>
In-Reply-To: <91C99130-A66C-4E6A-AE93-BA005CE6C792@qosient.com>
Content-Type: multipart/alternative; boundary="------------020802010509070202020402"
Cc: Argus , ipfix@ietf.org
Subject: Re: [IPFIX] recent ipfix drafts and argus
X-BeenThere: ipfix@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IPFIX WG discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 27 Feb 2012 22:53:07 -0000

This is a multi-part message in MIME format.
--------------020802010509070202020402
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Hi Carter,

After trying to abstract the style of your email, which I don't 
appreciate, I'm not too sure how to read your email.
Is this an IP claim? Or just "I've been doing this for years, so I know 
better"?

In all cases, that's a nice advertisement for your company... Maybe it 
was the point...

On my side, I certainly don't get my ideas from your products!
The last time I looked up your web site was at the time of RFC3955.
In total in my live, I don't think I spend more than 1/2 h on your web site.

And I don't feel like replying to the details of this email, or even 
playing the little game of comparing features of your company/my company.

Regards, Benoit.
> Gentle people,
> I'm generally pretty quiet when it comes to IPFIX and its efforts. 
>  But as the first
> person to develop IP flow records in the 1980's, first to present the 
> idea to the
> community in 1992, the first to provide open source flow technology in 
> 1995,
> and the author of the longest lived open source flow system, argus; I 
> feel that
> I have to say something about the recent wave of IPFIX drafts.
>
> The drafts on flow aggregation describe functionality that the Argus 
> project started
> over 20 years ago.  The ideas of key modification, conversion of 
> non-key attributes
> to key members, aggregation operators, interval distribution and 
> the architecture for it,
> were all developed in argus a long long time ago. 
>  draft-ietf-ipfix-a9n is basically
> describing the functionality of argus's racluster(), rasplit(), and 
> rabins() programs,
> and every example given in the text of draft-ietf-ipfix-a9n can be 
> generated using
> argus's rabins(), with only a few gyrations of its command-line, today.
>
> I personally would expect that if the IETF was going to describe 
> something that is
> "Standards Track", that there would be dozen's of implementations of 
> this kind of
> technology available, and that the WG is condensing years of experience to
> arrive at a "Standards Track", but, this is not the case.  There is 
> only one current
> implementation of the complete capabilities of the features of 
> draft-ietf-ipfix-a9n
> that I am aware of, and that is in argus.
>
> Taking just one of the technical descriptions in the draft, "interval 
> distribution", I
> am not aware of any description of this issue, or implementation of 
> this type
> of technology in the literature, outside of argus.  No Google search 
> results for "flow
> interval distribution".   In Argus we call it flow splitting.  The 
> first line from a
> Google search for "argus flow splitting" return:
>
>
>       Scholarly articles for *argus flow splitting*
>       
>
> ... and prediction of *flow *statistics from sampled packet ... 
>  - 
> Duffield - Cited by 217
>
>
> I'm not saying that Nick knows much about argus's support for flow 
> splitting, but
> its still pretty scary that the first hit is from a paper that is used 
> in IPFIX documents.
> One would have to assume that the IPFIX community should be aware.
>
> My problem is that most of  draft-ietf-ipfix-a9n is prior work that is 
> not widely
> implemented, some of the features are still unique to argus.   While 
> IETF support
> of technology is a good thing, descriptions of technology without 
> reference
> is a difficult thing to interpret.  Is the IPFIX WG describing what 
> they think is new
> technology? Does the IPFIX WG think that many companies have implemented
> this type of technology, and now its time to standardize it ?  Well, 
> I'm not aware
> of any implementation, open or closed, that does the complete set of 
> what the
> draft is recommending, other than argus.  So I don't think its new, 
> nor widely
> implemented.  I would say its a form of technology plagiarism.
>
> IPFIX is considering adding non-IP flows to their definitions.  Argus 
> is the only available
> flow technology that has significant non-IP flow data models and 
> support.  argus-1.2 had
> flow generation, transport, analytics and storage of non-IP flows 20 
> years ago, with its
> support for bi-directional ethernet, apple-talk and ARP transaction 
> tracking and reporting.
> In the last 10 years, argus has added MPLS, VLAN, ISO addresses, and 
> Infiniband flow
> models.  Not attributes, but true flow key elements.   This work is 
> non-trivial.
>
> The concept that the WG would consider dropping the IP from IPFIX and 
> think that is
> all that is needed, is really so completely wrong, that its laughable, 
> and a dis-service
> to those that have done the hard work to bring 
> situational awareness and analytics
> to non-IP traffic.   The same applies to bi-directional flows, but 
> that is another story.
>
> I would love to think that IPFIX could focus back on flow information 
> exchange.
> Multicast, non-template based connectionless transport strategies, say 
> over UDT
> as an example, rather than getting into areas for which the WG is 
> unprepared to
> do even a reasonable job, without resorting to dubious techniques.
>
> Just a few comments, I hope that anyone finds it useful.
>
> Carter
>
> Carter Bullard
> CEO/President
> QoSient, LLC
> 150 E. 57th Street Suite 12D
> New York, New York 10022
>
> +1 212 588-9133 Phone
> +1 212 588-9134 Fax
>
>
>
>
>
> _______________________________________________
> IPFIX mailing list
> IPFIX@ietf.org
> https://www.ietf.org/mailman/listinfo/ipfix


--------------020802010509070202020402
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit


  
    
  
  
    Hi Carter,

    

    After trying to abstract the style of your email, which I don't
    appreciate, I'm not too sure how to read your email. 

    Is this an IP claim? Or just "I've been doing this for years, so I
    know better"?

    

    In all cases, that's a nice advertisement for your company... Maybe
    it was the point...

    

    On my side, I certainly don't get my ideas from your products!

    The last time I looked up your web site was at the time of RFC3955.

    In total in my live, I don't think I spend more than 1/2 h on your
    web site.

    

    And I don't feel like replying to the details of this email, or even
    playing the little game of comparing features of your company/my
    company.

    

    Regards, Benoit.

    
Gentle people,
      
I'm generally pretty quiet when it comes to IPFIX and its
        efforts.  But as the first

      
person to develop IP flow records in the 1980's, first to
        present the idea to the

      
community in 1992, the first to provide open source flow
        technology in 1995,

      
and the author of the longest lived open source flow system,
        argus; I feel that

      
I have to say something about the recent wave of IPFIX
        drafts.

      


      

      
The drafts on flow aggregation describe functionality that
        the Argus project started 

      
over 20 years ago.  The ideas of key modification, conversion
        of non-key attributes

      
to key members, aggregation operators, interval
        distribution and the architecture for it,

      
were all developed in argus a long long time ago.
         draft-ietf-ipfix-a9n is basically

      
describing the functionality of
        argus's racluster(), rasplit(), and rabins() programs,

      
and every example given in the text of draft-ietf-ipfix-a9n
        can be generated using

      
argus's rabins(), with only a few gyrations of its
        command-line, today.

      


      

      
I personally would expect that if the IETF was going to
        describe something that is

      
"Standards Track", that there would be dozen's of
        implementations of this kind of

      
technology available, and that the WG is condensing years of
        experience to

      
arrive at a "Standards Track", but, this is not the case.
         There is only one current

      
implementation of the complete capabilities of the features
        of draft-ietf-ipfix-a9n

      
that I am aware of, and that is in argus.

      


      

      
Taking just one of the technical descriptions in the
        draft, "interval distribution", I

      
am not aware of any description of this issue,
        or implementation of this type

      
of technology in the literature, outside of argus.  No Google
        search results for "flow

      
interval distribution".   In Argus we call it flow splitting.
         The first line from a

      
Google search for "argus flow splitting" return:

      


      

      
      
I'm not saying that Nick knows much about argus's support for
        flow splitting, but

      
its still pretty scary that the first hit is from a paper
        that is used in IPFIX documents.

      
One would have to assume that the IPFIX community should be
        aware.

      


      

      
My problem is that most of  draft-ietf-ipfix-a9n is prior
        work that is not widely

      
implemented, some of the features are still unique to argus.
          While IETF support

      
of technology is a good thing, descriptions of technology
        without reference

      
is a difficult thing to interpret.  Is the IPFIX WG
        describing what they think is new

      
technology? Does the IPFIX WG think that many companies have
        implemented

      
this type of technology, and now its time to standardize it ?
         Well, I'm not aware

      
of any implementation, open or closed, that does the complete
        set of what the

      
draft is recommending, other than argus.  So I don't think
        its new, nor widely

      
implemented.  I would say its a form of technology
        plagiarism.

      


      

      
IPFIX is considering adding non-IP flows to their
        definitions.  Argus is the only available

      
flow technology that has significant non-IP flow data models
        and support.  argus-1.2 had

      
flow generation, transport, analytics and storage of non-IP
        flows 20 years ago, with its

      
support for bi-directional ethernet, apple-talk and ARP
        transaction tracking and reporting.

      
In the last 10 years, argus has added MPLS, VLAN, ISO
        addresses, and Infiniband flow

      
models.  Not attributes, but true flow key elements.   This
        work is non-trivial.

      


      

      
The concept that the WG would consider dropping the IP from
        IPFIX and think that is

      
all that is needed, is really so completely wrong, that its
        laughable, and a dis-service

      
to those that have done the hard work to bring
        situational awareness and analytics

      
to non-IP traffic.   The same applies to bi-directional
        flows, but that is another story.

      


      

      
I would love to think that IPFIX could focus back on flow
        information exchange.

      
Multicast, non-template based connectionless transport
        strategies, say over UDT

      
as an example, rather than getting into areas for which the
        WG is unprepared to

      
do even a reasonable job, without resorting to dubious
        techniques.

      


      

      
Just a few comments, I hope that anyone finds it useful.

      


      

      

        

          
            

              
Carter

            

          

      

      

      

        
          

            
Carter Bullard

            
CEO/President

            
QoSient, LLC

            
150 E. 57th Street Suite 12D

            
New York, New York 10022

            


            

            
+1 212 588-9133 Phone

            
+1 212 588-9134 Fax

          

          


          

        

      

      

      

      

      

      
_______________________________________________
IPFIX mailing list
IPFIX@ietf.org
https://www.ietf.org/mailman/listinfo/ipfix


    

    

  


--------------020802010509070202020402--

From carter@qosient.com  Mon Feb 27 15:50:04 2012
Return-Path: 
X-Original-To: ipfix@ietfa.amsl.com
Delivered-To: ipfix@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D866421F8674 for ; Mon, 27 Feb 2012 15:50:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.902
X-Spam-Level: 
X-Spam-Status: No, score=-0.902 tagged_above=-999 required=5 tests=[AWL=1.300,  BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Tm5QXul6Mu1Z for ; Mon, 27 Feb 2012 15:50:03 -0800 (PST)
Received: from mail1.g1.pair.com (mail1.g1.pair.com [66.39.3.162]) by ietfa.amsl.com (Postfix) with ESMTP id 80D7821F8631 for ; Mon, 27 Feb 2012 15:50:02 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by mail1.g1.pair.com (Postfix) with SMTP id A83522844B; Mon, 27 Feb 2012 18:49:57 -0500 (EST)
Received: from thoth.newyork.qosient.com (207-237-36-98.c3-0.avec-ubr1.nyr-avec.ny.static.cable.rcn.com [207.237.36.98]) by mail1.g1.pair.com (Postfix) with ESMTPSA id 0BB9E284D6; Mon, 27 Feb 2012 18:49:57 -0500 (EST)
Mime-Version: 1.0 (Apple Message framework v1257)
Content-Type: multipart/signed; boundary="Apple-Mail=_68476CB7-2B59-46A0-856F-04F9819F460D"; protocol="application/pkcs7-signature"; micalg=sha1
From: Carter Bullard 
In-Reply-To: <4F4C0948.5090709@cisco.com>
Date: Mon, 27 Feb 2012 18:49:56 -0500
Message-Id: <59B81331-3FE0-4F4D-9903-D0131285A95D@qosient.com>
References: <91C99130-A66C-4E6A-AE93-BA005CE6C792@qosient.com> <4F4C0948.5090709@cisco.com>
To: Benoit Claise 
X-Mailer: Apple Mail (2.1257)
Cc: Argus , ipfix@ietf.org
Subject: Re: [IPFIX] recent ipfix drafts and argus
X-BeenThere: ipfix@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IPFIX WG discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 27 Feb 2012 23:50:05 -0000

--Apple-Mail=_68476CB7-2B59-46A0-856F-04F9819F460D
Content-Type: multipart/alternative;
	boundary="Apple-Mail=_AB5A5505-FDCC-42F7-ADE7-A598A4E8C318"


--Apple-Mail=_AB5A5505-FDCC-42F7-ADE7-A598A4E8C318
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=windows-1252

Hey Benoit,
Well you should pay some attention.  You should know if there is prior =
art before you start presenting descriptions of technology, and you =
should give credit to that prior art.  Problem's come up when you =
present work, and your descriptions look like the prior art's source =
code, and your examples look like that prior arts program output.   =
Maybe its just a coincidence.

Argus is free and open source software, and the concepts that you are =
presenting in your draft were implemented in argus over 19 years ago, so =
I don't think I'm too worried about IP.  Its just the arrogance of it =
all that is a little bit of a concern.  IPFIX isn't doing the community =
any favors if its only authors don't have a clue.

Carter

Carter Bullard
CEO/President
QoSient, LLC
150 E. 57th Street Suite 12D
New York, New York 10022

+1 212 588-9133 Phone
+1 212 588-9134 Fax



On Feb 27, 2012, at 5:52 PM, Benoit Claise wrote:

> Hi Carter,
>=20
> After trying to abstract the style of your email, which I don't =
appreciate, I'm not too sure how to read your email.=20
> Is this an IP claim? Or just "I've been doing this for years, so I =
know better"?
>=20
> In all cases, that's a nice advertisement for your company... Maybe it =
was the point...
>=20
> On my side, I certainly don't get my ideas from your products!
> The last time I looked up your web site was at the time of RFC3955.
> In total in my live, I don't think I spend more than 1/2 h on your web =
site.
>=20
> And I don't feel like replying to the details of this email, or even =
playing the little game of comparing features of your company/my =
company.
>=20
> Regards, Benoit.
>> Gentle people,
>> I'm generally pretty quiet when it comes to IPFIX and its efforts.  =
But as the first
>> person to develop IP flow records in the 1980's, first to present the =
idea to the
>> community in 1992, the first to provide open source flow technology =
in 1995,
>> and the author of the longest lived open source flow system, argus; I =
feel that
>> I have to say something about the recent wave of IPFIX drafts.
>>=20
>> The drafts on flow aggregation describe functionality that the Argus =
project started=20
>> over 20 years ago.  The ideas of key modification, conversion of =
non-key attributes
>> to key members, aggregation operators, interval distribution and the =
architecture for it,
>> were all developed in argus a long long time ago.  =
draft-ietf-ipfix-a9n is basically
>> describing the functionality of argus's racluster(), rasplit(), and =
rabins() programs,
>> and every example given in the text of draft-ietf-ipfix-a9n can be =
generated using
>> argus's rabins(), with only a few gyrations of its command-line, =
today.
>>=20
>> I personally would expect that if the IETF was going to describe =
something that is
>> "Standards Track", that there would be dozen's of implementations of =
this kind of
>> technology available, and that the WG is condensing years of =
experience to
>> arrive at a "Standards Track", but, this is not the case.  There is =
only one current
>> implementation of the complete capabilities of the features of =
draft-ietf-ipfix-a9n
>> that I am aware of, and that is in argus.
>>=20
>> Taking just one of the technical descriptions in the draft, "interval =
distribution", I
>> am not aware of any description of this issue, or implementation of =
this type
>> of technology in the literature, outside of argus.  No Google search =
results for "flow
>> interval distribution".   In Argus we call it flow splitting.  The =
first line from a
>> Google search for "argus flow splitting" return:
>>=20
>> Scholarly articles for argus flow splitting
>> =85 and prediction of flow statistics from sampled packet =85 - =
Duffield - Cited by 217
>>=20
>> I'm not saying that Nick knows much about argus's support for flow =
splitting, but
>> its still pretty scary that the first hit is from a paper that is =
used in IPFIX documents.
>> One would have to assume that the IPFIX community should be aware.
>>=20
>> My problem is that most of  draft-ietf-ipfix-a9n is prior work that =
is not widely
>> implemented, some of the features are still unique to argus.   While =
IETF support
>> of technology is a good thing, descriptions of technology without =
reference
>> is a difficult thing to interpret.  Is the IPFIX WG describing what =
they think is new
>> technology? Does the IPFIX WG think that many companies have =
implemented
>> this type of technology, and now its time to standardize it ?  Well, =
I'm not aware
>> of any implementation, open or closed, that does the complete set of =
what the
>> draft is recommending, other than argus.  So I don't think its new, =
nor widely
>> implemented.  I would say its a form of technology plagiarism.
>>=20
>> IPFIX is considering adding non-IP flows to their definitions.  Argus =
is the only available
>> flow technology that has significant non-IP flow data models and =
support.  argus-1.2 had
>> flow generation, transport, analytics and storage of non-IP flows 20 =
years ago, with its
>> support for bi-directional ethernet, apple-talk and ARP transaction =
tracking and reporting.
>> In the last 10 years, argus has added MPLS, VLAN, ISO addresses, and =
Infiniband flow
>> models.  Not attributes, but true flow key elements.   This work is =
non-trivial.
>>=20
>> The concept that the WG would consider dropping the IP from IPFIX and =
think that is
>> all that is needed, is really so completely wrong, that its =
laughable, and a dis-service
>> to those that have done the hard work to bring situational awareness =
and analytics
>> to non-IP traffic.   The same applies to bi-directional flows, but =
that is another story.
>>=20
>> I would love to think that IPFIX could focus back on flow information =
exchange.
>> Multicast, non-template based connectionless transport strategies, =
say over UDT
>> as an example, rather than getting into areas for which the WG is =
unprepared to
>> do even a reasonable job, without resorting to dubious techniques.
>>=20
>> Just a few comments, I hope that anyone finds it useful.
>>=20
>> Carter
>>=20
>> Carter Bullard
>> CEO/President
>> QoSient, LLC
>> 150 E. 57th Street Suite 12D
>> New York, New York 10022
>>=20
>> +1 212 588-9133 Phone
>> +1 212 588-9134 Fax
>>=20
>>=20
>>=20
>>=20
>>=20
>> _______________________________________________
>> IPFIX mailing list
>> IPFIX@ietf.org
>> https://www.ietf.org/mailman/listinfo/ipfix
>=20


--Apple-Mail=_AB5A5505-FDCC-42F7-ADE7-A598A4E8C318
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=windows-1252

Hey =
Benoit,
Well you should pay some attention.  You should know if =
there is prior art before you start presenting descriptions of =
technology, and you should give credit to that prior art. =
 Problem's come up when you present work, and =
your descriptions look like the prior art's source code, and your =
examples look like that prior arts program output.   Maybe its just =
a coincidence.

Argus is free and open source =
software, and the concepts that you are presenting in your draft were =
implemented in argus over 19 years ago, so I don't think I'm too worried =
about IP.  Its just the arrogance of it all that is a little bit of =
a concern.  IPFIX isn't doing the community any favors if its only =
authors don't have a clue.

Carter




Carter Bullard
CEO/President
QoSient, =
LLC
150 E. 57th Street Suite =
12D
New York, New York =
10022

+1 212 588-9133 Phone
+1 212 588-9134 =
Fax






On Feb 27, 2012, at 5:52 PM, Benoit Claise wrote:


 =20
    
 =20
  

    Hi Carter,

    

    After trying to abstract the style of your email, which I don't
    appreciate, I'm not too sure how to read your email. 

    Is this an IP claim? Or just "I've been doing this for years, so I
    know better"?

    

    In all cases, that's a nice advertisement for your company... Maybe
    it was the point...

    

    On my side, I certainly don't get my ideas from your products!

    The last time I looked up your web site was at the time of =
RFC3955.

    In total in my live, I don't think I spend more than 1/2 h on your
    web site.

    

    And I don't feel like replying to the details of this email, or even
    playing the little game of comparing features of your company/my
    company.

    

    Regards, Benoit.

    
Gentle people,
      
I'm generally pretty quiet when it comes to IPFIX and its
        efforts.  But as the first

      
person to develop IP flow records in the 1980's, first to
        present the idea to the

      
community in 1992, the first to provide open source flow
        technology in 1995,

      
and the author of the longest lived open source flow system,
        argus; I feel that

      
I have to say something about the recent wave of IPFIX
        drafts.

      


      

      
The drafts on flow aggregation describe functionality =
that
        the Argus project started 

      
over 20 years ago.  The ideas of =
key modification, conversion
        of non-key attributes

      
to key members, aggregation operators, interval
        distribution and the architecture for it,

      
were all developed in argus a long long =
time ago.
         draft-ietf-ipfix-a9n is basically

      
describing the functionality of
        argus's racluster(), rasplit(), and rabins() =
programs,

      
and every example given in the text =
of draft-ietf-ipfix-a9n
        can be generated using

      
argus's rabins(), with only a few gyrations of its
        command-line, today.

      


      

      
I personally would expect that if the IETF was going to
        describe something that is

      
"Standards Track", that there would be dozen's of
        implementations of this kind of

      
technology available, and that the WG is condensing years of
        experience to

      
arrive at a "Standards Track", but, this is not the =
case.
         There is only one current

      
implementation of the complete capabilities of the =
features
        of draft-ietf-ipfix-a9n

      
that I am aware of, and that is in argus.

      


      

      
Taking just one of the technical descriptions in the
        draft, "interval distribution", I

      
am not aware of any description of this issue,
        or implementation of this type

      
of technology in the literature, outside of argus. =
 No Google
        search results for "flow

      
interval distribution".   In Argus we call it flow =
splitting.
         The first line from a

      
Google search for "argus flow splitting" return:

      


      

      

          

            
              

                
                  
Scholarly
                      articles for argus flow =
splitting

                		
              

              

                
                  
      
      

      

        
          

            
Carter Bullard

            
CEO/President

            
QoSient, LLC

            
150 E. 57th Street Suite =
12D

            
New York, New York =
10022

            


            

            
+1 212 588-9133 Phone

            
+1 212 588-9134 Fax

          

          


          

        

      

      

      

      

      

      
_______________________________________________
IPFIX mailing list
IPFIX@ietf.org
https://www.ietf.org/=
mailman/listinfo/ipfix


    
    

  


=

--Apple-Mail=_AB5A5505-FDCC-42F7-ADE7-A598A4E8C318--

--Apple-Mail=_68476CB7-2B59-46A0-856F-04F9819F460D
Content-Disposition: attachment;
	filename=smime.p7s
Content-Type: application/pkcs7-signature;
	name=smime.p7s
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMRjCCBVAw
ggQ4oAMCAQICEE/C1XPaEv5Xc80XjVqbwwowDQYJKoZIhvcNAQEFBQAwgd0xCzAJBgNVBAYTAlVT
MRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y
azE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEg
KGMpMDkxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuVmVyaVNpZ24g
Q2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMzAeFw0xMTA0MTQwMDAwMDBaFw0x
MjA0MTMyMzU5NTlaMIIBEzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT
aWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9S
UEEgSW5jb3JwLiBieSBSZWYuLExJQUIuTFREKGMpOTgxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZh
bGlkYXRlZDEzMDEGA1UECxMqRGlnaXRhbCBJRCBDbGFzcyAxIC0gTmV0c2NhcGUgRnVsbCBTZXJ2
aWNlMRcwFQYDVQQDFA5DYXJ0ZXIgQnVsbGFyZDEhMB8GCSqGSIb3DQEJARYSY2FydGVyQHFvc2ll
bnQuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAnUsVMagrR+kSPj9tNNsMP6ZO
CRf4x70f3vT5OerV6rikEAz4XYJ+iv5Y6FiY5wjr2ez4BTrEuKwhAJN+aPSXHBW4cBZgB0J7mHwF
yJpY/vhhy2RrfugdCXjotFySXzevQHCfON4htlh+I3DYhN6LXmeBnnPtGz+J4mNZqdimZVlcdXqV
h0m7ysvdFkClht66vEvF+WObwLEpg3LIaFzTZBWpAiQ1FPIDJJd6uU//96grDvRy+D0oNjCkxmBp
bCkG0w1jaOuay6o62xRh7H41CxCRljzYjy3H4SwRYlYBwtqZuXg0YOI0OHdSuie6UyrUgmT+3S1U
FPiGz9yP9hninQIDAQABo4HSMIHPMAkGA1UdEwQCMAAwRAYDVR0gBD0wOzA5BgtghkgBhvhFAQcX
ATAqMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhMAsGA1UdDwQEAwIF
oDAdBgNVHSUEFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIwUAYDVR0fBEkwRzBFoEOgQYY/aHR0cDov
L2luZGMxZGlnaXRhbGlkLWczLWNybC52ZXJpc2lnbi5jb20vSW5kQzFEaWdpdGFsSUQtRzMuY3Js
MA0GCSqGSIb3DQEBBQUAA4IBAQBSg1+LGDk7EKu1hYCrpHEZVHY3I+850erL2DxLtfgzldWZPLYr
NpVa8wH5XTDhaFNLQgWwLMGfs8sJPkqXm2TfZfG7BkJWLtubW3Jw5jZ//Eygbae2IOU0bm1tAaG2
uoreBROJ5PU1ykK8aTnbNZxN772otsdHQ54gXd2wpPUoDoT740WzsdTeSI0ZXU+3J7RPbC0VHNfI
E88GgkTYBD5Xk3Ro+BSCBOh4XAA1ypHBZh2OX8C4syhPp6yfGWvwvqJ+oV5lkbAcO6FkeBlvb/Fi
XPa35ynGIIpntzpqOvr+0XJs8xq7hE8KU/QUNE6fa0gZyjxBVcbw89mv4lQx4FSOMIIG7jCCBdag
AwIBAgIQcRVmBUrkkSFN6bxE+azT3DANBgkqhkiG9w0BAQUFADCByjELMAkGA1UEBhMCVVMxFzAV
BgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTow
OAYDVQQLEzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVkIHVzZSBvbmx5
MUUwQwYDVQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRpZmljYXRpb24g
QXV0aG9yaXR5IC0gRzMwHhcNMDkwNTAxMDAwMDAwWhcNMTkwNDMwMjM1OTU5WjCB3TELMAkGA1UE
BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBO
ZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29t
L3JwYSAoYykwOTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJp
U2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEczMIIBIjANBgkqhkiG9w0B
AQEFAAOCAQ8AMIIBCgKCAQEA7cRH3yooHXwGa7vXITLJbBOP6bGNQU4099oL42r6ZYggCxET6Zvg
SU6Lb9UB0F8NR5GKWkx0Pj/GkQm7TDSejW6hglFi92l2WJYHr54UGAdPWr2f0jGyVBlzRmoZQhHs
EnMhjfXcMM3l2VYKMcU2bSkUl70t2olHGYjYSwQ967Y8Zx50ABMN0Ibak2f4MwOuGjxraXj2wCyO
4YM/d/mZ//6fUlrCtIcK2GypR8FUKWVDPkrAlh/Brfd3r2yxBF6+wbaULZeQLSfSux7pg2qE9sSy
riMGZSalJ1grByK0b6ZiSBp38tVQJ5op05b7KPW6JHZi44xZ6/tu1ULEvkHH9QIDAQABo4ICuTCC
ArUwNAYIKwYBBQUHAQEEKDAmMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC52ZXJpc2lnbi5jb20w
EgYDVR0TAQH/BAgwBgEB/wIBADBwBgNVHSAEaTBnMGUGC2CGSAGG+EUBBxcBMFYwKAYIKwYBBQUH
AgEWHGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9jcHMwKgYIKwYBBQUHAgIwHhocaHR0cHM6Ly93
d3cudmVyaXNpZ24uY29tL3JwYTA0BgNVHR8ELTArMCmgJ6AlhiNodHRwOi8vY3JsLnZlcmlzaWdu
LmNvbS9wY2ExLWczLmNybDAOBgNVHQ8BAf8EBAMCAQYwbgYIKwYBBQUHAQwEYjBgoV6gXDBaMFgw
VhYJaW1hZ2UvZ2lmMCEwHzAHBgUrDgMCGgQUS2u5KJYGDLvQUjibKaxLB4shBRgwJhYkaHR0cDov
L2xvZ28udmVyaXNpZ24uY29tL3ZzbG9nbzEuZ2lmMC4GA1UdEQQnMCWkIzAhMR8wHQYDVQQDExZQ
cml2YXRlTGFiZWw0LTIwNDgtMTE4MB0GA1UdDgQWBBR5R2EIQf04BKJL57XM9UP2SSsR+DCB8QYD
VR0jBIHpMIHmoYHQpIHNMIHKMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4x
HzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOjA4BgNVBAsTMShjKSAxOTk5IFZlcmlT
aWduLCBJbmMuIC0gRm9yIGF1dGhvcml6ZWQgdXNlIG9ubHkxRTBDBgNVBAMTPFZlcmlTaWduIENs
YXNzIDEgUHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgLSBHM4IRAItbdVaE
VIULAM+vOEjOsaQwDQYJKoZIhvcNAQEFBQADggEBADlNz0GZgbWpBbVSOOk5hIls5DSoWufYbAlM
JBq6WaSHO3Mh8ZOBz79oY1pn/jWFK6HDXaNKwjoZ3TDWzE3v8dKBl8pUWkO/N4t6jhmND0OojPKv
YLMVirOVnDzgnrMnmKQ1chfl/Cpdh9OKDcLRRSr4wPSsKpM61a4ScAjr+zvid+zoK2Q1ds262uDR
yxTWcVibvtU+fbbZ6CTFJGZMXZEfdrMXPn8NxiGJL7M3uKH/XLJtSd5lUkL7DojS7Uodv0vj+Mxy
+kgOZY5JyNb4mZg7t5Q+MXEGh/psWVMu198r7V9jAKwV7QO4VRaMxmgD5yKocwuxvKDaUljdCg5/
wYIxggSLMIIEhwIBATCB8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMu
MR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2Ug
YXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwOTEeMBwGA1UECxMVUGVyc29uYSBO
b3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2Ny
aWJlciBDQSAtIEczAhBPwtVz2hL+V3PNF41am8MKMAkGBSsOAwIaBQCgggJtMBgGCSqGSIb3DQEJ
AzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEyMDIyNzIzNDk1N1owIwYJKoZIhvcNAQkE
MRYEFCSRaYmo75jdB6LGhkcJjtgsVxyWMIIBAwYJKwYBBAGCNxAEMYH1MIHyMIHdMQswCQYDVQQG
EwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5l
dHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20v
cnBhIChjKTA5MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMTLlZlcmlT
aWduIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzMCEE/C1XPaEv5Xc80XjVqb
wwowggEFBgsqhkiG9w0BCRACCzGB9aCB8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlT
aWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJt
cyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwOTEeMBwGA1UECxMV
UGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1
YWwgU3Vic2NyaWJlciBDQSAtIEczAhBPwtVz2hL+V3PNF41am8MKMA0GCSqGSIb3DQEBAQUABIIB
AFjetaS4/cN/iEZDRmCaWGBCdLpChAFqqmTWMk/U3121klzndxybuCNpIzOAQa0TK53O8WdGBuXf
M3F7OxO0AdOEaVQyr92nKGhv9iWCIP2YTkvP86noouO8+FeDu1s4c9J+aa10LznyW9xM5cvkvvvb
3G6rTMpq4GSi6+sXYKo63iHHMaZqin87bBSgcKaPu26ZkRdF8On+ztuNqlM0rdrRH9OViWKnQFnf
JlqbfbW3+uW7f4iywzltkfw0wORsvdsGCnWseVEATdDls5fnRlJLZ8YY/n8UiHUriQZ6RtPfVxrd
q0tTqP0QEn+e6rorvcDc5xMusGfdBYSsZh62MWYAAAAAAAA=

--Apple-Mail=_68476CB7-2B59-46A0-856F-04F9819F460D--

From Quittek@neclab.eu  Tue Feb 28 01:25:57 2012
Return-Path: 
X-Original-To: ipfix@ietfa.amsl.com
Delivered-To: ipfix@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 18F5F21F86AA for ; Tue, 28 Feb 2012 01:25:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.176
X-Spam-Level: 
X-Spam-Status: No, score=-102.176 tagged_above=-999 required=5 tests=[AWL=-0.177, BAYES_00=-2.599, J_CHICKENPOX_64=0.6, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jey60syzNYn4 for ; Tue, 28 Feb 2012 01:25:56 -0800 (PST)
Received: from mailer1.neclab.eu (mailer1.neclab.eu [195.37.70.40]) by ietfa.amsl.com (Postfix) with ESMTP id 9FEF921F8514 for ; Tue, 28 Feb 2012 01:25:55 -0800 (PST)
Received: from localhost (localhost.localdomain [127.0.0.1]) by mailer1.neclab.eu (Postfix) with ESMTP id 0143228000084; Tue, 28 Feb 2012 10:25:55 +0100 (CET)
X-Virus-Scanned: Amavisd on Debian GNU/Linux (netlab.nec.de)
Received: from mailer1.neclab.eu ([127.0.0.1]) by localhost (atlas1.office.hd [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J+Ogc5x+rDog; Tue, 28 Feb 2012 10:25:54 +0100 (CET)
Received: from ENCELADUS.office.hd (ENCELADUS.office.hd [192.168.24.52]) by mailer1.neclab.eu (Postfix) with ESMTP id D3C11280001CE; Tue, 28 Feb 2012 10:25:34 +0100 (CET)
Received: from DAPHNIS.office.hd ([169.254.2.41]) by ENCELADUS.office.hd ([192.168.24.52]) with mapi id 14.01.0323.003; Tue, 28 Feb 2012 10:25:34 +0100
From: Juergen Quittek 
To: Carter Bullard 
Thread-Topic: [IPFIX] recent ipfix drafts and argus
Thread-Index: AQHM9frr6/dYmdKkR0e6rVTy6/0TDA==
Date: Tue, 28 Feb 2012 09:25:33 +0000
Message-ID: 
In-Reply-To: <59B81331-3FE0-4F4D-9903-D0131285A95D@qosient.com>
Accept-Language: de-DE, en-US
Content-Language: de-DE
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.14.0.111121
x-originating-ip: [10.7.0.92]
Content-Type: text/plain; charset="Windows-1252"
Content-ID: <00F3B7F508A1B446B2572AEDBC58445D@office.hd>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: Argus , IETF IPFIX Working Group 
Subject: Re: [IPFIX] recent ipfix drafts and argus
X-BeenThere: ipfix@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IPFIX WG discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 28 Feb 2012 09:25:57 -0000

Hi Carter,

You know the IPFIX WG for long and our process has always been open.
Aggregation (also referred to as "concentration") was always among
the requirements to take care of by the IPFIX WG, see, for example,
RFC 3917 from 2004.

The open IETF process allows anybody to support technical documents
with solutions, such as ones on IPFIX aggregation.  So far, no such
contribution has been made by argus developers or users.  This is a
pity, but nothing you can blame any active members of the IPFIX WG
for.  If you want to blame someone, then rather blame the argus
community including yourself.  You aware of the IPFIX WG and
contributions from you or argus users would have been highly
appreciated.

The IPFIX WG is and will always open for contributions from the
argus community.  If you think that a technical contributions from
argus or a reference to argus would improve any of our current
documents, then please contribute to them, as you had already done
in the past.  Please particularly do so if you think the way argus
solved technical problems is better than what has so far been
contributed to the IPFIX WG.


While your technical contributions will always be welcome, I ask
you in my role as WG co-chair to stop making harsh statements on
the mailing list, even though the main effect that you achieve
with these statements is discrediting yourself.  In particular
I refer to two statements you made:

1. You accuse authors of draft draft-ietf-ipfix-a9n of plagiarism.
Your main reason for this was that you stated "I had the same idea
before" and it's publicly available.  I haven't checked if the
ideas are exactly the same, but this is not the point.  It does
happen that two people independently have the same idea.
For accusing someone of plagiarism, more evidence is necessary,
at least if you want to be taken serious.

2. You claim that authors of draft-ietf-ipfix-a9n are lacking
expertise.  Indeed, there are leading experts among the authors
with high reputation and high expertise in the area of IP
flow monitoring.  Claiming they "don't have a clue" because they
don't know argus by heart is a statement that may be valid in
an argus-centric world, but not in the world of the IP flow
monitoring community.


I look forward to your technical contributions for improving the
Standards we are developing in the IPFIX WG.

    Juergen
    WG co-chair


On 28.02.12 00:49, "Carter Bullard"  wrote:

>Hey Benoit,Well you should pay some attention.  You should know if there
>is prior art before you start presenting descriptions of technology, and
>you should give credit to that prior art.  Problem's come up when you
>present work, and your descriptions look like the prior art's source
>code, and your examples look like that prior arts program output.   Maybe
>its just a coincidence.
>
>Argus is free and open source software, and the concepts that you are
>presenting in your draft were implemented in argus over 19 years ago, so
>I don't think I'm too worried about IP.  Its just the arrogance of it all
>that is a little bit of a concern.  IPFIX isn't doing the community any
>favors if its only authors don't have a clue.
>
>Carter
>
>Carter Bullard
>CEO/President
>QoSient, LLC
>150 E. 57th Street Suite 12D
>New York, New York 10022
>
>+1 212 588-9133 Phone
>+1 212 588-9134 Fax
>
>
>
>
>
>On Feb 27, 2012, at 5:52 PM, Benoit Claise wrote:
>
>
> =20
>   =20
> =20
> =20
>    Hi Carter,
>   =20
>    After trying to abstract the style of your email, which I don't
>    appreciate, I'm not too sure how to read your email.
>    Is this an IP claim? Or just "I've been doing this for years, so I
>    know better"?
>   =20
>    In all cases, that's a nice advertisement for your company... Maybe
>    it was the point...
>   =20
>    On my side, I certainly don't get my ideas from your products!
>    The last time I looked up your web site was at the time of RFC3955.
>    In total in my live, I don't think I spend more than 1/2 h on your
>    web site.
>   =20
>    And I don't feel like replying to the details of this email, or even
>    playing the little game of comparing features of your company/my
>    company.
>   =20
>    Regards, Benoit.
>   =20
>Gentle people,
>      I'm generally pretty quiet when it comes to IPFIX and its
>        efforts.  But as the first
>      person to develop IP flow records in the 1980's, first to
>        present the idea to the
>      community in 1992, the first to provide open source flow
>        technology in 1995,
>      and the author of the longest lived open source flow system,
>        argus; I feel that
>      I have to say something about the recent wave of IPFIX
>        drafts.
>     =20
>     =20
>      The drafts on flow aggregation describe functionality that
>        the Argus project started
>      over 20 years ago.  The ideas of key modification, conversion
>        of non-key attributes
>      to key members, aggregation operators, interval
>        distribution and the architecture for it,
>      were all developed in argus a long long time ago.
>         draft-ietf-ipfix-a9n is basically
>      describing the functionality of
>        argus's racluster(), rasplit(), and rabins() programs,
>      and every example given in the text of draft-ietf-ipfix-a9n
>        can be generated using
>      argus's rabins(), with only a few gyrations of its
>        command-line, today.
>     =20
>     =20
>      I personally would expect that if the IETF was going to
>        describe something that is
>      "Standards Track", that there would be dozen's of
>        implementations of this kind of
>      technology available, and that the WG is condensing years of
>        experience to
>      arrive at a "Standards Track", but, this is not the case.
>         There is only one current
>      implementation of the complete capabilities of the features
>        of draft-ietf-ipfix-a9n
>      that I am aware of, and that is in argus.
>     =20
>     =20
>      Taking just one of the technical descriptions in the
>        draft, "interval distribution", I
>      am not aware of any description of this issue,
>        or implementation of this type
>      of technology in the literature, outside of argus.  No Google
>        search results for "flow
>      interval distribution".   In Argus we call it flow splitting.
>         The first line from a
>      Google search for "argus flow splitting" return:
>     =20
>     =20
>     =20
>         =20
>           =20
>             =20
>               =20
>                  Scholarly
>                      articles for argus flow splitting
>s_vis=3D1&oi=3Dscholart&sa=3DX&ei=3D-8NLT_6lKcnb0QHVs6z7DQ&ved=3D0CBoQgQMw=
AA>
>               =20
>             =20
>             =20
>               =20
>                  =8A
>                      and prediction of flow statistics from
>                      sampled packet =8A
>3Den%26q%3Dhttp://dl.acm.org/citation.cfm%253Fid%253D637225%26sa%3DX%26sci
>sig%3DAAGBfm1Qq9_hOFJINho1051rzZ6qOD5wuA%26oi%3Dscholarr&rct=3Dj&sa=3DX&ei=
=3D-8N
>LT_6lKcnb0QHVs6z7DQ&ved=3D0CBsQgAMoADAA&q=3Dargus+flow+splitting&usg=3DAFQ=
jCNFuM
>uC_b45uErbgoPHPab61egoZ3g> - Duffield -
>                      Cited by 217
>               =20
>             =20
>           =20
>         =20
>       =20
>       =20
>       =20
>     =20
>      I'm not saying that Nick knows much about argus's support for
>        flow splitting, but
>      its still pretty scary that the first hit is from a paper
>        that is used in IPFIX documents.
>      One would have to assume that the IPFIX community should be
>        aware.
>     =20
>     =20
>      My problem is that most of  draft-ietf-ipfix-a9n is prior
>        work that is not widely
>      implemented, some of the features are still unique to argus.
>          While IETF support
>      of technology is a good thing, descriptions of technology
>        without reference
>      is a difficult thing to interpret.  Is the IPFIX WG
>        describing what they think is new
>      technology? Does the IPFIX WG think that many companies have
>        implemented
>      this type of technology, and now its time to standardize it ?
>         Well, I'm not aware
>      of any implementation, open or closed, that does the complete
>        set of what the
>      draft is recommending, other than argus.  So I don't think
>        its new, nor widely
>      implemented.  I would say its a form of technology
>        plagiarism.
>     =20
>     =20
>      IPFIX is considering adding non-IP flows to their
>        definitions.  Argus is the only available
>      flow technology that has significant non-IP flow data models
>        and support.  argus-1.2 had
>      flow generation, transport, analytics and storage of non-IP
>        flows 20 years ago, with its
>      support for bi-directional ethernet, apple-talk and ARP
>        transaction tracking and reporting.
>      In the last 10 years, argus has added MPLS, VLAN, ISO
>        addresses, and Infiniband flow
>      models.  Not attributes, but true flow key elements.   This
>        work is non-trivial.
>     =20
>     =20
>      The concept that the WG would consider dropping the IP from
>        IPFIX and think that is
>      all that is needed, is really so completely wrong, that its
>        laughable, and a dis-service
>      to those that have done the hard work to bring
>        situational awareness and analytics
>      to non-IP traffic.   The same applies to bi-directional
>        flows, but that is another story.
>     =20
>     =20
>      I would love to think that IPFIX could focus back on flow
>        information exchange.
>      Multicast, non-template based connectionless transport
>        strategies, say over UDT
>      as an example, rather than getting into areas for which the
>        WG is unprepared to
>      do even a reasonable job, without resorting to dubious
>        techniques.
>     =20
>     =20
>      Just a few comments, I hope that anyone finds it useful.
>     =20
>     =20
>     =20
>       =20
>         =20
>           =20
>              Carter
>           =20
>         =20
>     =20
>     =20
>     =20
>       =20
>         =20
>            Carter Bullard
>            CEO/President
>            QoSient, LLC
>            150 E. 57th Street Suite 12D
>            New York, New York 10022
>           =20
>           =20
>            +1 212 588-9133 Phone
>            +1 212 588-9134 Fax
>         =20
>         =20
>         =20
>       =20
>     =20
>     =20
>     =20
>     =20
>     =20
>      _______________________________________________
>IPFIX mailing list
>IPFIX@ietf.orghttps://www.ietf.org/mailman/listinfo/ipfix
>   =20
>
>   =20
> =20
>
>
>
>
>
>
>
>_______________________________________________
>IPFIX mailing list
>IPFIX@ietf.org
>https://www.ietf.org/mailman/listinfo/ipfix


From carter@qosient.com  Tue Feb 28 07:13:13 2012
Return-Path: 
X-Original-To: ipfix@ietfa.amsl.com
Delivered-To: ipfix@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5631521F86B8 for ; Tue, 28 Feb 2012 07:13:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.252
X-Spam-Level: 
X-Spam-Status: No, score=-1.252 tagged_above=-999 required=5 tests=[AWL=0.350,  BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_64=0.6, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xW4NXmcNIdZf for ; Tue, 28 Feb 2012 07:13:11 -0800 (PST)
Received: from mail1.g1.pair.com (mail1.g1.pair.com [66.39.3.162]) by ietfa.amsl.com (Postfix) with ESMTP id 319E321F86C7 for ; Tue, 28 Feb 2012 07:13:11 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by mail1.g1.pair.com (Postfix) with SMTP id 4B77B28CEA; Tue, 28 Feb 2012 10:13:06 -0500 (EST)
Received: from thoth.newyork.qosient.com (207-237-36-98.c3-0.avec-ubr1.nyr-avec.ny.static.cable.rcn.com [207.237.36.98]) by mail1.g1.pair.com (Postfix) with ESMTPSA id 5C99D28AE0; Tue, 28 Feb 2012 10:13:05 -0500 (EST)
Mime-Version: 1.0 (Apple Message framework v1257)
Content-Type: multipart/signed; boundary="Apple-Mail=_141D9080-557F-4BA4-8DA8-2E96DFAF0561"; protocol="application/pkcs7-signature"; micalg=sha1
From: Carter Bullard 
In-Reply-To: 
Date: Tue, 28 Feb 2012 10:13:04 -0500
Message-Id: 
References: 
To: Juergen Quittek 
X-Mailer: Apple Mail (2.1257)
Cc: Argus , IETF IPFIX Working Group 
Subject: Re: [IPFIX] recent ipfix drafts and argus
X-BeenThere: ipfix@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IPFIX WG discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 28 Feb 2012 15:13:13 -0000

--Apple-Mail=_141D9080-557F-4BA4-8DA8-2E96DFAF0561
Content-Type: multipart/alternative;
	boundary="Apple-Mail=_B0A9CFF1-6C68-4C9A-A4C0-01F065B3EF67"


--Apple-Mail=_B0A9CFF1-6C68-4C9A-A4C0-01F065B3EF67
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=windows-1252

Hey Juergen,
It is not the responsibility of groups outside of the IETF to police =
IETF working groups
to ensure that they are doing the right thing. The IETF itself, has a =
responsibility to do
the right thing when it comes to publishing technical documents.

I am providing input to the WG that draft-ietf-ipfix-a9n-3 is not =
original work, the concepts
have been worked in the communications industry for a very long time, =
and there are open
public implementations of every concept in the draft.   I am also =
providing input to the WG
that draft-ietf-ipfix-a9n-3 appears to be using concepts, and examples =
that are curiously
specific to actual implementation and publications developed by Argus.

Based on the response from the authors to the mailing list, its clear =
that the authors
have not done any due diligence to ensure that their draft conforms to =
even the simplest of
ethics in technical publication.  Plagiarism is a very serious problem, =
and the authors
should know how to protect themselves from such a claim.

I am providing input to the WG that I believe the authors cannot defend =
themselves
from such a claim with their current draft, and that the WG should =
respond accordingly.

I would hope that the WG will use this input to improve their processes =
and products,
something that would benefit the entire flow community.

Carter

Carter Bullard
CEO/President
QoSient, LLC
150 E. 57th Street Suite 12D
New York, New York 10022

+1 212 588-9133 Phone
+1 212 588-9134 Fax



On Feb 28, 2012, at 4:25 AM, Juergen Quittek wrote:

> Hi Carter,
>=20
> You know the IPFIX WG for long and our process has always been open.
> Aggregation (also referred to as "concentration") was always among
> the requirements to take care of by the IPFIX WG, see, for example,
> RFC 3917 from 2004.
>=20
> The open IETF process allows anybody to support technical documents
> with solutions, such as ones on IPFIX aggregation.  So far, no such
> contribution has been made by argus developers or users.  This is a
> pity, but nothing you can blame any active members of the IPFIX WG
> for.  If you want to blame someone, then rather blame the argus
> community including yourself.  You aware of the IPFIX WG and
> contributions from you or argus users would have been highly
> appreciated.
>=20
> The IPFIX WG is and will always open for contributions from the
> argus community.  If you think that a technical contributions from
> argus or a reference to argus would improve any of our current
> documents, then please contribute to them, as you had already done
> in the past.  Please particularly do so if you think the way argus
> solved technical problems is better than what has so far been
> contributed to the IPFIX WG.
>=20
>=20
> While your technical contributions will always be welcome, I ask
> you in my role as WG co-chair to stop making harsh statements on
> the mailing list, even though the main effect that you achieve
> with these statements is discrediting yourself.  In particular
> I refer to two statements you made:
>=20
> 1. You accuse authors of draft draft-ietf-ipfix-a9n of plagiarism.
> Your main reason for this was that you stated "I had the same idea
> before" and it's publicly available.  I haven't checked if the
> ideas are exactly the same, but this is not the point.  It does
> happen that two people independently have the same idea.
> For accusing someone of plagiarism, more evidence is necessary,
> at least if you want to be taken serious.
>=20
> 2. You claim that authors of draft-ietf-ipfix-a9n are lacking
> expertise.  Indeed, there are leading experts among the authors
> with high reputation and high expertise in the area of IP
> flow monitoring.  Claiming they "don't have a clue" because they
> don't know argus by heart is a statement that may be valid in
> an argus-centric world, but not in the world of the IP flow
> monitoring community.
>=20
>=20
> I look forward to your technical contributions for improving the
> Standards we are developing in the IPFIX WG.
>=20
>    Juergen
>    WG co-chair
>=20
>=20
> On 28.02.12 00:49, "Carter Bullard"  wrote:
>=20
>> Hey Benoit,Well you should pay some attention.  You should know if =
there
>> is prior art before you start presenting descriptions of technology, =
and
>> you should give credit to that prior art.  Problem's come up when you
>> present work, and your descriptions look like the prior art's source
>> code, and your examples look like that prior arts program output.   =
Maybe
>> its just a coincidence.
>>=20
>> Argus is free and open source software, and the concepts that you are
>> presenting in your draft were implemented in argus over 19 years ago, =
so
>> I don't think I'm too worried about IP.  Its just the arrogance of it =
all
>> that is a little bit of a concern.  IPFIX isn't doing the community =
any
>> favors if its only authors don't have a clue.
>>=20
>> Carter
>>=20
>> Carter Bullard
>> CEO/President
>> QoSient, LLC
>> 150 E. 57th Street Suite 12D
>> New York, New York 10022
>>=20
>> +1 212 588-9133 Phone
>> +1 212 588-9134 Fax
>>=20
>>=20
>>=20
>>=20
>>=20
>> On Feb 27, 2012, at 5:52 PM, Benoit Claise wrote:
>>=20
>>=20
>>=20
>>=20
>>=20
>>=20
>>   Hi Carter,
>>=20
>>   After trying to abstract the style of your email, which I don't
>>   appreciate, I'm not too sure how to read your email.
>>   Is this an IP claim? Or just "I've been doing this for years, so I
>>   know better"?
>>=20
>>   In all cases, that's a nice advertisement for your company... Maybe
>>   it was the point...
>>=20
>>   On my side, I certainly don't get my ideas from your products!
>>   The last time I looked up your web site was at the time of RFC3955.
>>   In total in my live, I don't think I spend more than 1/2 h on your
>>   web site.
>>=20
>>   And I don't feel like replying to the details of this email, or =
even
>>   playing the little game of comparing features of your company/my
>>   company.
>>=20
>>   Regards, Benoit.
>>=20
>> Gentle people,
>>     I'm generally pretty quiet when it comes to IPFIX and its
>>       efforts.  But as the first
>>     person to develop IP flow records in the 1980's, first to
>>       present the idea to the
>>     community in 1992, the first to provide open source flow
>>       technology in 1995,
>>     and the author of the longest lived open source flow system,
>>       argus; I feel that
>>     I have to say something about the recent wave of IPFIX
>>       drafts.
>>=20
>>=20
>>     The drafts on flow aggregation describe functionality that
>>       the Argus project started
>>     over 20 years ago.  The ideas of key modification, conversion
>>       of non-key attributes
>>     to key members, aggregation operators, interval
>>       distribution and the architecture for it,
>>     were all developed in argus a long long time ago.
>>        draft-ietf-ipfix-a9n is basically
>>     describing the functionality of
>>       argus's racluster(), rasplit(), and rabins() programs,
>>     and every example given in the text of draft-ietf-ipfix-a9n
>>       can be generated using
>>     argus's rabins(), with only a few gyrations of its
>>       command-line, today.
>>=20
>>=20
>>     I personally would expect that if the IETF was going to
>>       describe something that is
>>     "Standards Track", that there would be dozen's of
>>       implementations of this kind of
>>     technology available, and that the WG is condensing years of
>>       experience to
>>     arrive at a "Standards Track", but, this is not the case.
>>        There is only one current
>>     implementation of the complete capabilities of the features
>>       of draft-ietf-ipfix-a9n
>>     that I am aware of, and that is in argus.
>>=20
>>=20
>>     Taking just one of the technical descriptions in the
>>       draft, "interval distribution", I
>>     am not aware of any description of this issue,
>>       or implementation of this type
>>     of technology in the literature, outside of argus.  No Google
>>       search results for "flow
>>     interval distribution".   In Argus we call it flow splitting.
>>        The first line from a
>>     Google search for "argus flow splitting" return:
>>=20
>>=20
>>=20
>>=20
>>=20
>>=20
>>=20
>>                 Scholarly
>>                     articles for argus flow splitting
>> =
> s_vis=3D1&oi=3Dscholart&sa=3DX&ei=3D-8NLT_6lKcnb0QHVs6z7DQ&ved=3D0CBoQg=
QMwAA>
>>=20
>>=20
>>=20
>>=20
>>                 =8A
>>                     and prediction of flow statistics from
>>                     sampled packet =8A
>> =
> =
3Den%26q%3Dhttp://dl.acm.org/citation.cfm%253Fid%253D637225%26sa%3DX%26sci=

>> =
sig%3DAAGBfm1Qq9_hOFJINho1051rzZ6qOD5wuA%26oi%3Dscholarr&rct=3Dj&sa=3DX&ei=
=3D-8N
>> =
LT_6lKcnb0QHVs6z7DQ&ved=3D0CBsQgAMoADAA&q=3Dargus+flow+splitting&usg=3DAFQ=
jCNFuM
>> uC_b45uErbgoPHPab61egoZ3g> - Duffield -
>>                     Cited by 217
>>=20
>>=20
>>=20
>>=20
>>=20
>>=20
>>=20
>>=20
>>     I'm not saying that Nick knows much about argus's support for
>>       flow splitting, but
>>     its still pretty scary that the first hit is from a paper
>>       that is used in IPFIX documents.
>>     One would have to assume that the IPFIX community should be
>>       aware.
>>=20
>>=20
>>     My problem is that most of  draft-ietf-ipfix-a9n is prior
>>       work that is not widely
>>     implemented, some of the features are still unique to argus.
>>         While IETF support
>>     of technology is a good thing, descriptions of technology
>>       without reference
>>     is a difficult thing to interpret.  Is the IPFIX WG
>>       describing what they think is new
>>     technology? Does the IPFIX WG think that many companies have
>>       implemented
>>     this type of technology, and now its time to standardize it ?
>>        Well, I'm not aware
>>     of any implementation, open or closed, that does the complete
>>       set of what the
>>     draft is recommending, other than argus.  So I don't think
>>       its new, nor widely
>>     implemented.  I would say its a form of technology
>>       plagiarism.
>>=20
>>=20
>>     IPFIX is considering adding non-IP flows to their
>>       definitions.  Argus is the only available
>>     flow technology that has significant non-IP flow data models
>>       and support.  argus-1.2 had
>>     flow generation, transport, analytics and storage of non-IP
>>       flows 20 years ago, with its
>>     support for bi-directional ethernet, apple-talk and ARP
>>       transaction tracking and reporting.
>>     In the last 10 years, argus has added MPLS, VLAN, ISO
>>       addresses, and Infiniband flow
>>     models.  Not attributes, but true flow key elements.   This
>>       work is non-trivial.
>>=20
>>=20
>>     The concept that the WG would consider dropping the IP from
>>       IPFIX and think that is
>>     all that is needed, is really so completely wrong, that its
>>       laughable, and a dis-service
>>     to those that have done the hard work to bring
>>       situational awareness and analytics
>>     to non-IP traffic.   The same applies to bi-directional
>>       flows, but that is another story.
>>=20
>>=20
>>     I would love to think that IPFIX could focus back on flow
>>       information exchange.
>>     Multicast, non-template based connectionless transport
>>       strategies, say over UDT
>>     as an example, rather than getting into areas for which the
>>       WG is unprepared to
>>     do even a reasonable job, without resorting to dubious
>>       techniques.
>>=20
>>=20
>>     Just a few comments, I hope that anyone finds it useful.
>>=20
>>=20
>>=20
>>=20
>>=20
>>=20
>>             Carter
>>=20
>>=20
>>=20
>>=20
>>=20
>>=20
>>=20
>>           Carter Bullard
>>           CEO/President
>>           QoSient, LLC
>>           150 E. 57th Street Suite 12D
>>           New York, New York 10022
>>=20
>>=20
>>           +1 212 588-9133 Phone
>>           +1 212 588-9134 Fax
>>=20
>>=20
>>=20
>>=20
>>=20
>>=20
>>=20
>>=20
>>=20
>>     _______________________________________________
>> IPFIX mailing list
>> IPFIX@ietf.orghttps://www.ietf.org/mailman/listinfo/ipfix
>>=20
>>=20
>>=20
>>=20
>>=20
>>=20
>>=20
>>=20
>>=20
>>=20
>>=20
>> _______________________________________________
>> IPFIX mailing list
>> IPFIX@ietf.org
>> https://www.ietf.org/mailman/listinfo/ipfix
>=20


--Apple-Mail=_B0A9CFF1-6C68-4C9A-A4C0-01F065B3EF67
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=windows-1252

Hey =
Juergen,
It is not the responsibility of groups outside of =
the IETF to police IETF working groups
to ensure that they are =
doing the right thing. The IETF itself, has a responsibility to =
do
the right thing when it comes to publishing technical =
documents.

I am providing input to the WG that =
draft-ietf-ipfix-a9n-3 is not original work, the concepts
have =
been worked in the communications industry for a very long time, and =
there are open
public implementations of every concept in =
the draft.   I am also providing input to the WG
that =
draft-ietf-ipfix-a9n-3 appears to be using concepts, and examples =
that are curiously
specific to actual implementation and =
publications developed by Argus.

Based on the =
response from the authors to the mailing list, its clear that the =
authors
have not done any due diligence to ensure that their =
draft conforms to even the simplest of
ethics in technical =
publication.  Plagiarism is a very serious problem, and the =
authors
should know how to protect themselves from such a =
claim.

I am providing input to the WG that I =
believe the authors cannot defend themselves
from such a claim =
with their current draft, and that the WG should respond =
accordingly.

I would hope that the WG will use =
this input to improve their processes and products,
something =
that would benefit the entire flow =
community.

Carter



Carter Bullard
CEO/President
QoSient, =
LLC
150 E. 57th Street Suite =
12D
New York, New York =
10022

+1 212 588-9133 Phone
+1 212 588-9134 =
Fax






On Feb 28, 2012, at 4:25 AM, Juergen Quittek =
wrote:

Hi Carter,

You know the IPFIX WG for long and =
our process has always been open.
Aggregation (also referred to as =
"concentration") was always among
the requirements to take care of by =
the IPFIX WG, see, for example,
RFC 3917 from 2004.

The open =
IETF process allows anybody to support technical documents
with =
solutions, such as ones on IPFIX aggregation.  So far, no =
such
contribution has been made by argus developers or users. =
 This is a
pity, but nothing you can blame any active members of =
the IPFIX WG
for.  If you want to blame someone, then rather =
blame the argus
community including yourself.  You aware of the =
IPFIX WG and
contributions from you or argus users would have been =
highly
appreciated.

The IPFIX WG is and will always open for =
contributions from the
argus community.  If you think that a =
technical contributions from
argus or a reference to argus would =
improve any of our current
documents, then please contribute to them, =
as you had already done
in the past.  Please particularly do so =
if you think the way argus
solved technical problems is better than =
what has so far been
contributed to the IPFIX WG.


While =
your technical contributions will always be welcome, I ask
you in my =
role as WG co-chair to stop making harsh statements on
the mailing =
list, even though the main effect that you achieve
with these =
statements is discrediting yourself.  In particular
I refer to =
two statements you made:

1. You accuse authors of draft =
draft-ietf-ipfix-a9n of plagiarism.
Your main reason for this was =
that you stated "I had the same idea
before" and it's publicly =
available.  I haven't checked if the
ideas are exactly the same, =
but this is not the point.  It does
happen that two people =
independently have the same idea.
For accusing someone of plagiarism, =
more evidence is necessary,
at least if you want to be taken =
serious.

2. You claim that authors of draft-ietf-ipfix-a9n are =
lacking
expertise.  Indeed, there are leading experts among the =
authors
with high reputation and high expertise in the area of =
IP
flow monitoring.  Claiming they "don't have a clue" because =
they
don't know argus by heart is a statement that may be valid =
in
an argus-centric world, but not in the world of the IP =
flow
monitoring community.


I look forward to your =
technical contributions for improving the
Standards we are developing =
in the IPFIX WG.

    Juergen
 =
   WG co-chair


On 28.02.12 00:49, "Carter =
Bullard" <carter@qosient.com> =
wrote:

Hey Benoit,Well you should pay =
some attention.  You should know if =
there
is prior art before you =
start presenting descriptions of technology, =
and
you should give credit to =
that prior art.  Problem's come up when =
you
present work, and your =
descriptions look like the prior art's =
source
code, and your examples =
look like that prior arts program output. =
  Maybe
its just a =
coincidence.

Argus is free =
and open source software, and the concepts that you =
are
presenting in your draft =
were implemented in argus over 19 years ago, =
so
I don't think I'm too =
worried about IP.  Its just the arrogance of it =
all
that is a little bit of a =
concern.  IPFIX isn't doing the community =
any
favors if its only authors =
don't have a clue.

Carter

Carter =
Bullard
CEO/President
QoSient, LLC
150 =
E. 57th Street Suite 12D
New =
York, New York 10022

+1 212 588-9133 =
Phone
+1 212 588-9134 =
Fax





On Feb 27, =
2012, at 5:52 PM, Benoit Claise wrote:






   Hi =
Carter,

 =
  After trying to abstract the style of your email, which I =
don't
   appreciate, =
I'm not too sure how to read your email.
   Is this an IP claim? Or just "I've been doing =
this for years, so I
 =
  know better"?

   In =
all cases, that's a nice advertisement for your company... =
Maybe
   it was the =
point...

   On =
my side, I certainly don't get my ideas from your =
products!
   The =
last time I looked up your web site was at the time of =
RFC3955.
   In total =
in my live, I don't think I spend more than 1/2 h on =
your
   web =
site.

 =
  And I don't feel like replying to the details of this email, =
or even
   playing =
the little game of comparing features of your =
company/my
 =
  company.

 =
  Regards, Benoit.

Gentle =
people,
 =
    I'm generally pretty quiet when it comes to =
IPFIX and its
 =
      efforts.  But as the =
first
 =
    person to develop IP flow records in the 1980's, =
first to
 =
      present the idea to =
the
 =
    community in 1992, the first to provide open =
source flow
 =
      technology in =
1995,
 =
    and the author of the longest lived open source =
flow system,
 =
      argus; I feel =
that
 =
    I have to say something about the recent wave of =
IPFIX
 =
      drafts.


 =
    The drafts on flow aggregation describe =
functionality that
 =
      the Argus project =
started
 =
    over 20 years ago.  The ideas of key =
modification, conversion
 =
      of non-key =
attributes
 =
    to key members, aggregation operators, =
interval
 =
      distribution and the architecture =
for it,
 =
    were all developed in argus a long long time =
ago.
 =
       draft-ietf-ipfix-a9n is =
basically
 =
    describing the functionality =
of
 =
      argus's racluster(), rasplit(), and =
rabins() programs,
 =
    and every example given in the text of =
draft-ietf-ipfix-a9n
 =
      can be generated =
using
 =
    argus's rabins(), with only a few gyrations of =
its
 =
      command-line, =
today.


 =
    I personally would expect that if the IETF was =
going to
 =
      describe something that =
is
 =
    "Standards Track", that there would be dozen's =
of
 =
      implementations of this kind =
of
 =
    technology available, and that the WG is =
condensing years of
 =
      experience =
to
 =
    arrive at a "Standards Track", but, this is not =
the case.
 =
       There is only one =
current
 =
    implementation of the complete capabilities of =
the features
 =
      of =
draft-ietf-ipfix-a9n
 =
    that I am aware of, and that is in =
argus.


 =
    Taking just one of the technical descriptions in =
the
 =
      draft, "interval distribution", =
I
     am =
not aware of any description of this issue,
       or implementation of =
this type
 =
    of technology in the literature, outside of =
argus.  No Google
 =
      search results for =
"flow
 =
    interval distribution".   In Argus we =
call it flow splitting.
 =
       The first line from =
a
 =
    Google search for "argus flow splitting" =
return:







 =
            &n=
bsp;   Scholarly
=
 =
            &n=
bsp;       articles for argus flow =
splitting
<http://scholar.google.com/scholar?q=3Dargus+flow+=
splitting&hl=3Den&as_sdt=3D0&a
s_vis=3D1&oi=3Dscholart&sa=3DX&ei=3D-8NLT_6lKcnb=
0QHVs6z7DQ&ved=3D0CBoQgQMwAA>




 =
            &n=
bsp;   =8A
 =
            &n=
bsp;       and prediction of flow =
statistics from
 =
            &n=
bsp;       sampled packet =
=8A
<http://www.google.com/url?url=3Dhttp://scholar.google.com/schol=
ar_url%3Fhl%
3Den%26q%3Dhttp://dl.acm.org/citation.cfm%253Fid%253D637225%=
26sa%3DX%26sci
sig%3DAAGBfm1Qq9_hOFJINho1051rzZ6qOD5wuA%26oi%3Dscholarr&=
;rct=3Dj&sa=3DX&ei=3D-8N
LT_6lKcnb0QHVs6z7DQ&ved=3D0CBsQgAMoADAA&q=3Dargus+fl=
ow+splitting&usg=3DAFQjCNFuM
uC_b45uErbgoPHPab61egoZ3g> - Duffield =
-
 =
            &n=
bsp;       Cited by =
217








 =
    I'm not saying that Nick knows much about =
argus's support for
 =
      flow splitting, =
but
 =
    its still pretty scary that the first hit is =
from a paper
 =
      that is used in IPFIX =
documents.
 =
    One would have to assume that the IPFIX =
community should be
 =
      aware.


 =
    My problem is that most of =
 draft-ietf-ipfix-a9n is prior
       work that is not =
widely
 =
    implemented, some of the features are still =
unique to argus.
 =
        While IETF =
support
 =
    of technology is a good thing, descriptions of =
technology
 =
      without =
reference
 =
    is a difficult thing to interpret.  Is the =
IPFIX WG
 =
      describing what they think is =
new
 =
    technology? Does the IPFIX WG think that many =
companies have
 =
      implemented
     this type of technology, and =
now its time to standardize it ?
        Well, I'm not =
aware
 =
    of any implementation, open or closed, that does =
the complete
 =
      set of what =
the
 =
    draft is recommending, other than argus. =
 So I don't think
 =
      its new, nor =
widely
 =
    implemented.  I would say its a form of =
technology
 =
      plagiarism.


 =
    IPFIX is considering adding non-IP flows to =
their
 =
      definitions.  Argus is the only =
available
 =
    flow technology that has significant non-IP flow =
data models
 =
      and support.  argus-1.2 =
had
 =
    flow generation, transport, analytics and =
storage of non-IP
 =
      flows 20 years ago, with =
its
 =
    support for bi-directional ethernet, apple-talk =
and ARP
 =
      transaction tracking and =
reporting.
 =
    In the last 10 years, argus has added MPLS, =
VLAN, ISO
 =
      addresses, and Infiniband =
flow
 =
    models.  Not attributes, but true flow key =
elements.   This
 =
      work is =
non-trivial.


 =
    The concept that the WG would consider dropping =
the IP from
 =
      IPFIX and think that =
is
 =
    all that is needed, is really so completely =
wrong, that its
 =
      laughable, and a =
dis-service
 =
    to those that have done the hard work to =
bring
 =
      situational awareness and =
analytics
 =
    to non-IP traffic.   The same applies =
to bi-directional
 =
      flows, but that is another =
story.


 =
    I would love to think that IPFIX could focus =
back on flow
 =
      information =
exchange.
 =
    Multicast, non-template based connectionless =
transport
 =
      strategies, say over =
UDT
 =
    as an example, rather than getting into areas =
for which the
 =
      WG is unprepared =
to
     do =
even a reasonable job, without resorting to =
dubious
 =
      techniques.


 =
    Just a few comments, I hope that anyone finds it =
useful.






 =
            Ca=
rter







 =
          Carter =
Bullard
 =
          CEO/President<=
br>
 =
          QoSient, =
LLC
 =
          150 E. 57th =
Street Suite 12D
 =
          New York, =
New York 10022


 =
          +1 212 =
588-9133 Phone
 =
          +1 212 =
588-9134 Fax









 =
    _______________________________________________
IPFIX mailing =
list
IPFIX@ietf.orghttps=
://www.ietf.org/mailman/listinfo/ipfix











_______________________________________________
IPFIX mailing =
list
IPFIX@ietf.org
https://www.ietf.org/=
mailman/listinfo/ipfix

=

--Apple-Mail=_B0A9CFF1-6C68-4C9A-A4C0-01F065B3EF67--

--Apple-Mail=_141D9080-557F-4BA4-8DA8-2E96DFAF0561
Content-Disposition: attachment;
	filename=smime.p7s
Content-Type: application/pkcs7-signature;
	name=smime.p7s
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMRjCCBVAw
ggQ4oAMCAQICEE/C1XPaEv5Xc80XjVqbwwowDQYJKoZIhvcNAQEFBQAwgd0xCzAJBgNVBAYTAlVT
MRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y
azE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEg
KGMpMDkxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuVmVyaVNpZ24g
Q2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMzAeFw0xMTA0MTQwMDAwMDBaFw0x
MjA0MTMyMzU5NTlaMIIBEzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT
aWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9S
UEEgSW5jb3JwLiBieSBSZWYuLExJQUIuTFREKGMpOTgxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZh
bGlkYXRlZDEzMDEGA1UECxMqRGlnaXRhbCBJRCBDbGFzcyAxIC0gTmV0c2NhcGUgRnVsbCBTZXJ2
aWNlMRcwFQYDVQQDFA5DYXJ0ZXIgQnVsbGFyZDEhMB8GCSqGSIb3DQEJARYSY2FydGVyQHFvc2ll
bnQuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAnUsVMagrR+kSPj9tNNsMP6ZO
CRf4x70f3vT5OerV6rikEAz4XYJ+iv5Y6FiY5wjr2ez4BTrEuKwhAJN+aPSXHBW4cBZgB0J7mHwF
yJpY/vhhy2RrfugdCXjotFySXzevQHCfON4htlh+I3DYhN6LXmeBnnPtGz+J4mNZqdimZVlcdXqV
h0m7ysvdFkClht66vEvF+WObwLEpg3LIaFzTZBWpAiQ1FPIDJJd6uU//96grDvRy+D0oNjCkxmBp
bCkG0w1jaOuay6o62xRh7H41CxCRljzYjy3H4SwRYlYBwtqZuXg0YOI0OHdSuie6UyrUgmT+3S1U
FPiGz9yP9hninQIDAQABo4HSMIHPMAkGA1UdEwQCMAAwRAYDVR0gBD0wOzA5BgtghkgBhvhFAQcX
ATAqMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhMAsGA1UdDwQEAwIF
oDAdBgNVHSUEFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIwUAYDVR0fBEkwRzBFoEOgQYY/aHR0cDov
L2luZGMxZGlnaXRhbGlkLWczLWNybC52ZXJpc2lnbi5jb20vSW5kQzFEaWdpdGFsSUQtRzMuY3Js
MA0GCSqGSIb3DQEBBQUAA4IBAQBSg1+LGDk7EKu1hYCrpHEZVHY3I+850erL2DxLtfgzldWZPLYr
NpVa8wH5XTDhaFNLQgWwLMGfs8sJPkqXm2TfZfG7BkJWLtubW3Jw5jZ//Eygbae2IOU0bm1tAaG2
uoreBROJ5PU1ykK8aTnbNZxN772otsdHQ54gXd2wpPUoDoT740WzsdTeSI0ZXU+3J7RPbC0VHNfI
E88GgkTYBD5Xk3Ro+BSCBOh4XAA1ypHBZh2OX8C4syhPp6yfGWvwvqJ+oV5lkbAcO6FkeBlvb/Fi
XPa35ynGIIpntzpqOvr+0XJs8xq7hE8KU/QUNE6fa0gZyjxBVcbw89mv4lQx4FSOMIIG7jCCBdag
AwIBAgIQcRVmBUrkkSFN6bxE+azT3DANBgkqhkiG9w0BAQUFADCByjELMAkGA1UEBhMCVVMxFzAV
BgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTow
OAYDVQQLEzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVkIHVzZSBvbmx5
MUUwQwYDVQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRpZmljYXRpb24g
QXV0aG9yaXR5IC0gRzMwHhcNMDkwNTAxMDAwMDAwWhcNMTkwNDMwMjM1OTU5WjCB3TELMAkGA1UE
BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBO
ZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29t
L3JwYSAoYykwOTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJp
U2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEczMIIBIjANBgkqhkiG9w0B
AQEFAAOCAQ8AMIIBCgKCAQEA7cRH3yooHXwGa7vXITLJbBOP6bGNQU4099oL42r6ZYggCxET6Zvg
SU6Lb9UB0F8NR5GKWkx0Pj/GkQm7TDSejW6hglFi92l2WJYHr54UGAdPWr2f0jGyVBlzRmoZQhHs
EnMhjfXcMM3l2VYKMcU2bSkUl70t2olHGYjYSwQ967Y8Zx50ABMN0Ibak2f4MwOuGjxraXj2wCyO
4YM/d/mZ//6fUlrCtIcK2GypR8FUKWVDPkrAlh/Brfd3r2yxBF6+wbaULZeQLSfSux7pg2qE9sSy
riMGZSalJ1grByK0b6ZiSBp38tVQJ5op05b7KPW6JHZi44xZ6/tu1ULEvkHH9QIDAQABo4ICuTCC
ArUwNAYIKwYBBQUHAQEEKDAmMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC52ZXJpc2lnbi5jb20w
EgYDVR0TAQH/BAgwBgEB/wIBADBwBgNVHSAEaTBnMGUGC2CGSAGG+EUBBxcBMFYwKAYIKwYBBQUH
AgEWHGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9jcHMwKgYIKwYBBQUHAgIwHhocaHR0cHM6Ly93
d3cudmVyaXNpZ24uY29tL3JwYTA0BgNVHR8ELTArMCmgJ6AlhiNodHRwOi8vY3JsLnZlcmlzaWdu
LmNvbS9wY2ExLWczLmNybDAOBgNVHQ8BAf8EBAMCAQYwbgYIKwYBBQUHAQwEYjBgoV6gXDBaMFgw
VhYJaW1hZ2UvZ2lmMCEwHzAHBgUrDgMCGgQUS2u5KJYGDLvQUjibKaxLB4shBRgwJhYkaHR0cDov
L2xvZ28udmVyaXNpZ24uY29tL3ZzbG9nbzEuZ2lmMC4GA1UdEQQnMCWkIzAhMR8wHQYDVQQDExZQ
cml2YXRlTGFiZWw0LTIwNDgtMTE4MB0GA1UdDgQWBBR5R2EIQf04BKJL57XM9UP2SSsR+DCB8QYD
VR0jBIHpMIHmoYHQpIHNMIHKMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4x
HzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOjA4BgNVBAsTMShjKSAxOTk5IFZlcmlT
aWduLCBJbmMuIC0gRm9yIGF1dGhvcml6ZWQgdXNlIG9ubHkxRTBDBgNVBAMTPFZlcmlTaWduIENs
YXNzIDEgUHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgLSBHM4IRAItbdVaE
VIULAM+vOEjOsaQwDQYJKoZIhvcNAQEFBQADggEBADlNz0GZgbWpBbVSOOk5hIls5DSoWufYbAlM
JBq6WaSHO3Mh8ZOBz79oY1pn/jWFK6HDXaNKwjoZ3TDWzE3v8dKBl8pUWkO/N4t6jhmND0OojPKv
YLMVirOVnDzgnrMnmKQ1chfl/Cpdh9OKDcLRRSr4wPSsKpM61a4ScAjr+zvid+zoK2Q1ds262uDR
yxTWcVibvtU+fbbZ6CTFJGZMXZEfdrMXPn8NxiGJL7M3uKH/XLJtSd5lUkL7DojS7Uodv0vj+Mxy
+kgOZY5JyNb4mZg7t5Q+MXEGh/psWVMu198r7V9jAKwV7QO4VRaMxmgD5yKocwuxvKDaUljdCg5/
wYIxggSLMIIEhwIBATCB8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMu
MR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2Ug
YXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwOTEeMBwGA1UECxMVUGVyc29uYSBO
b3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2Ny
aWJlciBDQSAtIEczAhBPwtVz2hL+V3PNF41am8MKMAkGBSsOAwIaBQCgggJtMBgGCSqGSIb3DQEJ
AzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEyMDIyODE1MTMwNVowIwYJKoZIhvcNAQkE
MRYEFDDHa6Zb69GtAlvBghUzafbyz0Z4MIIBAwYJKwYBBAGCNxAEMYH1MIHyMIHdMQswCQYDVQQG
EwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5l
dHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20v
cnBhIChjKTA5MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMTLlZlcmlT
aWduIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzMCEE/C1XPaEv5Xc80XjVqb
wwowggEFBgsqhkiG9w0BCRACCzGB9aCB8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlT
aWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJt
cyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwOTEeMBwGA1UECxMV
UGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1
YWwgU3Vic2NyaWJlciBDQSAtIEczAhBPwtVz2hL+V3PNF41am8MKMA0GCSqGSIb3DQEBAQUABIIB
AIHLsWuhGBUQbQ/EXR6lDub0njQKHgIOOeRmafOO0Cj0P885z4tLcTZWdhb9xmsgeCtbdyTXvLKU
feTJeyCLhIpuMRY8+bKHnUf5XG19cAqr+z/sIO5A9zQCck6NZe6tzs/kHXN1nEFokfImfAdcEosE
fQZXqu/v2OUTiasnS952tedWUWj3tkUmiKt3Z0luLdyxXcEDK4jjNEL2xXLP3ypqRSOXgYyGENg+
CIVT/6u6lMFvMOIFp/Im+h/KaejsiU1fxKgrTsfHsagLyPEpq9dgiXlhQNp+KQJzYDYPtqCbfLJZ
eH5nU7Hpdw6PR4PGICySysZWVfoxHafElZpUyI4AAAAAAAA=

--Apple-Mail=_141D9080-557F-4BA4-8DA8-2E96DFAF0561--

From Quittek@neclab.eu  Tue Feb 28 08:32:46 2012
Return-Path: 
X-Original-To: ipfix@ietfa.amsl.com
Delivered-To: ipfix@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D1E321F869A for ; Tue, 28 Feb 2012 08:32:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.174
X-Spam-Level: 
X-Spam-Status: No, score=-101.174 tagged_above=-999 required=5 tests=[AWL=-1.171, BAYES_00=-2.599, J_CHICKENPOX_64=0.6, J_CHICKENPOX_72=0.6, MIME_QP_LONG_LINE=1.396, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ev1u31L69sTX for ; Tue, 28 Feb 2012 08:32:45 -0800 (PST)
Received: from mailer1.neclab.eu (mailer1.neclab.eu [195.37.70.40]) by ietfa.amsl.com (Postfix) with ESMTP id 77B5021F8682 for ; Tue, 28 Feb 2012 08:32:44 -0800 (PST)
Received: from localhost (localhost.localdomain [127.0.0.1]) by mailer1.neclab.eu (Postfix) with ESMTP id 6B009280001CE; Tue, 28 Feb 2012 17:32:43 +0100 (CET)
X-Virus-Scanned: Amavisd on Debian GNU/Linux (netlab.nec.de)
Received: from mailer1.neclab.eu ([127.0.0.1]) by localhost (atlas1.office.hd [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MHUKLxAx4uME; Tue, 28 Feb 2012 17:32:42 +0100 (CET)
Received: from METHONE.office.hd (Methone.office.hd [192.168.24.54]) by mailer1.neclab.eu (Postfix) with ESMTP id AD98E28000084; Tue, 28 Feb 2012 17:32:22 +0100 (CET)
Received: from DAPHNIS.office.hd ([169.254.2.41]) by METHONE.office.hd ([192.168.24.54]) with mapi id 14.01.0323.003; Tue, 28 Feb 2012 17:32:18 +0100
From: Juergen Quittek 
To: Carter Bullard 
Thread-Topic: [IPFIX] recent ipfix drafts and argus
Thread-Index: AQHM9jaL1xt2eOCsw0GkdQp9rJLpGg==
Date: Tue, 28 Feb 2012 16:32:22 +0000
Message-ID: 
In-Reply-To: 
Accept-Language: de-DE, en-US
Content-Language: de-DE
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.14.0.111121
x-originating-ip: [10.1.2.219]
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="B_3413295140_25025474"
MIME-Version: 1.0
Cc: Argus , IETF IPFIX Working Group 
Subject: Re: [IPFIX] recent ipfix drafts and argus
X-BeenThere: ipfix@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IPFIX WG discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 28 Feb 2012 16:32:46 -0000

--B_3413295140_25025474
Content-type: text/plain;
	charset="ISO-8859-2"
Content-transfer-encoding: quoted-printable

Hi Carter,

It looks like there is a misconception on your side concerning IETF
publications.  You are confusing them with scientific conference and
journal publications.  The target of the IETF is not serving the community
with new unpublished ideas, but with standards specifications.  Whether
the technologies used for standards have been published before is not of
high relevance.  But of high relevance is if they are suited as a
standard.  The IETF has even a mechanism where people can claim IPR
related to IETF documents.  This is completely independent from the
authorship.

According to the rules of the IETF, authors of WG documents are assigned
by the WG chairs.  Typically these are the same authors that worked on an
individual draft on the same topic before, but not necessarily.  And there
is no rule at all at the IETF stating that a person can only be an author,
it he or she had the original idea described in the text.  If an RFC is
revised then often the original authors are removed and the ones making
the revision are added.  There is not concern about 'originality'.

All your complaints in this direction are pointless.

However, what the WG may consider is adding a reference to argus to
draft-ietf-ipfix-a9n.  You are welcome to provide text on which concepts
and methods are already well understood and tested from experiences with
argus.

    Juergen


On 28.02.12 16:13, "Carter Bullard"  wrote:

>Hey Juergen,It is not the responsibility of groups outside of the IETF to
>police IETF working groups
>to ensure that they are doing the right thing. The IETF itself, has a
>responsibility to do
>the right thing when it comes to publishing technical documents.
>
>I am providing input to the WG that draft-ietf-ipfix-a9n-3 is not
>original work, the concepts
>have been worked in the communications industry for a very long time, and
>there are open
>public implementations of every concept in the draft.   I am also
>providing input to the WG
>that draft-ietf-ipfix-a9n-3 appears to be using concepts, and examples
>that are curiously
>specific to actual implementation and publications developed by Argus.
>
>Based on the response from the authors to the mailing list, its clear
>that the authors
>have not done any due diligence to ensure that their draft conforms to
>even the simplest of
>ethics in technical publication.  Plagiarism is a very serious problem,
>and the authors
>should know how to protect themselves from such a claim.
>
>I am providing input to the WG that I believe the authors cannot defend
>themselves
>from such a claim with their current draft, and that the WG should
>respond accordingly.
>
>I would hope that the WG will use this input to improve their processes
>and products,
>something that would benefit the entire flow community.
>
>Carter
>
>Carter Bullard
>CEO/President
>QoSient, LLC
>150 E. 57th Street Suite 12D
>New York, New York 10022
>
>+1 212 588-9133 Phone
>+1 212 588-9134 Fax
>
>
>
>
>
>On Feb 28, 2012, at 4:25 AM, Juergen Quittek wrote:
>
>
>Hi Carter,
>
>You know the IPFIX WG for long and our process has always been open.
>Aggregation (also referred to as "concentration") was always among
>the requirements to take care of by the IPFIX WG, see, for example,
>RFC 3917 from 2004.
>
>The open IETF process allows anybody to support technical documents
>with solutions, such as ones on IPFIX aggregation.  So far, no such
>contribution has been made by argus developers or users.  This is a
>pity, but nothing you can blame any active members of the IPFIX WG
>for.  If you want to blame someone, then rather blame the argus
>community including yourself.  You aware of the IPFIX WG and
>contributions from you or argus users would have been highly
>appreciated.
>
>The IPFIX WG is and will always open for contributions from the
>argus community.  If you think that a technical contributions from
>argus or a reference to argus would improve any of our current
>documents, then please contribute to them, as you had already done
>in the past.  Please particularly do so if you think the way argus
>solved technical problems is better than what has so far been
>contributed to the IPFIX WG.
>
>
>While your technical contributions will always be welcome, I ask
>you in my role as WG co-chair to stop making harsh statements on
>the mailing list, even though the main effect that you achieve
>with these statements is discrediting yourself.  In particular
>I refer to two statements you made:
>
>1. You accuse authors of draft draft-ietf-ipfix-a9n of plagiarism.
>Your main reason for this was that you stated "I had the same idea
>before" and it's publicly available.  I haven't checked if the
>ideas are exactly the same, but this is not the point.  It does
>happen that two people independently have the same idea.
>For accusing someone of plagiarism, more evidence is necessary,
>at least if you want to be taken serious.
>
>2. You claim that authors of draft-ietf-ipfix-a9n are lacking
>expertise.  Indeed, there are leading experts among the authors
>with high reputation and high expertise in the area of IP
>flow monitoring.  Claiming they "don't have a clue" because they
>don't know argus by heart is a statement that may be valid in
>an argus-centric world, but not in the world of the IP flow
>monitoring community.
>
>
>I look forward to your technical contributions for improving the
>Standards we are developing in the IPFIX WG.
>
>    Juergen
>    WG co-chair
>
>
>On 28.02.12 00:49, "Carter Bullard"  wrote:
>
>
>Hey Benoit,Well you should pay some attention.  You should know if there
>
>is prior art before you start presenting descriptions of technology, and
>
>you should give credit to that prior art.  Problem's come up when you
>
>present work, and your descriptions look like the prior art's source
>
>code, and your examples look like that prior arts program output.   Maybe
>
>its just a coincidence.
>
>
>
>Argus is free and open source software, and the concepts that you are
>
>presenting in your draft were implemented in argus over 19 years ago, so
>
>I don't think I'm too worried about IP.  Its just the arrogance of it all
>
>that is a little bit of a concern.  IPFIX isn't doing the community any
>
>favors if its only authors don't have a clue.
>
>
>
>Carter
>
>
>
>Carter Bullard
>
>CEO/President
>
>QoSient, LLC
>
>150 E. 57th Street Suite 12D
>
>New York, New York 10022
>
>
>
>+1 212 588-9133 Phone
>
>+1 212 588-9134 Fax
>
>
>
>
>
>
>
>
>
>
>
>On Feb 27, 2012, at 5:52 PM, Benoit Claise wrote:
>
>
>
>
>
>
>
>
>
>
>
>
>
>   Hi Carter,
>
>
>
>   After trying to abstract the style of your email, which I don't
>
>   appreciate, I'm not too sure how to read your email.
>
>   Is this an IP claim? Or just "I've been doing this for years, so I
>
>   know better"?
>
>
>
>   In all cases, that's a nice advertisement for your company... Maybe
>
>   it was the point...
>
>
>
>   On my side, I certainly don't get my ideas from your products!
>
>   The last time I looked up your web site was at the time of RFC3955.
>
>   In total in my live, I don't think I spend more than 1/2 h on your
>
>   web site.
>
>
>
>   And I don't feel like replying to the details of this email, or even
>
>   playing the little game of comparing features of your company/my
>
>   company.
>
>
>
>   Regards, Benoit.
>
>
>
>Gentle people,
>
>     I'm generally pretty quiet when it comes to IPFIX and its
>
>       efforts.  But as the first
>
>     person to develop IP flow records in the 1980's, first to
>
>       present the idea to the
>
>     community in 1992, the first to provide open source flow
>
>       technology in 1995,
>
>     and the author of the longest lived open source flow system,
>
>       argus; I feel that
>
>     I have to say something about the recent wave of IPFIX
>
>       drafts.
>
>
>
>
>
>     The drafts on flow aggregation describe functionality that
>
>       the Argus project started
>
>     over 20 years ago.  The ideas of key modification, conversion
>
>       of non-key attributes
>
>     to key members, aggregation operators, interval
>
>       distribution and the architecture for it,
>
>     were all developed in argus a long long time ago.
>
>        draft-ietf-ipfix-a9n is basically
>
>     describing the functionality of
>
>       argus's racluster(), rasplit(), and rabins() programs,
>
>     and every example given in the text of draft-ietf-ipfix-a9n
>
>       can be generated using
>
>     argus's rabins(), with only a few gyrations of its
>
>       command-line, today.
>
>
>
>
>
>     I personally would expect that if the IETF was going to
>
>       describe something that is
>
>     "Standards Track", that there would be dozen's of
>
>       implementations of this kind of
>
>     technology available, and that the WG is condensing years of
>
>       experience to
>
>     arrive at a "Standards Track", but, this is not the case.
>
>        There is only one current
>
>     implementation of the complete capabilities of the features
>
>       of draft-ietf-ipfix-a9n
>
>     that I am aware of, and that is in argus.
>
>
>
>
>
>     Taking just one of the technical descriptions in the
>
>       draft, "interval distribution", I
>
>     am not aware of any description of this issue,
>
>       or implementation of this type
>
>     of technology in the literature, outside of argus.  No Google
>
>       search results for "flow
>
>     interval distribution".   In Argus we call it flow splitting.
>
>        The first line from a
>
>     Google search for "argus flow splitting" return:
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>                 Scholarly
>
>                     articles for argus flow splitting
>
>
>s_vis=3D1&oi=3Dscholart&sa=3DX&ei=3D-8NLT_6lKcnb0QHVs6z7DQ&ved=3D0CBoQgQMwAA>
>
>
>
>
>
>
>
>
>
>                 =A9
>
>                     and prediction of flow statistics from
>
>                     sampled packet =A9
>
>
>3Den%26q%3Dhttp://dl.acm.org/citation.cfm%253Fid%253D637225%26sa%3DX%26sci
>
>sig%3DAAGBfm1Qq9_hOFJINho1051rzZ6qOD5wuA%26oi%3Dscholarr&rct=3Dj&sa=3DX&ei=3D-8N
>
>LT_6lKcnb0QHVs6z7DQ&ved=3D0CBsQgAMoADAA&q=3Dargus+flow+splitting&usg=3DAFQjCNFuM
>
>uC_b45uErbgoPHPab61egoZ3g> - Duffield -
>
>                     Cited by 217
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>     I'm not saying that Nick knows much about argus's support for
>
>       flow splitting, but
>
>     its still pretty scary that the first hit is from a paper
>
>       that is used in IPFIX documents.
>
>     One would have to assume that the IPFIX community should be
>
>       aware.
>
>
>
>
>
>     My problem is that most of  draft-ietf-ipfix-a9n is prior
>
>       work that is not widely
>
>     implemented, some of the features are still unique to argus.
>
>         While IETF support
>
>     of technology is a good thing, descriptions of technology
>
>       without reference
>
>     is a difficult thing to interpret.  Is the IPFIX WG
>
>       describing what they think is new
>
>     technology? Does the IPFIX WG think that many companies have
>
>       implemented
>
>     this type of technology, and now its time to standardize it ?
>
>        Well, I'm not aware
>
>     of any implementation, open or closed, that does the complete
>
>       set of what the
>
>     draft is recommending, other than argus.  So I don't think
>
>       its new, nor widely
>
>     implemented.  I would say its a form of technology
>
>       plagiarism.
>
>
>
>
>
>     IPFIX is considering adding non-IP flows to their
>
>       definitions.  Argus is the only available
>
>     flow technology that has significant non-IP flow data models
>
>       and support.  argus-1.2 had
>
>     flow generation, transport, analytics and storage of non-IP
>
>       flows 20 years ago, with its
>
>     support for bi-directional ethernet, apple-talk and ARP
>
>       transaction tracking and reporting.
>
>     In the last 10 years, argus has added MPLS, VLAN, ISO
>
>       addresses, and Infiniband flow
>
>     models.  Not attributes, but true flow key elements.   This
>
>       work is non-trivial.
>
>
>
>
>
>     The concept that the WG would consider dropping the IP from
>
>       IPFIX and think that is
>
>     all that is needed, is really so completely wrong, that its
>
>       laughable, and a dis-service
>
>     to those that have done the hard work to bring
>
>       situational awareness and analytics
>
>     to non-IP traffic.   The same applies to bi-directional
>
>       flows, but that is another story.
>
>
>
>
>
>     I would love to think that IPFIX could focus back on flow
>
>       information exchange.
>
>     Multicast, non-template based connectionless transport
>
>       strategies, say over UDT
>
>     as an example, rather than getting into areas for which the
>
>       WG is unprepared to
>
>     do even a reasonable job, without resorting to dubious
>
>       techniques.
>
>
>
>
>
>     Just a few comments, I hope that anyone finds it useful.
>
>
>
>
>
>
>
>
>
>
>
>
>
>             Carter
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>           Carter Bullard
>
>           CEO/President
>
>           QoSient, LLC
>
>           150 E. 57th Street Suite 12D
>
>           New York, New York 10022
>
>
>
>
>
>           +1 212 588-9133 Phone
>
>           +1 212 588-9134 Fax
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>     _______________________________________________
>
>IPFIX mailing list
>
>IPFIX@ietf.orghttps://www.ietf.org/mailman/listinfo/ipfix
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>_______________________________________________
>
>IPFIX mailing list
>
>IPFIX@ietf.org
>
>https://www.ietf.org/mailman/listinfo/ipfix
>
>
>
>
>
>
>
>

--B_3413295140_25025474
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"

MIIUigYJKoZIhvcNAQcCoIIUezCCFHcCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC
EjIwggUzMIIEG6ADAgECAgQP7R53MA0GCSqGSIb3DQEBBQUAMIGQMQswCQYDVQQGEwJERTEY
MBYGA1UEChMPTkVDIEV1cm9wZSBMdGQuMSAwHgYDVQQLExdORUMgTGFib3JhdG9yaWVzIEV1
cm9wZTESMBAGA1UEAxMJTkVDTEFCLUNBMTEwLwYJKoZIhvcNAQkBFiJ6ZXJ0aWZpemllcnVu
Z3NzdGVsbGVAbncubmVjbGFiLmV1MB4XDTEwMDQyMDEyNDExMloXDTEzMDQxOTEyNDExMlow
YzELMAkGA1UEBhMCREUxGDAWBgNVBAoTD05FQyBFdXJvcGUgTHRkLjEgMB4GA1UECxMXTkVD
IExhYm9yYXRvcmllcyBFdXJvcGUxGDAWBgNVBAMTD0p1ZXJnZW4gUXVpdHRlazCCASIwDQYJ
KoZIhvcNAQEBBQADggEPADCCAQoCggEBANga4Hf5iSjDiva8/BTlatnXFlOWPfqZvY7AU6bt
CUKFiaGwytFar7XCwRggHcCeodYaMZoDRSEGY+bRUDvayjNvFTkhL19Fmzxg4MPmQA92tcIb
/+IylZD5YkVkw88/6zb6k+T+o875LlLAR79f8gvloaPMbxiB8KwQtdlGB9OiN1k3+7NiESpW
myT8WWrWw4F7qc0WLXaWuqv6/3vRo+jJSxyOwefEnzrRojCePJ2ZD4mgPMQvMHPqodDhTvIB
BupYoAtW53024WnL/PHH34pQ0Zmclz8u/YocnfMEYoyLDVuJKnQowDF75LVbnKmpXfCscKeb
SndFpSANP2TiI2cCAwEAAaOCAb8wggG7MAkGA1UdEwQCMAAwCwYDVR0PBAQDAgXgMCkGA1Ud
JQQiMCAGCCsGAQUFBwMCBggrBgEFBQcDBAYKKwYBBAGCNxQCAjAdBgNVHQ4EFgQU9WUPxjFB
AtJOXxJ7agqXozHDy9gwHwYDVR0jBBgwFoAUTxyHeh3gL5n2vhWq0TWdDkrmujYwHAYDVR0R
BBUwE4ERUXVpdHRla0BuZWNsYWIuZXUwfQYDVR0fBHYwdDA4oDagNIYyaHR0cDovL2NkcDEu
cGNhLmRmbi5kZS9uZWNsYWItY2EvcHViL2NybC9jYWNybC5jcmwwOKA2oDSGMmh0dHA6Ly9j
ZHAyLnBjYS5kZm4uZGUvbmVjbGFiLWNhL3B1Yi9jcmwvY2FjcmwuY3JsMIGYBggrBgEFBQcB
AQSBizCBiDBCBggrBgEFBQcwAoY2aHR0cDovL2NkcDEucGNhLmRmbi5kZS9uZWNsYWItY2Ev
cHViL2NhY2VydC9jYWNlcnQuY3J0MEIGCCsGAQUFBzAChjZodHRwOi8vY2RwMi5wY2EuZGZu
LmRlL25lY2xhYi1jYS9wdWIvY2FjZXJ0L2NhY2VydC5jcnQwDQYJKoZIhvcNAQEFBQADggEB
AH9VRaZ978LNoc+eM/2k/OQafNJl4UjKLjiEnH8FCuqnuNXZMAOdcfnMrRKK1bl+FhCy3sjg
gsuP4Nam2oSy7RDYWYjLY/MKMPO/MD/PpNSe6gox4948wfjWGmj4Uz3gqgDovQEC2H03jcPX
etJqBTipqmfnvMFqozoN5zjiEzJuuLpLMYNPM+E+4pQnLtRAhN94C1e9C7oP66b7as6OgVVC
CplE5llnoKM5ngtAFL5G3ygm/rZtptdmaNgRO6jDX1w9AOrsmSPGp+S+YRNonKGEqTolJpul
EJB7rMdAUimsUp/qdzvWrhIZ6A3fgzHwFhrIHqVBlDLmu7cQHu/QMUEwggUvMIIEF6ADAgEC
AgQNIQpHMA0GCSqGSIb3DQEBBQUAMFoxCzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpERk4tVmVy
ZWluMRAwDgYDVQQLEwdERk4tUEtJMSQwIgYDVQQDExtERk4tVmVyZWluIFBDQSBHbG9iYWwg
LSBHMDEwHhcNMDgxMDI0MDg1MjA4WhcNMTkwNjMwMDAwMDAwWjCBkDELMAkGA1UEBhMCREUx
GDAWBgNVBAoTD05FQyBFdXJvcGUgTHRkLjEgMB4GA1UECxMXTkVDIExhYm9yYXRvcmllcyBF
dXJvcGUxEjAQBgNVBAMTCU5FQ0xBQi1DQTExMC8GCSqGSIb3DQEJARYiemVydGlmaXppZXJ1
bmdzc3RlbGxlQG53Lm5lY2xhYi5ldTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEB
AJ7yFbG1EaoyDnG5367mJEXHljmacrzNnm52KW3dXD/s3Vpuskex0jvaaTntWWRSGrAK6kKX
nTxBb3J3EhveBUbltzQ+K0XKtPJm6VE5qVpl33WJSaUHs27Dhwlke+DV6BBGyukz2SDBaSa+
nc0AwMZ0XO1DoDuiUNVeNmd/QT4SGzyFs+uLfLL2n8WzkZsbpSZ+xecwyw3EdQBBsp/i/W+u
OQBsGqaCjYe3EkBU6nW+pBsj0Iy1n7b9PXb5gQynrK3Mi2V7g1idSzHos0o1BMoHUrMzVw94
Hj4CWlWmQ0t6Pdt1uYAMjwk0saQBY/Fyfv+wKeYycGIYyYCfJIRUeyUCAwEAAaOCAcQwggHA
MBIGA1UdEwEB/wQIMAYBAf8CAQEwCwYDVR0PBAQDAgEGMB0GA1UdDgQWBBRPHId6HeAvmfa+
FarRNZ0OSua6NjAfBgNVHSMEGDAWgBRJt8bP6D0ff+pEexMp9/EKcD7eZDAtBgNVHREEJjAk
gSJ6ZXJ0aWZpemllcnVuZ3NzdGVsbGVAbncubmVjbGFiLmV1MIGIBgNVHR8EgYAwfjA9oDug
OYY3aHR0cDovL2NkcDEucGNhLmRmbi5kZS9nbG9iYWwtcm9vdC1jYS9wdWIvY3JsL2NhY3Js
LmNybDA9oDugOYY3aHR0cDovL2NkcDIucGNhLmRmbi5kZS9nbG9iYWwtcm9vdC1jYS9wdWIv
Y3JsL2NhY3JsLmNybDCBogYIKwYBBQUHAQEEgZUwgZIwRwYIKwYBBQUHMAKGO2h0dHA6Ly9j
ZHAxLnBjYS5kZm4uZGUvZ2xvYmFsLXJvb3QtY2EvcHViL2NhY2VydC9jYWNlcnQuY3J0MEcG
CCsGAQUFBzAChjtodHRwOi8vY2RwMi5wY2EuZGZuLmRlL2dsb2JhbC1yb290LWNhL3B1Yi9j
YWNlcnQvY2FjZXJ0LmNydDANBgkqhkiG9w0BAQUFAAOCAQEAbDEPnQ9JpouPHYA1OEekP3l3
GNM0HBzadVbtbN5MDtFmoVgdLYqlQaHb30wFhuOMbsNCOzV0k8EOvBVOT9BiEJ70RWclSZQ4
60jZS2MY6n5oG/ilZuu6N/N3GSLg2pBBNH9vZFCyBJ9n4Px7A4gQF07G+CNfV2jdE1yyPjzI
VPhg6bBgia8nXroBFe6oteavMspo0gLGIJ63NsCbl6ckPa96grT+mnnQD0h6jk/IGtXS09mE
WRbN7zZu0x0q+SScpljG36Q+jnG0U5zQI0jAx8CcYEQQH5QOlsw1Zu35OI4lsi7ycFkzJNfb
fEC4ihuw9J2L43BFGMojkhPkhVExHTCCBCEwggMJoAMCAQICAgDHMA0GCSqGSIb3DQEBBQUA
MHExCzAJBgNVBAYTAkRFMRwwGgYDVQQKExNEZXV0c2NoZSBUZWxla29tIEFHMR8wHQYDVQQL
ExZULVRlbGVTZWMgVHJ1c3QgQ2VudGVyMSMwIQYDVQQDExpEZXV0c2NoZSBUZWxla29tIFJv
b3QgQ0EgMjAeFw0wNjEyMTkxMDI5MDBaFw0xOTA2MzAyMzU5MDBaMFoxCzAJBgNVBAYTAkRF
MRMwEQYDVQQKEwpERk4tVmVyZWluMRAwDgYDVQQLEwdERk4tUEtJMSQwIgYDVQQDExtERk4t
VmVyZWluIFBDQSBHbG9iYWwgLSBHMDEwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB
AQDpm8NnhfkNrvWNVMOWUDU9YuluTO2U1wBblSJ01CDrNI/W7MAxBAuZgeKmFNJSoCgjhIt0
iQReW+DieMF4yxbLKDU5ey2QRdDtoAB6fL9KDhsAw4bpXCsxEXsM84IkQ4wcOItqaACa7txP
eKvSxhObdq3u3ibo7wGvdA/BCaL2a869080UME/15eOkyGKbghoDJzANAmVgTe3RCSMqljVY
J9N2xnG2kB3E7f81hn1vM7PbD8URwoqDoZRdQWvY0hD1TP3KUazZve+Sg7va64sWVlZDz+HV
Ez2mHycwzUlU28kTNJpxdcVs6qcLmPkhnSevPqM5OUhqjK3JmfvDEvK9AgMBAAGjgdkwgdYw
cAYDVR0fBGkwZzBloGOgYYZfaHR0cDovL3BraS50ZWxlc2VjLmRlL2NnaS1iaW4vc2Vydmlj
ZS9hZl9Eb3dubG9hZEFSTC5jcmw/LWNybF9mb3JtYXQ9WF81MDkmLWlzc3Vlcj1EVF9ST09U
X0NBXzIwHQYDVR0OBBYEFEm3xs/oPR9/6kR7Eyn38QpwPt5kMB8GA1UdIwQYMBaAFDHDeRu6
9VPXF+CJei0XbAqzK50zMA4GA1UdDwEB/wQEAwIBBjASBgNVHRMBAf8ECDAGAQH/AgECMA0G
CSqGSIb3DQEBBQUAA4IBAQA74Vp3wEgX3KkY7IGvWonwvSiSpspZGBJw7Cjy565/lizn8l0Z
MfYTK3S9vYCyufdnyTmieTvhERHua3iRM347XyYndVNljjNj7s9zw7CSI0khUHUjoR8Y4pSF
PT8z6XcgjaK95qGFKUD2P3MyWA0Ja6bahWzAP7uNZmRWJE6uDT8yNQFb6YyC2XJZT7GGhfF0
hVblw/hc843uR7NTBXDn5U2KaYMo4RMJhp5eyOpYHgwf+aTUWgRo/Sg+iwK2WLX2oSw3VwBn
qyNojWOl75lrXP1LVvarQIc01BGSbOyHxQoLBzNytG8MHVQs2FHHzL8w00Ny8TK/jM5JY6gA
9/IcMIIDnzCCAoegAwIBAgIBJjANBgkqhkiG9w0BAQUFADBxMQswCQYDVQQGEwJERTEcMBoG
A1UEChMTRGV1dHNjaGUgVGVsZWtvbSBBRzEfMB0GA1UECxMWVC1UZWxlU2VjIFRydXN0IENl
bnRlcjEjMCEGA1UEAxMaRGV1dHNjaGUgVGVsZWtvbSBSb290IENBIDIwHhcNOTkwNzA5MTIx
MTAwWhcNMTkwNzA5MjM1OTAwWjBxMQswCQYDVQQGEwJERTEcMBoGA1UEChMTRGV1dHNjaGUg
VGVsZWtvbSBBRzEfMB0GA1UECxMWVC1UZWxlU2VjIFRydXN0IENlbnRlcjEjMCEGA1UEAxMa
RGV1dHNjaGUgVGVsZWtvbSBSb290IENBIDIwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEK
AoIBAQCrC6M14IspFLEUha88EOQ5bzVdSq7d6mGNlUn0b2SjGmBmpKlAIoTZ1KXleJMOaAGt
uU1cOs7TuKhCQN/Po7qCWWqSG6wcmtoIKyUn+WkjR/Hg6yx6m/UTAtB+NHzCnjwAWav12gz1
MjwrrFDa1sPeg5TKqAyZMg4ISFZbavva4VhYAUlfckE8FQYBjl2tqriTtM2e66foai1SNNs6
71x1Udrb8zH57nGYMsRUFUQM+ZtV7a3fGAigo4aKSe5TBY8ZTNXeWHmb0mocQqvF1afPaA+W
5OFhmHZhyJF81j4A4pFQh+GdCuatl9Idxjp9y7zaAzTVjlsB9WoHtxa2bkp/AgMBAAGjQjBA
MB0GA1UdDgQWBBQxw3kbuvVT1xfgiXotF2wKsyudMzAPBgNVHRMECDAGAQH/AgEFMA4GA1Ud
DwEB/wQEAwIBBjANBgkqhkiG9w0BAQUFAAOCAQEAlGRZrTlk5ynrE/5aw4sTV8gEJPB0d8Bg
42f76Ymmg7+Wgnxu1MM9756AbrsptJh6sTtU6zkXR34ajgv8HzFZMQSyzhfzLMdiNlXiItiJ
VbSYSKpk+tYcNthEeFpaIzpXl/V6ME+un2pMSyuOoAPjPuCp1NJ70rOo4nI8rZ7/gFnkm0W0
9juwzTkZmDLl6iFhkOQxIY40sfcvNUqFENrnijchvllj4PKFiDFT1FQUhXB59C4Gdyd1Lx+4
ivn+xbrYNuSD7Odlt79jWvNGr4GUN9RBjNYj1h7P9WgbRGOiWrqnNVmh5XAFmw4jV5mUCm26
OWMohpLzGITY+9HPBVZkVzGCAiAwggIcAgEBMIGZMIGQMQswCQYDVQQGEwJERTEYMBYGA1UE
ChMPTkVDIEV1cm9wZSBMdGQuMSAwHgYDVQQLExdORUMgTGFib3JhdG9yaWVzIEV1cm9wZTES
MBAGA1UEAxMJTkVDTEFCLUNBMTEwLwYJKoZIhvcNAQkBFiJ6ZXJ0aWZpemllcnVuZ3NzdGVs
bGVAbncubmVjbGFiLmV1AgQP7R53MAkGBSsOAwIaBQCgXTAjBgkqhkiG9w0BCQQxFgQU6ttR
LJT6CTROJ6q+5jBx5SjAtowwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0B
CQUxDxcNMTIwMjI4MTYzMjIwWjANBgkqhkiG9w0BAQEFAASCAQB8z7MoluoMOVQzcc++vcBQ
fKkUZ/p9M71ACgMDmoMp+1kPUkuQuMGBuuRV1OD9fhG2xHe88LcjMUobNLFIPhBK8PUfk56v
ZzST8/3K+koFVMknoKPjSGgvJmo6lrp5LmHsuHl/9QO8KG5RDETmSHFhscOjEST72sxeQp2P
8l8CSNjEzprHIPKto7cjR0KgpuQ6HvX5xktwhwARrJX5Ry3SRp0WFgAewptIRH8knYVC+OCc
0XocuefBd+suUgf4MoCQv5tkner/DfD/+VsA/ETC5Ei0a6KBsooNRMQXQwTlX/aiJCOR1+5+
AFRnzp/lF8VAD84mUtNZiU1vOhnLi6pP

--B_3413295140_25025474--

From carter@qosient.com  Tue Feb 28 09:03:18 2012
Return-Path: 
X-Original-To: ipfix@ietfa.amsl.com
Delivered-To: ipfix@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 350DF21F85E6 for ; Tue, 28 Feb 2012 09:03:18 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.069
X-Spam-Level: 
X-Spam-Status: No, score=-1.069 tagged_above=-999 required=5 tests=[AWL=-0.067, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_64=0.6, J_CHICKENPOX_72=0.6, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gks0kwGFmQ5r for ; Tue, 28 Feb 2012 09:03:16 -0800 (PST)
Received: from mail1.g1.pair.com (mail1.g1.pair.com [66.39.3.162]) by ietfa.amsl.com (Postfix) with ESMTP id 9AA0821F8667 for ; Tue, 28 Feb 2012 09:03:15 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by mail1.g1.pair.com (Postfix) with SMTP id 2908828695; Tue, 28 Feb 2012 12:03:10 -0500 (EST)
Received: from thoth.newyork.qosient.com (207-237-36-98.c3-0.avec-ubr1.nyr-avec.ny.static.cable.rcn.com [207.237.36.98]) by mail1.g1.pair.com (Postfix) with ESMTPSA id C164F2867C; Tue, 28 Feb 2012 12:03:08 -0500 (EST)
Mime-Version: 1.0 (Apple Message framework v1257)
Content-Type: multipart/signed; boundary="Apple-Mail=_FBEA1533-2F20-4986-9077-C87419460BEB"; protocol="application/pkcs7-signature"; micalg=sha1
From: Carter Bullard 
In-Reply-To: 
Date: Tue, 28 Feb 2012 12:03:08 -0500
Message-Id: <79D7A23D-3B81-41AB-8D0E-1A1CAFDB180F@qosient.com>
References: 
To: Juergen Quittek 
X-Mailer: Apple Mail (2.1257)
Cc: Argus , IETF IPFIX Working Group 
Subject: Re: [IPFIX] recent ipfix drafts and argus
X-BeenThere: ipfix@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IPFIX WG discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 28 Feb 2012 17:03:18 -0000

--Apple-Mail=_FBEA1533-2F20-4986-9077-C87419460BEB
Content-Type: multipart/alternative;
	boundary="Apple-Mail=_D6AC05FC-120C-4393-8277-63BA5A81A246"


--Apple-Mail=_D6AC05FC-120C-4393-8277-63BA5A81A246
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=iso-8859-2

Hey Juergen,
I know how the IETF works.  As you remember, I was a principal =
contributor
to the meetings that lead to the formation of IPFIX.   But all IETF =
documents
have an Acknowledgements and References sections for a reason.
When your authors use examples or technology that are well developed in
other projects, you should give those projects credit for the work they =
have
done.

Carter

Carter Bullard
CEO/President
QoSient, LLC
150 E. 57th Street Suite 12D
New York, New York 10022

+1 212 588-9133 Phone
+1 212 588-9134 Fax



On Feb 28, 2012, at 11:32 AM, Juergen Quittek wrote:

> Hi Carter,
>=20
> It looks like there is a misconception on your side concerning IETF
> publications.  You are confusing them with scientific conference and
> journal publications.  The target of the IETF is not serving the =
community
> with new unpublished ideas, but with standards specifications.  =
Whether
> the technologies used for standards have been published before is not =
of
> high relevance.  But of high relevance is if they are suited as a
> standard.  The IETF has even a mechanism where people can claim IPR
> related to IETF documents.  This is completely independent from the
> authorship.
>=20
> According to the rules of the IETF, authors of WG documents are =
assigned
> by the WG chairs.  Typically these are the same authors that worked on =
an
> individual draft on the same topic before, but not necessarily.  And =
there
> is no rule at all at the IETF stating that a person can only be an =
author,
> it he or she had the original idea described in the text.  If an RFC =
is
> revised then often the original authors are removed and the ones =
making
> the revision are added.  There is not concern about 'originality'.
>=20
> All your complaints in this direction are pointless.
>=20
> However, what the WG may consider is adding a reference to argus to
> draft-ietf-ipfix-a9n.  You are welcome to provide text on which =
concepts
> and methods are already well understood and tested from experiences =
with
> argus.
>=20
>    Juergen
>=20
>=20
> On 28.02.12 16:13, "Carter Bullard"  wrote:
>=20
>> Hey Juergen,It is not the responsibility of groups outside of the =
IETF to
>> police IETF working groups
>> to ensure that they are doing the right thing. The IETF itself, has a
>> responsibility to do
>> the right thing when it comes to publishing technical documents.
>>=20
>> I am providing input to the WG that draft-ietf-ipfix-a9n-3 is not
>> original work, the concepts
>> have been worked in the communications industry for a very long time, =
and
>> there are open
>> public implementations of every concept in the draft.   I am also
>> providing input to the WG
>> that draft-ietf-ipfix-a9n-3 appears to be using concepts, and =
examples
>> that are curiously
>> specific to actual implementation and publications developed by =
Argus.
>>=20
>> Based on the response from the authors to the mailing list, its clear
>> that the authors
>> have not done any due diligence to ensure that their draft conforms =
to
>> even the simplest of
>> ethics in technical publication.  Plagiarism is a very serious =
problem,
>> and the authors
>> should know how to protect themselves from such a claim.
>>=20
>> I am providing input to the WG that I believe the authors cannot =
defend
>> themselves
>> from such a claim with their current draft, and that the WG should
>> respond accordingly.
>>=20
>> I would hope that the WG will use this input to improve their =
processes
>> and products,
>> something that would benefit the entire flow community.
>>=20
>> Carter
>>=20
>> Carter Bullard
>> CEO/President
>> QoSient, LLC
>> 150 E. 57th Street Suite 12D
>> New York, New York 10022
>>=20
>> +1 212 588-9133 Phone
>> +1 212 588-9134 Fax
>>=20
>>=20
>>=20
>>=20
>>=20
>> On Feb 28, 2012, at 4:25 AM, Juergen Quittek wrote:
>>=20
>>=20
>> Hi Carter,
>>=20
>> You know the IPFIX WG for long and our process has always been open.
>> Aggregation (also referred to as "concentration") was always among
>> the requirements to take care of by the IPFIX WG, see, for example,
>> RFC 3917 from 2004.
>>=20
>> The open IETF process allows anybody to support technical documents
>> with solutions, such as ones on IPFIX aggregation.  So far, no such
>> contribution has been made by argus developers or users.  This is a
>> pity, but nothing you can blame any active members of the IPFIX WG
>> for.  If you want to blame someone, then rather blame the argus
>> community including yourself.  You aware of the IPFIX WG and
>> contributions from you or argus users would have been highly
>> appreciated.
>>=20
>> The IPFIX WG is and will always open for contributions from the
>> argus community.  If you think that a technical contributions from
>> argus or a reference to argus would improve any of our current
>> documents, then please contribute to them, as you had already done
>> in the past.  Please particularly do so if you think the way argus
>> solved technical problems is better than what has so far been
>> contributed to the IPFIX WG.
>>=20
>>=20
>> While your technical contributions will always be welcome, I ask
>> you in my role as WG co-chair to stop making harsh statements on
>> the mailing list, even though the main effect that you achieve
>> with these statements is discrediting yourself.  In particular
>> I refer to two statements you made:
>>=20
>> 1. You accuse authors of draft draft-ietf-ipfix-a9n of plagiarism.
>> Your main reason for this was that you stated "I had the same idea
>> before" and it's publicly available.  I haven't checked if the
>> ideas are exactly the same, but this is not the point.  It does
>> happen that two people independently have the same idea.
>> For accusing someone of plagiarism, more evidence is necessary,
>> at least if you want to be taken serious.
>>=20
>> 2. You claim that authors of draft-ietf-ipfix-a9n are lacking
>> expertise.  Indeed, there are leading experts among the authors
>> with high reputation and high expertise in the area of IP
>> flow monitoring.  Claiming they "don't have a clue" because they
>> don't know argus by heart is a statement that may be valid in
>> an argus-centric world, but not in the world of the IP flow
>> monitoring community.
>>=20
>>=20
>> I look forward to your technical contributions for improving the
>> Standards we are developing in the IPFIX WG.
>>=20
>>   Juergen
>>   WG co-chair
>>=20
>>=20
>> On 28.02.12 00:49, "Carter Bullard"  wrote:
>>=20
>>=20
>> Hey Benoit,Well you should pay some attention.  You should know if =
there
>>=20
>> is prior art before you start presenting descriptions of technology, =
and
>>=20
>> you should give credit to that prior art.  Problem's come up when you
>>=20
>> present work, and your descriptions look like the prior art's source
>>=20
>> code, and your examples look like that prior arts program output.   =
Maybe
>>=20
>> its just a coincidence.
>>=20
>>=20
>>=20
>> Argus is free and open source software, and the concepts that you are
>>=20
>> presenting in your draft were implemented in argus over 19 years ago, =
so
>>=20
>> I don't think I'm too worried about IP.  Its just the arrogance of it =
all
>>=20
>> that is a little bit of a concern.  IPFIX isn't doing the community =
any
>>=20
>> favors if its only authors don't have a clue.
>>=20
>>=20
>>=20
>> Carter
>>=20
>>=20
>>=20
>> Carter Bullard
>>=20
>> CEO/President
>>=20
>> QoSient, LLC
>>=20
>> 150 E. 57th Street Suite 12D
>>=20
>> New York, New York 10022
>>=20
>>=20
>>=20
>> +1 212 588-9133 Phone
>>=20
>> +1 212 588-9134 Fax
>>=20
>>=20
>>=20
>>=20
>>=20
>>=20
>>=20
>>=20
>>=20
>>=20
>>=20
>> On Feb 27, 2012, at 5:52 PM, Benoit Claise wrote:
>>=20
>>=20
>>=20
>>=20
>>=20
>>=20
>>=20
>>=20
>>=20
>>=20
>>=20
>>=20
>>=20
>>  Hi Carter,
>>=20
>>=20
>>=20
>>  After trying to abstract the style of your email, which I don't
>>=20
>>  appreciate, I'm not too sure how to read your email.
>>=20
>>  Is this an IP claim? Or just "I've been doing this for years, so I
>>=20
>>  know better"?
>>=20
>>=20
>>=20
>>  In all cases, that's a nice advertisement for your company... Maybe
>>=20
>>  it was the point...
>>=20
>>=20
>>=20
>>  On my side, I certainly don't get my ideas from your products!
>>=20
>>  The last time I looked up your web site was at the time of RFC3955.
>>=20
>>  In total in my live, I don't think I spend more than 1/2 h on your
>>=20
>>  web site.
>>=20
>>=20
>>=20
>>  And I don't feel like replying to the details of this email, or even
>>=20
>>  playing the little game of comparing features of your company/my
>>=20
>>  company.
>>=20
>>=20
>>=20
>>  Regards, Benoit.
>>=20
>>=20
>>=20
>> Gentle people,
>>=20
>>    I'm generally pretty quiet when it comes to IPFIX and its
>>=20
>>      efforts.  But as the first
>>=20
>>    person to develop IP flow records in the 1980's, first to
>>=20
>>      present the idea to the
>>=20
>>    community in 1992, the first to provide open source flow
>>=20
>>      technology in 1995,
>>=20
>>    and the author of the longest lived open source flow system,
>>=20
>>      argus; I feel that
>>=20
>>    I have to say something about the recent wave of IPFIX
>>=20
>>      drafts.
>>=20
>>=20
>>=20
>>=20
>>=20
>>    The drafts on flow aggregation describe functionality that
>>=20
>>      the Argus project started
>>=20
>>    over 20 years ago.  The ideas of key modification, conversion
>>=20
>>      of non-key attributes
>>=20
>>    to key members, aggregation operators, interval
>>=20
>>      distribution and the architecture for it,
>>=20
>>    were all developed in argus a long long time ago.
>>=20
>>       draft-ietf-ipfix-a9n is basically
>>=20
>>    describing the functionality of
>>=20
>>      argus's racluster(), rasplit(), and rabins() programs,
>>=20
>>    and every example given in the text of draft-ietf-ipfix-a9n
>>=20
>>      can be generated using
>>=20
>>    argus's rabins(), with only a few gyrations of its
>>=20
>>      command-line, today.
>>=20
>>=20
>>=20
>>=20
>>=20
>>    I personally would expect that if the IETF was going to
>>=20
>>      describe something that is
>>=20
>>    "Standards Track", that there would be dozen's of
>>=20
>>      implementations of this kind of
>>=20
>>    technology available, and that the WG is condensing years of
>>=20
>>      experience to
>>=20
>>    arrive at a "Standards Track", but, this is not the case.
>>=20
>>       There is only one current
>>=20
>>    implementation of the complete capabilities of the features
>>=20
>>      of draft-ietf-ipfix-a9n
>>=20
>>    that I am aware of, and that is in argus.
>>=20
>>=20
>>=20
>>=20
>>=20
>>    Taking just one of the technical descriptions in the
>>=20
>>      draft, "interval distribution", I
>>=20
>>    am not aware of any description of this issue,
>>=20
>>      or implementation of this type
>>=20
>>    of technology in the literature, outside of argus.  No Google
>>=20
>>      search results for "flow
>>=20
>>    interval distribution".   In Argus we call it flow splitting.
>>=20
>>       The first line from a
>>=20
>>    Google search for "argus flow splitting" return:
>>=20
>>=20
>>=20
>>=20
>>=20
>>=20
>>=20
>>=20
>>=20
>>=20
>>=20
>>=20
>>=20
>>=20
>>=20
>>                Scholarly
>>=20
>>                    articles for argus flow splitting
>>=20
>> =
>=20
>> s_vis=3D1&oi=3Dscholart&sa=3DX&ei=3D-8NLT_6lKcnb0QHVs6z7DQ&ved=3D0CBoQg=
QMwAA>
>>=20
>>=20
>>=20
>>=20
>>=20
>>=20
>>=20
>>=20
>>=20
>>                =A9
>>=20
>>                    and prediction of flow statistics from
>>=20
>>                    sampled packet =A9
>>=20
>> =
>=20
>> =
3Den%26q%3Dhttp://dl.acm.org/citation.cfm%253Fid%253D637225%26sa%3DX%26sci=

>>=20
>> =
sig%3DAAGBfm1Qq9_hOFJINho1051rzZ6qOD5wuA%26oi%3Dscholarr&rct=3Dj&sa=3DX&ei=
=3D-8N
>>=20
>> =
LT_6lKcnb0QHVs6z7DQ&ved=3D0CBsQgAMoADAA&q=3Dargus+flow+splitting&usg=3DAFQ=
jCNFuM
>>=20
>> uC_b45uErbgoPHPab61egoZ3g> - Duffield -
>>=20
>>                    Cited by 217
>>=20
>>=20
>>=20
>>=20
>>=20
>>=20
>>=20
>>=20
>>=20
>>=20
>>=20
>>=20
>>=20
>>=20
>>=20
>>=20
>>=20
>>    I'm not saying that Nick knows much about argus's support for
>>=20
>>      flow splitting, but
>>=20
>>    its still pretty scary that the first hit is from a paper
>>=20
>>      that is used in IPFIX documents.
>>=20
>>    One would have to assume that the IPFIX community should be
>>=20
>>      aware.
>>=20
>>=20
>>=20
>>=20
>>=20
>>    My problem is that most of  draft-ietf-ipfix-a9n is prior
>>=20
>>      work that is not widely
>>=20
>>    implemented, some of the features are still unique to argus.
>>=20
>>        While IETF support
>>=20
>>    of technology is a good thing, descriptions of technology
>>=20
>>      without reference
>>=20
>>    is a difficult thing to interpret.  Is the IPFIX WG
>>=20
>>      describing what they think is new
>>=20
>>    technology? Does the IPFIX WG think that many companies have
>>=20
>>      implemented
>>=20
>>    this type of technology, and now its time to standardize it ?
>>=20
>>       Well, I'm not aware
>>=20
>>    of any implementation, open or closed, that does the complete
>>=20
>>      set of what the
>>=20
>>    draft is recommending, other than argus.  So I don't think
>>=20
>>      its new, nor widely
>>=20
>>    implemented.  I would say its a form of technology
>>=20
>>      plagiarism.
>>=20
>>=20
>>=20
>>=20
>>=20
>>    IPFIX is considering adding non-IP flows to their
>>=20
>>      definitions.  Argus is the only available
>>=20
>>    flow technology that has significant non-IP flow data models
>>=20
>>      and support.  argus-1.2 had
>>=20
>>    flow generation, transport, analytics and storage of non-IP
>>=20
>>      flows 20 years ago, with its
>>=20
>>    support for bi-directional ethernet, apple-talk and ARP
>>=20
>>      transaction tracking and reporting.
>>=20
>>    In the last 10 years, argus has added MPLS, VLAN, ISO
>>=20
>>      addresses, and Infiniband flow
>>=20
>>    models.  Not attributes, but true flow key elements.   This
>>=20
>>      work is non-trivial.
>>=20
>>=20
>>=20
>>=20
>>=20
>>    The concept that the WG would consider dropping the IP from
>>=20
>>      IPFIX and think that is
>>=20
>>    all that is needed, is really so completely wrong, that its
>>=20
>>      laughable, and a dis-service
>>=20
>>    to those that have done the hard work to bring
>>=20
>>      situational awareness and analytics
>>=20
>>    to non-IP traffic.   The same applies to bi-directional
>>=20
>>      flows, but that is another story.
>>=20
>>=20
>>=20
>>=20
>>=20
>>    I would love to think that IPFIX could focus back on flow
>>=20
>>      information exchange.
>>=20
>>    Multicast, non-template based connectionless transport
>>=20
>>      strategies, say over UDT
>>=20
>>    as an example, rather than getting into areas for which the
>>=20
>>      WG is unprepared to
>>=20
>>    do even a reasonable job, without resorting to dubious
>>=20
>>      techniques.
>>=20
>>=20
>>=20
>>=20
>>=20
>>    Just a few comments, I hope that anyone finds it useful.
>>=20
>>=20
>>=20
>>=20
>>=20
>>=20
>>=20
>>=20
>>=20
>>=20
>>=20
>>=20
>>=20
>>            Carter
>>=20
>>=20
>>=20
>>=20
>>=20
>>=20
>>=20
>>=20
>>=20
>>=20
>>=20
>>=20
>>=20
>>=20
>>=20
>>          Carter Bullard
>>=20
>>          CEO/President
>>=20
>>          QoSient, LLC
>>=20
>>          150 E. 57th Street Suite 12D
>>=20
>>          New York, New York 10022
>>=20
>>=20
>>=20
>>=20
>>=20
>>          +1 212 588-9133 Phone
>>=20
>>          +1 212 588-9134 Fax
>>=20
>>=20
>>=20
>>=20
>>=20
>>=20
>>=20
>>=20
>>=20
>>=20
>>=20
>>=20
>>=20
>>=20
>>=20
>>=20
>>=20
>>=20
>>=20
>>    _______________________________________________
>>=20
>> IPFIX mailing list
>>=20
>> IPFIX@ietf.orghttps://www.ietf.org/mailman/listinfo/ipfix
>>=20
>>=20
>>=20
>>=20
>>=20
>>=20
>>=20
>>=20
>>=20
>>=20
>>=20
>>=20
>>=20
>>=20
>>=20
>>=20
>>=20
>>=20
>>=20
>>=20
>>=20
>>=20
>>=20
>> _______________________________________________
>>=20
>> IPFIX mailing list
>>=20
>> IPFIX@ietf.org
>>=20
>> https://www.ietf.org/mailman/listinfo/ipfix
>>=20
>>=20
>>=20
>>=20
>>=20
>>=20
>>=20
>>=20


--Apple-Mail=_D6AC05FC-120C-4393-8277-63BA5A81A246
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=iso-8859-2


Carter Bullard
CEO/President
QoSient, =
LLC
150 E. 57th Street Suite =
12D
New York, New York =
10022

+1 212 588-9133 Phone
+1 212 588-9134 =
Fax





On Feb 28, 2012, at 11:32 AM, Juergen Quittek =
wrote:

Hi Carter,

It looks like there is a =
misconception on your side concerning IETF
publications.  You =
are confusing them with scientific conference and
journal =
publications.  The target of the IETF is not serving the =
community
with new unpublished ideas, but with standards =
specifications.  Whether
the technologies used for standards =
have been published before is not of
high relevance.  But of =
high relevance is if they are suited as a
standard.  The IETF =
has even a mechanism where people can claim IPR
related to IETF =
documents.  This is completely independent from =
the
authorship.

According to the rules of the IETF, authors of =
WG documents are assigned
by the WG chairs.  Typically these are =
the same authors that worked on an
individual draft on the same topic =
before, but not necessarily.  And there
is no rule at all at the =
IETF stating that a person can only be an author,
it he or she had =
the original idea described in the text.  If an RFC is
revised =
then often the original authors are removed and the ones making
the =
revision are added.  There is not concern about =
'originality'.

All your complaints in this direction are =
pointless.

However, what the WG may consider is adding a =
reference to argus to
draft-ietf-ipfix-a9n.  You are welcome to =
provide text on which concepts
and methods are already well =
understood and tested from experiences with
argus.

 =
   Juergen


On 28.02.12 16:13, "Carter Bullard" =
<carter@qosient.com> =
wrote:

Hey Juergen,It is not the =
responsibility of groups outside of the IETF =
to
police IETF working =
groups
to ensure that they are =
doing the right thing. The IETF itself, has =
a
responsibility to =
do
the right thing when it =
comes to publishing technical documents.

I am providing =
input to the WG that draft-ietf-ipfix-a9n-3 is =
not
original work, the =
concepts
have been worked in =
the communications industry for a very long time, =
and
there are =
open
public implementations of =
every concept in the draft.   I am =
also
providing input to the =
WG
that draft-ietf-ipfix-a9n-3 =
appears to be using concepts, and examples
that are curiously
specific to actual implementation and publications =
developed by Argus.

Based on the =
response from the authors to the mailing list, its =
clear
that the =
authors
have not done any due =
diligence to ensure that their draft conforms =
to
even the simplest =
of
ethics in technical =
publication.  Plagiarism is a very serious =
problem,
and the =
authors
should know how to =
protect themselves from such a claim.

I am providing =
input to the WG that I believe the authors cannot =
defend
themselves
from =
such a claim with their current draft, and that the WG =
should
respond =
accordingly.

I would hope =
that the WG will use this input to improve their =
processes
and =
products,
something that would =
benefit the entire flow community.

Carter

Carter =
Bullard
CEO/President
QoSient, LLC
150 =
E. 57th Street Suite 12D
New =
York, New York 10022

+1 212 588-9133 =
Phone
+1 212 588-9134 =
Fax





On Feb 28, =
2012, at 4:25 AM, Juergen Quittek wrote:


Hi =
Carter,

You know the =
IPFIX WG for long and our process has always been =
open.
Aggregation (also =
referred to as "concentration") was always =
among
the requirements to take =
care of by the IPFIX WG, see, for example,
RFC 3917 from 2004.

The open IETF =
process allows anybody to support technical =
documents
with solutions, such =
as ones on IPFIX aggregation.  So far, no =
such
contribution has been =
made by argus developers or users.  This is =
a
pity, but nothing you can =
blame any active members of the IPFIX WG
for.  If you want to blame someone, then rather blame =
the argus
community including =
yourself.  You aware of the IPFIX WG =
and
contributions from you or =
argus users would have been highly
appreciated.

The IPFIX WG is =
and will always open for contributions from =
the
argus community.  If =
you think that a technical contributions =
from
argus or a reference to =
argus would improve any of our current
documents, then please contribute to them, as you had =
already done
in the past. =
 Please particularly do so if you think the way =
argus
solved technical =
problems is better than what has so far been
contributed to the IPFIX WG.


While your =
technical contributions will always be welcome, I =
ask
you in my role as WG =
co-chair to stop making harsh statements on
the mailing list, even though the main effect that you =
achieve
with these statements =
is discrediting yourself.  In =
particular
I refer to two =
statements you made:

1. You accuse =
authors of draft draft-ietf-ipfix-a9n of =
plagiarism.
Your main reason =
for this was that you stated "I had the same =
idea
before" and it's publicly =
available.  I haven't checked if the
ideas are exactly the same, but this is not the point. =
 It does
happen that two =
people independently have the same idea.
For accusing someone of plagiarism, more evidence is =
necessary,
at least if you =
want to be taken serious.

2. You claim =
that authors of draft-ietf-ipfix-a9n are =
lacking
expertise. =
 Indeed, there are leading experts among the =
authors
with high reputation =
and high expertise in the area of IP
flow monitoring.  Claiming they "don't have a clue" =
because they
don't know argus =
by heart is a statement that may be valid in
an argus-centric world, but not in the world of the IP =
flow
monitoring =
community.


I look forward =
to your technical contributions for improving =
the
Standards we are =
developing in the IPFIX WG.

 =
  Juergen
 =
  WG co-chair


On 28.02.12 =
00:49, "Carter Bullard" <carter@qosient.com> =
wrote:


Hey Benoit,Well =
you should pay some attention.  You should know if =
there

is prior art =
before you start presenting descriptions of technology, =
and

you should give credit to that prior art.  Problem's =
come up when you

present work, =
and your descriptions look like the prior art's =
source

code, and your =
examples look like that prior arts program output. =
  Maybe

its just a =
coincidence.



Argus is free =
and open source software, and the concepts that you =
are

presenting in your draft were implemented in argus over =
19 years ago, so

I don't think =
I'm too worried about IP.  Its just the arrogance of it =
all

that is a little bit of a concern.  IPFIX isn't =
doing the community any

favors if its =
only authors don't have a clue.



Carter



Carter =
Bullard

CEO/President

QoSient, =
LLC

150 E. 57th Street Suite 12D

New York, New =
York 10022



+1 212 588-9133 =
Phone

+1 212 588-9134 =
Fax











On Feb 27, =
2012, at 5:52 PM, Benoit Claise wrote:













  Hi =
Carter,



  After =
trying to abstract the style of your email, which I =
don't

 =
 appreciate, I'm not too sure how to read your =
email.

  Is this =
an IP claim? Or just "I've been doing this for years, so =
I

  know better"?



  In all =
cases, that's a nice advertisement for your company... =
Maybe

  it was =
the point...



  On my =
side, I certainly don't get my ideas from your =
products!

  The last =
time I looked up your web site was at the time of =
RFC3955.

  In total =
in my live, I don't think I spend more than 1/2 h on =
your

  web =
site.



  And I =
don't feel like replying to the details of this email, or =
even

  playing =
the little game of comparing features of your =
company/my

 =
 company.



  Regards, =
Benoit.



Gentle =
people,

 =
   I'm generally pretty quiet when it comes to IPFIX and =
its

      efforts.  But as the =
first

 =
   person to develop IP flow records in the 1980's, first =
to

      present the idea to =
the

    community in 1992, the first to =
provide open source flow

 =
     technology in =
1995,

 =
   and the author of the longest lived open source flow =
system,

 =
     argus; I feel =
that

 =
   I have to say something about the recent wave of =
IPFIX

 =
     drafts.





 =
   The drafts on flow aggregation describe functionality =
that

 =
     the Argus project =
started

 =
   over 20 years ago.  The ideas of key =
modification, conversion

 =
     of non-key =
attributes

 =
   to key members, aggregation operators, =
interval

 =
     distribution and the architecture for =
it,

    were all developed in argus a long =
long time ago.

 =
      draft-ietf-ipfix-a9n is =
basically

 =
   describing the functionality =
of

      argus's racluster(), =
rasplit(), and rabins() programs,

 =
   and every example given in the text of =
draft-ietf-ipfix-a9n

 =
     can be generated =
using

 =
   argus's rabins(), with only a few gyrations of =
its

      command-line, =
today.





 =
   I personally would expect that if the IETF was going =
to

      describe something that =
is

    "Standards Track", that there would be =
dozen's of

 =
     implementations of this kind =
of

    technology available, and that the WG =
is condensing years of

 =
     experience to

 =
   arrive at a "Standards Track", but, this is not the =
case.

 =
      There is only one =
current

 =
   implementation of the complete capabilities of the =
features

 =
     of =
draft-ietf-ipfix-a9n

 =
   that I am aware of, and that is in =
argus.





 =
   Taking just one of the technical descriptions in =
the

      draft, "interval =
distribution", I

 =
   am not aware of any description of this =
issue,

 =
     or implementation of this =
type

 =
   of technology in the literature, outside of argus. =
 No Google

 =
     search results for =
"flow

 =
   interval distribution".   In Argus we call =
it flow splitting.

 =
      The first line from =
a

    Google search for "argus flow =
splitting" return:















 =
            &n=
bsp;  Scholarly

 =
            &n=
bsp;      articles for argus flow =
splitting

<http://scholar.google.com/scholar?q=3Dargus+flow+=
splitting&hl=3Den&as_sdt=3D0&a

s_vis=3D1&oi=3Dscholart&sa=3DX&ei=3D-8NLT_6lKcnb=
0QHVs6z7DQ&ved=3D0CBoQgQMwAA>









 =
            &n=
bsp;  =A9

 =
            &n=
bsp;      and prediction of flow =
statistics from

 =
            &n=
bsp;      sampled packet =
=A9

<http://www.google.com/url?url=3Dhttp://scholar.google.com/schol=
ar_url%3Fhl%

3Den%26q%3Dhttp://dl.acm.org/citation.cfm%253Fid%253D637225%=
26sa%3DX%26sci

sig%3DAAGBfm1Qq9_hOFJINho1051rzZ6qOD5wuA%26oi%3Dscholarr&=
;rct=3Dj&sa=3DX&ei=3D-8N

LT_6lKcnb0QHVs6z7DQ&ved=3D0CBsQgAMoADAA&q=3Dargus+fl=
ow+splitting&usg=3DAFQjCNFuM

uC_b45uErbgoPHPab61egoZ3g> - Duffield =
-

 =
            &n=
bsp;      Cited by =
217

















 =
   I'm not saying that Nick knows much about argus's =
support for

 =
     flow splitting, =
but

    its still pretty scary that the first =
hit is from a paper

 =
     that is used in IPFIX =
documents.

 =
   One would have to assume that the IPFIX community =
should be

 =
     aware.





 =
   My problem is that most of  draft-ietf-ipfix-a9n =
is prior

 =
     work that is not =
widely

 =
   implemented, some of the features are still unique to =
argus.

 =
       While IETF =
support

 =
   of technology is a good thing, descriptions of =
technology

 =
     without =
reference

 =
   is a difficult thing to interpret.  Is the IPFIX =
WG

      describing what they think =
is new

 =
   technology? Does the IPFIX WG think that many =
companies have

 =
     implemented

 =
   this type of technology, and now its time to =
standardize it ?

 =
      Well, I'm not =
aware

 =
   of any implementation, open or closed, that does the =
complete

 =
     set of what =
the

    draft is recommending, other than =
argus.  So I don't think

 =
     its new, nor =
widely

 =
   implemented.  I would say its a form of =
technology

 =
     plagiarism.





 =
   IPFIX is considering adding non-IP flows to =
their

 =
     definitions.  Argus is the only =
available

 =
   flow technology that has significant non-IP flow data =
models

 =
     and support.  argus-1.2 =
had

    flow generation, transport, analytics =
and storage of non-IP

 =
     flows 20 years ago, with =
its

    support for bi-directional ethernet, =
apple-talk and ARP

 =
     transaction tracking and =
reporting.

 =
   In the last 10 years, argus has added MPLS, VLAN, =
ISO

      addresses, and Infiniband =
flow

 =
   models.  Not attributes, but true flow key =
elements.   This

 =
     work is =
non-trivial.





 =
   The concept that the WG would consider dropping the IP =
from

 =
     IPFIX and think that =
is

    all that is needed, is really so =
completely wrong, that its

 =
     laughable, and a =
dis-service

 =
   to those that have done the hard work to =
bring

 =
     situational awareness and =
analytics

 =
   to non-IP traffic.   The same applies to =
bi-directional

 =
     flows, but that is another =
story.





 =
   I would love to think that IPFIX could focus back on =
flow

 =
     information =
exchange.

 =
   Multicast, non-template based connectionless =
transport

 =
     strategies, say over =
UDT

    as an example, rather than getting =
into areas for which the

 =
     WG is unprepared =
to

    do even a reasonable job, without =
resorting to dubious

 =
     techniques.





 =
   Just a few comments, I hope that anyone finds it =
useful.













 =
           Carter















 =
         Carter =
Bullard

 =
         CEO/President

 =
         QoSient, =
LLC

 =
         150 E. 57th Street =
Suite 12D

 =
         New York, New York =
10022





 =
         +1 212 588-9133 =
Phone

 =
         +1 212 588-9134 =
Fax



















 =
   _______________________________________________

IPFIX mailing list

IPFIX@ietf.orghttps=
://www.ietf.org/mailman/listinfo/ipfix























_______________________________________________

IPFIX mailing list

IPFIX@ietf.org

https://www.ietf.org/=
mailman/listinfo/ipfix









=

--Apple-Mail=_D6AC05FC-120C-4393-8277-63BA5A81A246--

--Apple-Mail=_FBEA1533-2F20-4986-9077-C87419460BEB
Content-Disposition: attachment;
	filename=smime.p7s
Content-Type: application/pkcs7-signature;
	name=smime.p7s
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMRjCCBVAw
ggQ4oAMCAQICEE/C1XPaEv5Xc80XjVqbwwowDQYJKoZIhvcNAQEFBQAwgd0xCzAJBgNVBAYTAlVT
MRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y
azE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEg
KGMpMDkxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuVmVyaVNpZ24g
Q2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMzAeFw0xMTA0MTQwMDAwMDBaFw0x
MjA0MTMyMzU5NTlaMIIBEzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT
aWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9S
UEEgSW5jb3JwLiBieSBSZWYuLExJQUIuTFREKGMpOTgxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZh
bGlkYXRlZDEzMDEGA1UECxMqRGlnaXRhbCBJRCBDbGFzcyAxIC0gTmV0c2NhcGUgRnVsbCBTZXJ2
aWNlMRcwFQYDVQQDFA5DYXJ0ZXIgQnVsbGFyZDEhMB8GCSqGSIb3DQEJARYSY2FydGVyQHFvc2ll
bnQuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAnUsVMagrR+kSPj9tNNsMP6ZO
CRf4x70f3vT5OerV6rikEAz4XYJ+iv5Y6FiY5wjr2ez4BTrEuKwhAJN+aPSXHBW4cBZgB0J7mHwF
yJpY/vhhy2RrfugdCXjotFySXzevQHCfON4htlh+I3DYhN6LXmeBnnPtGz+J4mNZqdimZVlcdXqV
h0m7ysvdFkClht66vEvF+WObwLEpg3LIaFzTZBWpAiQ1FPIDJJd6uU//96grDvRy+D0oNjCkxmBp
bCkG0w1jaOuay6o62xRh7H41CxCRljzYjy3H4SwRYlYBwtqZuXg0YOI0OHdSuie6UyrUgmT+3S1U
FPiGz9yP9hninQIDAQABo4HSMIHPMAkGA1UdEwQCMAAwRAYDVR0gBD0wOzA5BgtghkgBhvhFAQcX
ATAqMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhMAsGA1UdDwQEAwIF
oDAdBgNVHSUEFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIwUAYDVR0fBEkwRzBFoEOgQYY/aHR0cDov
L2luZGMxZGlnaXRhbGlkLWczLWNybC52ZXJpc2lnbi5jb20vSW5kQzFEaWdpdGFsSUQtRzMuY3Js
MA0GCSqGSIb3DQEBBQUAA4IBAQBSg1+LGDk7EKu1hYCrpHEZVHY3I+850erL2DxLtfgzldWZPLYr
NpVa8wH5XTDhaFNLQgWwLMGfs8sJPkqXm2TfZfG7BkJWLtubW3Jw5jZ//Eygbae2IOU0bm1tAaG2
uoreBROJ5PU1ykK8aTnbNZxN772otsdHQ54gXd2wpPUoDoT740WzsdTeSI0ZXU+3J7RPbC0VHNfI
E88GgkTYBD5Xk3Ro+BSCBOh4XAA1ypHBZh2OX8C4syhPp6yfGWvwvqJ+oV5lkbAcO6FkeBlvb/Fi
XPa35ynGIIpntzpqOvr+0XJs8xq7hE8KU/QUNE6fa0gZyjxBVcbw89mv4lQx4FSOMIIG7jCCBdag
AwIBAgIQcRVmBUrkkSFN6bxE+azT3DANBgkqhkiG9w0BAQUFADCByjELMAkGA1UEBhMCVVMxFzAV
BgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTow
OAYDVQQLEzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVkIHVzZSBvbmx5
MUUwQwYDVQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRpZmljYXRpb24g
QXV0aG9yaXR5IC0gRzMwHhcNMDkwNTAxMDAwMDAwWhcNMTkwNDMwMjM1OTU5WjCB3TELMAkGA1UE
BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBO
ZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29t
L3JwYSAoYykwOTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJp
U2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEczMIIBIjANBgkqhkiG9w0B
AQEFAAOCAQ8AMIIBCgKCAQEA7cRH3yooHXwGa7vXITLJbBOP6bGNQU4099oL42r6ZYggCxET6Zvg
SU6Lb9UB0F8NR5GKWkx0Pj/GkQm7TDSejW6hglFi92l2WJYHr54UGAdPWr2f0jGyVBlzRmoZQhHs
EnMhjfXcMM3l2VYKMcU2bSkUl70t2olHGYjYSwQ967Y8Zx50ABMN0Ibak2f4MwOuGjxraXj2wCyO
4YM/d/mZ//6fUlrCtIcK2GypR8FUKWVDPkrAlh/Brfd3r2yxBF6+wbaULZeQLSfSux7pg2qE9sSy
riMGZSalJ1grByK0b6ZiSBp38tVQJ5op05b7KPW6JHZi44xZ6/tu1ULEvkHH9QIDAQABo4ICuTCC
ArUwNAYIKwYBBQUHAQEEKDAmMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC52ZXJpc2lnbi5jb20w
EgYDVR0TAQH/BAgwBgEB/wIBADBwBgNVHSAEaTBnMGUGC2CGSAGG+EUBBxcBMFYwKAYIKwYBBQUH
AgEWHGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9jcHMwKgYIKwYBBQUHAgIwHhocaHR0cHM6Ly93
d3cudmVyaXNpZ24uY29tL3JwYTA0BgNVHR8ELTArMCmgJ6AlhiNodHRwOi8vY3JsLnZlcmlzaWdu
LmNvbS9wY2ExLWczLmNybDAOBgNVHQ8BAf8EBAMCAQYwbgYIKwYBBQUHAQwEYjBgoV6gXDBaMFgw
VhYJaW1hZ2UvZ2lmMCEwHzAHBgUrDgMCGgQUS2u5KJYGDLvQUjibKaxLB4shBRgwJhYkaHR0cDov
L2xvZ28udmVyaXNpZ24uY29tL3ZzbG9nbzEuZ2lmMC4GA1UdEQQnMCWkIzAhMR8wHQYDVQQDExZQ
cml2YXRlTGFiZWw0LTIwNDgtMTE4MB0GA1UdDgQWBBR5R2EIQf04BKJL57XM9UP2SSsR+DCB8QYD
VR0jBIHpMIHmoYHQpIHNMIHKMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4x
HzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOjA4BgNVBAsTMShjKSAxOTk5IFZlcmlT
aWduLCBJbmMuIC0gRm9yIGF1dGhvcml6ZWQgdXNlIG9ubHkxRTBDBgNVBAMTPFZlcmlTaWduIENs
YXNzIDEgUHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgLSBHM4IRAItbdVaE
VIULAM+vOEjOsaQwDQYJKoZIhvcNAQEFBQADggEBADlNz0GZgbWpBbVSOOk5hIls5DSoWufYbAlM
JBq6WaSHO3Mh8ZOBz79oY1pn/jWFK6HDXaNKwjoZ3TDWzE3v8dKBl8pUWkO/N4t6jhmND0OojPKv
YLMVirOVnDzgnrMnmKQ1chfl/Cpdh9OKDcLRRSr4wPSsKpM61a4ScAjr+zvid+zoK2Q1ds262uDR
yxTWcVibvtU+fbbZ6CTFJGZMXZEfdrMXPn8NxiGJL7M3uKH/XLJtSd5lUkL7DojS7Uodv0vj+Mxy
+kgOZY5JyNb4mZg7t5Q+MXEGh/psWVMu198r7V9jAKwV7QO4VRaMxmgD5yKocwuxvKDaUljdCg5/
wYIxggSLMIIEhwIBATCB8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMu
MR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2Ug
YXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwOTEeMBwGA1UECxMVUGVyc29uYSBO
b3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2Ny
aWJlciBDQSAtIEczAhBPwtVz2hL+V3PNF41am8MKMAkGBSsOAwIaBQCgggJtMBgGCSqGSIb3DQEJ
AzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEyMDIyODE3MDMwOFowIwYJKoZIhvcNAQkE
MRYEFLu0tLd3glymUOZLOcV9BRcONMa/MIIBAwYJKwYBBAGCNxAEMYH1MIHyMIHdMQswCQYDVQQG
EwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5l
dHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20v
cnBhIChjKTA5MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMTLlZlcmlT
aWduIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzMCEE/C1XPaEv5Xc80XjVqb
wwowggEFBgsqhkiG9w0BCRACCzGB9aCB8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlT
aWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJt
cyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwOTEeMBwGA1UECxMV
UGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1
YWwgU3Vic2NyaWJlciBDQSAtIEczAhBPwtVz2hL+V3PNF41am8MKMA0GCSqGSIb3DQEBAQUABIIB
ACJ4dBwB7n0nv5yI02ftxJFj79SzYfy4lyKOl5MHv8ceMzvWtthIQ/6fq7uo45PZvyIdFwbSHjbn
9X61tIHoaTDKnkvHqmzU8Zgqx3S6aq735n3sGQcAr9P0NiDr0MaHr8i6jF7BNcy4Zg4iDs6vC40u
efnJheT+kOhGBUP6xUjKshGweSEFMBCR5tDz5rFgJO4mpff/n/yFxYgrbx+PNdMkdcN2anlhL8EF
XJhml69B2iafBGFy9PufneToDkUheRJq8Tp8zdGSWOWYAweVjm1Qbz1LnAHLcVIOZJJp7iodWQWP
f6KcjPiQdPbXe5ov2/C4yzd/bsYka4vAFyhzFZYAAAAAAAA=

--Apple-Mail=_FBEA1533-2F20-4986-9077-C87419460BEB--

From n.brownlee@auckland.ac.nz  Tue Feb 28 23:49:16 2012
Return-Path: 
X-Original-To: ipfix@ietfa.amsl.com
Delivered-To: ipfix@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8663221E8057 for ; Tue, 28 Feb 2012 23:49:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.367
X-Spam-Level: 
X-Spam-Status: No, score=-102.367 tagged_above=-999 required=5 tests=[AWL=0.232, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FBS+PO7K+8Mn for ; Tue, 28 Feb 2012 23:49:15 -0800 (PST)
Received: from mx2.auckland.ac.nz (mx2.auckland.ac.nz [130.216.12.44]) by ietfa.amsl.com (Postfix) with ESMTP id DA2C021E8075 for ; Tue, 28 Feb 2012 23:49:13 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=n.brownlee@auckland.ac.nz; q=dns/txt; s=uoa; t=1330501755; x=1362037755; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=p332iqdh+jZGuL3wFoHIg7+iNTreq5BV1RTaBs1O5mo=; b=kBoQcg5O4qYsWs3CmsfRbf/iOF1bcJzbf02JImB5VsqF3P/53ieoamHA cENAFfz4vyViTFopcBgJZnPYdBNI5h2sFx5kyuLoByK38YwxgAqx3iYK3 2Kpzenhs7/Db72rqC3oY/IHFdohe0d4acDEDsqC6ixOmFP83Ry7JrpPJ8 k=;
X-IronPort-AV: E=Sophos;i="4.73,501,1325415600"; d="scan'208";a="106325826"
X-Ironport-HAT: None - $RELAY-AUTH
X-Ironport-Source: 158.38.40.26 - Outgoing - Outgoing-SSL
Received: from eduroam-dhcp26.uninett.no (HELO [158.38.40.26]) ([158.38.40.26]) by mx2-int.auckland.ac.nz with ESMTP; 29 Feb 2012 20:49:10 +1300
Message-ID: <4F4DD86B.5060504@auckland.ac.nz>
Date: Tue, 28 Feb 2012 23:48:59 -0800
From: Nevil Brownlee 
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.27) Gecko/20120216 Thunderbird/3.1.19
MIME-Version: 1.0
To: Carter Bullard 
References: <91C99130-A66C-4E6A-AE93-BA005CE6C792@qosient.com>
In-Reply-To: <91C99130-A66C-4E6A-AE93-BA005CE6C792@qosient.com>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit
Cc: Argus , ipfix@ietf.org
Subject: Re: [IPFIX] recent ipfix drafts and argus
X-BeenThere: ipfix@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IPFIX WG discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 29 Feb 2012 07:49:16 -0000

Hi Carter:

As the other IPFIX co-chair I feel bound to respond to your comments.

Your idea that an Internet Standard should document something
that has "dozens of implementations" is weird, to say the least.
In many cases there are different groups of people proposing
different ideas, so to begin with there isn't even a single
implementation.

Your comment about 'a Google search for "Argus flow splitting"' is
disingenuous.  When I spent some time with Google looking for
information about Argus and its implementation, I simply wasn't able
to find anything.  Nick Duffield's papers about sampling, i.e.
   "Charging from sampled network usage" (2001),
   "Properties and Prediction of Flow Statistics from Sampled
     Packet Streams, " (2002),
   "Learn more, sample less: control of volume and variance in
     network measurement," (2005),
all cite the Quosient web page for Argus' way of defining flows,
but there's no text in any of these papers about Argus itself!

The IPFIX WG provides a forum for interested people to contribute
ideas about information reporting.  If you have something you'd like to
see in a WG draft, you need to contribute some text about it on the
IPFIX list. In the case of the Aggregation draft, you simply haven't
done that.

In short:
  - If there is published material out there about Argus,
      please tell us about it.
  - Kindly withdraw your mischievous accusations of plagiarism, these
      are unfounded.
  - Constructive technical discussion to the IPFIX list is, of course
      always welcome.

Cheers, Nevil


On 02/27/2012 11:37 AM, Carter Bullard wrote:
> Gentle people,
> I'm generally pretty quiet when it comes to IPFIX and its efforts.  But as the first
> person to develop IP flow records in the 1980's, first to present the idea to the
> community in 1992, the first to provide open source flow technology in 1995,
> and the author of the longest lived open source flow system, argus; I feel that
> I have to say something about the recent wave of IPFIX drafts.
>
> The drafts on flow aggregation describe functionality that the Argus project started
> over 20 years ago.  The ideas of key modification, conversion of non-key attributes
> to key members, aggregation operators, interval distribution and the architecture for it,
> were all developed in argus a long long time ago.  draft-ietf-ipfix-a9n is basically
> describing the functionality of argus's racluster(), rasplit(), and rabins() programs,
> and every example given in the text of draft-ietf-ipfix-a9n can be generated using
> argus's rabins(), with only a few gyrations of its command-line, today.
>
> I personally would expect that if the IETF was going to describe something that is
> "Standards Track", that there would be dozen's of implementations of this kind of
> technology available, and that the WG is condensing years of experience to
> arrive at a "Standards Track", but, this is not the case.  There is only one current
> implementation of the complete capabilities of the features of draft-ietf-ipfix-a9n
> that I am aware of, and that is in argus.
>
> Taking just one of the technical descriptions in the draft, "interval distribution", I
> am not aware of any description of this issue, or implementation of this type
> of technology in the literature, outside of argus.  No Google search results for "flow
> interval distribution".   In Argus we call it flow splitting.  The first line from a
> Google search for "argus flow splitting" return:
>
> Scholarly articles for argus flow splitting
> … and prediction of flow statistics from sampled packet … - Duffield - Cited by 217
>
> I'm not saying that Nick knows much about argus's support for flow splitting, but
> its still pretty scary that the first hit is from a paper that is used in IPFIX documents.
> One would have to assume that the IPFIX community should be aware.
>
> My problem is that most of  draft-ietf-ipfix-a9n is prior work that is not widely
> implemented, some of the features are still unique to argus.   While IETF support
> of technology is a good thing, descriptions of technology without reference
> is a difficult thing to interpret.  Is the IPFIX WG describing what they think is new
> technology? Does the IPFIX WG think that many companies have implemented
> this type of technology, and now its time to standardize it ?  Well, I'm not aware
> of any implementation, open or closed, that does the complete set of what the
> draft is recommending, other than argus.  So I don't think its new, nor widely
> implemented.  I would say its a form of technology plagiarism.
>
> IPFIX is considering adding non-IP flows to their definitions.  Argus is the only available
> flow technology that has significant non-IP flow data models and support.  argus-1.2 had
> flow generation, transport, analytics and storage of non-IP flows 20 years ago, with its
> support for bi-directional ethernet, apple-talk and ARP transaction tracking and reporting.
> In the last 10 years, argus has added MPLS, VLAN, ISO addresses, and Infiniband flow
> models.  Not attributes, but true flow key elements.   This work is non-trivial.
>
> The concept that the WG would consider dropping the IP from IPFIX and think that is
> all that is needed, is really so completely wrong, that its laughable, and a dis-service
> to those that have done the hard work to bring situational awareness and analytics
> to non-IP traffic.   The same applies to bi-directional flows, but that is another story.
>
> I would love to think that IPFIX could focus back on flow information exchange.
> Multicast, non-template based connectionless transport strategies, say over UDT
> as an example, rather than getting into areas for which the WG is unprepared to
> do even a reasonable job, without resorting to dubious techniques.
>
> Just a few comments, I hope that anyone finds it useful.
>
> Carter
>
> Carter Bullard
> CEO/President
> QoSient, LLC
> 150 E. 57th Street Suite 12D
> New York, New York 10022
>
> +1 212 588-9133 Phone
> +1 212 588-9134 Fax
>
>
>
>
>
>
>
> _______________________________________________
> IPFIX mailing list
> IPFIX@ietf.org
> https://www.ietf.org/mailman/listinfo/ipfix


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


From carter@qosient.com  Wed Feb 29 08:38:56 2012
Return-Path: 
X-Original-To: ipfix@ietfa.amsl.com
Delivered-To: ipfix@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2EEBF21F8790 for ; Wed, 29 Feb 2012 08:38:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.35
X-Spam-Level: 
X-Spam-Status: No, score=-2.35 tagged_above=-999 required=5 tests=[AWL=1.248,  BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gnffM8FA0Tdj for ; Wed, 29 Feb 2012 08:38:54 -0800 (PST)
Received: from mail1.g1.pair.com (mail1.g1.pair.com [66.39.3.162]) by ietfa.amsl.com (Postfix) with ESMTP id 1170221F8787 for ; Wed, 29 Feb 2012 08:38:54 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by mail1.g1.pair.com (Postfix) with SMTP id A9E682854A; Wed, 29 Feb 2012 11:38:45 -0500 (EST)
Received: from thoth.newyork.qosient.com (207-237-36-98.c3-0.avec-ubr1.nyr-avec.ny.static.cable.rcn.com [207.237.36.98]) by mail1.g1.pair.com (Postfix) with ESMTPSA id 8DA072854D; Wed, 29 Feb 2012 11:38:44 -0500 (EST)
Mime-Version: 1.0 (Apple Message framework v1257)
Content-Type: multipart/signed; boundary="Apple-Mail=_86883A7A-C64D-4F66-8653-32084EE14502"; protocol="application/pkcs7-signature"; micalg=sha1
From: Carter Bullard 
In-Reply-To: <4F4DD86B.5060504@auckland.ac.nz>
Date: Wed, 29 Feb 2012 11:38:43 -0500
Message-Id: 
References: <91C99130-A66C-4E6A-AE93-BA005CE6C792@qosient.com> <4F4DD86B.5060504@auckland.ac.nz>
To: Nevil Brownlee 
X-Mailer: Apple Mail (2.1257)
Cc: Argus , ipfix@ietf.org
Subject: Re: [IPFIX] recent ipfix drafts and argus
X-BeenThere: ipfix@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IPFIX WG discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 29 Feb 2012 16:38:56 -0000

--Apple-Mail=_86883A7A-C64D-4F66-8653-32084EE14502
Content-Type: multipart/alternative;
	boundary="Apple-Mail=_248AA176-EC60-4031-A900-4031B25FBD36"


--Apple-Mail=_248AA176-EC60-4031-A900-4031B25FBD36
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=windows-1252

Nevil,
I wasn't being disingenuous about Nick or the use of Google in any way.
Nick put in references to argus in his papers, and he didn't even really
say anything about it.  He even spelled the company's name correctly.

What I am saying is the aggregation draft is dealing with a topic that =
has
been around for a very long time, and there are lots of implementations =
of
all of the concepts needed in data aggregation around.  Billing =
packages,
statistics packages,  graphing software all have to deal with these =
issues.
I can provide you lots of text books that are good references on the =
topics of
data aggregation that the flow community needs, if you are interested.

With such an unbounded topic to talk about, with so much opportunity,
why do all of the examples in the draft look like documented argus =
examples
and program outputs?

I stated this in the original email.  I am stating it now.  If you are =
going to use
examples and technology from other efforts, reference those other =
efforts.

But each example in the draft is either a specific aggregation where =
argus has
dedicated programs to generate the output, or they are well documented
examples from the argus web site or mailing list. =20

For god's sake, just change the specific objects, the time intervals
and the order and format of the output fields, and you would at least
not look like you took the examples from argus program output.

If you want to look like argus program output, fine. Mention argus.
If you want to look like SiLK, then use SiLK, and mention it.  If you =
don't
want to look like anybody's tools, then just change the format so it =
doesn't
look like anybody's tools.

The IPFIX WG is just a working group in the IETF.  It's mailing list is =
the
only avenue to present issues regarding IPFIX WG business.  I am
saying again, and hopefully for the last time, if you are going to use=20=

the work of other forums and groups in the flow community, simply give
those efforts credit.  If you don't want to do that, modify your work so
that it doesn't look like you just lifted it, without concern.

Carter

Carter Bullard
CEO/President
QoSient, LLC
150 E. 57th Street Suite 12D
New York, New York 10022

+1 212 588-9133 Phone
+1 212 588-9134 Fax



On Feb 29, 2012, at 2:48 AM, Nevil Brownlee wrote:

>=20
> Hi Carter:
>=20
> As the other IPFIX co-chair I feel bound to respond to your comments.
>=20
> Your idea that an Internet Standard should document something
> that has "dozens of implementations" is weird, to say the least.
> In many cases there are different groups of people proposing
> different ideas, so to begin with there isn't even a single
> implementation.
>=20
> Your comment about 'a Google search for "Argus flow splitting"' is
> disingenuous.  When I spent some time with Google looking for
> information about Argus and its implementation, I simply wasn't able
> to find anything.  Nick Duffield's papers about sampling, i.e.
>  "Charging from sampled network usage" (2001),
>  "Properties and Prediction of Flow Statistics from Sampled
>    Packet Streams, " (2002),
>  "Learn more, sample less: control of volume and variance in
>    network measurement," (2005),
> all cite the Quosient web page for Argus' way of defining flows,
> but there's no text in any of these papers about Argus itself!
>=20
> The IPFIX WG provides a forum for interested people to contribute
> ideas about information reporting.  If you have something you'd like =
to
> see in a WG draft, you need to contribute some text about it on the
> IPFIX list. In the case of the Aggregation draft, you simply haven't
> done that.
>=20
> In short:
> - If there is published material out there about Argus,
>     please tell us about it.
> - Kindly withdraw your mischievous accusations of plagiarism, these
>     are unfounded.
> - Constructive technical discussion to the IPFIX list is, of course
>     always welcome.
>=20
> Cheers, Nevil
>=20
>=20
> On 02/27/2012 11:37 AM, Carter Bullard wrote:
>> Gentle people,
>> I'm generally pretty quiet when it comes to IPFIX and its efforts.  =
But as the first
>> person to develop IP flow records in the 1980's, first to present the =
idea to the
>> community in 1992, the first to provide open source flow technology =
in 1995,
>> and the author of the longest lived open source flow system, argus; I =
feel that
>> I have to say something about the recent wave of IPFIX drafts.
>>=20
>> The drafts on flow aggregation describe functionality that the Argus =
project started
>> over 20 years ago.  The ideas of key modification, conversion of =
non-key attributes
>> to key members, aggregation operators, interval distribution and the =
architecture for it,
>> were all developed in argus a long long time ago.  =
draft-ietf-ipfix-a9n is basically
>> describing the functionality of argus's racluster(), rasplit(), and =
rabins() programs,
>> and every example given in the text of draft-ietf-ipfix-a9n can be =
generated using
>> argus's rabins(), with only a few gyrations of its command-line, =
today.
>>=20
>> I personally would expect that if the IETF was going to describe =
something that is
>> "Standards Track", that there would be dozen's of implementations of =
this kind of
>> technology available, and that the WG is condensing years of =
experience to
>> arrive at a "Standards Track", but, this is not the case.  There is =
only one current
>> implementation of the complete capabilities of the features of =
draft-ietf-ipfix-a9n
>> that I am aware of, and that is in argus.
>>=20
>> Taking just one of the technical descriptions in the draft, "interval =
distribution", I
>> am not aware of any description of this issue, or implementation of =
this type
>> of technology in the literature, outside of argus.  No Google search =
results for "flow
>> interval distribution".   In Argus we call it flow splitting.  The =
first line from a
>> Google search for "argus flow splitting" return:
>>=20
>> Scholarly articles for argus flow splitting
>> =85 and prediction of flow statistics from sampled packet =85 - =
Duffield - Cited by 217
>>=20
>> I'm not saying that Nick knows much about argus's support for flow =
splitting, but
>> its still pretty scary that the first hit is from a paper that is =
used in IPFIX documents.
>> One would have to assume that the IPFIX community should be aware.
>>=20
>> My problem is that most of  draft-ietf-ipfix-a9n is prior work that =
is not widely
>> implemented, some of the features are still unique to argus.   While =
IETF support
>> of technology is a good thing, descriptions of technology without =
reference
>> is a difficult thing to interpret.  Is the IPFIX WG describing what =
they think is new
>> technology? Does the IPFIX WG think that many companies have =
implemented
>> this type of technology, and now its time to standardize it ?  Well, =
I'm not aware
>> of any implementation, open or closed, that does the complete set of =
what the
>> draft is recommending, other than argus.  So I don't think its new, =
nor widely
>> implemented.  I would say its a form of technology plagiarism.
>>=20
>> IPFIX is considering adding non-IP flows to their definitions.  Argus =
is the only available
>> flow technology that has significant non-IP flow data models and =
support.  argus-1.2 had
>> flow generation, transport, analytics and storage of non-IP flows 20 =
years ago, with its
>> support for bi-directional ethernet, apple-talk and ARP transaction =
tracking and reporting.
>> In the last 10 years, argus has added MPLS, VLAN, ISO addresses, and =
Infiniband flow
>> models.  Not attributes, but true flow key elements.   This work is =
non-trivial.
>>=20
>> The concept that the WG would consider dropping the IP from IPFIX and =
think that is
>> all that is needed, is really so completely wrong, that its =
laughable, and a dis-service
>> to those that have done the hard work to bring situational awareness =
and analytics
>> to non-IP traffic.   The same applies to bi-directional flows, but =
that is another story.
>>=20
>> I would love to think that IPFIX could focus back on flow information =
exchange.
>> Multicast, non-template based connectionless transport strategies, =
say over UDT
>> as an example, rather than getting into areas for which the WG is =
unprepared to
>> do even a reasonable job, without resorting to dubious techniques.
>>=20
>> Just a few comments, I hope that anyone finds it useful.
>>=20
>> Carter
>>=20
>> Carter Bullard
>> CEO/President
>> QoSient, LLC
>> 150 E. 57th Street Suite 12D
>> New York, New York 10022
>>=20
>> +1 212 588-9133 Phone
>> +1 212 588-9134 Fax
>>=20
>>=20
>>=20
>>=20
>>=20
>>=20
>>=20
>> _______________________________________________
>> IPFIX mailing list
>> IPFIX@ietf.org
>> https://www.ietf.org/mailman/listinfo/ipfix
>=20
>=20
> --=20
> ---------------------------------------------------------------------
> 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
>=20


--Apple-Mail=_248AA176-EC60-4031-A900-4031B25FBD36
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=windows-1252


Carter Bullard
CEO/President
QoSient, =
LLC
150 E. 57th Street Suite =
12D
New York, New York =
10022

+1 212 588-9133 Phone
+1 212 588-9134 =
Fax





On Feb 29, 2012, at 2:48 AM, Nevil Brownlee =
wrote:


Hi Carter:

As the other IPFIX co-chair I =
feel bound to respond to your comments.

Your idea that an =
Internet Standard should document something
that has "dozens of =
implementations" is weird, to say the least.
In many cases there are =
different groups of people proposing
different ideas, so to begin =
with there isn't even a single
implementation.

Your comment =
about 'a Google search for "Argus flow splitting"' is
disingenuous. =
 When I spent some time with Google looking for
information =
about Argus and its implementation, I simply wasn't able
to find =
anything.  Nick Duffield's papers about sampling, i.e.
 =
 "Charging from sampled network usage" (2001),
 =
 "Properties and Prediction of Flow Statistics from Sampled
 =
   Packet Streams, " (2002),
  "Learn more, =
sample less: control of volume and variance in
 =
   network measurement," (2005),
all cite the Quosient =
web page for Argus' way of defining flows,
but there's no text in any =
of these papers about Argus itself!

The IPFIX WG provides a forum =
for interested people to contribute
ideas about information =
reporting.  If you have something you'd like to
see in a WG =
draft, you need to contribute some text about it on the
IPFIX list. =
In the case of the Aggregation draft, you simply haven't
done =
that.

In short:
 - If there is published material out there =
about Argus,
     please tell us about it.
 - =
Kindly withdraw your mischievous accusations of plagiarism, these
 =
    are unfounded.
 - Constructive technical =
discussion to the IPFIX list is, of course
 =
    always welcome.

Cheers, =
Nevil


On 02/27/2012 11:37 AM, Carter Bullard =
wrote:
Gentle =
people,
I'm generally pretty =
quiet when it comes to IPFIX and its efforts.  But as the =
first
person to develop IP =
flow records in the 1980's, first to present the idea to =
the
community in 1992, the =
first to provide open source flow technology in =
1995,
and the author of the =
longest lived open source flow system, argus; I feel =
that
I have to say something =
about the recent wave of IPFIX drafts.

The drafts on =
flow aggregation describe functionality that the Argus project =
started
over 20 years ago. =
 The ideas of key modification, conversion of non-key =
attributes
to key members, =
aggregation operators, interval distribution and the architecture for =
it,
were all developed in =
argus a long long time ago.  draft-ietf-ipfix-a9n is =
basically
describing the =
functionality of argus's racluster(), rasplit(), and rabins() =
programs,
and every example =
given in the text of draft-ietf-ipfix-a9n can be generated =
using
argus's rabins(), with =
only a few gyrations of its command-line, =
today.

I personally =
would expect that if the IETF was going to describe something that =
is
"Standards Track", that =
there would be dozen's of implementations of this kind =
of
technology available, and =
that the WG is condensing years of experience =
to
arrive at a "Standards =
Track", but, this is not the case.  There is only one =
current
implementation of the =
complete capabilities of the features of =
draft-ietf-ipfix-a9n
that I am =
aware of, and that is in argus.

Taking just one =
of the technical descriptions in the draft, "interval distribution", =
I
am not aware of any =
description of this issue, or implementation of this =
type
of technology in the =
literature, outside of argus.  No Google search results for =
"flow
interval distribution". =
  In Argus we call it flow splitting.  The first line =
from a
Google search for =
"argus flow splitting" return:

Scholarly =
articles for argus flow splitting
=85 and prediction of flow statistics from sampled packet =
=85 - Duffield - Cited by 217

I'm not saying =
that Nick knows much about argus's support for flow splitting, =
but
its still pretty scary =
that the first hit is from a paper that is used in IPFIX =
documents.
One would have to =
assume that the IPFIX community should be =
aware.

My problem is =
that most of  draft-ietf-ipfix-a9n is prior work that is not =
widely
implemented, some of =
the features are still unique to argus.   While IETF =
support
of technology is a =
good thing, descriptions of technology without =
reference
is a difficult thing =
to interpret.  Is the IPFIX WG describing what they think is =
new
technology? Does the IPFIX =
WG think that many companies have =
implemented
this type of =
technology, and now its time to standardize it ?  Well, I'm not =
aware
of any implementation, =
open or closed, that does the complete set of what =
the
draft is recommending, =
other than argus.  So I don't think its new, nor =
widely
implemented.  I =
would say its a form of technology =
plagiarism.

IPFIX is =
considering adding non-IP flows to their definitions.  Argus is the =
only available
flow technology =
that has significant non-IP flow data models and support. =
 argus-1.2 had
flow =
generation, transport, analytics and storage of non-IP flows 20 years =
ago, with its
support for =
bi-directional ethernet, apple-talk and ARP transaction tracking and =
reporting.
In the last 10 =
years, argus has added MPLS, VLAN, ISO addresses, and Infiniband =
flow
models.  Not =
attributes, but true flow key elements.   This work is =
non-trivial.

The concept =
that the WG would consider dropping the IP from IPFIX and think that =
is
all that is needed, is =
really so completely wrong, that its laughable, and a =
dis-service
to those that have =
done the hard work to bring situational awareness and =
analytics
to non-IP traffic. =
  The same applies to bi-directional flows, but that is =
another story.

I would love to =
think that IPFIX could focus back on flow information =
exchange.
Multicast, =
non-template based connectionless transport strategies, say over =
UDT
as an example, rather than =
getting into areas for which the WG is unprepared =
to
do even a reasonable job, =
without resorting to dubious techniques.

Just a few =
comments, I hope that anyone finds it =
useful.

Carter

Carter =
Bullard
CEO/President
QoSient, LLC
150 =
E. 57th Street Suite 12D
New =
York, New York 10022

+1 212 588-9133 =
Phone
+1 212 588-9134 =
Fax







_______________________________________________
IPFIX mailing =
list
IPFIX@ietf.org
https://www.ietf.org/=
mailman/listinfo/ipfix


-- =

---------------------------------------------------------------------<=
br> Nevil Brownlee =
            &n=
bsp;      Computer Science Department | =
ITS
 Phone: +64 9 373 7599 x88941 =
            Th=
e University of Auckland
 FAX: +64 9 373 7453   Private Bag =
92019, Auckland 1142, New =
Zealand


=
=

--Apple-Mail=_248AA176-EC60-4031-A900-4031B25FBD36--

--Apple-Mail=_86883A7A-C64D-4F66-8653-32084EE14502
Content-Disposition: attachment;
	filename=smime.p7s
Content-Type: application/pkcs7-signature;
	name=smime.p7s
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMRjCCBVAw
ggQ4oAMCAQICEE/C1XPaEv5Xc80XjVqbwwowDQYJKoZIhvcNAQEFBQAwgd0xCzAJBgNVBAYTAlVT
MRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y
azE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEg
KGMpMDkxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuVmVyaVNpZ24g
Q2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMzAeFw0xMTA0MTQwMDAwMDBaFw0x
MjA0MTMyMzU5NTlaMIIBEzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT
aWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9S
UEEgSW5jb3JwLiBieSBSZWYuLExJQUIuTFREKGMpOTgxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZh
bGlkYXRlZDEzMDEGA1UECxMqRGlnaXRhbCBJRCBDbGFzcyAxIC0gTmV0c2NhcGUgRnVsbCBTZXJ2
aWNlMRcwFQYDVQQDFA5DYXJ0ZXIgQnVsbGFyZDEhMB8GCSqGSIb3DQEJARYSY2FydGVyQHFvc2ll
bnQuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAnUsVMagrR+kSPj9tNNsMP6ZO
CRf4x70f3vT5OerV6rikEAz4XYJ+iv5Y6FiY5wjr2ez4BTrEuKwhAJN+aPSXHBW4cBZgB0J7mHwF
yJpY/vhhy2RrfugdCXjotFySXzevQHCfON4htlh+I3DYhN6LXmeBnnPtGz+J4mNZqdimZVlcdXqV
h0m7ysvdFkClht66vEvF+WObwLEpg3LIaFzTZBWpAiQ1FPIDJJd6uU//96grDvRy+D0oNjCkxmBp
bCkG0w1jaOuay6o62xRh7H41CxCRljzYjy3H4SwRYlYBwtqZuXg0YOI0OHdSuie6UyrUgmT+3S1U
FPiGz9yP9hninQIDAQABo4HSMIHPMAkGA1UdEwQCMAAwRAYDVR0gBD0wOzA5BgtghkgBhvhFAQcX
ATAqMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhMAsGA1UdDwQEAwIF
oDAdBgNVHSUEFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIwUAYDVR0fBEkwRzBFoEOgQYY/aHR0cDov
L2luZGMxZGlnaXRhbGlkLWczLWNybC52ZXJpc2lnbi5jb20vSW5kQzFEaWdpdGFsSUQtRzMuY3Js
MA0GCSqGSIb3DQEBBQUAA4IBAQBSg1+LGDk7EKu1hYCrpHEZVHY3I+850erL2DxLtfgzldWZPLYr
NpVa8wH5XTDhaFNLQgWwLMGfs8sJPkqXm2TfZfG7BkJWLtubW3Jw5jZ//Eygbae2IOU0bm1tAaG2
uoreBROJ5PU1ykK8aTnbNZxN772otsdHQ54gXd2wpPUoDoT740WzsdTeSI0ZXU+3J7RPbC0VHNfI
E88GgkTYBD5Xk3Ro+BSCBOh4XAA1ypHBZh2OX8C4syhPp6yfGWvwvqJ+oV5lkbAcO6FkeBlvb/Fi
XPa35ynGIIpntzpqOvr+0XJs8xq7hE8KU/QUNE6fa0gZyjxBVcbw89mv4lQx4FSOMIIG7jCCBdag
AwIBAgIQcRVmBUrkkSFN6bxE+azT3DANBgkqhkiG9w0BAQUFADCByjELMAkGA1UEBhMCVVMxFzAV
BgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTow
OAYDVQQLEzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVkIHVzZSBvbmx5
MUUwQwYDVQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRpZmljYXRpb24g
QXV0aG9yaXR5IC0gRzMwHhcNMDkwNTAxMDAwMDAwWhcNMTkwNDMwMjM1OTU5WjCB3TELMAkGA1UE
BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBO
ZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29t
L3JwYSAoYykwOTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJp
U2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEczMIIBIjANBgkqhkiG9w0B
AQEFAAOCAQ8AMIIBCgKCAQEA7cRH3yooHXwGa7vXITLJbBOP6bGNQU4099oL42r6ZYggCxET6Zvg
SU6Lb9UB0F8NR5GKWkx0Pj/GkQm7TDSejW6hglFi92l2WJYHr54UGAdPWr2f0jGyVBlzRmoZQhHs
EnMhjfXcMM3l2VYKMcU2bSkUl70t2olHGYjYSwQ967Y8Zx50ABMN0Ibak2f4MwOuGjxraXj2wCyO
4YM/d/mZ//6fUlrCtIcK2GypR8FUKWVDPkrAlh/Brfd3r2yxBF6+wbaULZeQLSfSux7pg2qE9sSy
riMGZSalJ1grByK0b6ZiSBp38tVQJ5op05b7KPW6JHZi44xZ6/tu1ULEvkHH9QIDAQABo4ICuTCC
ArUwNAYIKwYBBQUHAQEEKDAmMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC52ZXJpc2lnbi5jb20w
EgYDVR0TAQH/BAgwBgEB/wIBADBwBgNVHSAEaTBnMGUGC2CGSAGG+EUBBxcBMFYwKAYIKwYBBQUH
AgEWHGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9jcHMwKgYIKwYBBQUHAgIwHhocaHR0cHM6Ly93
d3cudmVyaXNpZ24uY29tL3JwYTA0BgNVHR8ELTArMCmgJ6AlhiNodHRwOi8vY3JsLnZlcmlzaWdu
LmNvbS9wY2ExLWczLmNybDAOBgNVHQ8BAf8EBAMCAQYwbgYIKwYBBQUHAQwEYjBgoV6gXDBaMFgw
VhYJaW1hZ2UvZ2lmMCEwHzAHBgUrDgMCGgQUS2u5KJYGDLvQUjibKaxLB4shBRgwJhYkaHR0cDov
L2xvZ28udmVyaXNpZ24uY29tL3ZzbG9nbzEuZ2lmMC4GA1UdEQQnMCWkIzAhMR8wHQYDVQQDExZQ
cml2YXRlTGFiZWw0LTIwNDgtMTE4MB0GA1UdDgQWBBR5R2EIQf04BKJL57XM9UP2SSsR+DCB8QYD
VR0jBIHpMIHmoYHQpIHNMIHKMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4x
HzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOjA4BgNVBAsTMShjKSAxOTk5IFZlcmlT
aWduLCBJbmMuIC0gRm9yIGF1dGhvcml6ZWQgdXNlIG9ubHkxRTBDBgNVBAMTPFZlcmlTaWduIENs
YXNzIDEgUHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgLSBHM4IRAItbdVaE
VIULAM+vOEjOsaQwDQYJKoZIhvcNAQEFBQADggEBADlNz0GZgbWpBbVSOOk5hIls5DSoWufYbAlM
JBq6WaSHO3Mh8ZOBz79oY1pn/jWFK6HDXaNKwjoZ3TDWzE3v8dKBl8pUWkO/N4t6jhmND0OojPKv
YLMVirOVnDzgnrMnmKQ1chfl/Cpdh9OKDcLRRSr4wPSsKpM61a4ScAjr+zvid+zoK2Q1ds262uDR
yxTWcVibvtU+fbbZ6CTFJGZMXZEfdrMXPn8NxiGJL7M3uKH/XLJtSd5lUkL7DojS7Uodv0vj+Mxy
+kgOZY5JyNb4mZg7t5Q+MXEGh/psWVMu198r7V9jAKwV7QO4VRaMxmgD5yKocwuxvKDaUljdCg5/
wYIxggSLMIIEhwIBATCB8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMu
MR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2Ug
YXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwOTEeMBwGA1UECxMVUGVyc29uYSBO
b3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2Ny
aWJlciBDQSAtIEczAhBPwtVz2hL+V3PNF41am8MKMAkGBSsOAwIaBQCgggJtMBgGCSqGSIb3DQEJ
AzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEyMDIyOTE2Mzg0NFowIwYJKoZIhvcNAQkE
MRYEFKQKVi5mj+Ae0CQHgVdFOW86Y358MIIBAwYJKwYBBAGCNxAEMYH1MIHyMIHdMQswCQYDVQQG
EwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5l
dHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20v
cnBhIChjKTA5MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMTLlZlcmlT
aWduIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzMCEE/C1XPaEv5Xc80XjVqb
wwowggEFBgsqhkiG9w0BCRACCzGB9aCB8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlT
aWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJt
cyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwOTEeMBwGA1UECxMV
UGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1
YWwgU3Vic2NyaWJlciBDQSAtIEczAhBPwtVz2hL+V3PNF41am8MKMA0GCSqGSIb3DQEBAQUABIIB
AH3+TZXhajNmGRAMdiqX8tIHgy4QhMu56rtCCXpQdQ0vleJohIZeZHkXY56esN1ufqZiI4oVimd4
6H66B+fArdcf7djHZA8kuVEWqIYhRds2x6eJgyK8CEOd21Yebmp8BHgMQ2LdQdnO4Eq9GgESluEY
psbMq4FwOVRPrvx5qmMic5yT6z7YZceZObk5DboK25mhvQz4gD/OU8EoVtuSWgb91vGvuaqchPER
J4qXDhRsTZRswQnz99BX1PCd9AIawoISOemknjPMIOyuPLrZOyODSBk4L/30ru2gaXU4Eng2RTei
xF5QDu3Mb30EyiL+wDo0tffRBNB/28R4LdeXbywAAAAAAAA=

--Apple-Mail=_86883A7A-C64D-4F66-8653-32084EE14502--

From Quittek@neclab.eu  Wed Feb 29 13:42:22 2012
Return-Path: 
X-Original-To: ipfix@ietfa.amsl.com
Delivered-To: ipfix@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 12B4421E8054 for ; Wed, 29 Feb 2012 13:42:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.388
X-Spam-Level: 
X-Spam-Status: No, score=-102.388 tagged_above=-999 required=5 tests=[AWL=0.211, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fw1EKXAtNvWk for ; Wed, 29 Feb 2012 13:42:15 -0800 (PST)
Received: from mailer1.neclab.eu (mailer1.neclab.eu [195.37.70.40]) by ietfa.amsl.com (Postfix) with ESMTP id 55CB621E8026 for ; Wed, 29 Feb 2012 13:42:15 -0800 (PST)
Received: from localhost (localhost.localdomain [127.0.0.1]) by mailer1.neclab.eu (Postfix) with ESMTP id B225628000085; Wed, 29 Feb 2012 22:42:04 +0100 (CET)
X-Virus-Scanned: Amavisd on Debian GNU/Linux (netlab.nec.de)
Received: from mailer1.neclab.eu ([127.0.0.1]) by localhost (atlas1.office.hd [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SgfzWOR3Ked9; Wed, 29 Feb 2012 22:42:04 +0100 (CET)
Received: from METHONE.office.hd (Methone.office.hd [192.168.24.54]) by mailer1.neclab.eu (Postfix) with ESMTP id 9059A28000084; Wed, 29 Feb 2012 22:41:44 +0100 (CET)
Received: from DAPHNIS.office.hd ([169.254.2.41]) by METHONE.office.hd ([192.168.24.54]) with mapi id 14.01.0323.003; Wed, 29 Feb 2012 22:41:22 +0100
From: Juergen Quittek 
To: Carter Bullard 
Thread-Topic: [IPFIX] recent ipfix drafts and argus
Thread-Index: AQHM9yrh2oqCh6Xz9UinsM99mFmsLw==
Date: Wed, 29 Feb 2012 21:41:23 +0000
Message-ID: 
In-Reply-To: 
Accept-Language: de-DE, en-US
Content-Language: de-DE
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.14.0.111121
x-originating-ip: [10.7.0.92]
Content-Type: text/plain; charset="Windows-1252"
Content-ID: 
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: Nevil Brownlee , Argus , IETF IPFIX Working Group 
Subject: Re: [IPFIX] recent ipfix drafts and argus
X-BeenThere: ipfix@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IPFIX WG discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 29 Feb 2012 21:42:22 -0000

Hi Carter,

If you think it would be beneficial for the draft to have a reference
to argus, then please make a concrete proposal which text or reference
should be added where to the draft.  Improvements are always welcome.

And yes, the IPFIX WG does give credits to contributions and sources
of ideas.  If we missed anything we accept comments and add credits.
And we welcome hints in this direction if they are concrete.

You claim in your message below that examples in draft-ietf-ipfix-a9n
have been taken from the argus web page.  So far you have not pointed
at anything concrete.  Your statements are too general such as "each
example in the draft" has taken somehow from argus.  Please be specific.
Which example from the IETF draft has been taken from which example on
the argus web site?

    Juergen=20


On 29.02.12 17:38, "Carter Bullard"  wrote:

>Nevil,I wasn't being disingenuous about Nick or the use of Google in any
>way.
>Nick put in references to argus in his papers, and he didn't even really
>say anything about it.  He even spelled the company's name correctly.
>
>
>What I am saying is the aggregation draft is dealing with a topic that has
>been around for a very long time, and there are lots of implementations of
>all of the concepts needed in data aggregation around.  Billing packages,
>statistics packages,  graphing software all have to deal with these
>issues.
>I can provide you lots of text books that are good references on the
>topics of
>data aggregation that the flow community needs, if you are interested.
>
>With such an unbounded topic to talk about, with so much opportunity,
>why do all of the examples in the draft look like documented argus
>examples
>and program outputs?
>
>I stated this in the original email.  I am stating it now.  If you are
>going to use
>examples and technology from other efforts, reference those other efforts.
>
>But each example in the draft is either a specific aggregation where
>argus has
>dedicated programs to generate the output, or they are well documented
>examples from the argus web site or mailing list.
>
>For god's sake, just change the specific objects, the time intervals
>and the order and format of the output fields, and you would at least
>not look like you took the examples from argus program output.
>
>If you want to look like argus program output, fine. Mention argus.
>If you want to look like SiLK, then use SiLK, and mention it.  If you
>don't
>want to look like anybody's tools, then just change the format so it
>doesn't
>look like anybody's tools.
>
>The IPFIX WG is just a working group in the IETF.  It's mailing list is
>the
>only avenue to present issues regarding IPFIX WG business.  I am
>saying again, and hopefully for the last time, if you are going to use
>the work of other forums and groups in the flow community, simply give
>those efforts credit.  If you don't want to do that, modify your work so
>that it doesn't look like you just lifted it, without concern.
>
>Carter
>
>Carter Bullard
>CEO/President
>QoSient, LLC
>150 E. 57th Street Suite 12D
>New York, New York 10022
>
>+1 212 588-9133 Phone
>+1 212 588-9134 Fax
>
>
>
>
>
>On Feb 29, 2012, at 2:48 AM, Nevil Brownlee wrote:
>
>
>
>Hi Carter:
>
>As the other IPFIX co-chair I feel bound to respond to your comments.
>
>Your idea that an Internet Standard should document something
>that has "dozens of implementations" is weird, to say the least.
>In many cases there are different groups of people proposing
>different ideas, so to begin with there isn't even a single
>implementation.
>
>Your comment about 'a Google search for "Argus flow splitting"' is
>disingenuous.  When I spent some time with Google looking for
>information about Argus and its implementation, I simply wasn't able
>to find anything.  Nick Duffield's papers about sampling, i.e.
>  "Charging from sampled network usage" (2001),
>  "Properties and Prediction of Flow Statistics from Sampled
>    Packet Streams, " (2002),
>  "Learn more, sample less: control of volume and variance in
>    network measurement," (2005),
>all cite the Quosient web page for Argus' way of defining flows,
>but there's no text in any of these papers about Argus itself!
>
>The IPFIX WG provides a forum for interested people to contribute
>ideas about information reporting.  If you have something you'd like to
>see in a WG draft, you need to contribute some text about it on the
>IPFIX list. In the case of the Aggregation draft, you simply haven't
>done that.
>
>In short:
> - If there is published material out there about Argus,
>     please tell us about it.
> - Kindly withdraw your mischievous accusations of plagiarism, these
>     are unfounded.
> - Constructive technical discussion to the IPFIX list is, of course
>     always welcome.
>
>Cheers, Nevil
>
>
>On 02/27/2012 11:37 AM, Carter Bullard wrote:
>
>Gentle people,
>
>I'm generally pretty quiet when it comes to IPFIX and its efforts.  But
>as the first
>
>person to develop IP flow records in the 1980's, first to present the
>idea to the
>
>community in 1992, the first to provide open source flow technology in
>1995,
>
>and the author of the longest lived open source flow system, argus; I
>feel that
>
>I have to say something about the recent wave of IPFIX drafts.
>
>
>
>The drafts on flow aggregation describe functionality that the Argus
>project started
>
>over 20 years ago.  The ideas of key modification, conversion of non-key
>attributes
>
>to key members, aggregation operators, interval distribution and the
>architecture for it,
>
>were all developed in argus a long long time ago.  draft-ietf-ipfix-a9n
>is basically
>
>describing the functionality of argus's racluster(), rasplit(), and
>rabins() programs,
>
>and every example given in the text of draft-ietf-ipfix-a9n can be
>generated using
>
>argus's rabins(), with only a few gyrations of its command-line, today.
>
>
>
>I personally would expect that if the IETF was going to describe
>something that is
>
>"Standards Track", that there would be dozen's of implementations of this
>kind of
>
>technology available, and that the WG is condensing years of experience to
>
>arrive at a "Standards Track", but, this is not the case.  There is only
>one current
>
>implementation of the complete capabilities of the features of
>draft-ietf-ipfix-a9n
>
>that I am aware of, and that is in argus.
>
>
>
>Taking just one of the technical descriptions in the draft, "interval
>distribution", I
>
>am not aware of any description of this issue, or implementation of this
>type
>
>of technology in the literature, outside of argus.  No Google search
>results for "flow
>
>interval distribution".   In Argus we call it flow splitting.  The first
>line from a
>
>Google search for "argus flow splitting" return:
>
>
>
>Scholarly articles for argus flow splitting
>
>=8A and prediction of flow statistics from sampled packet =8A - Duffield -
>Cited by 217
>
>
>
>I'm not saying that Nick knows much about argus's support for flow
>splitting, but
>
>its still pretty scary that the first hit is from a paper that is used in
>IPFIX documents.
>
>One would have to assume that the IPFIX community should be aware.
>
>
>
>My problem is that most of  draft-ietf-ipfix-a9n is prior work that is
>not widely
>
>implemented, some of the features are still unique to argus.   While IETF
>support
>
>of technology is a good thing, descriptions of technology without
>reference
>
>is a difficult thing to interpret.  Is the IPFIX WG describing what they
>think is new
>
>technology? Does the IPFIX WG think that many companies have implemented
>
>this type of technology, and now its time to standardize it ?  Well, I'm
>not aware
>
>of any implementation, open or closed, that does the complete set of what
>the
>
>draft is recommending, other than argus.  So I don't think its new, nor
>widely
>
>implemented.  I would say its a form of technology plagiarism.
>
>
>
>IPFIX is considering adding non-IP flows to their definitions.  Argus is
>the only available
>
>flow technology that has significant non-IP flow data models and support.
> argus-1.2 had
>
>flow generation, transport, analytics and storage of non-IP flows 20
>years ago, with its
>
>support for bi-directional ethernet, apple-talk and ARP transaction
>tracking and reporting.
>
>In the last 10 years, argus has added MPLS, VLAN, ISO addresses, and
>Infiniband flow
>
>models.  Not attributes, but true flow key elements.   This work is
>non-trivial.
>
>
>
>The concept that the WG would consider dropping the IP from IPFIX and
>think that is
>
>all that is needed, is really so completely wrong, that its laughable,
>and a dis-service
>
>to those that have done the hard work to bring situational awareness and
>analytics
>
>to non-IP traffic.   The same applies to bi-directional flows, but that
>is another story.
>
>
>
>I would love to think that IPFIX could focus back on flow information
>exchange.
>
>Multicast, non-template based connectionless transport strategies, say
>over UDT
>
>as an example, rather than getting into areas for which the WG is
>unprepared to
>
>do even a reasonable job, without resorting to dubious techniques.
>
>
>
>Just a few comments, I hope that anyone finds it useful.
>
>
>
>Carter
>
>
>
>Carter Bullard
>
>CEO/President
>
>QoSient, LLC
>
>150 E. 57th Street Suite 12D
>
>New York, New York 10022
>
>
>
>+1 212 588-9133 Phone
>
>+1 212 588-9134 Fax
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>_______________________________________________
>
>IPFIX mailing list
>
>IPFIX@ietf.org
>
>https://www.ietf.org/mailman/listinfo/ipfix
>
>
>
>
>--=20
>---------------------------------------------------------------------
> Nevil Brownlee                    Computer Science Department | ITS
> Phone: +64 9 373 7599 x88941             The University of Auckland
> FAX: +64 9 373 7453   Private Bag 92019, Auckland 1142, New Zealand
>
>
>
>
>
>
>
>
>
>
>
>_______________________________________________
>IPFIX mailing list
>IPFIX@ietf.org
>https://www.ietf.org/mailman/listinfo/ipfix