From iesg-secretary@ietf.org Tue Jul 3 14:17: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 59A8F11E814B; Tue, 3 Jul 2012 14:17:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.502 X-Spam-Level: X-Spam-Status: No, score=-102.502 tagged_above=-999 required=5 tests=[AWL=0.097, 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 9mm0AgxeKxwH; Tue, 3 Jul 2012 14:17:18 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A7B0511E80A3; Tue, 3 Jul 2012 14:17:18 -0700 (PDT) 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: 4.30 Message-ID: <20120703211718.3017.75070.idtracker@ietfa.amsl.com> Date: Tue, 03 Jul 2012 14:17:18 -0700 Cc: ipfix@ietf.org Subject: [IPFIX] Last Call: (Guidelines for Authors and Reviewers of IPFIX Information Elements) to Best Current Practice 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: Tue, 03 Jul 2012 21:17:19 -0000 The IESG has received a request from the IP Flow Information Export WG (ipfix) to consider the following document: - 'Guidelines for Authors and Reviewers of IPFIX Information Elements' as Best Current Practice 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-07-17. 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 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. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-ipfix-ie-doctors/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-ipfix-ie-doctors/ballot/ No IPR declarations have been submitted directly on this I-D. From n.brownlee@auckland.ac.nz Tue Jul 3 20:00: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 70FCE11E80E4 for ; Tue, 3 Jul 2012 20:00:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, 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 a++cztUtv4Bp for ; Tue, 3 Jul 2012 20:00:30 -0700 (PDT) Received: from mx2.auckland.ac.nz (mx2.auckland.ac.nz [130.216.12.44]) by ietfa.amsl.com (Postfix) with ESMTP id 667C011E80BF for ; Tue, 3 Jul 2012 20:00:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=n.brownlee@auckland.ac.nz; q=dns/txt; s=uoa; t=1341370840; x=1372906840; h=message-id:date:from:mime-version:to:subject: content-transfer-encoding; bh=dFPhYhk0WKGOPLjpwKw/LPF8LBcBtAQuu5FrqTKwPFw=; b=qkQKRK5nMztMCDhAv1VjX9L/5IANr0fJTqUW2zhgxANEf2dJ4PB7M+En bsEX88rt5woPi4Q4S1HqB1/YLPPHXgUhpVGka7Z9GCjRivWl1nIfQb3En 8R0DQsiZGp0axeOsw8d/+YnjnCx8gXGiURAAeQ8dAek20fxhdXj+RinN4 k=; X-IronPort-AV: E=Sophos;i="4.77,519,1336305600"; d="scan'208";a="130950915" X-Ironport-HAT: UNIVERSITY - $RELAY-THROTTLE X-Ironport-Source: 130.216.38.131 - Outgoing - Outgoing-SSL Received: from nevil-laptop1.sfac.auckland.ac.nz (HELO [130.216.38.131]) ([130.216.38.131]) by mx2-int.auckland.ac.nz with ESMTP; 04 Jul 2012 15:00:36 +1200 Message-ID: <4FF3B1D3.6010307@auckland.ac.nz> Date: Wed, 04 Jul 2012 15:00:35 +1200 From: Nevil Brownlee User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: IPFIX Working Group Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [IPFIX] Initial draft of agenda for Vancouver meeting 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, 04 Jul 2012 03:00:31 -0000 Hi all: Here's my first draft of our Vancouver agenda. Please email me any changes, requests for meeting time, etc. Cheers, Nevil =========================================== IP Flow Information Export WG (ipfix) Agenda for IETF 84, Paris >>> DRAFT-00 <<< Thursday, 2 August, 1300-1500, Regency A =========================================== Chairs: Juergen Quittek Nevil Brownlee AGENDA: 1. Agenda review = 5 min 2. Update from last meeting / WG Status (Nevil) = 10 min IPFIX MIB RFC 6615 (Obsoletes 5815) published June 2012 IPFIX Configuration Model draft-ietf-ipfix-configuration-model-10, 18 Jul 11 Waiting on PSAMP MIB PSAMP MIB draft-ietf-ipfix-psamp-mib-04.txt, 27 Feb 12 Waiting on IPFIX MIB Flow Selection Techniques draft-ietf-ipfix-flow-selection-tech-11, 23 Apr 12 In AD Evaluation: Revised ID needed Guidelines for Information Elements (Brian Trammell) draft-ietf-ipfix-ie-doctors-03, in IETF Last Call IPFIX Aggregation (Brian Trammell) #IPR disclosures for IPFIX Aggregation (Avaya, Cisco) draft-ietf-ipfix-a9n-04, 27 June 12 <<< Nevil to do write-up draft-claise-export-application-info-In-ipfix-089 has been sent to IESG as an Individual submission, currently has two DISCUSSes 3. Current charter work items = 70 min b) Specification of the IP Flow Information eXport (IPFIX) Protocol for the Exchange of Flow Information (Brian Trammell) draft-ietf-ipfix-protocol-rfc5101bis-01, 7 Mar 11 c) Information Model for IP Flow Information eXport (IPFIX) (Brian Trammell) draft-ietf-ipfix-information-model-rfc5102bis-00, 24 Jan 12 e) Protocol for PFIX Mediation (Brian Trammell) draft-ietf-ipfix-mediation-protocol-00, 6 Dec 11 f) IEs for Data Link Layer Traffic Measurement (Paul Aitken) draft-ipfix-data-link-layer-monitoring-00 g) Exporting MIB objects (Paul Aitken) draft-ipfix-mib-variable-export-00 4. Other drafts = 20 min a) Reporting Unobserved Fields in IPFIX (Paul Aitken) draft-aitken-ipfix-unobserved-field, 30 Jan 12 b) tcpWindow Information Elements (Paul Aitken) c) VoIP Information elements in IPFIX (Hendrik Scholtz) draft-scholz-ipfix-rtp-msg-00, 5 Mar 12 d) Cisco Specific Information Elements reused in IPFIX (Andrew Yourtchenko) draft-yourtchenko-cisco-ies-03, 12 Mar 12 5. Discussion of future direction for IPFIX (if time allows) = 10 min 6. Any Other Business = 5 min -- --------------------------------------------------------------------- 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 internet-drafts@ietf.org Thu Jul 5 07:37: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 4DC3521F8557; Thu, 5 Jul 2012 07:37:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.52 X-Spam-Level: X-Spam-Status: No, score=-102.52 tagged_above=-999 required=5 tests=[AWL=0.079, 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 1PhBl0tUnesv; Thu, 5 Jul 2012 07:37:49 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B484721F8512; Thu, 5 Jul 2012 07:37:49 -0700 (PDT) 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.30 Message-ID: <20120705143749.2906.6667.idtracker@ietfa.amsl.com> Date: Thu, 05 Jul 2012 07:37:49 -0700 Cc: ipfix@ietf.org Subject: [IPFIX] I-D Action: draft-ietf-ipfix-psamp-mib-05.txt X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jul 2012 14:37:50 -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 Group = of the IETF. Title : Definitions of Managed Objects for Packet Sampling Author(s) : Thomas Dietz Benoit Claise Juergen Quittek Filename : draft-ietf-ipfix-psamp-mib-05.txt Pages : 28 Date : 2012-07-05 Abstract: This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes extensions to the IPFIX SELECTOR MIB module. For IPFIX implementations that use packet Sampling (PSAMP) techniques, this memo defines the PSAMP MIB module containing managed objects for providing information on applied packet selection functions and their parameters. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ipfix-psamp-mib There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-ipfix-psamp-mib-05 A diff from previous version is available at: http://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-ipfix-psamp-mib-05 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From Thomas.Dietz@neclab.eu Thu Jul 5 07:53: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 DBAED21F86E4 for ; Thu, 5 Jul 2012 07:53:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id avItisEwdizE for ; Thu, 5 Jul 2012 07:53:49 -0700 (PDT) Received: from mailer1.neclab.eu (mailer1.neclab.eu [195.37.70.40]) by ietfa.amsl.com (Postfix) with ESMTP id 9863521F86E1 for ; Thu, 5 Jul 2012 07:53:48 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailer1.neclab.eu (Postfix) with ESMTP id DD0BA101741; Thu, 5 Jul 2012 16:55:11 +0200 (CEST) X-Virus-Scanned: Amavisd on Debian GNU/Linux (netlab.nec.de) Received: from mailer1.neclab.eu ([127.0.0.1]) by localhost (atlas-a.office.hd [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zSN9nLwMFPZm; Thu, 5 Jul 2012 16:55:11 +0200 (CEST) Received: from ENCELADUS.office.hd (enceladus.office.hd [192.168.24.52]) by mailer1.neclab.eu (Postfix) with ESMTP id B5AAD10173F; Thu, 5 Jul 2012 16:55:01 +0200 (CEST) Received: from PALLENE.office.hd ([169.254.1.191]) by ENCELADUS.office.hd ([192.168.24.52]) with mapi id 14.01.0323.003; Thu, 5 Jul 2012 16:55:24 +0200 From: Thomas Dietz To: "ipfix@ietf.org" , Adrian Farrel Thread-Topic: [IPFIX] I-D Action: draft-ietf-ipfix-psamp-mib-05.txt Thread-Index: AQHNWrw3HH8zVYzDEE+caH15sgOuDpcaxZ2w Date: Thu, 5 Jul 2012 14:55:24 +0000 Message-ID: <75581E268A48F849916117B977D76D3734E43E6F@PALLENE.office.hd> References: <20120705143749.2906.6667.idtracker@ietfa.amsl.com> In-Reply-To: <20120705143749.2906.6667.idtracker@ietfa.amsl.com> Accept-Language: en-US, de-DE Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.1.1.108] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_019C_01CD5ACE.F7E00930" MIME-Version: 1.0 Subject: Re: [IPFIX] I-D Action: draft-ietf-ipfix-psamp-mib-05.txt X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jul 2012 14:53:51 -0000 ------=_NextPart_000_019C_01CD5ACE.F7E00930 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Dear all, Adrian, I just posted the new version of the above draft. Adrian, I believe I have addressed your discuss and your comments. Please check if you find the time. Thank you all and best regards, Thomas -- Thomas Dietz NEC Europe Ltd., NEC Laboratories, Network Research Division, 69115 Heidelberg, Germany NEC Europe Limited, Registered in England 2832014 Registered Office: NEC House, 1 Victoria Road, London W3 6BL > -----Original Message----- > From: ipfix-bounces@ietf.org [mailto:ipfix-bounces@ietf.org] On Behalf Of > internet-drafts@ietf.org > Sent: Thursday, July 05, 2012 4:38 PM > To: i-d-announce@ietf.org > Cc: ipfix@ietf.org > Subject: [IPFIX] I-D Action: draft-ietf-ipfix-psamp-mib-05.txt > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the IP Flow Information Export Working Group > of the IETF. > > Title : Definitions of Managed Objects for Packet Sampling > Author(s) : Thomas Dietz > Benoit Claise > Juergen Quittek > Filename : draft-ietf-ipfix-psamp-mib-05.txt > Pages : 28 > Date : 2012-07-05 > > Abstract: > This memo defines a portion of the Management Information Base (MIB) > for use with network management protocols in the Internet community. > In particular, it describes extensions to the IPFIX SELECTOR MIB > module. For IPFIX implementations that use packet Sampling (PSAMP) > techniques, this memo defines the PSAMP MIB module containing managed > objects for providing information on applied packet selection > functions and their parameters. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-ipfix-psamp-mib > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-ipfix-psamp-mib-05 > > A diff from previous version is available at: > http://tools.ietf.org/rfcdiff?url2=draft-ietf-ipfix-psamp-mib-05 > > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > IPFIX mailing list > IPFIX@ietf.org > https://www.ietf.org/mailman/listinfo/ipfix ------=_NextPart_000_019C_01CD5ACE.F7E00930 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIISNDCCA58w ggKHoAMCAQICASYwDQYJKoZIhvcNAQEFBQAwcTELMAkGA1UEBhMCREUxHDAaBgNVBAoTE0RldXRz Y2hlIFRlbGVrb20gQUcxHzAdBgNVBAsTFlQtVGVsZVNlYyBUcnVzdCBDZW50ZXIxIzAhBgNVBAMT GkRldXRzY2hlIFRlbGVrb20gUm9vdCBDQSAyMB4XDTk5MDcwOTEyMTEwMFoXDTE5MDcwOTIzNTkw MFowcTELMAkGA1UEBhMCREUxHDAaBgNVBAoTE0RldXRzY2hlIFRlbGVrb20gQUcxHzAdBgNVBAsT FlQtVGVsZVNlYyBUcnVzdCBDZW50ZXIxIzAhBgNVBAMTGkRldXRzY2hlIFRlbGVrb20gUm9vdCBD QSAyMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAqwujNeCLKRSxFIWvPBDkOW81XUqu 3ephjZVJ9G9koxpgZqSpQCKE2dSl5XiTDmgBrblNXDrO07ioQkDfz6O6gllqkhusHJraCCslJ/lp I0fx4Ossepv1EwLQfjR8wp48AFmr9doM9TI8K6xQ2tbD3oOUyqgMmTIOCEhWW2r72uFYWAFJX3JB PBUGAY5draq4k7TNnuun6GotUjTbOu9cdVHa2/Mx+e5xmDLEVBVEDPmbVe2t3xgIoKOGiknuUwWP GUzV3lh5m9JqHEKrxdWnz2gPluThYZh2YciRfNY+AOKRUIfhnQrmrZfSHcY6fcu82gM01Y5bAfVq B7cWtm5KfwIDAQABo0IwQDAdBgNVHQ4EFgQUMcN5G7r1U9cX4Il6LRdsCrMrnTMwDwYDVR0TBAgw BgEB/wIBBTAOBgNVHQ8BAf8EBAMCAQYwDQYJKoZIhvcNAQEFBQADggEBAJRkWa05ZOcp6xP+WsOL E1fIBCTwdHfAYONn++mJpoO/loJ8btTDPe+egG67KbSYerE7VOs5F0d+Go4L/B8xWTEEss4X8yzH YjZV4iLYiVW0mEiqZPrWHDbYRHhaWiM6V5f1ejBPrp9qTEsrjqAD4z7gqdTSe9KzqOJyPK2e/4BZ 5JtFtPY7sM05GZgy5eohYZDkMSGONLH3LzVKhRDa54o3Ib5ZY+DyhYgxU9RUFIVwefQuBncndS8f uIr5/sW62Dbkg+znZbe/Y1rzRq+BlDfUQYzWI9Yez/VoG0Rjolq6pzVZoeVwBZsOI1eZlAptujlj KIaS8xiE2PvRzwVWZFcwggQhMIIDCaADAgECAgIAxzANBgkqhkiG9w0BAQUFADBxMQswCQYDVQQG EwJERTEcMBoGA1UEChMTRGV1dHNjaGUgVGVsZWtvbSBBRzEfMB0GA1UECxMWVC1UZWxlU2VjIFRy dXN0IENlbnRlcjEjMCEGA1UEAxMaRGV1dHNjaGUgVGVsZWtvbSBSb290IENBIDIwHhcNMDYxMjE5 MTAyOTAwWhcNMTkwNjMwMjM1OTAwWjBaMQswCQYDVQQGEwJERTETMBEGA1UEChMKREZOLVZlcmVp bjEQMA4GA1UECxMHREZOLVBLSTEkMCIGA1UEAxMbREZOLVZlcmVpbiBQQ0EgR2xvYmFsIC0gRzAx MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA6ZvDZ4X5Da71jVTDllA1PWLpbkztlNcA W5UidNQg6zSP1uzAMQQLmYHiphTSUqAoI4SLdIkEXlvg4njBeMsWyyg1OXstkEXQ7aAAeny/Sg4b AMOG6VwrMRF7DPOCJEOMHDiLamgAmu7cT3ir0sYTm3at7t4m6O8Br3QPwQmi9mvOvdPNFDBP9eXj pMhim4IaAycwDQJlYE3t0QkjKpY1WCfTdsZxtpAdxO3/NYZ9bzOz2w/FEcKKg6GUXUFr2NIQ9Uz9 ylGs2b3vkoO72uuLFlZWQ8/h1RM9ph8nMM1JVNvJEzSacXXFbOqnC5j5IZ0nrz6jOTlIaoytyZn7 wxLyvQIDAQABo4HZMIHWMHAGA1UdHwRpMGcwZaBjoGGGX2h0dHA6Ly9wa2kudGVsZXNlYy5kZS9j Z2ktYmluL3NlcnZpY2UvYWZfRG93bmxvYWRBUkwuY3JsPy1jcmxfZm9ybWF0PVhfNTA5Ji1pc3N1 ZXI9RFRfUk9PVF9DQV8yMB0GA1UdDgQWBBRJt8bP6D0ff+pEexMp9/EKcD7eZDAfBgNVHSMEGDAW gBQxw3kbuvVT1xfgiXotF2wKsyudMzAOBgNVHQ8BAf8EBAMCAQYwEgYDVR0TAQH/BAgwBgEB/wIB AjANBgkqhkiG9w0BAQUFAAOCAQEAO+Fad8BIF9ypGOyBr1qJ8L0okqbKWRgScOwo8ueuf5Ys5/Jd GTH2Eyt0vb2Asrn3Z8k5onk74RER7mt4kTN+O18mJ3VTZY4zY+7Pc8OwkiNJIVB1I6EfGOKUhT0/ M+l3II2iveahhSlA9j9zMlgNCWum2oVswD+7jWZkViROrg0/MjUBW+mMgtlyWU+xhoXxdIVW5cP4 XPON7kezUwVw5+VNimmDKOETCYaeXsjqWB4MH/mk1FoEaP0oPosCtli19qEsN1cAZ6sjaI1jpe+Z a1z9S1b2q0CHNNQRkmzsh8UKCwczcrRvDB1ULNhRx8y/MNNDcvEyv4zOSWOoAPfyHDCCBS8wggQX oAMCAQICBA0hCkcwDQYJKoZIhvcNAQEFBQAwWjELMAkGA1UEBhMCREUxEzARBgNVBAoTCkRGTi1W ZXJlaW4xEDAOBgNVBAsTB0RGTi1QS0kxJDAiBgNVBAMTG0RGTi1WZXJlaW4gUENBIEdsb2JhbCAt IEcwMTAeFw0wODEwMjQwODUyMDhaFw0xOTA2MzAwMDAwMDBaMIGQMQswCQYDVQQGEwJERTEYMBYG A1UEChMPTkVDIEV1cm9wZSBMdGQuMSAwHgYDVQQLExdORUMgTGFib3JhdG9yaWVzIEV1cm9wZTES MBAGA1UEAxMJTkVDTEFCLUNBMTEwLwYJKoZIhvcNAQkBFiJ6ZXJ0aWZpemllcnVuZ3NzdGVsbGVA bncubmVjbGFiLmV1MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAnvIVsbURqjIOcbnf ruYkRceWOZpyvM2ebnYpbd1cP+zdWm6yR7HSO9ppOe1ZZFIasArqQpedPEFvcncSG94FRuW3ND4r Rcq08mbpUTmpWmXfdYlJpQezbsOHCWR74NXoEEbK6TPZIMFpJr6dzQDAxnRc7UOgO6JQ1V42Z39B PhIbPIWz64t8svafxbORmxulJn7F5zDLDcR1AEGyn+L9b645AGwapoKNh7cSQFTqdb6kGyPQjLWf tv09dvmBDKesrcyLZXuDWJ1LMeizSjUEygdSszNXD3gePgJaVaZDS3o923W5gAyPCTSxpAFj8XJ+ /7Ap5jJwYhjJgJ8khFR7JQIDAQABo4IBxDCCAcAwEgYDVR0TAQH/BAgwBgEB/wIBATALBgNVHQ8E BAMCAQYwHQYDVR0OBBYEFE8ch3od4C+Z9r4VqtE1nQ5K5ro2MB8GA1UdIwQYMBaAFEm3xs/oPR9/ 6kR7Eyn38QpwPt5kMC0GA1UdEQQmMCSBInplcnRpZml6aWVydW5nc3N0ZWxsZUBudy5uZWNsYWIu ZXUwgYgGA1UdHwSBgDB+MD2gO6A5hjdodHRwOi8vY2RwMS5wY2EuZGZuLmRlL2dsb2JhbC1yb290 LWNhL3B1Yi9jcmwvY2FjcmwuY3JsMD2gO6A5hjdodHRwOi8vY2RwMi5wY2EuZGZuLmRlL2dsb2Jh bC1yb290LWNhL3B1Yi9jcmwvY2FjcmwuY3JsMIGiBggrBgEFBQcBAQSBlTCBkjBHBggrBgEFBQcw AoY7aHR0cDovL2NkcDEucGNhLmRmbi5kZS9nbG9iYWwtcm9vdC1jYS9wdWIvY2FjZXJ0L2NhY2Vy dC5jcnQwRwYIKwYBBQUHMAKGO2h0dHA6Ly9jZHAyLnBjYS5kZm4uZGUvZ2xvYmFsLXJvb3QtY2Ev cHViL2NhY2VydC9jYWNlcnQuY3J0MA0GCSqGSIb3DQEBBQUAA4IBAQBsMQ+dD0mmi48dgDU4R6Q/ eXcY0zQcHNp1Vu1s3kwO0WahWB0tiqVBodvfTAWG44xuw0I7NXSTwQ68FU5P0GIQnvRFZyVJlDjr SNlLYxjqfmgb+KVm67o383cZIuDakEE0f29kULIEn2fg/HsDiBAXTsb4I19XaN0TXLI+PMhU+GDp sGCJrydeugEV7qi15q8yymjSAsYgnrc2wJuXpyQ9r3qCtP6aedAPSHqOT8ga1dLT2YRZFs3vNm7T HSr5JJymWMbfpD6OcbRTnNAjSMDHwJxgRBAflA6WzDVm7fk4jiWyLvJwWTMk19t8QLiKG7D0nYvj cEUYyiOSE+SFUTEdMIIFNTCCBB2gAwIBAgIED+0gWzANBgkqhkiG9w0BAQUFADCBkDELMAkGA1UE BhMCREUxGDAWBgNVBAoTD05FQyBFdXJvcGUgTHRkLjEgMB4GA1UECxMXTkVDIExhYm9yYXRvcmll cyBFdXJvcGUxEjAQBgNVBAMTCU5FQ0xBQi1DQTExMC8GCSqGSIb3DQEJARYiemVydGlmaXppZXJ1 bmdzc3RlbGxlQG53Lm5lY2xhYi5ldTAeFw0xMDA0MjAxMjQ5MTVaFw0xMzA0MTkxMjQ5MTVaMGAx CzAJBgNVBAYTAkRFMRgwFgYDVQQKEw9ORUMgRXVyb3BlIEx0ZC4xIDAeBgNVBAsTF05FQyBMYWJv cmF0b3JpZXMgRXVyb3BlMRUwEwYDVQQDEwxUaG9tYXMgRGlldHowggEiMA0GCSqGSIb3DQEBAQUA A4IBDwAwggEKAoIBAQD2mMcvPbgraEaWMV6uNCs6t88lhBczgfxybD46mwr8D3VaQLEnqTsBOAf/ Y8ARtq+P6Dkm2MBMXQG+Ebo2qhif6O4dH7whcG9E88F9247R2EJjcXmxMYZWYGQTI2vGw/joerRB waiwfxCXWBTLutbdWEEKL/DG9A1yQRPGJc+jJYfgm0ekYn+WESOLYaBH7G9aIIZQ7en3afhPpbQA Ajh92K240TG+VgBpe1vnDdth28Ps5XeN+otookDZHwwGQYwYrPZJtnhGIyjKMm7OkXL62Rf3aSoI doVUwYYS67RYYNOY0C7qOVyCUF+z4Bkn758sZhZzotiLQVT3AZ625PrvAgMBAAGjggHEMIIBwDAJ BgNVHRMEAjAAMAsGA1UdDwQEAwIF4DApBgNVHSUEIjAgBggrBgEFBQcDAgYIKwYBBQUHAwQGCisG AQQBgjcUAgIwHQYDVR0OBBYEFH9fxgi2EshupgLF49SzaAX0QFoMMB8GA1UdIwQYMBaAFE8ch3od 4C+Z9r4VqtE1nQ5K5ro2MCEGA1UdEQQaMBiBFlRob21hcy5EaWV0ekBuZWNsYWIuZXUwfQYDVR0f BHYwdDA4oDagNIYyaHR0cDovL2NkcDEucGNhLmRmbi5kZS9uZWNsYWItY2EvcHViL2NybC9jYWNy bC5jcmwwOKA2oDSGMmh0dHA6Ly9jZHAyLnBjYS5kZm4uZGUvbmVjbGFiLWNhL3B1Yi9jcmwvY2Fj cmwuY3JsMIGYBggrBgEFBQcBAQSBizCBiDBCBggrBgEFBQcwAoY2aHR0cDovL2NkcDEucGNhLmRm bi5kZS9uZWNsYWItY2EvcHViL2NhY2VydC9jYWNlcnQuY3J0MEIGCCsGAQUFBzAChjZodHRwOi8v Y2RwMi5wY2EuZGZuLmRlL25lY2xhYi1jYS9wdWIvY2FjZXJ0L2NhY2VydC5jcnQwDQYJKoZIhvcN AQEFBQADggEBACnPHI1mIY1TVY9Aj8zsHHxiwMRx02Hp6DLZGYXHGG9IkflrRKNiDIV2LbBDpXVH vojMxTtCt10iwbyVMGaevet/VHYCJSHzrCLkw+GkvuhDU70lNsWw9P+mai7OHa+NQ6im8+4RnY1B yhqidcCt3hIV9B69ax0/KIhIFpiWz/lKZVIghki07I4m8mf1sbvCORKxudH0TVLlRJlX1r8S+8ea 9e+Q8pgXfrsCeyxBV3KAjszRQkqDZsbD7jQHQWokkMPIjbaTjw6V/5SRzmcAy0XlKNOCbldlzmCB jDZTQWdSH/AFDy5L2l4j0Ck0vVlQv+r1F4omsb4BelRq+vHd+lExggQsMIIEKAIBATCBmTCBkDEL MAkGA1UEBhMCREUxGDAWBgNVBAoTD05FQyBFdXJvcGUgTHRkLjEgMB4GA1UECxMXTkVDIExhYm9y YXRvcmllcyBFdXJvcGUxEjAQBgNVBAMTCU5FQ0xBQi1DQTExMC8GCSqGSIb3DQEJARYiemVydGlm aXppZXJ1bmdzc3RlbGxlQG53Lm5lY2xhYi5ldQIED+0gWzAJBgUrDgMCGgUAoIICZzAYBgkqhkiG 9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xMjA3MDUxNDU1MjNaMCMGCSqGSIb3 DQEJBDEWBBRTL7IA1NURMiIJD5s0Zlpm3WGh3zCBqgYJKwYBBAGCNxAEMYGcMIGZMIGQMQswCQYD VQQGEwJERTEYMBYGA1UEChMPTkVDIEV1cm9wZSBMdGQuMSAwHgYDVQQLExdORUMgTGFib3JhdG9y aWVzIEV1cm9wZTESMBAGA1UEAxMJTkVDTEFCLUNBMTEwLwYJKoZIhvcNAQkBFiJ6ZXJ0aWZpemll cnVuZ3NzdGVsbGVAbncubmVjbGFiLmV1AgQP7SBbMIGrBgkqhkiG9w0BCQ8xgZ0wgZowCwYJYIZI AWUDBAEqMAsGCWCGSAFlAwQBFjAKBggqhkiG9w0DBzALBglghkgBZQMEAQIwDgYIKoZIhvcNAwIC AgCAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgFAMA0GCCqGSIb3DQMCAgEoMAcGBSsOAwIaMAsGCWCG SAFlAwQCAzALBglghkgBZQMEAgIwCwYJYIZIAWUDBAIBMIGsBgsqhkiG9w0BCRACCzGBnKCBmTCB kDELMAkGA1UEBhMCREUxGDAWBgNVBAoTD05FQyBFdXJvcGUgTHRkLjEgMB4GA1UECxMXTkVDIExh Ym9yYXRvcmllcyBFdXJvcGUxEjAQBgNVBAMTCU5FQ0xBQi1DQTExMC8GCSqGSIb3DQEJARYiemVy dGlmaXppZXJ1bmdzc3RlbGxlQG53Lm5lY2xhYi5ldQIED+0gWzANBgkqhkiG9w0BAQEFAASCAQCz 35Ah/Nyg6UfVVicbZBeGnL+QUjQDZwZekXwXPOuuX0YQGk9DXzVOa6skiaKieXTY0+xmbYe3jg3U Xi6PDup1pS8tO9ablAulDUq6neVkUTQffu80RMFw+VKT88rrFEM3mvqbqzkA9obfAvpmT15TGmtR zuRcMQm3Edn5RHqwqOA6UorTyM17svmshzfGf0czOQnKmFPsarEXH3OqhrkbQ6OhsM6kDUOM5wSk z7Uk4FPQL0eQpBRXvpZEn5NER8JcrEtwQ3BbmSu8e2U1Xl79U7zijZaJdARqqRjrXwFiYuxrdDtX XwEhBx9xNYa17prQIrLx2RVPRT0AStdDkoRWAAAAAAAA ------=_NextPart_000_019C_01CD5ACE.F7E00930-- From internet-drafts@ietf.org Fri Jul 6 00:52: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 46EB821F86AA; Fri, 6 Jul 2012 00:52:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[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 GVgx30Powoyt; Fri, 6 Jul 2012 00:52:17 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A28DF21F8652; Fri, 6 Jul 2012 00:52:17 -0700 (PDT) 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.30p2 Message-ID: <20120706075217.7706.52076.idtracker@ietfa.amsl.com> Date: Fri, 06 Jul 2012 00:52:17 -0700 Cc: ipfix@ietf.org Subject: [IPFIX] I-D Action: draft-ietf-ipfix-a9n-05.txt X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jul 2012 07:52:18 -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 Group = 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-05.txt Pages : 48 Date : 2012-07-06 Abstract: This document provides a common implementation-independent basis for the interoperable application of the IP Flow Information Export (IPFIX) Protocol to the handling of Aggregated Flows, which are IPFIX Flow representing packets from multiple Original Flows sharing some set of common properties. It does this through a detailed terminology and a descriptive Intermediate Aggregation Process architecture, including a specification of methods for Original Flow counting and counter distribution across intervals. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ipfix-a9n There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-ipfix-a9n-05 A diff from previous version is available at: http://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-ipfix-a9n-05 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From trammell@tik.ee.ethz.ch Fri Jul 6 02:05: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 4164021F8714 for ; Fri, 6 Jul 2012 02:05:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oRkk6jlxzQ5k for ; Fri, 6 Jul 2012 02:05:39 -0700 (PDT) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) by ietfa.amsl.com (Postfix) with ESMTP id 706B721F870F for ; Fri, 6 Jul 2012 02:05:38 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id E38E7D9312 for ; Fri, 6 Jul 2012 11:05:50 +0200 (MEST) X-Virus-Scanned: by amavisd-new on smtp.ee.ethz.ch Received: from smtp.ee.ethz.ch ([127.0.0.1]) by localhost (.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 4Le6x1+I3JRp for ; Fri, 6 Jul 2012 11:05:50 +0200 (MEST) Received: from [10.0.27.104] (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 AF6EED930C for ; Fri, 6 Jul 2012 11:05:50 +0200 (MEST) From: Brian Trammell Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Fri, 6 Jul 2012 11:05:49 +0200 Message-Id: To: ipfix@ietf.org Mime-Version: 1.0 (Apple Message framework v1278) X-Mailer: Apple Mail (2.1278) Subject: [IPFIX] RFC5102bis vs http://www.iana.org/assignments/ipfix.xml X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jul 2012 09:05:40 -0000 Greetings, all, In editing rfc5101bis and rfc5102bis, I've noticed that both of these = documents carry over the basic assumption that RFC5102 (-bis) is the = normative reference for the IPFIX Information Element Registry. Indeed, = there have been a few conversations on this list that I read as, in = part, being caused by confusion by implementors or potential = implementors about which reference is canonical. =46rom discussions over time, I believe the intention of the WG is that = the IANA registry be normative; I've already edited the working copy of = rfc5102bis-03 to reflect this, and to point people at the IANA registry.=20= This in itself raises a procedural question: can an IANA registry be = normative? Second, almost everywhere in 5101 (and therefore 5101bis), readers are = pointed to 5102 (5102bis) as a reference for any specific Information = Element or Information Elements as a whole. I believe that these = references (where the target of the reference is an IE definition, and = not the definition of the information model itself) should be changed to = point to the registry instead. But this raises the procedural question = above, again. Thoughts? Can we do this? Or should be keep referring to 5102bis, and = hope that people will follow the references down to IANA? Many thanks, best regards, Brian From paitken@cisco.com Fri Jul 6 02:20: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 8667621F86BD for ; Fri, 6 Jul 2012 02:20:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.099 X-Spam-Level: X-Spam-Status: No, score=-10.099 tagged_above=-999 required=5 tests=[AWL=0.500, 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 FbWK7Kve4hrv for ; Fri, 6 Jul 2012 02:20:27 -0700 (PDT) Received: from ams-iport-4.cisco.com (ams-iport-4.cisco.com [144.254.224.147]) by ietfa.amsl.com (Postfix) with ESMTP id 114E321F86BE for ; Fri, 6 Jul 2012 02:20:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=paitken@cisco.com; l=1939; q=dns/txt; s=iport; t=1341566443; x=1342776043; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=rjoo0ClLs86qH4jLgS/HvV2jPRFXVOYvHDmbLzfL56A=; b=R4+yP7327K6yeHwopG0BjJrhtPrkp7snwe3/2OZuANZOv/IxAc/hXSzw LECS03c2GxFngQS5bDsb7RDC4eu+TFqEZ/DbyuPyUmS7gRn9xf+RsVkmN 87+Y7YPlrvFHuV8zT7IcNz/dBTI7gkbswzzURr/EjRU/a4uDLXkNFXpgH 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAB2t9k+Q/khN/2dsb2JhbABFtziBB4IYAQEBBAEBAQ8BJTYKARALEgYJFg8JAwIBAgEVIg4GDQEFAgEBHodpC5oXoB+RXwOVN4EShESIR4FmgmA X-IronPort-AV: E=Sophos;i="4.77,536,1336348800"; d="scan'208";a="6456469" Received: from ams-core-4.cisco.com ([144.254.72.77]) by ams-iport-4.cisco.com with ESMTP; 06 Jul 2012 09:20:39 +0000 Received: from [10.61.106.29] (dhcp-10-61-106-29.cisco.com [10.61.106.29]) by ams-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id q669KdNX019553; Fri, 6 Jul 2012 09:20:39 GMT Message-ID: <4FF6ADE7.9060507@cisco.com> Date: Fri, 06 Jul 2012 10:20:39 +0100 From: Paul Aitken User-Agent: Mozilla/5.0 (X11; Linux i686; rv:12.0) Gecko/20120430 Thunderbird/12.0.1 MIME-Version: 1.0 To: Brian Trammell References: <20120706075217.7706.52076.idtracker@ietfa.amsl.com> In-Reply-To: <20120706075217.7706.52076.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: ipfix@ietf.org Subject: Re: [IPFIX] I-D Action: draft-ietf-ipfix-a9n-05.txt X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jul 2012 09:20:28 -0000 Brian, FYI, I'm just finishing a long review of draft-ietf-ipfix-a9n-04. Has anyone else reviewed this recently? Also on my list: IE doctors and the -bis drafts. Who else has reviewed them? Thanks, P. On 06/07/12 08:52, 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-05.txt > Pages : 48 > Date : 2012-07-06 > > Abstract: > This document provides a common implementation-independent basis for > the interoperable application of the IP Flow Information Export > (IPFIX) Protocol to the handling of Aggregated Flows, which are IPFIX > Flow representing packets from multiple Original Flows sharing some > set of common properties. It does this through a detailed > terminology and a descriptive Intermediate Aggregation Process > architecture, including a specification of methods for Original Flow > counting and counter distribution across intervals. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-ipfix-a9n > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-ipfix-a9n-05 > > A diff from previous version is available at: > http://tools.ietf.org/rfcdiff?url2=draft-ietf-ipfix-a9n-05 > > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > IPFIX mailing list > IPFIX@ietf.org > https://www.ietf.org/mailman/listinfo/ipfix From internet-drafts@ietf.org Fri Jul 6 02:52:27 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 87E4D21F85D9; Fri, 6 Jul 2012 02:52:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[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 pKJPz0RjubPg; Fri, 6 Jul 2012 02:52:26 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B5DBA21F8543; Fri, 6 Jul 2012 02:52:14 -0700 (PDT) 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.30p2 Message-ID: <20120706095214.32520.67677.idtracker@ietfa.amsl.com> Date: Fri, 06 Jul 2012 02:52:14 -0700 Cc: ipfix@ietf.org Subject: [IPFIX] I-D Action: draft-ietf-ipfix-mediation-protocol-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: Fri, 06 Jul 2012 09:52:28 -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 Group = of the IETF. Title : Operation of the IP Flow Information Export (IPFIX) Prot= ocol on IPFIX Mediators Author(s) : Benoit Claise Atsushi Kobayashi Brian Trammell Filename : draft-ietf-ipfix-mediation-protocol-02.txt Pages : 27 Date : 2012-07-06 Abstract: This document specifies the the operation of the IP Flow Information Export (IPFIX) protocol specific to IPFIX Mediators, including Template and Observation Point management, timing considerations, and other Mediator-specific concerns. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ipfix-mediation-protocol There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-ipfix-mediation-protocol-02 A diff from previous version is available at: http://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-ipfix-mediation-protocol-02 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From trammell@tik.ee.ethz.ch Fri Jul 6 02:56:34 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 DA2D921F8769 for ; Fri, 6 Jul 2012 02:56:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ch9Eug-IAcE9 for ; Fri, 6 Jul 2012 02:56:34 -0700 (PDT) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) by ietfa.amsl.com (Postfix) with ESMTP id DBB7021F8767 for ; Fri, 6 Jul 2012 02:56:33 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id 76CEAD930D for ; Fri, 6 Jul 2012 11:56:49 +0200 (MEST) X-Virus-Scanned: by amavisd-new on smtp.ee.ethz.ch Received: from smtp.ee.ethz.ch ([127.0.0.1]) by localhost (.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with LMTP id kKUuZSW2MI3T for ; Fri, 6 Jul 2012 11:56:49 +0200 (MEST) Received: from [10.0.27.104] (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 2CFAED930C for ; Fri, 6 Jul 2012 11:56:49 +0200 (MEST) From: Brian Trammell Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Fri, 6 Jul 2012 11:56:48 +0200 References: <20120706095214.32520.67677.idtracker@ietfa.amsl.com> To: ipfix@ietf.org Message-Id: Mime-Version: 1.0 (Apple Message framework v1278) X-Mailer: Apple Mail (2.1278) Subject: [IPFIX] Fwd: I-D Action: draft-ietf-ipfix-mediation-protocol-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: Fri, 06 Jul 2012 09:56:35 -0000 Greetings, all, I've posted a new revision of the mediation protocol draft which = addresses some trivial EDITOR'S NOTE concerns from the -01 version, in = advance of the Vancouver meeting. Additional progress (specifically = sections 4.1, 4.3, 4.4, and 5) will, I think, require discussion within = the WG. If you're interested in general Mediator operation, please = review the document and chime in on these, or any other open issues you = see. Best regards, Brian Begin forwarded message: > From: internet-drafts@ietf.org > Subject: [IPFIX] I-D Action: = draft-ietf-ipfix-mediation-protocol-02.txt > Date: July 6, 2012 11:52:14 AM GMT+02: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 : Operation of the IP Flow Information Export = (IPFIX) Protocol on IPFIX Mediators > Author(s) : Benoit Claise > Atsushi Kobayashi > Brian Trammell > Filename : draft-ietf-ipfix-mediation-protocol-02.txt > Pages : 27 > Date : 2012-07-06 >=20 > Abstract: > This document specifies the the operation of the IP Flow Information > Export (IPFIX) protocol specific to IPFIX Mediators, including > Template and Observation Point management, timing considerations, = and > other Mediator-specific concerns. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-ipfix-mediation-protocol >=20 > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-ipfix-mediation-protocol-02 >=20 > A diff from previous version is available at: > = http://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-ipfix-mediation-protocol-0= 2 >=20 >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > IPFIX mailing list > IPFIX@ietf.org > https://www.ietf.org/mailman/listinfo/ipfix From andrjohn@cisco.com Fri Jul 6 06:42:02 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 30C8521F869A for ; Fri, 6 Jul 2012 06:42:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eISZuhA1tmVp for ; Fri, 6 Jul 2012 06:42:00 -0700 (PDT) Received: from mtv-iport-3.cisco.com (mtv-iport-3.cisco.com [173.36.130.14]) by ietfa.amsl.com (Postfix) with ESMTP id B411C21F8699 for ; Fri, 6 Jul 2012 06:42:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=andrjohn@cisco.com; l=9668; q=dns/txt; s=iport; t=1341582137; x=1342791737; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=1m7vIsLAHIW6CyI2/Mqb4a9CO9YjwUr34AztWhkoBvQ=; b=Fd0cgrpZvfxbpPjyCs9xXaj1gnARstW/ZONXjR1SKeBlhIB4+YMihfgD IVm7Luk9+K5fIqHn62AdPqnn167liR+7q5syiKYNWv4kx9CYcboxGtAt0 qpuZXKrRoL1nMPYzKdWPE2y8znqDu4BvQOaMrz3s211+CzA3w/yo4Gkk4 s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EAJfq9k+rRDoG/2dsb2JhbAA7Crc5gQeCGAEBAQQBAQEPARRHCxALGC4nMAYTIodoAQuaJaAZBIs5EAqFLGADlTeOHYFmgmCBXg X-IronPort-AV: E=Sophos;i="4.77,537,1336348800"; d="scan'208";a="48635597" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-3.cisco.com with ESMTP; 06 Jul 2012 13:42:17 +0000 Received: from cisco.com (mrwint.cisco.com [64.103.70.36]) by mtv-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id q66DgFOW000574 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 6 Jul 2012 13:42:16 GMT Received: from ams-andrjohn-8716.cisco.com (ams-andrjohn-8716.cisco.com [10.55.163.39]) by cisco.com (8.14.4+Sun/8.8.8) with ESMTP id q66DgBt9014955; Fri, 6 Jul 2012 14:42:12 +0100 (BST) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=iso-8859-1 From: Andrew Johnson In-Reply-To: <4FEECE19.4080003@net.in.tum.de> Date: Fri, 6 Jul 2012 14:42:06 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <397E0C84-8482-4C4F-B1A3-95D42DEFA1E5@cisco.com> References: <4FDC9E8B.1070800@cisco.com> <4FDE112B.40706@net.in.tum.de> <4FE88612.1080702@cisco.com> <4FE896DE.6050908@net.in.tum.de> <4FE89B1A.5060301@cisco.com> <4FE89EE0.9020409@net.in.tum.de> <4FEECE19.4080003@net.in.tum.de> To: Gerhard Muenz X-Mailer: Apple Mail (2.1278) Cc: ipfix-ads@tools.ietf.org, IETF IPFIX Working Group , "ipfix-chairs@tools.ietf.org" Subject: Re: [IPFIX] new monitoring interval information elements 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, 06 Jul 2012 13:42:02 -0000 Hi Gerhard There is more than one way to present the model I describe. It would = seem to be valid to suggest that the Metering Process is re-initialising = every interval and you could use delta or total counts, but you would = also have to honour all the other aspects of re-initialising the = Metering Process, like resetting any Metering Process statistics being = gathered. I think this model would add a requirement on any Collecting = Process to understand new IEs that describe the Metering Process = re-initialisation in order to properly understand the total counts. I would like to model this using the idea that the interval is a common = property (i.e. key field) of the flow. Again, delta counts or total = counts *could* be used, because once a certain window has passed the new = flows would have a different set of keys. Delta counts make more sense = though, because then the collector doesn't have to be configured to = understand that the interval is the key. The collector would be free to = aggregate as it needs, with the ability to: * show the aggregate view of flows, i.e. aggregate each flow across = intervals * show the whole network over time, i.e. aggregate all flows per = interval * show how a flow evolves over time, i.e. filter out a flow and = display the per-interval info The problem we are having, is to accurately define IEs that can describe = the beginning and end of this interval. I was hoping that by laying out = the model, we could get some consensus on the model and the IE = definitions. My initial suggestion was: observationWindowStart dateTimeMilliseconds The absolute timestamp = of the beginning of the current Observation Window. observationWindowEnd dateTimeMilliseconds The absolute timestamp = of the end of the current Observation Window. but Observation Window is undefined. I'm open to suggestions on = improving these. Perhaps: meteringIntervalStart dateTimeMilliseconds The absolute timestamp = of beginning of the Metering Interval the observation = occurred in. Where a series of Metering = Intervals separates time into a a set of discrete = buckets of a configurable length.=20 meteringIntervalEnd dateTimeMilliseconds The absolute timestamp = of the end of the Metering Interval the observation = occurred in. See meteringIntervalStart. Cheers, Andrew On 30 Jun 2012, at 10:59, Gerhard Muenz wrote: > Andrew, >=20 > As I pointed out in my previous mail, the window IEs do not seem to be = compatible with the descriptions of existing *TotalCount IEs because = these refer to the time since (re-)initialization. You could use = *DeltaCount, though. >=20 > Gerhard >=20 >=20 > On 29.06.2012 01:25, Andrew Johnson wrote: >> Hi Gerhard >>=20 >> Thanks for your inputs on this thread. It seems to me that the idea = of "re-initialising" the Metering Process is pretty confusing, in light = of what we're actually doing. I think my mental mode of what is = happening is a bit different from Paul's, so let me start at the = beginning, show how I think of the behaviour, and see what we can come = up with to solve our problem. >>=20 >> We would like to split the monitored packet streams into discrete = buckets, based on time. >>=20 >> t0 -----> t1 -----> t2 -----> t3 -----> t4 -----> t5 -----> >>=20 >>=20 >> The packet stream is processed by the Metering Process as usual, and = flows form in the cache in the usual manner. However, observations from = one interval won't be merged with observations from a different = interval. Ideally, at the end of each interval, all flows are exported = and flushed from the cache. >>=20 >> There are several ways to think about this. One way is to explicitly = flush the cache at the end of each interval (i.e. reset / reinitialise = the Metering Process). The way I see it though, we could just make an = identifier of the current interval a key field and apply the = optimisation of allowing flows from outside the current interval to be = flushed from the cache ASAP, since we know they won't be updated again. >>=20 >> Hopefully that gives a bit of a bigger picture. What we are looking = for are two new fields that we can add to the flows, that identify the = beginning at end of the interval they were observed in. In some = circumstances the device may not fully stick to the provided interval = window, so we can't rely on the end of the interval really being the = intervalStart + intervalSize. >>=20 >> I was thinking of: >>=20 >> observationWindowStart dateTimeMilliseconds The absolute = timestamp of the beginning of the current Observation Window. >> observationWindowEnd dateTimeMilliseconds The absolute = timestamp of the end of the current Observation Window. >>=20 >>=20 >> However, Paul rightly pointed out to me that IPFIX doesn't have any = concept of an Observation Window, and we're not sure how we can define = that in description of the IE. The idea of re-initialising the Metering = Process may fit in with the current IPFIX model, but I don't think it = properly conveys the behaviour we're after. >>=20 >>=20 >> Kind regards, >>=20 >> Andrew >>=20 >>=20 >> On 25 Jun 2012, at 18:24, Gerhard Muenz wrote: >>> Paul, >>>=20 >>> It depends on what kind of interval you want to specify. >>>=20 >>> If you want to specify the (re-)initialization time of the Metering = Process, why not name the IE meteringProcessSysUpTime or (if you do not = like sysup) meteringProcessInitializationTime? >>> And mention (re-)initialization in the description? >>> Dito for exportingProcessInitializationTime etc. >>>=20 >>> If we need the stop time, you can use meteringProcessStopTime or so. >>>=20 >>> If you want to define a new interval which is not starting at = (re-)initialization time but later, then your definitions are ok. But = this means that you need to specify new counter elements for this = interval. >>>=20 >>> Thanks, >>> Gerhard >>>=20 >>>=20 >>> On 25.06.2012 19:08, Paul Aitken wrote: >>>> Gerhard, >>>>=20 >>>>> Ok, I see the difference to discontinuity time. >>>>>=20 >>>>> Some further thoughts: >>>>>=20 >>>>> The common understanding is that the "time since = re-initialization" >>>>> means sysUpTime. For example, have a look at the description of >>>>> flowEndSysUpTime: >>>>> "The relative timestamp of the last packet of this Flow. It = indicates >>>>> the number of milliseconds since the last (re-)initialization of = the >>>>> IPFIX Device (sysUpTime)." >>>>=20 >>>> Yes, sysUpTime (so specifically, flowStartSysUpTime and >>>> flowEndSysUpTime), are times "since the last (re-)initialization of = the >>>> IPFIX Device". >>>>=20 >>>> These are not necessarily related to the metering process. >>>>=20 >>>> Taking some other examples: octetTotalCount, packetTotalCount, >>>> droppedOctetTotalCount, droppedPacketTotalCount, = observedFlowTotalCount, >>>> ignoredPacketTotalCount, ignoredOctetTotalCount, >>>> postMCastOctetTotalCount, ... are all of the form: >>>>=20 >>>> "The total number of X since the Metering Process >>>> (re-)initialization for this Observation Point." >>>>=20 >>>> We could suppose that the Metering Process initialised at system = uptime. >>>> However, that may not be the case: it could have started any amount = of >>>> time later. eg, a user could configure a Metering Process at any = time. >>>> Or, an automated system could start and stop Metering Processes >>>> according to different times of day or different network = conditions. >>>> Without timestamps to tell us, we simply do not know. >>>>=20 >>>>=20 >>>>=20 >>>>> Your proposed IEs do not mention neither (re-)initialization nor >>>>> sysUpTime. They rather seem to specify a time interval which is >>>>> located somewhere within the sysuptime interval. Hence, the = interval >>>>> does not work to define the time frame of = exportedMessageTotalCount, >>>>> for example. You would need to define a new IE >>>>> exportedMessageInMonitoringInterval. >>>>=20 >>>> Indeed, because the IEs which I'm specifying here are particular to = the >>>> Monitoring Process, whereas exportedMessageTotalCount seems to = require a >>>> time reference for the Exporting Process. It's a related, though >>>> different, issue. >>>>=20 >>>> (ie, the Exporting Process may start from system init, or at any = time >>>> since then. It may have been started before, or after, the Metering >>>> Process. Without a suitable timestamp IE, we simply do not know.) >>>>=20 >>>>=20 >>>>> The different IE descriptions suggest that the time of >>>>> re-initialization (i.e. sysuptime) can be different for Metering >>>>> Process, Exporting Process etc. >>>>=20 >>>> Indeed this is so. There is no necessity for these to be the same. >>>>=20 >>>>=20 >>>>> It seems that we need IE to export sysUpTime for each process. >>>>=20 >>>> We agree. >>>>=20 >>>> So in principal, you understand what I'm trying to do. However, you >>>> would like clearer definitions of the Information Elements? >>>>=20 >>>> Thanks, >>>> P. >>>>=20 >>>=20 >>>=20 >>>=20 >>> _______________________________________________ >>> IPFIX mailing list >>> IPFIX@ietf.org >>> https://www.ietf.org/mailman/listinfo/ipfix >>=20 >=20 From paitken@cisco.com Fri Jul 6 08:22: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 F2A3221F8792 for ; Fri, 6 Jul 2012 08:22:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.182 X-Spam-Level: X-Spam-Status: No, score=-10.182 tagged_above=-999 required=5 tests=[AWL=0.417, 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 ZRk3OjXOCwMg for ; Fri, 6 Jul 2012 08:22:31 -0700 (PDT) Received: from ams-iport-3.cisco.com (ams-iport-3.cisco.com [144.254.224.146]) by ietfa.amsl.com (Postfix) with ESMTP id 9D37621F8773 for ; Fri, 6 Jul 2012 08:22:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=paitken@cisco.com; l=1951; q=dns/txt; s=iport; t=1341588168; x=1342797768; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=sibA9RpoA1V0kPQr/e4e/MXyGd4jDgp3zAR6+qIAKzc=; b=Ng2yrEzfYTmn4SARAo18DE/VcD3vxBuiaDR1LiheBsklO9iOjXPedWAt f4XLKTz3XkRhBsFt5BIEOAMbm5DjP1GVbo3rvicLOD7+Iy8vxeetOS85t rw8xUwl8GngaxWkVcoKQ0RoT7c0kX0CKs9shzbLbJbb/+7BrGSHTI67aE 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EANYB90+Q/khR/2dsb2JhbABFtz2BB4IYAQEBBAEBAQ8BJTYKARALGAkWDwkDAgECARUwBg0BBQIBAQUZh2kLmkGgIJFfA5U3hVaIR4FmgmA X-IronPort-AV: E=Sophos;i="4.77,537,1336348800"; d="scan'208";a="6461293" Received: from ams-core-1.cisco.com ([144.254.72.81]) by ams-iport-3.cisco.com with ESMTP; 06 Jul 2012 15:22:47 +0000 Received: from [10.61.106.29] (dhcp-10-61-106-29.cisco.com [10.61.106.29]) by ams-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id q66FMl0S032517; Fri, 6 Jul 2012 15:22:47 GMT Message-ID: <4FF702C8.1010109@cisco.com> Date: Fri, 06 Jul 2012 16:22:48 +0100 From: Paul Aitken User-Agent: Mozilla/5.0 (X11; Linux i686; rv:12.0) Gecko/20120430 Thunderbird/12.0.1 MIME-Version: 1.0 To: Brian Trammell References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: ipfix@ietf.org Subject: Re: [IPFIX] RFC5102bis vs http://www.iana.org/assignments/ipfix.xml X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jul 2012 15:22:33 -0000 Brian, I agree that the IANA registry needs to be normative, and the IPFIX docs should point there. I've requested around 70 new Information Elements from IANA - and more every week - which simply aren't listed anywhere else. We should not refer to 5102 as the master reference unless we plan to update it on a regular basis. Let's look at how other WGs with IANA registries have addressed this. P. On 06/07/12 10:05, Brian Trammell wrote: > Greetings, all, > > In editing rfc5101bis and rfc5102bis, I've noticed that both of these documents carry over the basic assumption that RFC5102 (-bis) is the normative reference for the IPFIX Information Element Registry. Indeed, there have been a few conversations on this list that I read as, in part, being caused by confusion by implementors or potential implementors about which reference is canonical. > > > From discussions over time, I believe the intention of the WG is that the IANA registry be normative; I've already edited the working copy of rfc5102bis-03 to reflect this, and to point people at the IANA registry. > > This in itself raises a procedural question: can an IANA registry be normative? > > Second, almost everywhere in 5101 (and therefore 5101bis), readers are pointed to 5102 (5102bis) as a reference for any specific Information Element or Information Elements as a whole. I believe that these references (where the target of the reference is an IE definition, and not the definition of the information model itself) should be changed to point to the registry instead. But this raises the procedural question above, again. > > Thoughts? Can we do this? Or should be keep referring to 5102bis, and hope that people will follow the references down to IANA? > > Many thanks, best regards, > > Brian > > _______________________________________________ > IPFIX mailing list > IPFIX@ietf.org > https://www.ietf.org/mailman/listinfo/ipfix From internet-drafts@ietf.org Fri Jul 6 14:50:34 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 B09ED21F862B; Fri, 6 Jul 2012 14:50:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.578 X-Spam-Level: X-Spam-Status: No, score=-102.578 tagged_above=-999 required=5 tests=[AWL=0.021, 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 SeXB24qtR-De; Fri, 6 Jul 2012 14:50:34 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E98AC21F8616; Fri, 6 Jul 2012 14:50:33 -0700 (PDT) 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.30p2 Message-ID: <20120706215033.17875.96013.idtracker@ietfa.amsl.com> Date: Fri, 06 Jul 2012 14:50:33 -0700 Cc: ipfix@ietf.org Subject: [IPFIX] I-D Action: draft-ietf-ipfix-mib-variable-export-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: Fri, 06 Jul 2012 21:50:35 -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 Group = of the IETF. Title : Exporting MIB Variables using the IPFIX Protocol Author(s) : Benoit Claise Paul Aitken Juergen Schoenwaelder Filename : draft-ietf-ipfix-mib-variable-export-00.txt Pages : 52 Date : 2012-07-06 Abstract: This document specifies a way to complement IPFIX Flow Records with Management Base (MIB) objects, avoiding the need to define new IPFIX Information Elements for existing Management Information Base objects that are already fully specified. This method requires an extension to the current IPFIX protocol. New Template Set and Options Template Sets are specified to allow the export of Simple Network Management Protocol (SNMP) MIB Objects along with IPFIX Information Elements. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ipfix-mib-variable-export There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-ipfix-mib-variable-export-00 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From internet-drafts@ietf.org Fri Jul 6 14:51: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 99AF521F8636; Fri, 6 Jul 2012 14:51:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.578 X-Spam-Level: X-Spam-Status: No, score=-102.578 tagged_above=-999 required=5 tests=[AWL=0.021, 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 PR4Q-cwN0uhT; Fri, 6 Jul 2012 14:51:24 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF03421F8661; Fri, 6 Jul 2012 14:51:24 -0700 (PDT) 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.30p2 Message-ID: <20120706215124.19465.56634.idtracker@ietfa.amsl.com> Date: Fri, 06 Jul 2012 14:51:24 -0700 Cc: ipfix@ietf.org Subject: [IPFIX] I-D Action: draft-ietf-ipfix-data-link-layer-monitoring-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: Fri, 06 Jul 2012 21:51:26 -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 Group = of the IETF. Title : Information Elements for Data Link Layer Traffic Measure= ment Author(s) : Shingo Kashima Atsushi Kobayashi Paul Aitken Filename : draft-ietf-ipfix-data-link-layer-monitoring-00.txt Pages : 34 Date : 2012-07-06 Abstract: This document describes Information Elements related to data link layer. They are used by the IP Flow Information Export (IPFIX) protocol for encoding measured data link layer traffic information. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ipfix-data-link-layer-monitoring There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-ipfix-data-link-layer-monitoring-00 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From trammell@tik.ee.ethz.ch Mon Jul 9 01:35: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 282C321F87EA for ; Mon, 9 Jul 2012 01:35:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.048 X-Spam-Level: X-Spam-Status: No, score=-5.048 tagged_above=-999 required=5 tests=[AWL=-0.749, BAYES_00=-2.599, MANGLED_SEX=2.3, 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 Aq8e-vMWV+Yp for ; Mon, 9 Jul 2012 01:35:53 -0700 (PDT) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) by ietfa.amsl.com (Postfix) with ESMTP id C65BC21F863C for ; Mon, 9 Jul 2012 01:35:52 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id 1016CD9305 for ; Mon, 9 Jul 2012 10:36:16 +0200 (MEST) X-Virus-Scanned: by amavisd-new on smtp.ee.ethz.ch Received: from smtp.ee.ethz.ch ([127.0.0.1]) by localhost (.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with LMTP id Q1Q+vyjvunHL for ; Mon, 9 Jul 2012 10:36:15 +0200 (MEST) Received: from pb-10243.ethz.ch (pb-10243.ethz.ch [82.130.102.152]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: briant) by smtp.ee.ethz.ch (Postfix) with ESMTPSA id C6AEAD9304 for ; Mon, 9 Jul 2012 10:36:15 +0200 (MEST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1278) From: Brian Trammell In-Reply-To: <20120706215033.17875.96013.idtracker@ietfa.amsl.com> Date: Mon, 9 Jul 2012 10:36:14 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <98C850CD-92E0-422A-A680-ECB6C5B4D13D@tik.ee.ethz.ch> References: <20120706215033.17875.96013.idtracker@ietfa.amsl.com> To: IETF IPFIX Working Group X-Mailer: Apple Mail (2.1278) Subject: Re: [IPFIX] I-D Action: draft-ietf-ipfix-mib-variable-export-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: Mon, 09 Jul 2012 08:35:54 -0000 hi, Benoit, Paul, Juergen, all, As the content of this document appears identical to = draft-johnson-ipfix-mib-variable-export-04, my comments as to a more = general extensible template mechanism = (http://www.ietf.org/mail-archive/web/ipfix/current/msg06347.html and = quoted below) apply as well to this draft. If the WG decides it doesn't make sense to use two SetIDs for this, I = would suggest an alternate approach, completely compatible with vanilla = 5101(-bis) IPFIX, which requires no new Set ID: simply use the extended = type information mechanism from RFC 5610. Here a template may have = multiple instances of the MIB OID Extension IE, then an Options Template = describing records scoped by templateID, informationElementNumber, and = informationElementIndex, containing a variable-length OID Information = Element. (Again, I'm not sure how to handle indexing here but a = mechanism similar to that described in the draft or in the message below = should work...) Best regards, Brian On Apr 9, 2012, at 9:07 PM, trammell@tik.ee.ethz.ch wrote: > Greetings, all, >=20 > I've had a look at draft-johnson-ipfix-mib-variable-export, and as I = noted at the meeting in Paris, have a concern about the mechanism = presented in section 5.3.x for adding extended field specifiers to = IPFIX. I'd like to suggest a generalization of this approach. >=20 > Supporting the description of fields in an IPFIX Record as MIB Objects = is a special case of extending the Information Element space in general. = I see two other _particular_ applications for this: the ability to flag = or index IEs within a template (to note reverse counters, indexes, = pre/post or other packet handling notation, and so on), and the ability = to add type restrictions to Structured Data containers (in order to = maintain template-level type information for templates containing = structured data). >=20 > However, completely defining these mechanisms is clearly out of scope = for the mibvar draft (and would delay it unnecessarily), so I'd like to = tweak the mechanism presented there such that it could be extended in = the future. >=20 > The basic mechanism I'm proposing is: >=20 > 1. the creation of an general Extended Template Set (Set ID 4) and an = Extended Options Template Set (Set ID 5). >=20 > 2. Extended Template Sets contain Templates with a Template Record = Header identical to those in Template Sets (Set ID 2); Extended Options = Template Sets contain Templates with a Template Record Header identical = to those in Options Template Sets (Set ID 3). >=20 > 3. Both contain Extended Field Specifiers, which for IANA Information = Elements appear as follows: >=20 > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |0| Information Element ident. | Field Length | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |M| IE Ext. ID | IE Ext. Len. | | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | > | Extension Content (defined by ID/Length) | > ... ... ... > | | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >=20 > and for enterprise-specific Information Elements appear as follows: >=20 > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |0| Information Element ident. | Field Length | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Enterprise Number | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |M| IE Ext. ID | IE Ext. Len. | | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | > | Extension Content (defined by ID/Length) | > ... ... ... > | | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >=20 >=20 > The two-byte field after the Field Length or the Enterprise Number is = an extension specifier: >=20 > 0 1 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |M| IE Ext. ID | IE Ext. Len. | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > ^ ^ ^ > | | Extension length (2-255 bytes, including = specifier) > | Extension type (as per new Template Extension Registry, see = below) > More Bit (1 =3D more extensions after this; 0 =3D this is the last = extension) >=20 > 4. The creation of a Template Extension Registry, to be managed by = IANA and modified by Standards Action, initially having the following = two entries: >=20 > IE Extension ID 0 =3D Null Extension: allows the specification of a = standard IPFIX Information Element not having any extension information = within an Extended Template Record. Null Extensions MAY have any length = (greater than the minimum 2). Their content SHOULD be zero and MUST be = ignored by the CP. This allows the maintenance of 32-bit alignment = within templates if desired by the EP; a non-extended IE could then look = either like: >=20 > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |0| Information Element ident. | Field Length | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |0| ext ID =3D 0 | ext len =3D 2 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >=20 > or: >=20 > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |0| Information Element ident. | Field Length | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |0| ext ID =3D 0 | ext len =3D 4 | 0 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >=20 > IE Extension ID 1 =3D MIB Variable Extension: allows the specification = of an Information Element as a MIB Object, as follows. The Information = Element Identifier is in this case _ignored_, but SHOULD be the MIB OID = IE. An EP MUST NOT export a Template with a MIB OID IE field without a = MIB Variable Extension attached. >=20 > 5. The definition of the MIB Variable Extension format, which as far = as I am concerned remains an open question. It's pretty clear that for = non-indexed MIB objects it looks very much like just sticking the = content in section 5.3.2 into the extension content: >=20 > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |0| MIB OID IE | Field Length | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |0| 1 (mibvar) | IE Ext. Len. | Index Count 0 | MIB OID Len | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | MIB Object Identifier | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >=20 > I'm not sure if I like the indexing mechanism specified in sections = 5.3.3 through 5.3.5 yet (I'm not an SNMP guy), so I might suggest = something. The question I _think_ I have an answer for but am not = convinced of: is there _ever_ a case where a MIB Object element will be = indexed by something _NOT_ in the enclosing template? If not, why not = just have a list of template field indices as MIB object indices? seems = like it would take a lot less effort at both the EP and the CP, and = would lead to a lot less possibility of exporting a bad extension. i.e.: >=20 > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |0| MIB OID IE | Field Length | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |0| 1 (mibvar) | IE Ext. Len. | Index Count 2 | MIB OID Len | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | MIB Object Identifier | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | field spec pos of 1st index | field spec pos of 2nd index | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >=20 > Thoughts? >=20 > Best regards, >=20 > Brian >=20 On Jul 6, 2012, at 11:50 PM, internet-drafts@ietf.org wrote: >=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 : Exporting MIB Variables using the IPFIX = Protocol > Author(s) : Benoit Claise > Paul Aitken > Juergen Schoenwaelder > Filename : draft-ietf-ipfix-mib-variable-export-00.txt > Pages : 52 > Date : 2012-07-06 >=20 > Abstract: > This document specifies a way to complement IPFIX Flow Records with > Management Base (MIB) objects, avoiding the need to define new IPFIX > Information Elements for existing Management Information Base = objects > that are already fully specified. >=20 > This method requires an extension to the current IPFIX protocol. = New > Template Set and Options Template Sets are specified to allow the > export of Simple Network Management Protocol (SNMP) MIB Objects = along > with IPFIX Information Elements. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-ipfix-mib-variable-export >=20 > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-ipfix-mib-variable-export-00 >=20 >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > IPFIX mailing list > IPFIX@ietf.org > https://www.ietf.org/mailman/listinfo/ipfix From paitken@cisco.com Mon Jul 9 02:09:01 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 E294C21F864B for ; Mon, 9 Jul 2012 02:09:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.242 X-Spam-Level: X-Spam-Status: No, score=-10.242 tagged_above=-999 required=5 tests=[AWL=0.357, 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 Ktzn8LvTnzov for ; Mon, 9 Jul 2012 02:09:01 -0700 (PDT) Received: from ams-iport-3.cisco.com (ams-iport-3.cisco.com [144.254.224.146]) by ietfa.amsl.com (Postfix) with ESMTP id AC47321F8648 for ; Mon, 9 Jul 2012 02:09:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=paitken@cisco.com; l=2141; q=dns/txt; s=iport; t=1341824965; x=1343034565; h=message-id:date:from:mime-version:to:subject:references: in-reply-to:content-transfer-encoding; bh=M2lJtOyWXBi9Z8joab/IAudbn4FXiDXB8mZfeExYOr8=; b=I/7ISP1k/nhlgaUUD2bLKjE4ncj1lcV3PJGo8BnIPOw1/9Lp5UMM+PbB FEs8XoXIaq/CIJNols2x4VG85zjhe1TlFyzMSh3y9wWwAAXMTroSTffcP x4xGExa9s1IE79d4Vzgdog9u3sSBeA8z4WFRfopAsA3w+l+NH/d8/7+Cn k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAFSf+k+Q/khR/2dsb2JhbABFt2iBB4IgAQEBBAEBAQ8BJTYKEQsYCRYPCQMCAQIBFTATBgIBAR6HawuafZ8djjCDHAOVNoEShESISYFmgmA X-IronPort-AV: E=Sophos;i="4.77,551,1336348800"; d="scan'208";a="6501081" Received: from ams-core-1.cisco.com ([144.254.72.81]) by ams-iport-3.cisco.com with ESMTP; 09 Jul 2012 09:09:24 +0000 Received: from [10.55.91.34] (dhcp-10-55-91-34.cisco.com [10.55.91.34]) by ams-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id q6999Nqv018660 for ; Mon, 9 Jul 2012 09:09:23 GMT Message-ID: <4FFA9FC4.5060408@cisco.com> Date: Mon, 09 Jul 2012 10:09:24 +0100 From: Paul Aitken User-Agent: Mozilla/5.0 (X11; Linux i686; rv:12.0) Gecko/20120430 Thunderbird/12.0.1 MIME-Version: 1.0 To: ipfix@ietf.org References: <20120706215124.19465.56634.idtracker@ietfa.amsl.com> In-Reply-To: <20120706215124.19465.56634.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [IPFIX] I-D Action: draft-ietf-ipfix-data-link-layer-monitoring-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: Mon, 09 Jul 2012 09:09:02 -0000 Dear All, This is the WG -00 version of the draft. The main change is that the previous version proposed IEs 347 through 354: | 347 | dataLinkFrameType | | 348 | sectionOffset | | 349 | sectionObservedOctets | | 350 | dot1qServiceInstanceTag | | 351 | dot1qServiceInstanceId | | 352 | dot1qServiceInstancePriority | | 353 | dot1qCustomerDestinationMacAddress | | 354 | dot1qCustomerSourceMacAddress | Unfortunately these have already been allocated for other purposes, so I've changed them all to "TBD". Hopefully nobody already implemented these? Other changes were: * authors: -Nakata, +Aitken * typos corrected * removed unused references. P. On 06/07/12 22:51, 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 : Information Elements for Data Link Layer Traffic Measurement > Author(s) : Shingo Kashima > Atsushi Kobayashi > Paul Aitken > Filename : draft-ietf-ipfix-data-link-layer-monitoring-00.txt > Pages : 34 > Date : 2012-07-06 > > Abstract: > This document describes Information Elements related to data link > layer. They are used by the IP Flow Information Export (IPFIX) > protocol for encoding measured data link layer traffic information. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-ipfix-data-link-layer-monitoring > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-ipfix-data-link-layer-monitoring-00 > > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > IPFIX mailing list > IPFIX@ietf.org > https://www.ietf.org/mailman/listinfo/ipfix From paitken@cisco.com Mon Jul 9 02:09: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 B3C7821F87E7 for ; Mon, 9 Jul 2012 02:09:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.286 X-Spam-Level: X-Spam-Status: No, score=-10.286 tagged_above=-999 required=5 tests=[AWL=0.313, 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 FP6Nmyuw2wTB for ; Mon, 9 Jul 2012 02:09:07 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id EEEC421F87DF for ; Mon, 9 Jul 2012 02:09:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=paitken@cisco.com; l=1727; q=dns/txt; s=iport; t=1341824971; x=1343034571; h=message-id:date:from:mime-version:to:subject:references: in-reply-to:content-transfer-encoding; bh=tcM3reob8ctNNNZXoT3KKO2nnMstv3SZZzauKJRlR7A=; b=hdoDmQbAajPFcs1SD+G87FcUIXiEGM9umSGwMy20ruVjYL4wiGTMlOVH mK93nBvkQyx7I3ocp0AOomXSPWThFIp9xdoRRj6q7AqOe/qshPbfEZ2qb BC61r3fAfBpuwkVtqPi76saOrYldPe310lQzEkkJW/L5oU/TWIpuBXDJd M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAOme+k+Q/khR/2dsb2JhbABFt2iBB4IgAQEBBAEBAQ8BJTYKEQsYCRYPCQMCAQIBFTATBgIBAR6HawuafZ8djjCDHAOVNoEShESISYFmgmA X-IronPort-AV: E=Sophos;i="4.77,551,1336348800"; d="scan'208";a="140868805" Received: from ams-core-1.cisco.com ([144.254.72.81]) by ams-iport-1.cisco.com with ESMTP; 09 Jul 2012 09:09:30 +0000 Received: from [10.55.91.34] (dhcp-10-55-91-34.cisco.com [10.55.91.34]) by ams-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id q6999TJH018676 for ; Mon, 9 Jul 2012 09:09:29 GMT Message-ID: <4FFA9FCA.9060504@cisco.com> Date: Mon, 09 Jul 2012 10:09:30 +0100 From: Paul Aitken User-Agent: Mozilla/5.0 (X11; Linux i686; rv:12.0) Gecko/20120430 Thunderbird/12.0.1 MIME-Version: 1.0 To: ipfix@ietf.org References: <20120706215033.17875.96013.idtracker@ietfa.amsl.com> In-Reply-To: <20120706215033.17875.96013.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [IPFIX] I-D Action: draft-ietf-ipfix-mib-variable-export-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: Mon, 09 Jul 2012 09:09:07 -0000 Dear All, This is the WG -00 version. There are no differences other than the name and date change. P. On 06/07/12 22:50, 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 : Exporting MIB Variables using the IPFIX Protocol > Author(s) : Benoit Claise > Paul Aitken > Juergen Schoenwaelder > Filename : draft-ietf-ipfix-mib-variable-export-00.txt > Pages : 52 > Date : 2012-07-06 > > Abstract: > This document specifies a way to complement IPFIX Flow Records with > Management Base (MIB) objects, avoiding the need to define new IPFIX > Information Elements for existing Management Information Base objects > that are already fully specified. > > This method requires an extension to the current IPFIX protocol. New > Template Set and Options Template Sets are specified to allow the > export of Simple Network Management Protocol (SNMP) MIB Objects along > with IPFIX Information Elements. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-ipfix-mib-variable-export > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-ipfix-mib-variable-export-00 > > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > IPFIX mailing list > IPFIX@ietf.org > https://www.ietf.org/mailman/listinfo/ipfix From internet-drafts@ietf.org Tue Jul 10 07:51: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 F406021F86DC; Tue, 10 Jul 2012 07:51:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.267 X-Spam-Level: X-Spam-Status: No, score=-102.267 tagged_above=-999 required=5 tests=[AWL=0.332, 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 Pq45LjyPtCae; Tue, 10 Jul 2012 07:51:13 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 54D4521F8702; Tue, 10 Jul 2012 07:51:13 -0700 (PDT) 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.30p3 Message-ID: <20120710145113.27881.87575.idtracker@ietfa.amsl.com> Date: Tue, 10 Jul 2012 07:51:13 -0700 Cc: ipfix@ietf.org Subject: [IPFIX] I-D Action: draft-ietf-ipfix-psamp-mib-06.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, 10 Jul 2012 14:51:14 -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 Group = of the IETF. Title : Definitions of Managed Objects for Packet Sampling Author(s) : Thomas Dietz Benoit Claise Juergen Quittek Filename : draft-ietf-ipfix-psamp-mib-06.txt Pages : 28 Date : 2012-07-10 Abstract: This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes extensions to the IPFIX SELECTOR MIB module. For IPFIX implementations that use packet Sampling (PSAMP) techniques, this memo defines the PSAMP MIB module containing managed objects for providing information on applied packet selection functions and their parameters. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ipfix-psamp-mib There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-ipfix-psamp-mib-06 A diff from previous version is available at: http://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-ipfix-psamp-mib-06 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From Thomas.Dietz@neclab.eu Tue Jul 10 07:55:24 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 CD97911E8088 for ; Tue, 10 Jul 2012 07:55:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fd5wqZ7MpgY6 for ; Tue, 10 Jul 2012 07:55:20 -0700 (PDT) Received: from mailer1.neclab.eu (mailer1.neclab.eu [195.37.70.40]) by ietfa.amsl.com (Postfix) with ESMTP id 5A86D11E808F for ; Tue, 10 Jul 2012 07:55:19 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailer1.neclab.eu (Postfix) with ESMTP id 876B81017C7 for ; Tue, 10 Jul 2012 16:57:44 +0200 (CEST) X-Virus-Scanned: Amavisd on Debian GNU/Linux (netlab.nec.de) Received: from mailer1.neclab.eu ([127.0.0.1]) by localhost (atlas-a.office.hd [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fh7FBlhJlAcj for ; Tue, 10 Jul 2012 16:57:44 +0200 (CEST) Received: from METHONE.office.hd (methone.office.hd [192.168.24.54]) by mailer1.neclab.eu (Postfix) with ESMTP id 6A0E61017C6 for ; Tue, 10 Jul 2012 16:57:39 +0200 (CEST) Received: from PALLENE.office.hd ([169.254.1.191]) by METHONE.office.hd ([192.168.24.54]) with mapi id 14.01.0323.003; Tue, 10 Jul 2012 16:56:45 +0200 From: Thomas Dietz To: "ipfix@ietf.org" Thread-Topic: [IPFIX] I-D Action: draft-ietf-ipfix-psamp-mib-06.txt Thread-Index: AQHNXqvPzzAHx+B1T0GGHZKtmDvprZcimtoQ Date: Tue, 10 Jul 2012 14:56:45 +0000 Message-ID: <75581E268A48F849916117B977D76D3734E4A144@PALLENE.office.hd> References: <20120710145113.27881.87575.idtracker@ietfa.amsl.com> In-Reply-To: <20120710145113.27881.87575.idtracker@ietfa.amsl.com> Accept-Language: en-US, de-DE Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.1.1.108] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_002D_01CD5EBC.FE6CD3E0" MIME-Version: 1.0 Subject: Re: [IPFIX] I-D Action: draft-ietf-ipfix-psamp-mib-06.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, 10 Jul 2012 14:55:24 -0000 ------=_NextPart_000_002D_01CD5EBC.FE6CD3E0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Dear all, this is a minor update which was requested by IANA to have a proper IANA consideration and action section. Best Regards, Thomas -- Thomas Dietz NEC Europe Ltd., NEC Laboratories, Network Research Division, 69115 Heidelberg, Germany NEC Europe Limited, Registered in England 2832014 Registered Office: NEC House, 1 Victoria Road, London W3 6BL > -----Original Message----- > From: ipfix-bounces@ietf.org [mailto:ipfix-bounces@ietf.org] On Behalf Of > internet-drafts@ietf.org > Sent: Tuesday, July 10, 2012 4:51 PM > To: i-d-announce@ietf.org > Cc: ipfix@ietf.org > Subject: [IPFIX] I-D Action: draft-ietf-ipfix-psamp-mib-06.txt > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the IP Flow Information Export Working Group > of the IETF. > > Title : Definitions of Managed Objects for Packet Sampling > Author(s) : Thomas Dietz > Benoit Claise > Juergen Quittek > Filename : draft-ietf-ipfix-psamp-mib-06.txt > Pages : 28 > Date : 2012-07-10 > > Abstract: > This memo defines a portion of the Management Information Base (MIB) > for use with network management protocols in the Internet community. > In particular, it describes extensions to the IPFIX SELECTOR MIB > module. For IPFIX implementations that use packet Sampling (PSAMP) > techniques, this memo defines the PSAMP MIB module containing managed > objects for providing information on applied packet selection > functions and their parameters. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-ipfix-psamp-mib > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-ipfix-psamp-mib-06 > > A diff from previous version is available at: > http://tools.ietf.org/rfcdiff?url2=draft-ietf-ipfix-psamp-mib-06 > > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > IPFIX mailing list > IPFIX@ietf.org > https://www.ietf.org/mailman/listinfo/ipfix ------=_NextPart_000_002D_01CD5EBC.FE6CD3E0 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIISNDCCA58w ggKHoAMCAQICASYwDQYJKoZIhvcNAQEFBQAwcTELMAkGA1UEBhMCREUxHDAaBgNVBAoTE0RldXRz Y2hlIFRlbGVrb20gQUcxHzAdBgNVBAsTFlQtVGVsZVNlYyBUcnVzdCBDZW50ZXIxIzAhBgNVBAMT GkRldXRzY2hlIFRlbGVrb20gUm9vdCBDQSAyMB4XDTk5MDcwOTEyMTEwMFoXDTE5MDcwOTIzNTkw MFowcTELMAkGA1UEBhMCREUxHDAaBgNVBAoTE0RldXRzY2hlIFRlbGVrb20gQUcxHzAdBgNVBAsT FlQtVGVsZVNlYyBUcnVzdCBDZW50ZXIxIzAhBgNVBAMTGkRldXRzY2hlIFRlbGVrb20gUm9vdCBD QSAyMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAqwujNeCLKRSxFIWvPBDkOW81XUqu 3ephjZVJ9G9koxpgZqSpQCKE2dSl5XiTDmgBrblNXDrO07ioQkDfz6O6gllqkhusHJraCCslJ/lp I0fx4Ossepv1EwLQfjR8wp48AFmr9doM9TI8K6xQ2tbD3oOUyqgMmTIOCEhWW2r72uFYWAFJX3JB PBUGAY5draq4k7TNnuun6GotUjTbOu9cdVHa2/Mx+e5xmDLEVBVEDPmbVe2t3xgIoKOGiknuUwWP GUzV3lh5m9JqHEKrxdWnz2gPluThYZh2YciRfNY+AOKRUIfhnQrmrZfSHcY6fcu82gM01Y5bAfVq B7cWtm5KfwIDAQABo0IwQDAdBgNVHQ4EFgQUMcN5G7r1U9cX4Il6LRdsCrMrnTMwDwYDVR0TBAgw BgEB/wIBBTAOBgNVHQ8BAf8EBAMCAQYwDQYJKoZIhvcNAQEFBQADggEBAJRkWa05ZOcp6xP+WsOL E1fIBCTwdHfAYONn++mJpoO/loJ8btTDPe+egG67KbSYerE7VOs5F0d+Go4L/B8xWTEEss4X8yzH YjZV4iLYiVW0mEiqZPrWHDbYRHhaWiM6V5f1ejBPrp9qTEsrjqAD4z7gqdTSe9KzqOJyPK2e/4BZ 5JtFtPY7sM05GZgy5eohYZDkMSGONLH3LzVKhRDa54o3Ib5ZY+DyhYgxU9RUFIVwefQuBncndS8f uIr5/sW62Dbkg+znZbe/Y1rzRq+BlDfUQYzWI9Yez/VoG0Rjolq6pzVZoeVwBZsOI1eZlAptujlj KIaS8xiE2PvRzwVWZFcwggQhMIIDCaADAgECAgIAxzANBgkqhkiG9w0BAQUFADBxMQswCQYDVQQG EwJERTEcMBoGA1UEChMTRGV1dHNjaGUgVGVsZWtvbSBBRzEfMB0GA1UECxMWVC1UZWxlU2VjIFRy dXN0IENlbnRlcjEjMCEGA1UEAxMaRGV1dHNjaGUgVGVsZWtvbSBSb290IENBIDIwHhcNMDYxMjE5 MTAyOTAwWhcNMTkwNjMwMjM1OTAwWjBaMQswCQYDVQQGEwJERTETMBEGA1UEChMKREZOLVZlcmVp bjEQMA4GA1UECxMHREZOLVBLSTEkMCIGA1UEAxMbREZOLVZlcmVpbiBQQ0EgR2xvYmFsIC0gRzAx MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA6ZvDZ4X5Da71jVTDllA1PWLpbkztlNcA W5UidNQg6zSP1uzAMQQLmYHiphTSUqAoI4SLdIkEXlvg4njBeMsWyyg1OXstkEXQ7aAAeny/Sg4b AMOG6VwrMRF7DPOCJEOMHDiLamgAmu7cT3ir0sYTm3at7t4m6O8Br3QPwQmi9mvOvdPNFDBP9eXj pMhim4IaAycwDQJlYE3t0QkjKpY1WCfTdsZxtpAdxO3/NYZ9bzOz2w/FEcKKg6GUXUFr2NIQ9Uz9 ylGs2b3vkoO72uuLFlZWQ8/h1RM9ph8nMM1JVNvJEzSacXXFbOqnC5j5IZ0nrz6jOTlIaoytyZn7 wxLyvQIDAQABo4HZMIHWMHAGA1UdHwRpMGcwZaBjoGGGX2h0dHA6Ly9wa2kudGVsZXNlYy5kZS9j Z2ktYmluL3NlcnZpY2UvYWZfRG93bmxvYWRBUkwuY3JsPy1jcmxfZm9ybWF0PVhfNTA5Ji1pc3N1 ZXI9RFRfUk9PVF9DQV8yMB0GA1UdDgQWBBRJt8bP6D0ff+pEexMp9/EKcD7eZDAfBgNVHSMEGDAW gBQxw3kbuvVT1xfgiXotF2wKsyudMzAOBgNVHQ8BAf8EBAMCAQYwEgYDVR0TAQH/BAgwBgEB/wIB AjANBgkqhkiG9w0BAQUFAAOCAQEAO+Fad8BIF9ypGOyBr1qJ8L0okqbKWRgScOwo8ueuf5Ys5/Jd GTH2Eyt0vb2Asrn3Z8k5onk74RER7mt4kTN+O18mJ3VTZY4zY+7Pc8OwkiNJIVB1I6EfGOKUhT0/ M+l3II2iveahhSlA9j9zMlgNCWum2oVswD+7jWZkViROrg0/MjUBW+mMgtlyWU+xhoXxdIVW5cP4 XPON7kezUwVw5+VNimmDKOETCYaeXsjqWB4MH/mk1FoEaP0oPosCtli19qEsN1cAZ6sjaI1jpe+Z a1z9S1b2q0CHNNQRkmzsh8UKCwczcrRvDB1ULNhRx8y/MNNDcvEyv4zOSWOoAPfyHDCCBS8wggQX oAMCAQICBA0hCkcwDQYJKoZIhvcNAQEFBQAwWjELMAkGA1UEBhMCREUxEzARBgNVBAoTCkRGTi1W ZXJlaW4xEDAOBgNVBAsTB0RGTi1QS0kxJDAiBgNVBAMTG0RGTi1WZXJlaW4gUENBIEdsb2JhbCAt IEcwMTAeFw0wODEwMjQwODUyMDhaFw0xOTA2MzAwMDAwMDBaMIGQMQswCQYDVQQGEwJERTEYMBYG A1UEChMPTkVDIEV1cm9wZSBMdGQuMSAwHgYDVQQLExdORUMgTGFib3JhdG9yaWVzIEV1cm9wZTES MBAGA1UEAxMJTkVDTEFCLUNBMTEwLwYJKoZIhvcNAQkBFiJ6ZXJ0aWZpemllcnVuZ3NzdGVsbGVA bncubmVjbGFiLmV1MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAnvIVsbURqjIOcbnf ruYkRceWOZpyvM2ebnYpbd1cP+zdWm6yR7HSO9ppOe1ZZFIasArqQpedPEFvcncSG94FRuW3ND4r Rcq08mbpUTmpWmXfdYlJpQezbsOHCWR74NXoEEbK6TPZIMFpJr6dzQDAxnRc7UOgO6JQ1V42Z39B PhIbPIWz64t8svafxbORmxulJn7F5zDLDcR1AEGyn+L9b645AGwapoKNh7cSQFTqdb6kGyPQjLWf tv09dvmBDKesrcyLZXuDWJ1LMeizSjUEygdSszNXD3gePgJaVaZDS3o923W5gAyPCTSxpAFj8XJ+ /7Ap5jJwYhjJgJ8khFR7JQIDAQABo4IBxDCCAcAwEgYDVR0TAQH/BAgwBgEB/wIBATALBgNVHQ8E BAMCAQYwHQYDVR0OBBYEFE8ch3od4C+Z9r4VqtE1nQ5K5ro2MB8GA1UdIwQYMBaAFEm3xs/oPR9/ 6kR7Eyn38QpwPt5kMC0GA1UdEQQmMCSBInplcnRpZml6aWVydW5nc3N0ZWxsZUBudy5uZWNsYWIu ZXUwgYgGA1UdHwSBgDB+MD2gO6A5hjdodHRwOi8vY2RwMS5wY2EuZGZuLmRlL2dsb2JhbC1yb290 LWNhL3B1Yi9jcmwvY2FjcmwuY3JsMD2gO6A5hjdodHRwOi8vY2RwMi5wY2EuZGZuLmRlL2dsb2Jh bC1yb290LWNhL3B1Yi9jcmwvY2FjcmwuY3JsMIGiBggrBgEFBQcBAQSBlTCBkjBHBggrBgEFBQcw AoY7aHR0cDovL2NkcDEucGNhLmRmbi5kZS9nbG9iYWwtcm9vdC1jYS9wdWIvY2FjZXJ0L2NhY2Vy dC5jcnQwRwYIKwYBBQUHMAKGO2h0dHA6Ly9jZHAyLnBjYS5kZm4uZGUvZ2xvYmFsLXJvb3QtY2Ev cHViL2NhY2VydC9jYWNlcnQuY3J0MA0GCSqGSIb3DQEBBQUAA4IBAQBsMQ+dD0mmi48dgDU4R6Q/ eXcY0zQcHNp1Vu1s3kwO0WahWB0tiqVBodvfTAWG44xuw0I7NXSTwQ68FU5P0GIQnvRFZyVJlDjr SNlLYxjqfmgb+KVm67o383cZIuDakEE0f29kULIEn2fg/HsDiBAXTsb4I19XaN0TXLI+PMhU+GDp sGCJrydeugEV7qi15q8yymjSAsYgnrc2wJuXpyQ9r3qCtP6aedAPSHqOT8ga1dLT2YRZFs3vNm7T HSr5JJymWMbfpD6OcbRTnNAjSMDHwJxgRBAflA6WzDVm7fk4jiWyLvJwWTMk19t8QLiKG7D0nYvj cEUYyiOSE+SFUTEdMIIFNTCCBB2gAwIBAgIED+0gWzANBgkqhkiG9w0BAQUFADCBkDELMAkGA1UE BhMCREUxGDAWBgNVBAoTD05FQyBFdXJvcGUgTHRkLjEgMB4GA1UECxMXTkVDIExhYm9yYXRvcmll cyBFdXJvcGUxEjAQBgNVBAMTCU5FQ0xBQi1DQTExMC8GCSqGSIb3DQEJARYiemVydGlmaXppZXJ1 bmdzc3RlbGxlQG53Lm5lY2xhYi5ldTAeFw0xMDA0MjAxMjQ5MTVaFw0xMzA0MTkxMjQ5MTVaMGAx CzAJBgNVBAYTAkRFMRgwFgYDVQQKEw9ORUMgRXVyb3BlIEx0ZC4xIDAeBgNVBAsTF05FQyBMYWJv cmF0b3JpZXMgRXVyb3BlMRUwEwYDVQQDEwxUaG9tYXMgRGlldHowggEiMA0GCSqGSIb3DQEBAQUA A4IBDwAwggEKAoIBAQD2mMcvPbgraEaWMV6uNCs6t88lhBczgfxybD46mwr8D3VaQLEnqTsBOAf/ Y8ARtq+P6Dkm2MBMXQG+Ebo2qhif6O4dH7whcG9E88F9247R2EJjcXmxMYZWYGQTI2vGw/joerRB waiwfxCXWBTLutbdWEEKL/DG9A1yQRPGJc+jJYfgm0ekYn+WESOLYaBH7G9aIIZQ7en3afhPpbQA Ajh92K240TG+VgBpe1vnDdth28Ps5XeN+otookDZHwwGQYwYrPZJtnhGIyjKMm7OkXL62Rf3aSoI doVUwYYS67RYYNOY0C7qOVyCUF+z4Bkn758sZhZzotiLQVT3AZ625PrvAgMBAAGjggHEMIIBwDAJ BgNVHRMEAjAAMAsGA1UdDwQEAwIF4DApBgNVHSUEIjAgBggrBgEFBQcDAgYIKwYBBQUHAwQGCisG AQQBgjcUAgIwHQYDVR0OBBYEFH9fxgi2EshupgLF49SzaAX0QFoMMB8GA1UdIwQYMBaAFE8ch3od 4C+Z9r4VqtE1nQ5K5ro2MCEGA1UdEQQaMBiBFlRob21hcy5EaWV0ekBuZWNsYWIuZXUwfQYDVR0f BHYwdDA4oDagNIYyaHR0cDovL2NkcDEucGNhLmRmbi5kZS9uZWNsYWItY2EvcHViL2NybC9jYWNy bC5jcmwwOKA2oDSGMmh0dHA6Ly9jZHAyLnBjYS5kZm4uZGUvbmVjbGFiLWNhL3B1Yi9jcmwvY2Fj cmwuY3JsMIGYBggrBgEFBQcBAQSBizCBiDBCBggrBgEFBQcwAoY2aHR0cDovL2NkcDEucGNhLmRm bi5kZS9uZWNsYWItY2EvcHViL2NhY2VydC9jYWNlcnQuY3J0MEIGCCsGAQUFBzAChjZodHRwOi8v Y2RwMi5wY2EuZGZuLmRlL25lY2xhYi1jYS9wdWIvY2FjZXJ0L2NhY2VydC5jcnQwDQYJKoZIhvcN AQEFBQADggEBACnPHI1mIY1TVY9Aj8zsHHxiwMRx02Hp6DLZGYXHGG9IkflrRKNiDIV2LbBDpXVH vojMxTtCt10iwbyVMGaevet/VHYCJSHzrCLkw+GkvuhDU70lNsWw9P+mai7OHa+NQ6im8+4RnY1B yhqidcCt3hIV9B69ax0/KIhIFpiWz/lKZVIghki07I4m8mf1sbvCORKxudH0TVLlRJlX1r8S+8ea 9e+Q8pgXfrsCeyxBV3KAjszRQkqDZsbD7jQHQWokkMPIjbaTjw6V/5SRzmcAy0XlKNOCbldlzmCB jDZTQWdSH/AFDy5L2l4j0Ck0vVlQv+r1F4omsb4BelRq+vHd+lExggQsMIIEKAIBATCBmTCBkDEL MAkGA1UEBhMCREUxGDAWBgNVBAoTD05FQyBFdXJvcGUgTHRkLjEgMB4GA1UECxMXTkVDIExhYm9y YXRvcmllcyBFdXJvcGUxEjAQBgNVBAMTCU5FQ0xBQi1DQTExMC8GCSqGSIb3DQEJARYiemVydGlm aXppZXJ1bmdzc3RlbGxlQG53Lm5lY2xhYi5ldQIED+0gWzAJBgUrDgMCGgUAoIICZzAYBgkqhkiG 9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xMjA3MTAxNDU2NDdaMCMGCSqGSIb3 DQEJBDEWBBQnQOjXkKUfE4o6P/j8E8/OfzuzTjCBqgYJKwYBBAGCNxAEMYGcMIGZMIGQMQswCQYD VQQGEwJERTEYMBYGA1UEChMPTkVDIEV1cm9wZSBMdGQuMSAwHgYDVQQLExdORUMgTGFib3JhdG9y aWVzIEV1cm9wZTESMBAGA1UEAxMJTkVDTEFCLUNBMTEwLwYJKoZIhvcNAQkBFiJ6ZXJ0aWZpemll cnVuZ3NzdGVsbGVAbncubmVjbGFiLmV1AgQP7SBbMIGrBgkqhkiG9w0BCQ8xgZ0wgZowCwYJYIZI AWUDBAEqMAsGCWCGSAFlAwQBFjAKBggqhkiG9w0DBzALBglghkgBZQMEAQIwDgYIKoZIhvcNAwIC AgCAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgFAMA0GCCqGSIb3DQMCAgEoMAcGBSsOAwIaMAsGCWCG SAFlAwQCAzALBglghkgBZQMEAgIwCwYJYIZIAWUDBAIBMIGsBgsqhkiG9w0BCRACCzGBnKCBmTCB kDELMAkGA1UEBhMCREUxGDAWBgNVBAoTD05FQyBFdXJvcGUgTHRkLjEgMB4GA1UECxMXTkVDIExh Ym9yYXRvcmllcyBFdXJvcGUxEjAQBgNVBAMTCU5FQ0xBQi1DQTExMC8GCSqGSIb3DQEJARYiemVy dGlmaXppZXJ1bmdzc3RlbGxlQG53Lm5lY2xhYi5ldQIED+0gWzANBgkqhkiG9w0BAQEFAASCAQAp 607BUHwJh/lJIRDcmP7+48TsbKI43jBRi0pyaxFziNgnzoa+J2FvmRB7s4dd16nZzXRfRGyOUW0R 6x8Npi4DTYV6q59kO/hjeI4zMWxvmkvQBkc9qTIM/hjYfDOgU6Ij2DERFO5FS5quSsCg3VeRviMw 1pc4ARM2yV0ZN8nyQyVIocik8Dzu/jc3/N0lk/s/A9ySfzkWyAmN9vPK/AUFSzhm1aIJcpKtmDAy OwYRK7iFtYNs/msoupKgP0Cp/nOoUqRuXJKFbMhQUXeVGVSqHjEJl4Wqjib2dtMrRLWJIzOjfcyb rNOjVRMzCVmdpbmU5slFfRfC8K4kQ591Me1eAAAAAAAA ------=_NextPart_000_002D_01CD5EBC.FE6CD3E0-- From n.brownlee@auckland.ac.nz Wed Jul 11 19:41: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 32F1B11E80FA for ; Wed, 11 Jul 2012 19:41:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, 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 s+BtLo51b8Jz for ; Wed, 11 Jul 2012 19:41:29 -0700 (PDT) Received: from mx2.auckland.ac.nz (mx2.auckland.ac.nz [130.216.12.44]) by ietfa.amsl.com (Postfix) with ESMTP id A92D921F84EE for ; Wed, 11 Jul 2012 19:41:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=n.brownlee@auckland.ac.nz; q=dns/txt; s=uoa; t=1342060921; x=1373596921; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=AfVyx8pqfrVCT3P3C3Pjd4nRTeIp5FyM9dKX5LEBFow=; b=akgkCLuw3DDkonaFJYW6yFzTtZQj0XABuwv3zSQkrmSOJXc9zcP8H43e KlwxbauUptmFjmsc3SVEHYOGuv8cMDNLJAqoTQpbyi5oC305qEsm0aMzn ZrAkrfakogxmFIJ5b78gbCNs9X56m5bIxOOrB1CHGac9Dba5JWPtFYKwz 4=; X-IronPort-AV: E=Sophos;i="4.77,572,1336305600"; d="scan'208";a="132137534" X-Ironport-HAT: UNIVERSITY - $RELAY-THROTTLE X-Ironport-Source: 130.216.38.131 - Outgoing - Outgoing-SSL Received: from nevil-laptop1.sfac.auckland.ac.nz (HELO [130.216.38.131]) ([130.216.38.131]) by mx2-int.auckland.ac.nz with ESMTP; 12 Jul 2012 14:41:59 +1200 Message-ID: <4FFE3976.8000902@auckland.ac.nz> Date: Thu, 12 Jul 2012 14:41:58 +1200 From: Nevil Brownlee User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: iana-prot-param-comment@iana.org References: <201206111440.q5BEe6ps030247@smtp1.lax.icann.org> <4FDFB4DC.2010106@auckland.ac.nz> In-Reply-To: <4FDFB4DC.2010106@auckland.ac.nz> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: IPFIX Working Group Subject: Re: [IPFIX] [IANA #579482] General Request for Assignment (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: Thu, 12 Jul 2012 02:41:31 -0000 Hi Amanda: These four IEs aren't in the registry yet, please add them. Cheers, Nevil On 19/06/12 11:08 AM, Nevil Brownlee wrote: > > Hi again Amanda: > > These four have been discussed on the IPFIX list, they're OK as > submitted. They'll be > > 361 portRangeStart > 362 portRangeEnd > 363 portRangeStepSize > 364 portRangeNumPorts > > Cheers, Nevil > > > On 12/06/12 8:51 AM, Amanda Baber via RT wrote: >> Hi Nevil, >> >> Here's Paul's second request. >> >> thanks, >> Amanda >> >> === >> >> Contact Name: >> Paul Aitken >> >> Contact Email: >> paitken@cisco.com >> >> Type of Assignment: >> IPFIX Information Elements >> >> Registry: >> http://www.iana.org/assignments/ipfix/ipfix.xml#ipfix-information-elements >> >> >> Description: >> Please allocate the four new fields specified below, which may be used >> in various combinations to specify port ranges in IPFIX. >> >> Additional Info: >> Name: portRangeStart >> Type: unsigned16 >> Semantics: identifier >> Description: The port number identifying the start of a range of ports. >> A value of zero indicates that the range start is not specified, ie the >> range is defined in some other way. >> Additional information on defined TCP port numbers can be found at [IANA >> registry port-numbers]. >> >> Name: portRangeEnd >> Type: unsigned16 >> Semantics: identifier >> Description: The port number identifying the end of a range of ports. >> A value of zero indicates that the range end is not specified, ie the >> range is defined in some other way. >> Additional information on defined TCP port numbers can be found at [IANA >> registry port-numbers]. >> >> Name: portRangeStepSize >> Type: unsigned16 >> Semantics: identifier >> Description: The step size in a port range. The default step size is 1, >> which indicates contiguous ports. >> A value of zero indicates that the step size is not specified, ie the >> range is defined in some other way. >> >> Name: portRangeNumPorts >> Type: unsigned16 >> Semantics: identifier >> Description: The number of ports in a port range. >> A value of zero indicates that the number of ports is not specified, ie >> the range is defined in some other way. > > -- --------------------------------------------------------------------- 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 Wed Jul 11 19:42: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 5CCCE21F84F7 for ; Wed, 11 Jul 2012 19:42:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.299 X-Spam-Level: X-Spam-Status: No, score=-106.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_65=0.6, RCVD_IN_DNSWL_MED=-4, 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 GkLZ3QoSkL2f for ; Wed, 11 Jul 2012 19:41:59 -0700 (PDT) Received: from mx2.auckland.ac.nz (mx2.auckland.ac.nz [130.216.12.44]) by ietfa.amsl.com (Postfix) with ESMTP id 83CF221F84EE for ; Wed, 11 Jul 2012 19:41:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=n.brownlee@auckland.ac.nz; q=dns/txt; s=uoa; t=1342060952; x=1373596952; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=MSDhynpGW+0jJRn1u48xnDRInPiN8WB22pLZ1yI5qK4=; b=fwZ20sYanKQ1RkJDdRFP88tB4n0xHMq/7fA8KbCltAfFRkHbv1wi9q1j LXQ+w++P7N2ZqYtxyHBFO3Xl258am5Y1gksOEKNbbR/vvvp4ftVZgIZgo rUWeqUlEAI9y+4UY8FDjwuGqPGYxJ5NFuEQbFwOpB25DQ0/wgXI+4/EPq g=; X-IronPort-AV: E=Sophos;i="4.77,572,1336305600"; d="scan'208";a="132137572" X-Ironport-HAT: UNIVERSITY - $RELAY-THROTTLE X-Ironport-Source: 130.216.38.131 - Outgoing - Outgoing-SSL Received: from nevil-laptop1.sfac.auckland.ac.nz (HELO [130.216.38.131]) ([130.216.38.131]) by mx2-int.auckland.ac.nz with ESMTP; 12 Jul 2012 14:42:16 +1200 Message-ID: <4FFE3987.7050101@auckland.ac.nz> Date: Thu, 12 Jul 2012 14:42:15 +1200 From: Nevil Brownlee User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: iana-prot-param-comment@iana.org References: <201206251141.q5PBfBLt001598@smtp1.lax.icann.org> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: ipfix Working Group Subject: Re: [IPFIX] [IANA #584408] General Request for Assignment (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: Thu, 12 Jul 2012 02:42:00 -0000 Hi Amanda: This one is OK, please allocate it as IE 300. Cheers, Nevil On 11/07/12 8:26 PM, Amanda Baber via RT wrote: > Hi Nevil, > > Resending this one. > > thanks, > Amanda > > On Wed Jun 27 06:21:42 2012, amanda.baber wrote: >> Hi Nevil, >> >> Another request from Paul Aitken here. >> >> thanks, >> Amanda >> >> === >> >> Contact Name: >> Paul Aitken >> >> Contact Email: >> paitken@cisco.com >> >> Type of Assignment: >> IPFIX information elements. >> >> Registry: >> http://www.iana.org/assignments/ipfix/ipfix.xml#ipfix-information-elements >> >> Description: >> New field, observationDomainName, complementing the existing >> observationDomainId (#149). >> >> Additional Info: >> Name: observationDomainName >> Type: string >> Semantic: - >> Description: The name of an observation domain identified by an >> observationDomainId. >> References: See observationDomainId #149. > > -- --------------------------------------------------------------------- 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 internet-drafts@ietf.org Fri Jul 13 04:59: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 01EC121F875A; Fri, 13 Jul 2012 04:59:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.494 X-Spam-Level: X-Spam-Status: No, score=-102.494 tagged_above=-999 required=5 tests=[AWL=0.105, 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 kRLlNe33hdu0; Fri, 13 Jul 2012 04:59:36 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 514AD21F86FA; Fri, 13 Jul 2012 04:59:36 -0700 (PDT) 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.30p3 Message-ID: <20120713115936.23585.9987.idtracker@ietfa.amsl.com> Date: Fri, 13 Jul 2012 04:59:36 -0700 Cc: ipfix@ietf.org Subject: [IPFIX] I-D Action: draft-ietf-ipfix-information-model-rfc5102bis-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: Fri, 13 Jul 2012 11:59:37 -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 Group = of the IETF. Title : Information Model for IP Flow Information eXport (IPFIX) Author(s) : Benoit Claise Brian Trammell Filename : draft-ietf-ipfix-information-model-rfc5102bis-03.txt Pages : 29 Date : 2012-07-13 Abstract: This document provides an overview of the information model for the IP Flow Information eXport (IPFIX) protocol, as defined in the IANA IPFIX Information Element Registry. It is used by the IPFIX Protocol for encoding measured traffic information and information related to the traffic Observation Point, the traffic Metering Process, and the Exporting Process. Although developed for the IPFIX Protocol, the model is defined in an open way that easily allows using it in other protocols, interfaces, and applications. This document obsoletes RFC 5102. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ipfix-information-model-rfc5102= bis There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-ipfix-information-model-rfc5102bis-03 A diff from previous version is available at: http://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-ipfix-information-model-rfc= 5102bis-03 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From trammell@tik.ee.ethz.ch Fri Jul 13 05:04: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 165F121F86AF for ; Fri, 13 Jul 2012 05:04:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.115 X-Spam-Level: X-Spam-Status: No, score=-6.115 tagged_above=-999 required=5 tests=[AWL=0.484, 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 Z6T27JKyF6PX for ; Fri, 13 Jul 2012 05:04:37 -0700 (PDT) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) by ietfa.amsl.com (Postfix) with ESMTP id EBA4721F8637 for ; Fri, 13 Jul 2012 05:04:36 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id 56549D930D for ; Fri, 13 Jul 2012 14:05:12 +0200 (MEST) X-Virus-Scanned: by amavisd-new on smtp.ee.ethz.ch Received: from smtp.ee.ethz.ch ([127.0.0.1]) by localhost (.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with LMTP id dxnYJOZUQiW4 for ; Fri, 13 Jul 2012 14:05:12 +0200 (MEST) Received: from pb-10243.ethz.ch (pb-10243.ethz.ch [82.130.102.152]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: briant) by smtp.ee.ethz.ch (Postfix) with ESMTPSA id 25DBFD9304 for ; Fri, 13 Jul 2012 14:05:12 +0200 (MEST) From: Brian Trammell Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Fri, 13 Jul 2012 14:05:11 +0200 References: <20120713115936.23585.9987.idtracker@ietfa.amsl.com> To: IETF IPFIX Working Group Message-Id: <098D883C-E6DE-43B2-99BA-9F3625714009@tik.ee.ethz.ch> Mime-Version: 1.0 (Apple Message framework v1278) X-Mailer: Apple Mail (2.1278) Subject: [IPFIX] Fwd: I-D Action: draft-ietf-ipfix-information-model-rfc5102bis-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: Fri, 13 Jul 2012 12:04:38 -0000 Greetings, all, I've posted a -03 revision of 5102bis; this revision is primarily = editorial, making it even more clear that 5102(-bis) should not be used = as the canonical reference for IE definitions, in favor of the IANA = registry, as per list discussion. Best regards, Brian Begin forwarded message: > From: internet-drafts@ietf.org > Subject: [IPFIX] I-D Action: = draft-ietf-ipfix-information-model-rfc5102bis-03.txt > Date: July 13, 2012 1:59:36 PM GMT+02: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 : Information Model for IP Flow Information = eXport (IPFIX) > Author(s) : Benoit Claise > Brian Trammell > Filename : = draft-ietf-ipfix-information-model-rfc5102bis-03.txt > Pages : 29 > Date : 2012-07-13 >=20 > Abstract: > This document provides an overview of the information model for the IP > Flow Information eXport (IPFIX) protocol, as defined in the IANA IPFIX > Information Element Registry. It is used by the IPFIX Protocol for > encoding measured traffic information and information related to the > traffic Observation Point, the traffic Metering Process, and the > Exporting Process. Although developed for the IPFIX Protocol, the = model > is defined in an open way that easily allows using it in other > protocols, interfaces, and applications. This document obsoletes RFC > 5102. >=20 >=20 > The IETF datatracker status page for this draft is: > = https://datatracker.ietf.org/doc/draft-ietf-ipfix-information-model-rfc510= 2bis >=20 > There's also a htmlized version available at: > = http://tools.ietf.org/html/draft-ietf-ipfix-information-model-rfc5102bis-0= 3 >=20 > A diff from previous version is available at: > = http://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-ipfix-information-model-rf= c5102bis-03 >=20 >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > IPFIX mailing list > IPFIX@ietf.org > https://www.ietf.org/mailman/listinfo/ipfix From j.schoenwaelder@jacobs-university.de Fri Jul 13 05:09: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 00BC421F86C7 for ; Fri, 13 Jul 2012 05:09:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.203 X-Spam-Level: X-Spam-Status: No, score=-103.203 tagged_above=-999 required=5 tests=[AWL=0.046, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, 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 vGSv4mTsscoL for ; Fri, 13 Jul 2012 05:09:14 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 9C4A121F86C2 for ; Fri, 13 Jul 2012 05:09:14 -0700 (PDT) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 2F8CF20BEC; Fri, 13 Jul 2012 14:09:50 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id wQ_NIcrF7wSn; Fri, 13 Jul 2012 14:09:50 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id C590B205A3; Fri, 13 Jul 2012 14:09:49 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 4999620612FE; Fri, 13 Jul 2012 14:09:49 +0200 (CEST) Date: Fri, 13 Jul 2012 14:09:49 +0200 From: Juergen Schoenwaelder To: ipfix@ietf.org Message-ID: <20120713120949.GC14053@elstar.local> Mail-Followup-To: ipfix@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) Subject: [IPFIX] information model vs. information elements X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jul 2012 12:09:16 -0000 Hi, since this came up recently again in another context, the usage of the term "information model" in IPFIX is I think rather unfortunate. Since 5102 is being revised, would it make sense to change its title and the terminology in the document? OLD Information Model for IP Flow Information Export NEW Information Elements for IP Flow Information Export There are a few sentences to change as well and perhaps a paragraph to remove. But I believe the proposed new title is less confusing, it actually tells upfront what is in the specification. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From trammell@tik.ee.ethz.ch Fri Jul 13 05:19: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 78AF821F87B0 for ; Fri, 13 Jul 2012 05:19:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.163 X-Spam-Level: X-Spam-Status: No, score=-6.163 tagged_above=-999 required=5 tests=[AWL=0.436, 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 rc87iXrtNFcm for ; Fri, 13 Jul 2012 05:19:40 -0700 (PDT) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) by ietfa.amsl.com (Postfix) with ESMTP id 2D41C21F8528 for ; Fri, 13 Jul 2012 05:19:40 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id B9097D9304; Fri, 13 Jul 2012 14:20:15 +0200 (MEST) X-Virus-Scanned: by amavisd-new on smtp.ee.ethz.ch Received: from smtp.ee.ethz.ch ([127.0.0.1]) by localhost (.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with LMTP id dGngBOvAmt54; Fri, 13 Jul 2012 14:20:01 +0200 (MEST) Received: from pb-10243.ethz.ch (pb-10243.ethz.ch [82.130.102.152]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: briant) by smtp.ee.ethz.ch (Postfix) with ESMTPSA id 29185D930D; Fri, 13 Jul 2012 14:20:01 +0200 (MEST) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: Brian Trammell In-Reply-To: <20120713120949.GC14053@elstar.local> Date: Fri, 13 Jul 2012 14:20:00 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <7925A0B8-DF63-4CAD-A389-B16DD532F237@tik.ee.ethz.ch> References: <20120713120949.GC14053@elstar.local> To: Juergen Schoenwaelder X-Mailer: Apple Mail (2.1278) Cc: ipfix@ietf.org Subject: Re: [IPFIX] information model vs. information elements 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, 13 Jul 2012 12:19:41 -0000 Hi, Juergen, all, This is probably doable, though not quite so simply, I think... = 5102(-bis) has been known as "the information model" in an IPFIX context = for long enough that if all references to it=20 disappeared, there might be confusion. It might make sense to change the title, though; however, since the = document is no longer the canonical reference for information elements for IPFIX, the proposed = title isn't really right either. How about "IP Flow Information Export = (IPFIX) Information Element Overview"? We do also have this paragraph in section 1, which on rereading could = also do with some improvement: OLD: The use of the term 'information model' is not fully in line with the definition of this term in [RFC3444]. The IPFIX information model does not specify relationships between Information Elements, but also it does not specify a concrete encoding of Information Elements. Besides the encoding used by the IPFIX protocol, other encodings of IPFIX Information Elements can be applied, for example, XML-based encodings. NEW (for next revision): This document is, for historical reasons, often referred to as "the IPFIX Information Model". However, use of the term 'information=20= model' is not fully in line with the definition of this term in [RFC3444]. This document specifies = neither relationships between Information Elements nor a concrete encoding of them. Relationships among Information Elements IPFIX are dynamic,=20 determined by Templates used at runtime by the protocol. The IPFIX=20 protocol [RFC5101bis] specifies binary encodings suitable for use=20 with the protocol for each of the data types defined in Section 3.1. In addition, other encodings of IPFIX Information Elements could be applied, for example, XML-based encodings, to apply the Information Elements to other protocols. Comments? Thanks, best regards, Brian On Jul 13, 2012, at 2:09 PM, Juergen Schoenwaelder wrote: > Hi, >=20 > since this came up recently again in another context, the usage of the > term "information model" in IPFIX is I think rather unfortunate. Since > 5102 is being revised, would it make sense to change its title and the > terminology in the document? >=20 > OLD >=20 > Information Model for IP Flow Information Export >=20 > NEW >=20 > Information Elements for IP Flow Information Export >=20 > There are a few sentences to change as well and perhaps a paragraph to > remove. But I believe the proposed new title is less confusing, it > actually tells upfront what is in the specification. >=20 > /js >=20 > --=20 > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 > _______________________________________________ > IPFIX mailing list > IPFIX@ietf.org > https://www.ietf.org/mailman/listinfo/ipfix From j.schoenwaelder@jacobs-university.de Fri Jul 13 05:40:08 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 118D221F879D for ; Fri, 13 Jul 2012 05:40:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.204 X-Spam-Level: X-Spam-Status: No, score=-103.204 tagged_above=-999 required=5 tests=[AWL=0.045, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, 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 wBNqf34czVKQ for ; Fri, 13 Jul 2012 05:40:07 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 6314121F87D3 for ; Fri, 13 Jul 2012 05:39:58 -0700 (PDT) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id E53E820BCD; Fri, 13 Jul 2012 14:40:33 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id hmho-RBBOWcV; Fri, 13 Jul 2012 14:40:33 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 7CC0420BC1; Fri, 13 Jul 2012 14:40:33 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 6A69E2061460; Fri, 13 Jul 2012 14:40:32 +0200 (CEST) Date: Fri, 13 Jul 2012 14:40:32 +0200 From: Juergen Schoenwaelder To: Brian Trammell Message-ID: <20120713124031.GA14416@elstar.local> Mail-Followup-To: Brian Trammell , ipfix@ietf.org References: <20120713120949.GC14053@elstar.local> <7925A0B8-DF63-4CAD-A389-B16DD532F237@tik.ee.ethz.ch> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <7925A0B8-DF63-4CAD-A389-B16DD532F237@tik.ee.ethz.ch> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: ipfix@ietf.org Subject: Re: [IPFIX] information model vs. information elements X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jul 2012 12:40:08 -0000 On Fri, Jul 13, 2012 at 02:20:00PM +0200, Brian Trammell wrote: > It might make sense to change the title, though; however, since the document is no longer the > canonical reference for information elements for IPFIX, the proposed title isn't really right either. How about "IP Flow Information Export (IPFIX) Information Element Overview"? Is it an overview? I do not think so. What about "Common IP Flow Information Export (IPFIX) Information Elements"? That's what I ended up calling the YANG data types document. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From paitken@cisco.com Fri Jul 13 06:12: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 E4F9F21F8839 for ; Fri, 13 Jul 2012 06:12:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.321 X-Spam-Level: X-Spam-Status: No, score=-10.321 tagged_above=-999 required=5 tests=[AWL=0.278, 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 tdMV0paxjRHf for ; Fri, 13 Jul 2012 06:12:16 -0700 (PDT) Received: from ams-iport-3.cisco.com (ams-iport-3.cisco.com [144.254.224.146]) by ietfa.amsl.com (Postfix) with ESMTP id 66AEF21F8830 for ; Fri, 13 Jul 2012 06:12:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=paitken@cisco.com; l=5003; q=dns/txt; s=iport; t=1342185173; x=1343394773; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=ONkIjVdF0SE+x5Bx6RgESirk/aUpANJLYootHiMkhN0=; b=knDJFd76s6uUM9+oEuBxgeHn+i0KuzqVpwJ6gG+N+fOSkSC0pm3lvxzF Nlohto+DIJ81NwqokhFICbbGXCsKrwoCf/PAZjw9h8Zq/uEP1QXkhT1dq NvixIG0PpAhG0h5JB2KnL3gnvthCbjH3gadJHx3I78IlNA8X26jcJe5xR Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAEceAFCQ/khL/2dsb2JhbABFuCOBB4IgAQEBAwESASVAAQULCyEWDwkDAgECAUUGDQEHAQEeh2UGmzCgLItFhW0DlTqFVohKgWaCYIFV X-IronPort-AV: E=Sophos;i="4.77,579,1336348800"; d="scan'208";a="6614936" Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-3.cisco.com with ESMTP; 13 Jul 2012 13:12:51 +0000 Received: from [10.55.80.9] (dhcp-10-55-80-9.cisco.com [10.55.80.9]) by ams-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id q6DDCpQT000357; Fri, 13 Jul 2012 13:12:51 GMT Message-ID: <50001ED4.7040308@cisco.com> Date: Fri, 13 Jul 2012 14:12:52 +0100 From: Paul Aitken User-Agent: Mozilla/5.0 (X11; Linux i686; rv:12.0) Gecko/20120430 Thunderbird/12.0.1 MIME-Version: 1.0 To: Brian Trammell References: <4FDBAA42.60003@cisco.com> <84E8C12B-C43B-479A-B97E-3F689A93B964@tik.ee.ethz.ch> In-Reply-To: <84E8C12B-C43B-479A-B97E-3F689A93B964@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] review of draft-trammell-ipfix-a9n-03 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, 13 Jul 2012 13:12:18 -0000 Brian, Herewith feedback on a couple of your responses to my previous feedback. I'm almost done reviewing -a9n-05. P. >>> Key aggregation is a spatial aggregation operation which results in >>> the addition, modification, or deletion of Flow Key fields in the >>> partially aggregated Flows. New Flow Key fields may be derived >>> from existing Flow Key fields (e.g., looking up an AS number for >>> an IP address), or "promoted" from non-Key fields (e.g., when >>> aggregating Flows by packet count per Flow). Key aggregation can >>> >> The above sounds like any non-key can be promoted, which isn't true and needs to be discussed (see later). >> >> Consider, "or derived from certain specific non-Key fields" ? > Okay... although I'm not convinced there exist non-promoteable fields. Certainly some of these might not make a whole lot of sense sense, but you can always count all incoming flows that have some property equal to each distinct value of that property. A non-key field holds a single value from a set of possible values. There's generally no information about how representative that value is of the set: it could be the first or last observation, or it could be derived from some operation (min, max, average, OR, most frequent, ...). If you wanted to know how representative it is, you'd have observed it as a key field. "Unrepresentative" non-key fields shouldn't be promoted to key fields. The only exception is when the NK field is representative, ie despite being NK it contains the only value which was ever observed for the field, so there's no difference between it being NK or key. >>> counter distribution is greatly simplified by the choice of an >>> interval longer than the duration of longest original Flow, itself >>> generally determined by the original Flow's Metering Process active >>> timeout; in this case an original Flow can contribute to at most two >>> Aggregated Flows, and the more complex value distribution methods >>> become inapplicable. >>> >> This only considers the Metering Process; it fails to consider any delay in the Exporting Process. >> >> eg, consider and implementation with 64K cache entries which are checked for exporting at a rate of 1000 entries/second. It will take> 1 minute to check and export the entire cache. > And the timestamps are put on the flows by the EP as opposed to the MP? No, except for the export header timestamp. The point is that the flows continue to exist as cache entries for longer than might be expected, so traffic from the next interval could be added to flows (cache entries) from the previous interval. >>> from correlation of the original Flow information with some external >>> source. There are two basic operations here. First, Aggregated Flow >>> Keys may be derived directly from original Flow Keys through >>> reduction, or the dropping of fields or precision in the original >>> Flow Keys. Second, an Aggregated Flow Key may be derived through >>> replacement, e.g. by removing one or more fields from the original >>> Flow and replacing them with a fields derived from the removed >>> fields. Replacement may refer to external information (e.g., IP to >>> AS number mappings). Replacement need not replace only key fields. >>> For example, consider an application which aggregates flows by packet >>> count (i.e., generating an Aggregated Flow for all one-packet Flows, >>> one for all two-packet Flows, and so on). This application would >>> promote the packet count to a Flow Key field. >> >> Say more about promotion, ie it can only be done on non-key fields which represent a single unique value. eg, counters, time. >> If a NK field might be any value from a set of>1 values (eg, an IP address, port number, AS, TOS) then it's not suitable for promotion to Key, because there's no way of knowing which other values were or were not observed, and therefore no way of dividing the flow amongst those values. > I'm not sure I follow you here. Why does the potential set of values (and its difference to the actual set) affect the promotion ability? Can you give a more detailed example? See what I said above about how representative the value is. eg, an IP address which represents just one of many hundreds of possible values can't be promoted from non-key to key since it simply is not a key field. If it was a key field, each flow would have been split into many hundreds of flows. However, if that IP address was invariant - eg, you're monitoring all the traffic into a server, and it's the destination address of the server - then it won't make any difference whether it's observed as key or non-key: in the end, the flows will be the same. So if it was observed as NK, it could be promoted to key without affecting any of the observations. P. From paitken@cisco.com Fri Jul 13 08:07:52 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 6F29321F878B for ; Fri, 13 Jul 2012 08:07:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0 X-Spam-Level: X-Spam-Status: No, score=x tagged_above=-999 required=5 tests=[] 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 6ZjZhLlVhwdm for ; Fri, 13 Jul 2012 08:07:52 -0700 (PDT) Received: from ams-iport-4.cisco.com (ams-iport-4.cisco.com [144.254.224.147]) by ietfa.amsl.com (Postfix) with ESMTP id BA56121F86A6 for ; Fri, 13 Jul 2012 08:07:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=paitken@cisco.com; l=267159; q=dns/txt; s=iport; t=1342192104; x=1343401704; h=message-id:date:from:mime-version:to:cc:subject; bh=42J++KmY5baZfaI1pWsxccazbNypFCyxGqBYCaGsBnY=; b=SXfXTGIv+LAUq2+fx0ptCjXUhRaIksmfUhjBB2RlkuWOXkEoUxaz3tOk HmGf1tNcU8+BRsORbdj3gTCVeZ9vOYXie/F/Dqyd9d6W5I+MvqPQjxNsh KC2AT20/49mW01g1ubLCsisIBXExO0Sf+LLouE/LL2GswrmE/hqKUpDv+ o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEADY5AFCQ/khM/2dsb2JhbAA X-IronPort-AV: E=Sophos;i="4.77,579,1336348800"; d="scan'208,217";a="6622100" Received: from ams-core-3.cisco.com ([144.254.72.76]) by ams-iport-4.cisco.com with ESMTP; 13 Jul 2012 15:08:20 +0000 Received: from [10.55.80.9] (dhcp-10-55-80-9.cisco.com [10.55.80.9]) by ams-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id q6DF8Drp030888; Fri, 13 Jul 2012 15:08:13 GMT Message-ID: <500039DE.5050706@cisco.com> Date: Fri, 13 Jul 2012 16:08:14 +0100 From: Paul Aitken User-Agent: Mozilla/5.0 (X11; Linux i686; rv:12.0) Gecko/20120430 Thunderbird/12.0.1 MIME-Version: 1.0 To: Brian Trammell , IETF IPFIX Working Group Content-Type: multipart/alternative; boundary="------------030603030609090505000903" Cc: draft-ietf-ipfix-a9n@tools.ietf.org Subject: [IPFIX] review of draft-ietf-ipfix-a9n-04 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, 13 Jul 2012 15:07:52 -0000 This is a multi-part message in MIME format. --------------030603030609090505000903 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Dear Authors, Here with an extensive and detailed review of draft-ietf-ipfix-a9n-04. P. > IPFIX Working Group B. Trammell > Internet-Draft ETH Zurich > Intended status: Standards Track A. Wagner > Expires: December 29, 2012 Consecom AG > B. Claise > Cisco Systems, Inc. > June 27, 2012 > > > Flow Aggregation for the IP Flow Information Export (IPFIX) Protocol > draft-ietf-ipfix-a9n-04.txt > > Abstract > > This document provides a common implementation-independent basis for > the interoperable application of the IP Flow Information Export > (IPFIX) Protocol to the handling of Aggregated Flows, which are IPFIX > Flow representing packets from multiple Original Flows sharing some s/Flow/Flows/ > > set of common properties. It does this through a detailed > terminology and a descriptive Intermediate Aggregation Process > architecture, including a specification of methods for Original Flow > counting and counter distribution across intervals. > > Status of this Memo > > This Internet-Draft is submitted in full conformance with the > provisions of BCP 78 and BCP 79. > > Internet-Drafts are working documents of the Internet Engineering > Task Force (IETF). Note that other groups may also distribute > working documents as Internet-Drafts. The list of current Internet- > Drafts is at http://datatracker.ietf.org/drafts/current/. > > Internet-Drafts are draft documents valid for a maximum of six months > and may be updated, replaced, or obsoleted by other documents at any > time. It is inappropriate to use Internet-Drafts as reference > material or to cite them other than as "work in progress." > > This Internet-Draft will expire on December 29, 2012. > > Copyright Notice > > Copyright (c) 2012 IETF Trust and the persons identified as the > document authors. All rights reserved. > > This document is subject to BCP 78 and the IETF Trust's Legal > Provisions Relating to IETF Documents > (http://trustee.ietf.org/license-info) in effect on the date of > > > > Trammell, et al. Expires December 29, 2012 [Page 1] > > Internet-Draft IPFIX Aggregation June 2012 > > > publication of this document. Please review these documents > carefully, as they describe your rights and restrictions with respect > to this document. Code Components extracted from this document must > include Simplified BSD License text as described in Section 4.e of > the Trust Legal Provisions and are provided without warranty as > described in the Simplified BSD License. > > > Table of Contents > > 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 > 1.1. IPFIX Protocol Overview . . . . . . . . . . . . . . . . . 5 > 1.2. IPFIX Documents Overview . . . . . . . . . . . . . . . . . 5 > 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 > 3. Use Cases for IPFIX Aggregation . . . . . . . . . . . . . . . 7 > 4. Architecture for Flow Aggregation . . . . . . . . . . . . . . 8 > 4.1. Aggregation within the IPFIX Architecture . . . . . . . . 8 > 4.2. Intermediate Aggregation Process Architecture . . . . . . 12 > 4.2.1. Correlation and Normalization . . . . . . . . . . . . 14 > 5. IP Flow Aggregation Operations . . . . . . . . . . . . . . . . 15 > 5.1. Temporal Aggregation through Interval Distribution . . . . 15 > 5.1.1. Distributing Values Across Intervals . . . . . . . . . 16 > 5.1.2. Time Composition . . . . . . . . . . . . . . . . . . . 18 > 5.1.3. External Interval Distribution . . . . . . . . . . . . 19 > 5.2. Spatial Aggregation of Flow Keys . . . . . . . . . . . . . 19 > 5.2.1. Counting Original Flows . . . . . . . . . . . . . . . 21 > 5.2.2. Counting Distinct Key Values . . . . . . . . . . . . . 22 > 5.3. Spatial Aggregation of Non-Key Fields . . . . . . . . . . 22 > 5.3.1. Counter Statistics . . . . . . . . . . . . . . . . . . 22 > 5.3.2. Derivation of New Values from Flow Keys and > non-Key fields . . . . . . . . . . . . . . . . . . . . 22 > 5.4. Aggregation Combination . . . . . . . . . . . . . . . . . 23 > 6. Additional Considerations and Special Cases in Flow > Aggregation . . . . . . . . . . . . . . . . . . . . . . . . . 23 > 6.1. Exact versus Approximate Counting during Aggregation . . . 24 > 6.2. Delay and Loss introduced by the IAP . . . . . . . . . . . 24 > 6.3. Considerations for Aggregation of Sampled Flows . . . . . 24 > 6.4. Considerations for Aggregation of Heterogeneous Flows . . 24 > 7. Export of Aggregated IP Flows using IPFIX . . . . . . . . . . 25 > 7.1. Time Interval Export . . . . . . . . . . . . . . . . . . . 25 > 7.2. Flow Count Export . . . . . . . . . . . . . . . . . . . . 26 > 7.2.1. originalFlowsPresent . . . . . . . . . . . . . . . . . 26 > 7.2.2. originalFlowsInitiated . . . . . . . . . . . . . . . . 26 > 7.2.3. originalFlowsCompleted . . . . . . . . . . . . . . . . 26 > 7.2.4. deltaFlowCount . . . . . . . . . . . . . . . . . . . . 26 > 7.3. Distinct Host Export . . . . . . . . . . . . . . . . . . . 27 > 7.3.1. distinctCountOfSourceIPAddress . . . . . . . . . . . . 27 > 7.3.2. distinctCountOfDestinationIPAddress . . . . . . . . . 27 > > > > Trammell, et al. Expires December 29, 2012 [Page 2] > > Internet-Draft IPFIX Aggregation June 2012 > > > 7.3.3. distinctCountOfSourceIPv4Address . . . . . . . . . . . 27 > 7.3.4. distinctCountOfDestinationIPv4Address . . . . . . . . 28 > 7.3.5. distinctCountOfSourceIPv6Address . . . . . . . . . . . 28 > 7.3.6. distinctCountOfDestinationIPv6Address . . . . . . . . 28 > 7.4. Aggregate Counter Distribution Export . . . . . . . . . . 28 > 7.4.1. Aggregate Counter Distribution Options Template . . . 29 > 7.4.2. valueDistributionMethod Information Element . . . . . 29 > 8. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 31 > 8.1. Traffic Time-Series per Source . . . . . . . . . . . . . . 32 > 8.2. Core Traffic Matrix . . . . . . . . . . . . . . . . . . . 36 > 8.3. Distinct Source Count per Destination Endpoint . . . . . . 41 > 8.4. Traffic Time-Series per Source with Counter > Distribution . . . . . . . . . . . . . . . . . . . . . . . 43 > 9. Security Considerations . . . . . . . . . . . . . . . . . . . 45 > 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 45 > 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 46 > 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 46 > 12.1. Normative References . . . . . . . . . . . . . . . . . . . 46 > 12.2. Informative References . . . . . . . . . . . . . . . . . . 46 > Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 48 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Trammell, et al. Expires December 29, 2012 [Page 3] > > Internet-Draft IPFIX Aggregation June 2012 > > > 1. Introduction > > The assembly of packet data into Flows serves a variety of different > purposes, as noted in the requirements [RFC3917] and applicability > statement [RFC5472] for the IP Flow Information Export (IPFIX) > protocol [I-D.ietf-ipfix-protocol-rfc5101bis]. Aggregation beyond > the flow level, into records representing multiple Flows, is a common > analysis and data reduction technique as well, with applicability to > large-scale network data analysis, archiving, and inter-organization > exchange. This applicability in large-scale situations, in > particular, led to the inclusion of aggregation as part of the IPFIX > Mediators Problem Statement [RFC5982], and the definition of an > Intermediate Aggregation Process in the Mediator framework [RFC6183]. > > Aggregation is used for analysis and data reduction in a wide variety > of applications, for example in traffic matrix calculation, > generation of time series data for visualizations or anomaly > detection, or data reduction for long-term trending and storage. > Depending on the keys used for aggregation, it may additionally have > an anonymizing affect on the data: for example, aggregation > operations which eliminate IP addresses make it impossible to later > identify nodes using those addresses. Not necessarily. "may make it impossible..." ? > > > Aggregation as defined and described in this document covers the > applications defined in [RFC5982], including 5.1 "Adjusting Flow > Granularity", 5.4 "Time Composition", and 5.5 "Spatial Composition". > However, this document specifies a more flexible architecture for an > Intermediate Aggregation Process than that envisioned by the original > Mediator work, in Section 4.2. Sounds like "Section 4.2" refers to the "original Mediator work" rather than to "this document". Consider: "However, Section 4.2 of this document specifies a more flexible architecture for an Intermediate Aggregation Process than that envisioned by the original Mediator work." > Instead of a focus on these specific > limited use cases, the Intermediate Aggregation Process is specified > to cover any activity commonly described as "flow aggregation". This > architecture is intended to describe any such activity without > reference to the specific implementation of aggregation. > > An Intermediate Aggregation Process may be applied to data collected > from multiple Observation Points, as it is natural to use aggregation > for data reduction when concentrating measurement data. This > document specifically does not address the protocol issues that arise > when combining IPFIX data from multiple Observation Points and > exporting from a single Mediator, as these issues are general to > IPFIX Mediation; they are therefore treated in detail in the Mediaton s/Mediaton/Mediation/ > > Protocol [I-D.ietf-ipfix-mediation-protocol] document. "...Mediation Protocol document [I-D.ietf-ipfix-mediation-protocol]". > > > Since Aggregated Flows as defined in the following section are > essentially Flows, the IPFIX protocol > [I-D.ietf-ipfix-protocol-rfc5101bis] can be used to export, and the > IPFIX File Format [RFC5655] can be used to store, aggregated data > "as-is"; there are no changes necessary to the protocol. This > > > > Trammell, et al. Expires December 29, 2012 [Page 4] > > Internet-Draft IPFIX Aggregation June 2012 > > > document provides a common basis for the application of IPFIX to the > handling of aggregated data, through a detailed terminology, > Intermediate Aggregation Process architecture, and methods for > Original Flow counting and counter distribution across intervals. > > 1.1. IPFIX Protocol Overview > > In the IPFIX protocol, { type, length, value } tuples are expressed > in templates containing { type, length } pairs, specifying which { > value } fields are present in data records conforming to the > Template, giving great flexibility as to what data is transmitted. > Since Templates are sent very infrequently compared with Data > Records, this results in significant bandwidth savings. Various > different data formats may be transmitted simply by sending new > Templates specifying the { type, length } pairs for the new data > format. See [I-D.ietf-ipfix-protocol-rfc5101bis] for more > information. > > The IPFIX Information Element Registry [iana-ipfix-assignments] > defines a large number of standard Information Elements which provide > the necessary { type } information for Templates. The use of > standard elements enables interoperability among different vendors' > implementations. Additionally, non-standard enterprise-specific > elements may be defined for private use. > > 1.2. IPFIX Documents Overview > > "Specification of the IPFIX Protocol for the Exchange of IP Traffic > Flow Information" [I-D.ietf-ipfix-protocol-rfc5101bis] and its > associated documents define the IPFIX Protocol, which provides > network engineers and administrators with access to IP traffic flow > information. > > "Architecture for IP Flow Information Export" [RFC5470] defines the > architecture for the export of measured IP flow information out of an > IPFIX Exporting Process to an IPFIX Collecting Process, and the basic > terminology used to describe the elements of this architecture, per > the requirements defined in "Requirements for IP Flow Information > Export" [RFC3917]. The IPFIX Protocol document > [I-D.ietf-ipfix-protocol-rfc5101bis] then covers the details of the > method for transporting IPFIX Data Records and Templates via a > congestion-aware transport protocol from an IPFIX Exporting Process > to an IPFIX Collecting Process. > > This document specifies an Intermediate Process which may be applied > at an IPFIX Mediator. This sounds limiting. The process may be applied anywhere, eg even at the original OP prior to export. I'd move the above sentence to the end of this paragraph, so the present work is introduced in context after having explained mediation. > "IP Flow Information Export (IPFIX) Mediation: > Problem Statement" [RFC5982] introduces the concept of IPFIX > Mediators, and defines the use cases for which they were designed; > > > > Trammell, et al. Expires December 29, 2012 [Page 5] > > Internet-Draft IPFIX Aggregation June 2012 > > > "IP Flow Information Export (IPFIX) Mediation: Framework" [RFC6183] > then provides an architectural framework for Mediators. Protocol- > level issues (e.g., template and observation domain handling across > Mediators) are covered by "Specification of the Protocol for IPFIX > Mediation" [I-D.ietf-ipfix-mediation-protocol]. > > > 2. Terminology > > Terms used in this document that are defined in the Terminology > section of the IPFIX Protocol [I-D.ietf-ipfix-protocol-rfc5101bis] > document are to be interpreted as defined there. > > The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", > "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this > document are to be interpreted as described in [RFC2119]. > > In addition, this document defines the following terms > > Aggregated Flow: A Flow, as defined by > [I-D.ietf-ipfix-protocol-rfc5101bis], derived from a set of zero > or more original Flows within a defined Aggregation Interval. The Zero things can't be aggregated. You can only say, "none were seen". > > primary difference between a Flow and an Aggregated Flow in the > general case is that the time interval (i.e., the two-tuple of > start and end times) of a Flow is derived from information about > the timing of the packets comprising the Flow, while the time > interval of an Aggregated Flow is often externally imposed. Note > that an Aggregated Flow is defined in the context of an > Intermediate Aggregation Process only. Once an Aggregated Flow is > exported, it is essentially a Flow as in > [I-D.ietf-ipfix-protocol-rfc5101bis] and can be treated as such. > > Intermediate Aggregation Process: an Intermediate Process as in Add "(IAP)" here, since that's the term used throughout the document. > > [RFC6183] that aggregates records, based upon a set of Flow Keys > or functions applied to fields from the record. > > Aggregation Interval: A time interval imposed upon an Aggregated > Flow. Intermediate Aggregation Processes may use a regular > Aggregation Interval (e.g. "every five minutes", "every calendar > month"), though regularity is not necessary. Aggregation > intervals may also be derived from the time intervals of the > Original Flows being aggregated. > > Partially Aggregated Flow: A Flow during processing within an > Intermediate Aggregation Process; refers to an intermediate data > structure during aggregation within the Intermediate Aggregation > Process architecture detailed in Section 4.2. > > > > > Trammell, et al. Expires December 29, 2012 [Page 6] > > Internet-Draft IPFIX Aggregation June 2012 > > > Original Flow: A Flow given as input to an Intermediate Aggregation > Process in order to generate Aggregated Flows. > > Contributing Flow: An Original Flow that is partially or completely > represented within an Aggregated Flow. Each Aggregated Flow is > made up of zero or more Contributing Flows, and an Original Flow > may contribute to zero or more Aggregated Flows. > > Original Exporter: When the Intermediate Aggregation Process is > hosted in an IPFIX Mediator, the Original Exporter is the Exporter > from which the Original Flows are received. Does the meaning of "Original Exporter" change when the Intermediate Aggregation Process is _not_ hosted in an IPFIX Mediator? > > > The terminology presented herein improves the precision of, but does > not supersede or contradict the terms related to mediation and > aggregation defined in the problem statement [RFC5982] and the "Meditation Problem Statement [RFC5982]". > > framework [RFC6183] documents. Within this document, the terminology "Mediation Framework [RFC6183] documents." > > defined in this section is to be considered normative. > > > 3. Use Cases for IPFIX Aggregation > > Aggregation, as a common data reduction method used in traffic data > analysis, has many applications. When used with a regular > Aggregation Interval and Original Flows containing timing > information, it generates time series data from a collection of Flows > with discrete intervals, as in the example in Section 8.1. This time > series data is itself useful for a wide variety of analysis tasks, > such as generating input for network anomaly detection systems, or > driving visualizations of volume per time for traffic with specific > characteristics. As a second example, traffic matrix calculation > from flow data, as shown in Section 8.2 is inherently an aggregation > action, by aggregating the Flow Key down to input or output > interface, address prefix, or autonomous system. Clarify that aggregating interface, address, or AS, is aggregation in space versus aggregation in time. > > > Irregular or data-dependent Aggregation Intervals and key aggregation > operations can also be used to provide adaptive aggregation of > network flow data. Here, full Flow Records can be kept for Flows of > interest, while Flows deemed "less interesting" to a given > application can be aggregated. For example, in an IPFIX Mediator > equipped with traffic classification capabilities for security > purposes, potentially malicious Flows could be exported directly, > while known-good or probably-good Flows (e.g. normal web browsing) > could be exported simply as time series volumes per web server. > > Aggregation can also be applied to final analysis of stored Flow > data, as shown in the example in Section 8.3. All such aggregation > applications in which timing information is not available or not > important can be treated as if an infinite Aggregation Interval > > > > Trammell, et al. Expires December 29, 2012 [Page 7] > > Internet-Draft IPFIX Aggregation June 2012 > > > applies. > > Note that an Intermediate Aggregation Process which removes > potentially sensitive information as identified in [RFC6235] may tend > to have an anonymising effect on the Aggregated Flows, as well; Remove the comma. > > however, any application of aggregation as part of a data protection > scheme should ensure that all the issues raised in [RFC6235] are > addressed, specifically Section 4 "Anonymization of IP Flow Data", > Section 7.2 "IPFIX-Specific Anonymization Guidelines", and Section 9 > "Security Considerations". > > While much of the discussion in this document, and all of the > examples, apply to the common case that the Original Flows to be > aggregated are all of the same underlying type (i.e., are represented > with identical or compatible Templates), and that each packet What are "compatible" Templates ? How does this work when there are zero things to be aggregated? ie, are zero things all of the same type? > > observed by the Metering Process on the far side of the Original Where is "the far side" ? > > Exporter is represented, this is not a necessary assumption. > Aggregation can also be applied as part of a technique applying both > aggregation and correlation to pull together multiple views of the > same traffic from different Observation Points using different > Templates. For example, consider a set of applications running at > different Observation Points for different purposes -- one generating > flows with round-trip-times for passive performance measurement, and > one generating billing records. Once correlated, these flows could > used to produce Aggregated Flows containing both volume and > performance information together. The correlation and normalization > operation described in Section 4.2.1 handles this specific case of > correlation. Flow correlation in the general case is outside the > scope of this document. > > > 4. Architecture for Flow Aggregation > > This section specifies the architecture of the Intermediate > Aggregation Process, and how it fits into the IPFIX Architecture. > > 4.1. Aggregation within the IPFIX Architecture > > An Intermediate Aggregation Process could be deployed at any of three > places within the IPFIX Architecture. While aggregation is most > commonly done within a Mediator which collects Original Flows from an > Original Exporter and exports Aggregated Flows, aggregation can also > occur before initial export, or after final collection, as shown in > Figure 1. The presence of an IAP at any of these points is of course > optional. > > > > > > > Trammell, et al. Expires December 29, 2012 [Page 8] > > Internet-Draft IPFIX Aggregation June 2012 > > > +===========================================+ > | IPFIX Exporter +----------------+ | > | | Metering Proc. | | > | +-----------------+ +----------------+ | > | | Metering Proc. | or | IAP | | > | +-----------------+----+----------------+ | > | | Exporting Process | | > | +-|----------------------------------|--+ | > +===|==================================|====+ > | | > | (Aggregated Flow Export) | Why label just one of the streams as "Aggregated Flow Export" ? Why not label the other as regular flow export, and indicate below that both streams are AFE. > > | | > +===|===========================+ | > | | Aggregating Mediator | | > + +-V-------------------+ | | > | | Collecting Process | | | > + +---------------------+ | | > | | IAP | | | > + +---------------------+ | | > | | Exporting Process | | | > + +-|-------------------+ | | > +===|===========================+ | > | | > | | > +===|==================================|=====+ > | | Collector | | > | +-V----------------------------------V-+ | > | | Collecting Process | | > | +------------------+-------------------+ | > | | IAP | | Note that this IAP could be aggregating aggregated flows. Nothing wrong with that, though I don't think it's specifically mentioned. > > | +-------------------+ | > | (Aggregation | File Writer | | > for Storage) +-----------|-------+ | > +================================|===========+ > | > +------V-----------+ > | IPFIX File | > +------------------+ > > Figure 1: Potential Aggregation Locations > > The Mediator use case is further shown in Figures A and B in > [RFC6183]. > > Aggregation can be applied for either intermediate or final analytic > purposes. In certain circumstances, it may make sense to export > Aggregated Flows directly from an original Exporting Process, for Should "original EP" be defined terminology in this doc? > > example, if the Exporting Process is applied to drive a time-series > > > > Trammell, et al. Expires December 29, 2012 [Page 9] > > Internet-Draft IPFIX Aggregation June 2012 > > > visualization, or when flow data export bandwidth is restricted and > flow or packet sampling is not an option. Note that this case, where > the Aggregation Process is essentially integrated into the Metering > Process, is essentially covered by the IPFIX architecture [RFC5470]: > the Flow Keys used are simply a subset of those that would normally > be used, and time intervals may be chosen other than those available > from the cache policies customarily offered by the Metering Process. > A Metering Process in this arrangement MAY choose to simulate the > generation of larger Flows in order to generate Original Flow counts, > if the application calls for compatibility with an Aggregation > Process deployed in a separate location. > > In the specific case that an Aggregation Process is employed for data > reduction for storage purposes, it can take Original Flows from a > Collecting Process or File Reader and pass Aggregated Flows to a File > Writer for storage. > > Deployment of an Intermediate Aggregation Process within a Mediator > [RFC5982] is a much more flexible arrangement. Here, the Mediator > consumes Original Flows and produces Aggregated Flows; this > arrangement is suited to any of the use cases detailed in Section 3. > In a Mediator, Original Flows from multiple sources can also be > aggregated into a single stream of Aggregated Flows; the > architectural specifics of this arrangement are not addressed in this > document, which is concerned only with the aggregation operation > itself; see [I-D.ietf-ipfix-mediation-protocol] for details. > > The data paths into and out of an Intermediate Aggregation Process > are shown in Figure 2. > > > > > > > > > > > > > > > > > > > > > > > Trammell, et al. Expires December 29, 2012 [Page 10] > > Internet-Draft IPFIX Aggregation June 2012 > > > packets --+ IPFIX Messages IPFIX Files > | | | > V V V > +==================+ +====================+ +=============+ > | Metering Process | | Collecting Process | | File Reader | > | | +====================+ +=============+ > | (Original Flows | | Original Flows | > | or direct aggr.)| V V What is "direct aggr." ? > > + - - - - - - - - -+======================================+ > | Intermediate Aggregation Process (IAP) | This is the 6th time that "IAP" has been used, and the first time it has been explained. Please define the term. > > +=========================================================+ > | Aggregated Aggregated | > | Flows Flows | > V V > +===================+ +=============+ > | Exporting Process | | File Writer | > +===================+ +=============+ > | | > V V > IPFIX Messages IPFIX Files > > Figure 2: Data paths through the aggregation process > > Aggregation may also need to correlate original flows from multiple > Metering Processes, each according to a different Template with > different Flow Keys and values. This arrangement is shown in > Figure 3; in this case, the correlation and normalization operation > described in Section 4.2.1 handles merging the Original Flows before Missing text: "before..." what? > > > > > > > > > > > > > > > > > > > > > > > > > Trammell, et al. Expires December 29, 2012 [Page 11] > > Internet-Draft IPFIX Aggregation June 2012 > > > packets --+---------------------+------------------+ > | | | > V V V > +====================+ +====================+ +====================+ > | Metering Process 1 | | Metering Process 2 | | Metering Process n | > +====================+ +====================+ +====================+ > | | Original Flows | > V V V > +==================================================================+ > | Intermediate Aggregation Process + correlation / normalization | > +==================================================================+ > | Aggregated Aggregated | > | Flows Flows | > V V > +===================+ +=============+ > | Exporting Process | | File Writer | > +===================+ +=============+ > | | > +------------> IPFIX Messages<----------+ > > Figure 3: Aggregating Original Flows from multiple Metering Processes > > 4.2. Intermediate Aggregation Process Architecture > > Within this document, an Intermediate Aggregation Process can be seen > as hosting a function composed of four types of operations on > Partially Aggregated Flows, as illustrated in Figure 4. "Partially > Aggregated Flows" as defined in Section 2 are essentially the > intermediate results of aggregation, internal to the Intermediate > Aggregation Process. > > > > > > > > > > > > > > > > > > > > > > Trammell, et al. Expires December 29, 2012 [Page 12] > > Internet-Draft IPFIX Aggregation June 2012 > > > Original Flows / Original Flows requiring correlation > +=============|===================|===================|=============+ > | | Intermediate | Aggregation | Process | > | | V V | > | | +-----------------------------------------------+ | > | | | (optional) correlation and normalization | | > | | +-----------------------------------------------+ | > | | | | > | V V | > | +--------------------------------------------------------------+ | > | | interval distribution (temporal) | | > | +--------------------------------------------------------------+ | > | | ^ | ^ | | > | | | Partially Aggregated | | Flows | | > | V | V | | | > | +-------------------+ +--------------------+ | | > | | key aggregation |<------| value aggregation | | | > | | (spatial) |------>| (spatial) | | | > | +-------------------+ +--------------------+ | | > | | | | | > | | Partially Aggregated | Flows | | Separating out "Partially Aggregated Flows" like this doesn't work for me. Put "Flows" underneath "PA". > > | V V V | > | +--------------------------------------------------------------+ | > | | aggregate combination | | > | +--------------------------------------------------------------+ | > | | | > +=======================================|===========================+ > V > Aggregated Flows > > Figure 4: Conceptual model of aggregation operations within an IAP The section below has irregular indentation: label, then 2 or 3 spaces, then text. > > Interval distribution is a temporal aggregation operation which > imposes an Aggregation Interval on the partially Aggregated Flow. > This Aggregation Interval may be regular, irregular, or derived > from the timing of the Original Flows themselves. Interval > distribution is discussed in detail in Section 5.1. > > Key aggregation is a spatial aggregation operation which results in > the addition, modification, or deletion of Flow Key fields in the > Partially Aggregated Flows. New Flow Keys may be derived from > existing Flow Keys (e.g., looking up an AS number for an IP > address), or "promoted" from specific non-Key fields (e.g., when > aggregating Flows by packet count per Flow). Key aggregation can > also add new non-Key fields derived from Flow Keys that are > deleted during key aggregation; mainly counters of unique reduced > keys. Key aggregation is discussed in detail in Section 5.2. > > > > > Trammell, et al. Expires December 29, 2012 [Page 13] > > Internet-Draft IPFIX Aggregation June 2012 > > > Value aggregation is a spatial aggregation operation which results > in the addition, modification, or deletion of non-Key fields in > the Partially Aggregated Flows. These non-Key fields may be > "demoted" from existing Key fields, or derived from existing Key > or non-Key fields. Value aggregation is discussed in detail in > Section 5.3. > > Aggregate combination combines multiple partially Aggregated Flows > having undergone interval distribution, key aggregation, and value > aggregation which share Flow Keys and Aggregation Intervals into a > single Aggregated Flow per set of Flow Key values and Aggregation > Interval. Aggregate combination is discussed in detail in > Section 5.4. > > Correlation and normalization is required when accepting Original > Flows from Metering Processes which export different views of > essentially the same Flows before aggregation; the details of > correlation and normalization are specified in Section 4.2.1, > below. > > The first three of these operations may be carried out any number of > times in any order, either on Original Flows or on the results of one > of the operations above, with one caveat: since Flows carry their own > interval data, any spatial aggregation operation implies a temporal > aggregation operation, so at least one interval distribution step, > even if implicit, is required by this architecture. This is shown as > the first step for the sake of simplicity in the diagram above. Once > all aggregation operations are complete, aggregate combination > ensures that for a given Aggregation Interval, set of Flow Key > values, and Observation Domain, only one Flow is produced by the > Intermediate Aggregation Process. > > This model describes the operations within a single Intermediate > Aggregation Process, and it is anticipated that most aggregation will > be applied within a single process. However, as the steps in the > model may be applied in any order and aggregate combination is > idempotent, any number of Intermediate Aggregation Processes > operating in series can be modeled as a single process. This allows > aggregation operations to be flexibly distributed across any number > of processes, should application or deployment considerations so > dictate. > > 4.2.1. Correlation and Normalization > > When accepting Original Flows from multiple Metering Processes, each > of which provides a different view of the Original Flow as seen from > the point of view of the IAP, an optional correlation and > normalization operation combines each of these single Flow Records > > > > Trammell, et al. Expires December 29, 2012 [Page 14] > > Internet-Draft IPFIX Aggregation June 2012 > > > into a set of unified partially aggregated Flows before applying > interval distribution. These unified Flows appear as if they had > been measured at a single Metering Process which used the union of > the set of Flow Keys and non-key fields of all Metering Processes > sending Original Flows to the IAP. > > Since, due to export errors or other slight irregularities in flow > metering, the multiple views may not be completely consistent; > normalization involves applying a set of aggregation application > specific corrections in order to ensure consistency in the unified > Flows. > > In general, correlation and normalization should take multiple views > of essentially the same Flow, as determined by the configuration of > the operation itself, and render them into a single unified Flow. > Flows which are essentially different should not be unified by the > correlation and normalization operation. This operation therefore > requires enough information about the configuration and deployment of > Metering Processes from which it correlates Original Flows in order > to make this distinction correctly and consistently. > > The exact steps performed to correlate and normalize flows in this > step are application-, implementation-, and deployment-specific, and > will not be further specified in this document. > > > 5. IP Flow Aggregation Operations > > As stated in Section 2, an Aggregated Flow is simply an IPFIX Flow > generated from Original Flows by an Intermediate Aggregation Process. > Here, we detail the operations by which this is achieved within an > Intermediate Aggregation Process. > > 5.1. Temporal Aggregation through Interval Distribution > > Interval distribution imposes a time interval on the resulting > Aggregated Flows. The selection of an interval is specific to the > given aggregation application. Intervals may be derived from the > Original Flows themselves (e.g., an interval may be selected to cover > the entire time containing the set of all Flows sharing a given Key, > as in Time Composition described in Section 5.1.2) or externally > imposed; in the latter case the externally imposed interval may be > regular (e.g., every five minutes) or irregular (e.g., to allow for > different time resolutions at different times of day, under different > network conditions, or indeed for different sets of Original Flows). > > The length of the imposed interval itself has tradeoffs. Shorter > intervals allow higher-resolution aggregated data and, in streaming > > > > Trammell, et al. Expires December 29, 2012 [Page 15] > > Internet-Draft IPFIX Aggregation June 2012 > > > applications, faster reaction time. Longer intervals generally lead > to greater data reduction and simplified counter distribution. > Specifically, counter distribution is greatly simplified by the > choice of an interval longer than the duration of longest Original > Flow, itself generally determined by the Original Flow's Metering > Process active timeout; in this case an Original Flow can contribute > to at most two Aggregated Flows, and the more complex value > distribution methods become inapplicable. > > | | | | > | |<--Flow A-->| | | | > | |<--Flow B-->| | | > | |<-------------Flow C-------------->| | > | | | | > | interval 0 | interval 1 | interval 2 | > > Figure 5: Illustration of interval distribution > > In Figure 5, we illustrate three common possibilities for interval > distribution as applies with regular intervals to a set of three > Original Flows. For Flow A, the start and end times lie within the > boundaries of a single interval 0; therefore, Flow A contributes to > only one Aggregated Flow. Flow B, by contrast, has the same duration > but crosses the boundary between intervals 0 and 1; therefore, it > will contribute to two Aggregated Flows, and its counters must be > distributed among these Flows, though in the two-interval case this > can be simplified somewhat simply by picking one of the two > intervals, or proportionally distributing between them. Only Flows > like Flow A and Flow B will be produced when the interval is chosen > to be longer than the duration of longest Original Flow, as above. > More complicated is the case of Flow C, which contributes to more > than two Aggregated Flows, and must have its counters distributed > according to some policy as in Section 5.1.1. This discussion applies equally to many other fields. eg, Figure 5 could show source ports, with the "intervals" grouping well-known ports and ephemeral ports. Flow A uses only a few source ports whereas Flow C uses many. > > 5.1.1. Distributing Values Across Intervals > > In general, counters in Aggregated Flows are treated the same as in > any Flow. Each counter is independently calculated as if it were > derived from the set of packets in the Original Flow. For the most > part, when aggregating Original Flows into Aggregated Flows, this is > simply done by summation. Not true: it depends on the counter's semantics. Delta counters can be summed. However, a total count would be superseded by a subsequent total count. > > > When the Aggregation Interval is guaranteed to be longer than the > longest Original Flow, a Flow can cross at most one Interval > boundary, and will therefore contribute to at most two Aggregated > Flows. Most common in this case is to arbitrarily but consistently > choose to account the Original Flow's counters either to the first or > the last Aggregated Flow to which it could contribute. > > > > Trammell, et al. Expires December 29, 2012 [Page 16] > > Internet-Draft IPFIX Aggregation June 2012 > > > However, this becomes more complicated when the Aggregation Interval > is shorter than the longest Original Flow in the source data. In > such cases, each Original Flow can incompletely cover one or more > time intervals, and apply to one or more Aggregated Flows. In this > case, the Aggregation Process must distribute the counters in the > Original Flows across the multiple Aggregated Flows. There are "must distribute" seems contrary to the "End Interval" and "Start Interval" schemes below. > > several methods for doing this, listed here in roughly increasing > order of complexity and accuracy; most of these are necessary only in > specialized cases. > > End Interval: The counters for an Original Flow are added to the > counters of the appropriate Aggregated Flow containing the end > time of the Original Flow. > > Start Interval: The counters for an Original Flow are added to the > counters of the appropriate Aggregated Flow containing the start > time of the Original Flow. > > Mid Interval: The counters for an Original Flow are added to the > counters of a single appropriate Aggregated Flow containing some > timestamp between start and end time of the Original Flow. > > Simple Uniform Distribution: Each counter for an Original Flow is > divided by the number of time intervals the Original Flow covers > (i.e., of appropriate Aggregated Flows sharing the same Flow > Keys), and this number is added to each corresponding counter in > each Aggregated Flow. > > Proportional Uniform Distribution: This is like simple uniform > distribution, but accounts for the fractional portions of a time > interval covered by an Original Flow in the first and last time > interval. Each counter for an Original Flow is divided by the > number of time _units_ the Original Flow covers, to derive a mean > count rate. This rate is then multiplied by the number of time > units in the intersection of the duration of the Original Flow and > the time interval of each Aggregated Flow. > > Simulated Process: Each counter of the Original Flow is distributed > among the intervals of the Aggregated Flows according to some > function the Aggregation Process uses based upon properties of > Flows presumed to be like the Original Flow. For example, Flow > Records representing bulk transfer might follow a more or less > proportional uniform distribution, while interactive processes are > far more bursty. BTW, the case of a collector or mediator aggregating received flows presents another possibility: the flow could be received late (eg, delayed export), so rather than re-opening an old start / mid / end aggregation, the flow is simply included in the "current" aggregation. ie, real time aggregation, regardless of the flow timestamps. > > > > > > > > > Trammell, et al. Expires December 29, 2012 [Page 17] > > Internet-Draft IPFIX Aggregation June 2012 > > > Direct: The Aggregation Process has access to the original packet > timings from the packets making up the Original Flow, and uses > these to distribute or recalculate the counters. > > A method for exporting the distribution of counters across multiple > Aggregated Flows is detailed in Section 7.4. In any case, counters > MUST be distributed across the multiple Aggregated Flows in such a > way that the total count is preserved, within the limits of accuracy > of the implementation. This property allows data to be aggregated > and re-aggregated with negligible loss of original count information. > To avoid confusion in interpretation of the aggregated data, all the > counters for a set of given Original Flows SHOULD be distributed via > the same method. Consider changing that to a "MUST". As long as the method is consistent, is it necessary to know what method was used? > > > More complex counter distribution methods generally require that the > interval distribution process track multiple "current" time intervals > at once. This may introduce some delay into the aggregation > operation, as an interval should only expire and be available for > export when no additional Original Flows applying to the interval are > expected to arrive at the Intermediate Aggregation Process. > > Note, however, that since there is no guarantee that Flows from the > Original Exporter will arrive in any given order, whether for > transport-specific reasons (i.e. UDP reordering) or Metering Process Or Exporting Process. > > implementation-specific reasons, even simpler distribution methods > may need to deal with flows arriving in other than start time or end > time order. Therefore, the use of larger intervals does not obviate > the need to buffer Partially Aggregated Flows within "current" time > intervals, to ensure it can accept flow time intervals in any arrival The subject is missing for "it". eg, "the need for an aggregation process to buffer", or "to ensure the aggregation process can accept". > > order. More generally, the interval distribution process SHOULD > accept flow start and end times in the Original Flows in any > reasonable order. The expiration of intervals in interval > distribution operations is dependent on implementation and deployment > requirements, and SHOULD be made configurable in contexts in which > "reasonable order" is not obvious at implementation time. This > operation may lead to delay and loss introduced by the IAP, as > detailed in Section 6.2. > > 5.1.2. Time Composition > > Time Composition as in Section 5.4 of [RFC5982] (or interval > combination) is a special case of aggregation, where interval > distribution imposes longer intervals on Flows with matching keys and > "chained" start and end times, without any key reduction, in order to > join long-lived Flows which may have been split (e.g., due to an > active timeout shorter than the actual duration of the Flow.) Here, > no Key aggregation is applied, and the Aggregation Interval is chosen > on a per-Flow basis to cover the interval spanned by the set of > > > > Trammell, et al. Expires December 29, 2012 [Page 18] > > Internet-Draft IPFIX Aggregation June 2012 > > > aggregated Flows. This may be applied alone in order to normalize > split Flows, or in combination with other aggregation functions in > order to obtain more accurate Original Flow counts. > > 5.1.3. External Interval Distribution > > Note that much of the difficulty of interval distribution at an IAP > can be avoided simply by configuring the original Exporters to > synchronize the time intervals in the Original Flows with the desired > aggregation interval. The resulting Original Flows would then be > split to align perfectly with the time intervals imposed during > Interval Imposition (i.e., like Flow A in Figure 5), though this may > reduce their usefulness for non-Aggregation purposes. This approach > allows the Intermediate Aggregation Process to use Start Interval or > End Interval distribution, while having equivalent information to > that available to Direct interval distribution. > > 5.2. Spatial Aggregation of Flow Keys > > Key aggregation generates a new set of Flow Key values for the > Aggregated Flows from the Original Flow Key and non-Key fields in the > Original Flows, or from correlation of the Original Flow information > with some external source. There are two basic operations here. > First, Aggregated Flow Keys may be derived directly from Original > Flow Keys through reduction, or the dropping of fields or precision > in the Original Flow Keys. Second, Aggregated Flow Keys may be > derived through replacement, e.g. by removing one or more fields from > the Original Flow and replacing them with fields derived from the > removed fields. Replacement may refer to external information (e.g., > IP to AS number mappings). Replacement may apply to Flow Keys as > well as non-key fields. For example, consider an application which > aggregates Original Flows by packet count (i.e., generating an > Aggregated Flow for all one-packet Flows, one for all two-packet > Flows, and so on). This application would promote the packet count > to a Flow Key. In this case, the non-key counter field can be promoted to a key field since it only contains a single value which is consistent across all the flows. However, if the aggregation was "all small flows < 10 packets", then t would be inappropriate to promote the packet count to a key field. > > > Key aggregation may also result in the addition of new non-Key fields > to the Aggregated Flows, namely Original Flow counters and unique > reduced key counters; these are treated in more detail in > Section 5.2.1 and Section 5.2.2, respectively. > > In any key aggregation operation, reduction and/or replacement may be > applied any number of times in any order. Which of these operations > are supported by a given implementation is implementation- and > application-dependent. > > > > > > > Trammell, et al. Expires December 29, 2012 [Page 19] > > Internet-Draft IPFIX Aggregation June 2012 > > > Original Flow Keys > +---------+---------+----------+----------+-------+-----+ > | src ip4 | dst ip4 | src port | dst port | proto | tos | > +---------+---------+----------+----------+-------+-----+ > | | | | | | > retain mask /24 X X X X > V V > +---------+-------------+ > | src ip4 | dst ip4 /24 | > +---------+-------------+ > Aggregated Flow Keys (by source address and destination class-C) > > Figure 6: Illustration of key aggregation by reduction > > Figure 6 illustrates an example reduction operation, aggregation by > source address and destination class C network. Here, the port, > protocol, and type-of-service information is removed from the Flow > Key, the source address is retained, and the destination address is > masked by dropping the lower 8 bits. The text and figures are a bit cramped here. Can you improve the layout by spacing things out a little? > > > Original Flow Keys > +---------+---------+----------+----------+-------+-----+ > | src ip4 | dst ip4 | src port | dst port | proto | tos | > +---------+---------+----------+----------+-------+-----+ > | | | | | | > +-------------------+ X X X X > | ASN lookup table | > +-------------------+ > V V > +---------+---------+ > | src asn | dst asn | > +---------+---------+ > Aggregated Flow Keys (by source and dest ASN) > > Figure 7: Illustration of key aggregation by reduction and > replacement > > Figure 7 illustrates an example reduction and replacement operation, > aggregation by source and destination Border Gateway Protocol (BGP) > Autonomous System Number (ASN) without ASN information available in > the Original Flow. Here, the port, protocol, and type-of-service > information is removed from the Flow Keys, while the source and > destination addresses are run though an IP address to ASN lookup > table, and the Aggregated Flow Keys are made up of the resulting > source and destination ASNs. > > > > > > > Trammell, et al. Expires December 29, 2012 [Page 20] > > Internet-Draft IPFIX Aggregation June 2012 > > > 5.2.1. Counting Original Flows > > When aggregating multiple Original Flows into an Aggregated Flow, it > is often useful to know how many Original Flows are present in the > Aggregated Flow. This document introduces four new information > elements in Section 7.2 to export these counters. "Section 7.2 ofthis document introduces four new information elements to export these counters." > > > There are two possible ways to count Original Flows, which we call > here conservative and non-conservative. Conservative flow counting > has the property that each Original Flow contributes exactly one to > the total flow count within a set of Aggregated Flows. In other > words, conservative flow counters are distributed just as any other > counter during interval distribution, except each Original Flow is > assumed to have a flow count of one. When a count for an Original > Flow must be distributed across a set of Aggregated Flows, and a > distribution method is used which does not account for that Original > Flow completely within a single Aggregated Flow, conservative flow > counting requires a fractional representation. > > By contrast, non-conservative flow counting is used to count how many > Contributing Flows are represented in an Aggregated Flow. Flow > counters are not distributed in this case. An Original Flow which is > present within N Aggregated Flows would add N to the sum of non- > conservative flow counts, one to each Aggregated Flow. In other > words, the sum of conservative flow counts over a set of Aggregated > Flows is always equal to the number of Original Flows, while the sum > of non-conservative flow counts is strictly greater than or equal to > the number of Original Flows. > > For example, consider Flows A, B, and C as illustrated in Figure 5. > Assume that the key aggregation step aggregates the keys of these > three Flows to the same aggregated Flow Key, and that start interval > counter distribution is in effect. The conservative flow count for > interval 0 is 3 (since Flows A, B, and C all begin in this interval), > and for the other two intervals is 0. The non-conservative flow > count for interval 0 is also 3 (due to the presence of Flows A, B, > and C), for interval 1 is 2 (Flows B and C), and for interval 2 is 1 > (Flow C). The sum of the conservative counts 3 + 0 + 0 = 3, the > number of Original Flows; while the sum of the non-conservative > counts 3 + 2 + 1 = 6. > > Note that the active and inactive timeouts used to generate Original > Flows, as well as the cache policy used to generate those Flows, have > an effect on how meaningful either the conservative or non- > conservative flow count will be during aggregation. In general, all > the Original Exporters producing Original Flows to be aggregated > SHOULD be aggregated using caches configured identically or > similarly. Original Exporters using the IPFIX Configuration Model What does "identically or similarly" mean? In other words, how do we determine compliance with the SHOULD? > > > > > Trammell, et al. Expires December 29, 2012 [Page 21] > > Internet-Draft IPFIX Aggregation June 2012 > > > SHOULD be configured to export Flows with equal or similar > activeTimeout and inactiveTimeout configuration values, and the same > cacheMode, as defined in [I-D.ietf-ipfix-configuration-model]. > > 5.2.2. Counting Distinct Key Values > > One common case in aggregation is counting distinct key values that > were reduced away during key aggregation. The most common use case > for this is counting distinct hosts per Flow Key; for example, in > host characterization or anomaly detection, distinct sources per > destination or distinct destinations per source are common metrics. > These new non-Key fields are added during key aggregation. > > For such applications, Information Elements for distinct counts of > IPv4 and IPv6 addresses are defined in Section 7.3. These are named > distinctCountOf(KeyName). Additional such Information Elements > SHOULD be registered with IANA on an as-needed basis. > > 5.3. Spatial Aggregation of Non-Key Fields > > Aggregation operations may also lead to the addition of value fields > demoted from key fields, or derived from other value fields in the > Original Flows. Specific cases of this are treated in the > subsections below. > > 5.3.1. Counter Statistics > > Some applications of aggregation may benefit from computing different > statistics than those native to each non-key field (i.e., union for > flags, sum for counters). For example, minimum and maximum packet NB ambiguity whether the examples in the "ie" are the "native" or "different" statistics. > > counts per Flow, mean bytes per packet per Contributing Flow, and so > on. Certain Information Elements for these applications are already > provided in the IANA IPFIX Information Elements registry > (http://www.iana.org/assignments/ipfix/ipfix.html (e.g. > minimumIpTotalLength). > > A complete specification of additional aggregate counter statistics > is outside the scope of this document, and should be added in the > future to the IANA IPFIX Information Elements registry on a per- > application, as-needed basis. > > 5.3.2. Derivation of New Values from Flow Keys and non-Key fields > > More complex operations may lead to other derived fields being > generated from the set of values or Flow Keys reduced away during > aggregation. A prime example of this is sample entropy calculation. > This counts distinct values and frequency, so is similar to distinct > key counting as in Section 5.2.2, but may be applied to the > > > > Trammell, et al. Expires December 29, 2012 [Page 22] > > Internet-Draft IPFIX Aggregation June 2012 > > > distribution of values for any flow field. > > Sample entropy calculation provides a one-number normalized > representation of the value spread and is useful for annomaly s/annomaly/anomaly/ > > detection. The behaviour of entropy statistics is such that a small > number of keys showing up very often drives the entropy value down > towards zero, while a large number of keys, each showing up with > lower frequency drives the entropy value up. Add comma: "lower frequency," > > > Entropy statistics are generally useful for address-like keys, like What does "address-like" mean? > > IP addresses, port numbers, AS numbers, etc. They can also be done Consider "done" -> "calculated" ? > > on flow length, flow duration fields and the like, even if this > generally yields less distinct value shifts when the traffic mix > changes. > > As a practical example, one host scanning a lot of other hosts will > drive source IP entropy down and target IP entropy up. A similar > effect can be observed for ports. This pattern can also be caused by > the scan-traffic of a fast Internet worm. A second example would be > a DDoS flooding attack against a single target (or small number of > targets) which drives source IP entropy up and target IP entropy > down. > > A complete specification of additional derived values or entropy > information elements is outside the scope of this document. Any such > Information Elements should be added in the future to the IANA IPFIX > Information Elements registry on a per-application, as-needed basis. > However, in the special case of entropy calculations, to support > comparability of entropies of fields with different bit sizes, > entropy SHOULD be represented as a float32 or float64 value > normalized to the range [0..1]. You're hoping that future requesters / experts will remember to refer to this recommendation? Are you citing this from IE police? > > > 5.4. Aggregation Combination > > Interval distribution and key aggregation together may generate > multiple Partially Aggregated Flows covering the same time interval > with the same set of Flow Key values. The process of combining these > Partially Aggregated Flows into a single Aggregated Flow is called > aggregation combination. In general, non-Key values from multiple > Contributing Flows are combined using the same operation by which > values are combined from packets to form Flows for each Information > Element. Counters are summed, averages are averaged, flags are > unioned, and so on. Disagree. Delta counters can be summed; total counters need the latest (newest) value. However, averages *cannot* be averaged. Suppose A1 = 0.25 and A2 = 0.75, what is their average? -> we can't know without knowing the base population size. eg, if flow 1 sampled 25 out of 100 packets (ie, 0.25) and flow 2 sampled 150 out of 200 packets (0.75), the aggregate represents (25 + 150) out of (100 + 200) = 175/300 = 0.58. > > > > 6. Additional Considerations and Special Cases in Flow Aggregation > > > > > > Trammell, et al. Expires December 29, 2012 [Page 23] > > Internet-Draft IPFIX Aggregation June 2012 > > > 6.1. Exact versus Approximate Counting during Aggregation > > In certain circumstances, particularly involving aggregation by > devices with limited resources, and in situations where exact > aggregated counts are less important than relative magnitudes (e.g. > driving graphical displays), counter distribution during key > aggregation may be performed by approximate counting means (e.g. > Bloom filters). The choice to use approximate counting is > implementation- and application-dependent. Check spacing: "implementation- and application- dependent." > > > 6.2. Delay and Loss introduced by the IAP > > When accepting Original Flows in export order from traffic captured > live, the Intermediate Aggregation Process wait for all Original s/wait/waits/ > > Flows which may contribute to a given interval during interval > distribution. This is generally dominated by the active timeout of > the Metering Process measuring the Original Flows. For example, with > Metering Processes configured with a 5 minute active timeout, the > Intermediate Aggregation Process introduces a delay of at least 5 > minutes to all exported Aggregated Flows to ensure it has received > all Original Flows. > > In certain circumstances, additional delay at the original Exporter > may cause an IAP to close an interval before the last Original > Flow(s) accountable to the interval arrives; in this case the IAP > SHOULD drop the late Original Flow(s). Accounting of flows lost at > an Intermediate Process due to such issues is covered in > [I-D.ietf-ipfix-mediation-protocol]. > > 6.3. Considerations for Aggregation of Sampled Flows > > The accuracy of Aggregated Flows may also be affected by sampling of > the Original Flows, or sampling of packets making up the Original > Flows. At the time of writing, the effect of sampling on flow > aggregation is still an open research question. However, to maximize > the comparability of Aggregated Flows, aggregation of sampled Flows > SHOULD only use Original Flows sampled using the same sampling rate > and sampling algorithm, Flows created from packets sampled using the > same sampling rate and sampling algorithm, or Original Flows which > have been normalized as if they had the same sampling rate and > algorithm before aggregation. For more on packet sampling within > IPFIX, see [RFC5476]. For more on Flow sampling within the IPFIX > Mediator Framework, see [I-D.ietf-ipfix-flow-selection-tech]. > > 6.4. Considerations for Aggregation of Heterogeneous Flows > > Aggregation may be applied to Original Flows from different sources > and of different types (i.e., represented using different, perhaps > > > > Trammell, et al. Expires December 29, 2012 [Page 24] > > Internet-Draft IPFIX Aggregation June 2012 > > > wildly-different Templates). When the goal is to separate the > heterogeneous Original Flows and aggregate them into heterogeneous > Aggregated Flows, each aggregation should be done at its own > Intermediate Aggregation Process. The Observation Domain ID on the > Messages containing the output Aggregated Flows can be used to > identify the different Processes, and to segregate the output. > > However, when the goal is to aggregate these Flows into a single > stream of Aggregated Flows representing one type of data, and if the > Original Flows may represent the same original packet at two > different Observation Points, the Original Flows should be correlated > by the correlation and normalization operation within the IAP to > ensure that each packet is only represented in a single Aggregated > Flow or set of Aggregated Flows differing only by aggregation > interval. > > > 7. Export of Aggregated IP Flows using IPFIX > > In general, Aggregated Flows are exported in IPFIX as any normal Consider using "other" instead of "normal" to avoid the connotation that there are "abnormal" flows. > > Flow. However, certain aspects of Aggregated Flow export benefit > from additional guidelines, or new Information Elements to represent > aggregation metadata or information generated during aggregation. > These are detailed in the following subsections. > > 7.1. Time Interval Export > > Since an Aggregated Flow is simply a Flow, the existing timestamp > Information Elements in the IPFIX Information Model (e.g., > flowStartMilliseconds, flowEndNanoseconds) are sufficient to specify > the time interval for aggregation. Therefore, this document > specifies no new aggregation-specific Information Elements for > exporting time interval information. More strongly: "Therefore, no new aggregation-specific Information Elements are required for exporting time interval information." > > > Each Aggregated Flow carrying timing information SHOULD contain both > an interval start and interval end timestamp. Can this next paragraph be removed? The above text is sufficient. > If an exporter of > Aggregated Flows omits the interval end timestamp from each > Aggregated Flow, the time interval for Aggregated Flows within an > Observation Domain and Transport Session MUST be regular and > constant. However, note that this approach might lead to > interoperability problems when exporting Aggregated Flows to non- > aggregation-aware Collecting Processes and downstream analysis tasks; > therefore, an Exporting Process capable of exporting only interval > start timestamps MUST provide a configuration option to export > interval end timestamps as well. (removed to here) > > > > > > > > Trammell, et al. Expires December 29, 2012 [Page 25] > > Internet-Draft IPFIX Aggregation June 2012 > > > 7.2. Flow Count Export > > The following four Information Elements are defined to count Original > Flows as discussed in Section 5.2.1. > > 7.2.1. originalFlowsPresent > > Description: The non-conservative count of Original Flows > contributing to this Aggregated Flow. Non-conservative counts > need not sum to the original count on re-aggregation. > > Abstract Data Type: unsigned64 Sematics? Either totalCount or deltaCount. Same for the fields below too. > > > ElementId: TBD1 > > Status: Current I'm sure it's not necessary to say "Status: Current", since it's very unlikely that we'd be introducing new but deprecated fields. What does IE police have to say on this matter? > > > 7.2.2. originalFlowsInitiated > > Description: The conservative count of Original Flows whose first > packet is represented within this Aggregated Flow. Conservative > counts must sum to the original count on re-aggregation. > > Abstract Data Type: unsigned64 > > ElementId: TBD2 > > Status: Current > > 7.2.3. originalFlowsCompleted > > Description: The conservative count of Original Flows whose last > packet is represented within this Aggregated Flow. Conservative > counts must sum to the original count on re-aggregation. > > Abstract Data Type: unsigned64 > > ElementId: TBD3 > > Status: Current > > 7.2.4. deltaFlowCount > > Description: The conservative count of Original Flows contributing > to this Aggregated Flow; may be distributed via any of the methods > described in Section 5.1.1. This Information Element is > compatible with Information Element 3 as used in NetFlow version > 9. This is not a good description for inclusion in the IANA registry (which currently doesn't define element 3): - "may be distributed via any of the methods described in Section 5.1.1." only makes sense within the context of this document. - "This Information Element is compatible with Information Element 3 as used in NetFlow version 9." is suitable as a Note, but not as part of the description. > > > > > Trammell, et al. Expires December 29, 2012 [Page 26] > > Internet-Draft IPFIX Aggregation June 2012 > > > Abstract Data Type: unsigned64 > > ElementId: 3 > > Status: Current > > 7.3. Distinct Host Export > > The following four Information Elements represent the distinct counts > of source and destination network-layer addresses, used to export > distinct host counts reduced away during key aggregation. > > 7.3.1. distinctCountOfSourceIPAddress > > Description: The count of distinct source IP address values for > Original Flows contributing to this Aggregated Flow, without > regard to version. This Information Element is preferred to the "regard to _IP_ version". > > IP-version-specific counters, unless it is important to separate > the counts by version. > > Abstract Data Type: unsigned64 > > ElementId: TBD4 > > Status: Current > > 7.3.2. distinctCountOfDestinationIPAddress > > Description: The count of distinct destination IP address values > for Original Flows contributing to this Aggregated Flow, without > regard to version. This Information Element is preferred to the "regard to _IP_ version". > > version-specific counters below, unless it is important to > separate the counts by version. > > Abstract Data Type: unsigned64 > > ElementId: TBD5 > > Status: Current > > 7.3.3. distinctCountOfSourceIPv4Address > > Description: The count of distinct source IPv4 address values for > Original Flows contributing to this Aggregated Flow. > > > > > > > > Trammell, et al. Expires December 29, 2012 [Page 27] > > Internet-Draft IPFIX Aggregation June 2012 > > > Abstract Data Type: unsigned32 > > ElementId: TBD6 > > Status: Current > > 7.3.4. distinctCountOfDestinationIPv4Address > > Description: The count of distinct destination IPv4 address values > for Original Flows contributing to this Aggregated Flow. > > Abstract Data Type: unsigned32 > > ElementId: TBD7 > > Status: Current > > 7.3.5. distinctCountOfSourceIPv6Address > > Description: The count of distinct source IPv6 address values for > Original Flows contributing to this Aggregated Flow. > > Abstract Data Type: unsigned64 > > ElementId: TBD8 > > Status: Current > > 7.3.6. distinctCountOfDestinationIPv6Address > > Description: The count of distinct destination IPv6 address values > for Original Flows contributing to this Aggregated Flow. > > Abstract Data Type: unsigned64 > > ElementId: TBD9 > > Status: Current It's a pity that six new IEs were required here, rather than a single "countOf" field + property. eg, "countOf" + "SourceIPv6Address". > > > 7.4. Aggregate Counter Distribution Export > > When exporting counters distributed among Aggregated Flows, as > described in Section 5.1.1, the Exporting Process MAY export an > Aggregate Counter Distribution Option Record for each Template > describing Aggregated Flow records; this Options Template is > described below. It uses the valueDistributionMethod Information > Element, also defined below. Since in many cases distribution is > simple, accounting the counters from Contributing Flows to the first > > > > Trammell, et al. Expires December 29, 2012 [Page 28] > > Internet-Draft IPFIX Aggregation June 2012 > > > Interval to which they contribute, this is the default situation, for > which no Aggregate Counter Distribution Record is necessary; > Aggregate Counter Distribution Records are only applicable in more > exotic situations, such as using an Aggregation Interval smaller than > the durations of Original Flows. > > 7.4.1. Aggregate Counter Distribution Options Template > > This Options Template defines the Aggregate Counter Distribution > Record, which allows the binding of a value distribution method to a > Template ID. Note that this Options Template causes the > valueDistributionMethod to be implicitly scoped to the Observation > Domain ID of the IPFIX Message containing the Aggregate Counter > Distribution Record. This is used to signal to the Collecting > Process how the counters were distributed. The fields are as below: > > +-------------------------+-----------------------------------------+ > | IE | Description | > +-------------------------+-----------------------------------------+ > | templateId [scope] | The Template ID of the Template | > | | defining the Aggregated Flows to which | > | | this distribution option applies. This | > | | Information Element MUST be defined as | > | | a Scope Field. | > | valueDistributionMethod | The method used to distribute the | > | | counters for the Aggregated Flows | > | | defined by the associated Template. | > +-------------------------+-----------------------------------------+ Label this "Figure X" so it can be more easily referred to from future documents. > > > 7.4.2. valueDistributionMethod Information Element > > Description: A description of the method used to distribute the > counters from Contributing Flows into the Aggregated Flow records > described by an associated scope, generally a Template. The > method is deemed to apply to all the non-key Information Elements > in the referenced scope for which value distribution is a valid > operation; if the originalFlowsInitiated and/or > originalFlowsCompleted Information Elements appear in the > Template, they are not subject to this distribution method, as > they each infer their own distribution method. This is intended > to be a complete set of possible value distribution methods; it is Do you mean to say it's a non-extensible? > > taken from the discussion Section 5.1.1 and encoded as follows: "discussion _in_ Section 5.1.1." > > > > > > > > > > > Trammell, et al. Expires December 29, 2012 [Page 29] > > Internet-Draft IPFIX Aggregation June 2012 > > > +-------+-----------------------------------------------------------+ > | Value | Description | > +-------+-----------------------------------------------------------+ > | 0 | Arbitrary: The counters for an Original Flow are | > | | explicitly not distributed according to any defined | > | | method. | > | | --------------------------------------------------------- | > | 1 | Start Interval: The counters for an Original Flow are | > | | added to the counters of the appropriate Aggregated Flow | > | | containing the start time of the Original Flow. This | > | | should be assumed the default if value distribution | > | | information is not available at a Collecting Process for | > | | an Aggregated Flow. | > | | --------------------------------------------------------- | > | 2 | End Interval: The counters for an Original Flow are added | > | | to the counters of the appropriate Aggregated Flow | > | | containing the end time of the Original Flow. | > | | --------------------------------------------------------- | > | 3 | Mid Interval: The counters for an Original Flow are added | > | | to the counters of a single appropriate Aggregated Flow | > | | containing some timestamp between start and end time of | > | | the Original Flow. | > | | --------------------------------------------------------- | > | 4 | Simple Uniform Distribution: Each counter for an Original | > | | Flow is divided by the number of time intervals the | > | | Original Flow covers (i.e., of appropriate Aggregated | > | | Flows sharing the same Flow Key), and this number is | > | | added to each corresponding counter in each Aggregated | > | | Flow. | > | | --------------------------------------------------------- | > | 5 | Proportional Uniform Distribution: Each counter for an | > | | Original Flow is divided by the number of time _units_ | > | | the Original Flow covers, to derive a mean count rate. | > | | This mean count rate is then multiplied by the number of | > | | time units in the intersection of the duration of the | > | | Original Flow and the time interval of each Aggregated | > | | Flow. This is like simple uniform distribution, but | > | | accounts for the fractional portions of a time interval | > | | covered by an Original Flow in the first and last time | > | | interval. | > | | --------------------------------------------------------- | > > > > > > > > > > > Trammell, et al. Expires December 29, 2012 [Page 30] > > Internet-Draft IPFIX Aggregation June 2012 > > > | 6 | Simulated Process: Each counter of the Original Flow is | > | | distributed among the intervals of the Aggregated Flows | > | | according to some function the Aggregation Process uses | > | | based upon properties of Flows presumed to be like the | > | | Original Flow. This is essentially an assertion that the | > | | Aggregation Process has no direct packet timing | > | | information but is nevertheless not using one of the | > | | other simpler distribution methods. The Aggregation | > | | Process specifically makes no assertion as to the | > | | correctness of the simulation. | > | | --------------------------------------------------------- | > | 7 | Direct: The Aggregation Process has access to the | > | | original packet timings from the packets making up the | > | | Original Flow, and uses these to distribute or | > | | recalculate the counters. | > +-------+-----------------------------------------------------------+ > > Abstract Data Type: unsigned8 > > ElementId: TBD10 > > Status: Current > > > 8. Examples > > In these examples, the same data, described by the same template, > will be aggregated multiple different ways; this illustrates the > various different functions which could be implemented by > Intermediate Aggregation Processes. Templates are shown in IESpec > format as introduced in [I-D.ietf-ipfix-ie-doctors]. The source data > format is a simplified flow: timestamps, traditional 5-tuple, and > octet count. The template is shown in Figure 8. > > flowStartMilliseconds(152)[8] > flowEndMilliseconds(153)[8] > sourceIPv4Address(8)[4] > destinationIPv4Address(12)[4] > sourceTransportPort(7)[2] > destinationTransportPort(11)[2] > protocolIdentifier(4)[1] > octetDeltaCount(1)[8] > > Figure 8: Input template for examples This isn't really a figure. > > > The data records given as input to the examples in this section are > shown below, in the format "flowStartMilliseconds-flowEndMilliseconds > sourceIPv4Address:sourceTransportPort -> destinationIPv4Address: > > > > Trammell, et al. Expires December 29, 2012 [Page 31] > > Internet-Draft IPFIX Aggregation June 2012 > > > destinationTransportPort (protocolIdentifier) octetDeltaCount"; > timestamps are given in H:MM:SS.sss format. This text should reflect the new format below. > > > start time end time source ip4 port dest ip4 port prt octets > 9:00:00.138 9:00:00.138 192.0.2.2 47113 192.0.2.131 53 17 119 > 9:00:03.246 9:00:03.246 192.0.2.2 22153 192.0.2.131 53 17 83 > 9:00:00.478 9:00:03.486 192.0.2.2 52420 198.51.100.2 443 6 1637 > 9:00:07.172 9:00:07.172 192.0.2.3 56047 192.0.2.131 53 17 111 > 9:00:07.309 9:00:14.861 192.0.2.3 41183 198.51.100.67 80 6 16838 > 9:00:03.556 9:00:19.876 192.0.2.2 17606 198.51.100.68 80 6 11538 > 9:00:25.210 9:00:25.210 192.0.2.3 47113 192.0.2.131 53 17 119 > 9:00:26.358 9:00:30.198 192.0.2.3 48458 198.51.100.133 80 6 2973 > 9:00:29.213 9:01:00.061 192.0.2.4 61295 198.51.100.2 443 6 8350 > 9:04:00.207 9:04:04.431 203.0.113.3 41256 198.51.100.133 80 6 778 > 9:03:59.624 9:04:06.984 203.0.113.3 51662 198.51.100.3 80 6 883 > 9:00:30.532 9:06:15.402 192.0.2.2 37581 198.51.100.2 80 6 15420 > 9:06:56.813 9:06:59.821 203.0.113.3 52572 198.51.100.2 443 6 1637 > 9:06:30.565 9:07:00.261 203.0.113.3 49914 197.51.100.133 80 6 561 s/197.51.100.133/ 198.51.100.133/ > > 9:06:55.160 9:07:05.208 192.0.2.2 50824 198.51.100.2 443 6 1899 > 9:06:49.322 9:07:05.322 192.0.2.3 34597 198.51.100.3 80 6 1284 > 9:07:05.849 9:07:09.625 203.0.113.3 58907 198.51.100.4 80 6 2670 > 9:10:45.161 9:10:45.161 192.0.2.4 22478 192.0.2.131 53 17 75 > 9:10:45.209 9:11:01.465 192.0.2.4 49513 198.51.100.68 80 6 3374 > 9:10:57.094 9:11:00.614 192.0.2.4 64832 198.51.100.67 80 6 138 > 9:10:59.770 9:11:02.842 192.0.2.3 60833 198.51.100.69 443 6 2325 > 9:02:18.390 9:13:46.598 203.0.113.3 39586 198.51.100.17 80 6 11200 > 9:13:53.933 9:14:06.605 192.0.2.2 19638 198.51.100.3 80 6 2869 > 9:13:02.864 9:14:08.720 192.0.2.3 40429 198.51.100.4 80 6 18289 > > Figure 9: Input data for examples This definitely isn't a figure; it's a table. Perhaps it's a table of figures? Ditto umpteen times below. > > > 8.1. Traffic Time-Series per Source > > Aggregating flows by source IP address in time series (i.e., with a > regular interval) can be used in subsequent heavy-hitter analysis and > as a source parameter for statistical anomaly detection techniques. > Here, the Intermediate Aggregation Process imposes an interval, > aggregates the key to remove all key fields other than the source IP "the key _fields_" ? You haven't indicated which fields are the keys. > > address, then combines the result into a stream of Aggregated Flows. > The imposed interval of 5 minutes is longer than the majority of > flows; for those flows crossing interval boundaries, the entire flow > is accounted to the interval containing the start time of the flow. > > In this example the Partially Aggregated Flows after each conceptual > operation in the Intermediate Aggregation Process are shown. These > are meant to be illustrative of the conceptual operations only, and > not to suggest an implementation (indeed, the example shown here > would not necessarily be the most efficient method for performing > > > > Trammell, et al. Expires December 29, 2012 [Page 32] > > Internet-Draft IPFIX Aggregation June 2012 > > > these operations). Subsequent examples will omit the Partially > Aggregated Flows for brevity. > > The input to this process could be any Flow Record containing a > source IP address and octet counter; consider for this example the > template and data from the introduction. The Intermediate > Aggregation Process would then output records containing just > timestamps, source IP, and octetDeltaCount, as in Figure 10. > > flowStartMilliseconds(152)[8] > flowEndMilliseconds(153)[8] > sourceIPv4Address(8)[4] > octetDeltaCount(1)[8] > > Figure 10: Output template for time series per source > > Assume the goal is to get 5-minute (300s) time series of octet counts > per source IP address. The aggregation operations would then be > arranged as in Figure 11. > > Original Flows > | > V > +-----------------------+ > | interval distribution | > | * impose uniform | > | 300s time interval | > +-----------------------+ > | > | Partially Aggregated Flows > V > +------------------------+ > | key aggregation | > | * reduce key to only | > | sourceIPv4Address | > +------------------------+ > | > | Partially Aggregated Flows > V > +-------------------------+ > | aggregate combination | > | * sum octetDeltaCount | > +-------------------------+ > | > V > Aggregated Flows > > Figure 11: Aggregation operations for time series per source > > > > Trammell, et al. Expires December 29, 2012 [Page 33] > > Internet-Draft IPFIX Aggregation June 2012 > > > After the interval distribution step, only the time intervals have > changed; the Partially Aggregated flows are shown in Figure 12. Note > that interval distribution follows the default Start Interval policy; > that is, the entire flow is accounted to the interval containing the > flow's start time. > > start time end time source ip4 port dest ip4 port prt octets > 9:00:00.000 9:05:00.000 192.0.2.2 47113 192.0.2.131 53 17 119 > 9:00:00.000 9:05:00.000 192.0.2.2 22153 192.0.2.131 53 17 83 > 9:00:00.000 9:05:00.000 192.0.2.2 52420 198.51.100.2 443 6 1637 > 9:00:00.000 9:05:00.000 192.0.2.3 56047 192.0.2.131 53 17 111 > 9:00:00.000 9:05:00.000 192.0.2.3 41183 198.51.100.67 80 6 16838 > 9:00:00.000 9:05:00.000 192.0.2.2 17606 198.51.100.68 80 6 11538 > 9:00:00.000 9:05:00.000 192.0.2.3 47113 192.0.2.131 53 17 119 > 9:00:00.000 9:05:00.000 192.0.2.3 48458 198.51.100.133 80 6 2973 > 9:00:00.000 9:05:00.000 192.0.2.4 61295 198.51.100.2 443 6 8350 > 9:00:00.000 9:05:00.000 203.0.113.3 41256 198.51.100.133 80 6 778 > 9:00:00.000 9:05:00.000 203.0.113.3 51662 198.51.100.3 80 6 883 > 9:00:00.000 9:05:00.000 192.0.2.2 37581 198.51.100.2 80 6 15420 > 9:00:00.000 9:05:00.000 203.0.113.3 39586 198.51.100.17 80 6 11200 > 9:05:00.000 9:10:00.000 203.0.113.3 52572 198.51.100.2 443 6 1637 > 9:05:00.000 9:10:00.000 203.0.113.3 49914 197.51.100.133 80 6 561 > 9:05:00.000 9:10:00.000 192.0.2.2 50824 198.51.100.2 443 6 1899 > 9:05:00.000 9:10:00.000 192.0.2.3 34597 198.51.100.3 80 6 1284 > 9:05:00.000 9:10:00.000 203.0.113.3 58907 198.51.100.4 80 6 2670 > 9:10:00.000 9:15:00.000 192.0.2.4 22478 192.0.2.131 53 17 75 > 9:10:00.000 9:15:00.000 192.0.2.4 49513 198.51.100.68 80 6 3374 > 9:10:00.000 9:15:00.000 192.0.2.4 64832 198.51.100.67 80 6 138 > 9:10:00.000 9:15:00.000 192.0.2.3 60833 198.51.100.69 443 6 2325 > 9:10:00.000 9:15:00.000 192.0.2.2 19638 198.51.100.3 80 6 2869 > 9:10:00.000 9:15:00.000 192.0.2.3 40429 198.51.100.4 80 6 18289 > > Figure 12: Interval imposition for time series per source > > After the key aggregation step, all Flow Keys except the source IP > address have been discarded, as shown in Figure 13. This leaves > duplicate Partially Aggregated flows to be combined in the final > operation. > > > > > > > > > > > > > > Trammell, et al. Expires December 29, 2012 [Page 34] > > Internet-Draft IPFIX Aggregation June 2012 > > > start time end time source ip4 octets > 9:00:00.000 9:05:00.000 192.0.2.2 119 > 9:00:00.000 9:05:00.000 192.0.2.2 83 > 9:00:00.000 9:05:00.000 192.0.2.2 1637 > 9:00:00.000 9:05:00.000 192.0.2.3 111 > 9:00:00.000 9:05:00.000 192.0.2.3 16838 > 9:00:00.000 9:05:00.000 192.0.2.2 11538 > 9:00:00.000 9:05:00.000 192.0.2.3 119 > 9:00:00.000 9:05:00.000 192.0.2.3 2973 > 9:00:00.000 9:05:00.000 192.0.2.4 8350 > 9:00:00.000 9:05:00.000 203.0.113.3 778 > 9:00:00.000 9:05:00.000 203.0.113.3 883 The last two entries are missing here: 9:00:00.000 9:05:00.000 192.0.2.2 15420 9:00:00.000 9:05:00.000 203.0.113.3 11200 > > 9:05:00.000 9:10:00.000 203.0.113.3 1637 > 9:05:00.000 9:10:00.000 203.0.113.3 561 > 9:05:00.000 9:10:00.000 192.0.2.2 1899 > 9:05:00.000 9:10:00.000 192.0.2.3 1284 > 9:05:00.000 9:10:00.000 203.0.113.3 2670 > 9:10:00.000 9:15:00.000 192.0.2.4 75 > 9:10:00.000 9:15:00.000 192.0.2.4 3374 > 9:10:00.000 9:15:00.000 192.0.2.4 138 > 9:10:00.000 9:15:00.000 192.0.2.3 2325 > 9:10:00.000 9:15:00.000 192.0.2.2 2869 > 9:10:00.000 9:15:00.000 192.0.2.3 18289 > > Figure 13: Key aggregation for time series per source > > Aggregate combination sums the counters per key and interval; the > summations of the first two keys and intervals are shown in detail in > Figure 14. > > 9:00:00.000 9:05:00.000 192.0.2.2 119 > 9:00:00.000 9:05:00.000 192.0.2.2 83 > 9:00:00.000 9:05:00.000 192.0.2.2 1637 > 9:00:00.000 9:05:00.000 192.0.2.2 11538 > + 9:00:00.000 9:05:00.000 192.0.2.2 15420 > ----- > = 9:00:00.000 9:05:00.000 192.0.2.2 28797 > > 9:00:00.000 9:05:00.000 192.0.2.3 111 > 9:00:00.000 9:05:00.000 192.0.2.3 16838 > 9:00:00.000 9:05:00.000 192.0.2.3 119 > + 9:00:00.000 9:05:00.000 192.0.2.3 2973 > ----- > = 9:00:00.000 9:05:00.000 192.0.2.3 20041 > > Figure 14: Summation during aggregate combination > > Applying this to each set of Partially Aggregated Flows to produce > > > > Trammell, et al. Expires December 29, 2012 [Page 35] > > Internet-Draft IPFIX Aggregation June 2012 > > > the final Aggregated Flows shown in Figure 15 to be exported by the > template in Figure 10. > > 9:00:00.000-9:05:00.000 192.0.2.2 28797 > 9:00:00.000-9:05:00.000 192.0.2.3 20041 > 9:00:00.000-9:05:00.000 192.0.2.4 8350 > 9:00:00.000-9:05:00.000 203.0.113.3 12861 > > 9:05:00.000-9:10:00.000 192.0.2.2 1899 > 9:05:00.000-9:10:00.000 192.0.2.3 1284 > 9:05:00.000-9:10:00.000 203.0.113.3 4868 > 9:10:00.000-9:15:00.000 192.0.2.2 2869 > 9:10:00.000-9:15:00.000 192.0.2.3 20614 > 9:10:00.000-9:15:00.000 192.0.2.4 3587 > > Figure 15: Aggregated Flows for time series per source > > 8.2. Core Traffic Matrix > > Aggregating flows by source and destination autonomous system number > in time series is used to generate core traffic matrices. The core > traffic matrix provides a view of the state of the routes within a > network, and can be used for long-term planning of changes to network > design based on traffic demand. Here, imposed time intervals are > generally much longer than active flow timeouts. The traffic matrix > is reported in terms of octets, packets, and flows, as each of these > values may have a subtly different effect on capacity planning. > > This example demonstrates key aggregation using derived keys and > original flow counting. While some Original Flows may be generated NB "original flow" and "Original Flows" ? > > by Exporting Processes on forwarding devices, and therefore contain > the bgpSourceAsNumber and bgpDestinationAsNumber Information > Elements, Original Flows from Exporting Processes on dedicated > measurement devices will contain only a destinationIPv[46]Address. Speculation. s/will/may only/. > > For these flows, the Mediator must look up a next hop AS from a IP to "an IP" > > AS table, replacing source and destination addresses with AS numbers. > The table used in this example is shown in Figure 16. (Note that due > to limited example address space, in this example we ignore the > common practice of routing only blocks of /24 or larger). > > prefix ASN > 192.0.2.0/25 64496 > 192.0.2.128/25 64497 > 198.51.100/24 64498 > 203.0.113.0/24 64499 > > Figure 16: Example Autonomous system number map > > The template for Aggregated Flows produced by this example is shown > > > > Trammell, et al. Expires December 29, 2012 [Page 36] > > Internet-Draft IPFIX Aggregation June 2012 > > > in Figure 17. > > flowStartMilliseconds(152)[8] > flowEndMilliseconds(153)[8] > bgpSourceAsNumber(16)[4] > bgpDestinationAsNumber(17)[4] > octetDeltaCount(1)[8] > > Figure 17: Output template for traffic matrix > > Assume the goal is to get 60-minute time series of octet counts per > source/destination ASN pair. The aggregation operations would then > be arranged as in Figure 18. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Trammell, et al. Expires December 29, 2012 [Page 37] > > Internet-Draft IPFIX Aggregation June 2012 > > > Original Flows > | > V > +-----------------------+ > | interval distribution | > | * impose uniform | > | 3600s time interval | > +-----------------------+ > | > | Partially Aggregated Flows > V > +------------------------+ > | key aggregation | > | * reduce key to only | > | sourceIPv4Address + | > | destIPv4Address | > +------------------------+ > | > V > +------------------------+ > | key aggregation | > | * replace addresses | > | with ASN from map | > +------------------------+ > | > | Partially Aggregated Flows > V > +-------------------------+ > | aggregate combination | > | * sum octetDeltaCount | > +-------------------------+ > | > V > Aggregated Flows > > Figure 18: Aggregation operations for traffic matrix > > After the interval distribution step, only the time intervals have > changed; the Partially Aggregated flows are shown in Figure 19. Note For clarity, it's worth re-stating that the source data is per Figure 9. > > that the flows are identical to those in interval distribution step > in the previous example, except the chosen interval (1 hour, 3600 > seconds) is different; therefore, all the flows fit into a single > interval. > > > > > > > > > Trammell, et al. Expires December 29, 2012 [Page 38] > > Internet-Draft IPFIX Aggregation June 2012 > > > start time end time source ip4 port dest ip4 port prt octets > 9:00:00 10:00:00 192.0.2.2 47113 192.0.2.131 53 17 119 > 9:00:00 10:00:00 192.0.2.2 22153 192.0.2.131 53 17 83 > 9:00:00 10:00:00 192.0.2.2 52420 198.51.100.2 443 6 1637 > 9:00:00 10:00:00 192.0.2.3 56047 192.0.2.131 53 17 111 > 9:00:00 10:00:00 192.0.2.3 41183 198.51.100.67 80 6 16838 > 9:00:00 10:00:00 192.0.2.2 17606 198.51.100.68 80 6 11538 > 9:00:00 10:00:00 192.0.2.3 47113 192.0.2.131 53 17 119 > 9:00:00 10:00:00 192.0.2.3 48458 198.51.100.133 80 6 2973 > 9:00:00 10:00:00 192.0.2.4 61295 198.51.100.2 443 6 8350 > 9:00:00 10:00:00 203.0.113.3 41256 198.51.100.133 80 6 778 > 9:00:00 10:00:00 203.0.113.3 51662 198.51.100.3 80 6 883 > 9:00:00 10:00:00 192.0.2.2 37581 198.51.100.2 80 6 15420 > 9:00:00 10:00:00 203.0.113.3 52572 198.51.100.2 443 6 1637 > 9:00:00 10:00:00 203.0.113.3 49914 197.51.100.133 80 6 561 > 9:00:00 10:00:00 192.0.2.2 50824 198.51.100.2 443 6 1899 > 9:00:00 10:00:00 192.0.2.3 34597 198.51.100.3 80 6 1284 > 9:00:00 10:00:00 203.0.113.3 58907 198.51.100.4 80 6 2670 > 9:00:00 10:00:00 192.0.2.4 22478 192.0.2.131 53 17 75 > 9:00:00 10:00:00 192.0.2.4 49513 198.51.100.68 80 6 3374 > 9:00:00 10:00:00 192.0.2.4 64832 198.51.100.67 80 6 138 > 9:00:00 10:00:00 192.0.2.3 60833 198.51.100.69 443 6 2325 > 9:00:00 10:00:00 203.0.113.3 39586 198.51.100.17 80 6 11200 > 9:00:00 10:00:00 192.0.2.2 19638 198.51.100.3 80 6 2869 > 9:00:00 10:00:00 192.0.2.3 40429 198.51.100.4 80 6 18289 > > Figure 19: Interval imposition for traffic matrix > > The next step is to discard irrelevant key fields, and replace the > source and destination addresses with source and destination AS Per Figure 18, that's two steps. NB the way it's written sounds like "get rid of X and replace it with Y", rather than the intended "get rid of X, then replace Y with Z". > > numbers in the map; the results of these key aggregation steps are > shown in Figure 20. > > > > > > > > > > > > > > > > > > > > Trammell, et al. Expires December 29, 2012 [Page 39] > > Internet-Draft IPFIX Aggregation June 2012 > > > start time end time source ASN dest ASN octets > 9:00:00 10:00:00 AS64496 AS64497 119 > 9:00:00 10:00:00 AS64496 AS64497 83 > 9:00:00 10:00:00 AS64496 AS64498 1637 > 9:00:00 10:00:00 AS64496 AS64497 111 > 9:00:00 10:00:00 AS64496 AS64498 16838 > 9:00:00 10:00:00 AS64496 AS64498 11538 > 9:00:00 10:00:00 AS64496 AS64497 119 > 9:00:00 10:00:00 AS64496 AS64498 2973 > 9:00:00 10:00:00 AS64496 AS64498 8350 > 9:00:00 10:00:00 AS64499 AS64498 778 > 9:00:00 10:00:00 AS64499 AS64498 883 > 9:00:00 10:00:00 AS64496 AS64498 15420 > 9:00:00 10:00:00 AS64499 AS64498 1637 > 9:00:00 10:00:00 AS64499 AS64498 561 > 9:00:00 10:00:00 AS64496 AS64498 1899 > 9:00:00 10:00:00 AS64496 AS64498 1284 > 9:00:00 10:00:00 AS64499 AS64498 2670 > 9:00:00 10:00:00 AS64496 AS64497 75 > 9:00:00 10:00:00 AS64496 AS64498 3374 > 9:00:00 10:00:00 AS64496 AS64498 138 > 9:00:00 10:00:00 AS64496 AS64498 2325 > 9:00:00 10:00:00 AS64499 AS64498 11200 > 9:00:00 10:00:00 AS64496 AS64498 2869 > 9:00:00 10:00:00 AS64496 AS64498 18289 > > Figure 20: Key aggregation for traffic matrix: reduction and > replacement > > Finally, aggregate combination sums the counters per key and > interval. The resulting Aggregated Flows containing the traffic > matrix, shown in Figure 21, are then exported using the template in > Figure 17. Note that these aggregated flows represent a sparse > matrix: AS pairs for which no traffic was received have no > corresponding record in the output. > > start time end time source ASN dest ASN octets > 9:00:00 10:00:00 AS64496 AS64497 507 > 9:00:00 10:00:00 AS64496 AS64498 86934 > 9:00:00 10:00:00 AS64499 AS64498 17729 > > Figure 21: Aggregated Flows for traffic matrix > > The output of this operation is suitable for re-aggregation: that is, > traffic matrices from single links or observarion points can be s/observarion/observation/ > > aggregated through the same interval imposition and aggregate > combination steps in order to build a traffic matrix for an entire > network. > > > > Trammell, et al. Expires December 29, 2012 [Page 40] > > Internet-Draft IPFIX Aggregation June 2012 > > > 8.3. Distinct Source Count per Destination Endpoint > > Aggregating flows by destination address and port, and counting > distinct sources aggregated away, can be used as part of passive > service inventory and host characterization approaches. This example What are "host characterization approaches"? Did you mean"host characterization methodologies", or just "host characterization" ? > > shows aggregation as an analysis technique, performed on source data > stored in an IPFIX File. As the Transport Session in this File is > bounded, removal of all timestamp information allows summarization of > the entire time interval contained within the interval. Removal of > timing information during interval imposition is equivalent to an > infinitely long imposed time interval. This demonstrates both how > infinite intervals work, and how unique counters work. The > aggregation operations are summarized in Figure 22. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Trammell, et al. Expires December 29, 2012 [Page 41] > > Internet-Draft IPFIX Aggregation June 2012 > > > Original Flows > | > V > +-----------------------+ > | interval distribution | > | * discard timestamps | > +-----------------------+ > | > | Partially Aggregated Flows > V > +----------------------------+ > | value aggregation | > | * discard octetDeltaCount | > +----------------------------+ > | > | Partially Aggregated Flows > V > +----------------------------+ > | key aggregation | > | * reduce key to only | > | destIPv4Address + | > | destTransportPort, | > | * count distinct sources | > +----------------------------+ > | > | Partially Aggregated Flows > V > +----------------------------------------------+ > | aggregate combination | > | * no-op (distinct sources already counted) | > +----------------------------------------------+ > | > V > Aggregated Flows > > Figure 22: Aggregation operations for source count > > The template for Aggregated Flows produced by this example is shown > in Figure 23. > > destinationIPv4Address(12)[4] > destinationTransportPort(11)[2] > distinctCountOfSourceIPAddress(TBD4)[8] > > Figure 23: Output template for source count > > Interval distribution, in this case, merely discards the timestamp > information from the Original Flows, and as such is not shown. > > > > Trammell, et al. Expires December 29, 2012 [Page 42] > > Internet-Draft IPFIX Aggregation June 2012 > > > Likewise, the value aggregation step simply discards the > octetDeltaCount value field. The key aggregation step reduces the > key to the destinationIPv4Address and destinationTransportPort, > counting the distinct source addresses. Since this is essentially > the output of this aggregation function, the aggregate combination > operation is a no-op; the resulting Aggregated Flows are shown in > Figure 24. Once again, it's worth re-stating that again, the data from Figure 9 (or table X, whichever) is the source data. > > > dest ip4 port dist src > 192.0.2.131 53 3 > 198.51.100.2 80 1 > 198.51.100.2 443 3 > 198.51.100.67 80 2 > 198.51.100.68 80 2 > 198.51.100.133 80 2 > 198.51.100.3 80 3 > 198.51.100.4 80 2 > 198.51.100.17 80 1 > 198.51.100.69 443 1 This table seems to be completely wrong. Even the total counts is wrong - ie, add up the "dist src" = 20. Yet Figure 9 has 24 entries. I think it should be: 198.51.100.17 80 4 198.51.100.2 80 1 198.51.100.2 443 4 198.51.100.3 80 3 198.51.100.4 80 2 198.51.100.68 80 4 198.51.100.69 443 1 I had serious deja vu here. I thought I had pointed this out already? Am I reviewing the wrong draft again? > > > Figure 24: Aggregated flows for source count > > 8.4. Traffic Time-Series per Source with Counter Distribution > > Returning to the example in Section 8.1, note that our source data > contains some flows with durations longer than the imposed interval > of five minutes. The default method for dealing with such flows is > to account them to the interval containing the flow's start time. > > In this example, the same data is aggregated using the same > arrangement of operations and the same output template as the as in > Section 8.1, but using a different counter distribution policy, > Simple Uniform Distribution, as described in Section 5.1.1. In order > to do this, the Exporting Process first exports the Aggregate Counter > Distribution Options Template, as in Figure 25. > > templateId(12)[2]{scope} > valueDistribtutionMethod(TBD10)[1] s/valueDistribtutionMethod/valueDistributionMethod/ > > > Figure 25: Aggregate Counter Distribution Options Template > > This is followed by an Aggregate Counter Distribution Record > described by this Template; assuming the output template in Figure 10 > has ID 257, this would appear as in Figure 26. There are too many "this" here to understand. > > > templateId 257: valueDistributionMethod 4 (Simple Uniform) Where is the figure? > > > Figure 26: Aggregate Counter Distribution Record > > > > Trammell, et al. Expires December 29, 2012 [Page 43] > > Internet-Draft IPFIX Aggregation June 2012 > > > Following metadata export, the aggregation steps follow as before. > However, two long flows are distributed across multiple intervals in > the interval imposition step, as indicated with "*" in Figure 27. It might help to use *1 and *2 to distinguish the two flows. > > Note the uneven distribution of the three-interval, 11200-octet flow > into three Partially Aggregated Flows of 3733, 3733, and 3734 octets; > this ensures no cumulative error is injected by the interval > distribution step. > > start time end time source ip4 port dest ip4 port prt octets > 9:00:00.000 9:05:00.000 192.0.2.2 47113 192.0.2.131 53 17 119 > 9:00:00.000 9:05:00.000 192.0.2.2 22153 192.0.2.131 53 17 83 > 9:00:00.000 9:05:00.000 192.0.2.2 52420 198.51.100.2 443 6 1637 > 9:00:00.000 9:05:00.000 192.0.2.3 56047 192.0.2.131 53 17 111 > 9:00:00.000 9:05:00.000 192.0.2.3 41183 198.51.100.67 80 6 16838 > 9:00:00.000 9:05:00.000 192.0.2.2 17606 198.51.100.68 80 6 11538 > 9:00:00.000 9:05:00.000 192.0.2.3 47113 192.0.2.131 53 17 119 > 9:00:00.000 9:05:00.000 192.0.2.3 48458 198.51.100.133 80 6 2973 > 9:00:00.000 9:05:00.000 192.0.2.4 61295 198.51.100.2 443 6 8350 > 9:00:00.000 9:05:00.000 203.0.113.3 41256 198.51.100.133 80 6 778 > 9:00:00.000 9:05:00.000 203.0.113.3 51662 198.51.100.3 80 6 883 > 9:00:00.000 9:05:00.000 192.0.2.2 37581 198.51.100.2 80 6 7710 * > 9:00:00.000 9:05:00.000 203.0.113.3 39586 198.51.100.17 80 6 3733 * > 9:05:00.000 9:10:00.000 203.0.113.3 52572 198.51.100.2 443 6 1637 > 9:05:00.000 9:10:00.000 203.0.113.3 49914 197.51.100.133 80 6 561 > 9:05:00.000 9:10:00.000 192.0.2.2 50824 198.51.100.2 443 6 1899 > 9:05:00.000 9:10:00.000 192.0.2.3 34597 198.51.100.3 80 6 1284 > 9:05:00.000 9:10:00.000 203.0.113.3 58907 198.51.100.4 80 6 2670 > 9:05:00.000 9:10:00.000 192.0.2.2 37581 198.51.100.2 80 6 7710 * > 9:05:00.000 9:10:00.000 203.0.113.3 39586 198.51.100.17 80 6 3733 * > 9:10:00.000 9:15:00.000 192.0.2.4 22478 192.0.2.131 53 17 75 > 9:10:00.000 9:15:00.000 192.0.2.4 49513 198.51.100.68 80 6 3374 > 9:10:00.000 9:15:00.000 192.0.2.4 64832 198.51.100.67 80 6 138 > 9:10:00.000 9:15:00.000 192.0.2.3 60833 198.51.100.69 443 6 2325 > 9:10:00.000 9:15:00.000 192.0.2.2 19638 198.51.100.3 80 6 2869 > 9:10:00.000 9:15:00.000 192.0.2.3 40429 198.51.100.4 80 6 18289 > 9:10:00.000 9:15:00.000 203.0.113.3 39586 198.51.100.17 80 6 3734 * > > Figure 27: Distirbuted interval imposition for time series per source s/Distirbuted/Distributed/ > > > Subsequent steps are as in Section 8.1; the results, to be exported > using Figure 10, are shown in Figure 28, with Aggregated Flows "using the template shown in Figure 10". > > differing from the example in Section 8.1 indicated by "*". > > > > > > > > > > Trammell, et al. Expires December 29, 2012 [Page 44] > > Internet-Draft IPFIX Aggregation June 2012 > > > start time end time source ip4 octets > 9:00:00.000 9:05:00.000 192.0.2.2 21087 * > 9:00:00.000 9:05:00.000 192.0.2.3 20041 > 9:00:00.000 9:05:00.000 192.0.2.4 8350 > 9:00:00.000 9:05:00.000 203.0.113.3 9394 * 9394 should be 778 + 883 + 3733 = 5394. > > 9:05:00.000 9:10:00.000 192.0.2.2 9609 * > 9:05:00.000 9:10:00.000 192.0.2.3 1284 > 9:05:00.000 9:10:00.000 203.0.113.3 8601 * > 9:10:00.000 9:15:00.000 192.0.2.2 2869 > 9:10:00.000 9:15:00.000 192.0.2.3 20594 20594 should be 2325 + 18289 = 20614. > > 9:10:00.000 9:15:00.000 192.0.2.4 3587 > 9:10:00.000 9:15:00.000 203.0.113.3 3734 * As a check, the total octets in this figure is 109150, whereas the total in Figure 27 is 105170. With the modified figures I've shown above, the two totals agree. > > > Figure 28: Aggregated Flows for time series per source with counter > distribution > > > 9. Security Considerations > > This document specifies the operation of an Intermediate Aggregation > Process with the IPFIX Protocol; the Security Considerations for the > protocol itself in Section 11 [RFC-EDITOR NOTE: verify section > number] of [I-D.ietf-ipfix-protocol-rfc5101bis] therefore apply. In > the common case that aggregation is performed on a Mediator, the > Security Considerations for Mediators in Section 9 of [RFC6183] apply > as well. > > As mentioned in Section 3, certain aggregation operations may tend to > have an anyonymizing effect on flow data by obliterating sensitive s/anyonymizing/anonymizing/ > > identifiers. Aggregation may also be combined with anonymization > within a Mediator, or as part of a chain of Mediators, to further > leverage this effect. In any case in which an Intermediate > Aggregation Process is applied as part of a data anonymization or > protection scheme, or is used together with anonymization as > described in [RFC6235], the Security Considerations in Section 9 of > [RFC6235] apply. > > > 10. IANA Considerations > > This document specifies the creation of new IPFIX Information > Elements in the IPFIX Information Element registry located at > http://www.iana.org/assignments/ipfix, as defined in Section 7 above. > IANA has assigned Information Element numbers to these Information > Elements, and entered them into the registry. > > [NOTE for IANA: The text TBDn should be replaced with the respective > assigned Information Element numbers where they appear in this > > > > Trammell, et al. Expires December 29, 2012 [Page 45] > > Internet-Draft IPFIX Aggregation June 2012 > > > document. Note that the deltaFlowCount Information Element has been > assigned the number 3, as it is compatible with the corresponding > existing (reserved) NetFlow v9 Information Element. Other > Information Element numbers should be assigned outside the NetFlow V9 > compatibility range, as these Information Elements are not supported > by NetFlow V9.] > > > 11. Acknowledgments > > Special thanks to Elisa Boschi for early work on the concepts laid > out in this document. Thanks to Paul Aitken, Lothar Braun, Christian > Henke, and Rahul Patel for their reviews and valuable feedback. This > work is materially supported by the European Union Seventh Framework > Programme under grant agreement 257315 (DEMONS). > > > 12. References > > 12.1. Normative References > > [I-D.ietf-ipfix-protocol-rfc5101bis] > Claise, B. and B. Trammell, "Specification of the IP Flow > Information eXport (IPFIX) Protocol for the Exchange of > Flow Information", draft-ietf-ipfix-protocol-rfc5101bis-01 > (work in progress), March 2012. > > [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate > Requirement Levels", BCP 14, RFC 2119, March 1997. > > 12.2. Informative References > > [RFC3917] Quittek, J., Zseby, T., Claise, B., and S. Zander, > "Requirements for IP Flow Information Export (IPFIX)", > RFC 3917, October 2004. > > [RFC5103] Trammell, B. and E. Boschi, "Bidirectional Flow Export > Using IP Flow Information Export (IPFIX)", RFC 5103, > January 2008. > > [RFC5153] Boschi, E., Mark, L., Quittek, J., Stiemerling, M., and P. > Aitken, "IP Flow Information Export (IPFIX) Implementation > Guidelines", RFC 5153, April 2008. > > [RFC5470] Sadasivan, G., Brownlee, N., Claise, B., and J. Quittek, > "Architecture for IP Flow Information Export", RFC 5470, > March 2009. > > > > > Trammell, et al. Expires December 29, 2012 [Page 46] > > Internet-Draft IPFIX Aggregation June 2012 > > > [RFC5472] Zseby, T., Boschi, E., Brownlee, N., and B. Claise, "IP > Flow Information Export (IPFIX) Applicability", RFC 5472, > March 2009. > > [RFC5476] Claise, B., Johnson, A., and J. Quittek, "Packet Sampling > (PSAMP) Protocol Specifications", RFC 5476, March 2009. > > [RFC5610] Boschi, E., Trammell, B., Mark, L., and T. Zseby, > "Exporting Type Information for IP Flow Information Export > (IPFIX) Information Elements", RFC 5610, July 2009. > > [RFC5655] Trammell, B., Boschi, E., Mark, L., Zseby, T., and A. > Wagner, "Specification of the IP Flow Information Export > (IPFIX) File Format", RFC 5655, October 2009. > > [RFC5835] Morton, A. and S. Van den Berghe, "Framework for Metric > Composition", RFC 5835, April 2010. > > [RFC5982] Kobayashi, A. and B. Claise, "IP Flow Information Export > (IPFIX) Mediation: Problem Statement", RFC 5982, > August 2010. > > [RFC6183] Kobayashi, A., Claise, B., Muenz, G., and K. Ishibashi, > "IP Flow Information Export (IPFIX) Mediation: Framework", > RFC 6183, April 2011. > > [RFC6235] Boschi, E. and B. Trammell, "IP Flow Anonymization > Support", RFC 6235, May 2011. > > [I-D.ietf-ipfix-mediation-protocol] > Claise, B., Kobayashi, A., and B. Trammell, "Operation of > the IP Flow Information Export (IPFIX) Protocol on IPFIX > Mediators", draft-ietf-ipfix-mediation-protocol-01 (work > in progress), June 2012. > > [I-D.ietf-ipfix-ie-doctors] > Trammell, B. and B. Claise, "Guidelines for Authors and > Reviewers of IPFIX Information Elements", > draft-ietf-ipfix-ie-doctors-03 (work in progress), > June 2012. > > [I-D.ietf-ipfix-configuration-model] > Muenz, G., Claise, B., and P. Aitken, "Configuration Data > Model for IPFIX and PSAMP", > draft-ietf-ipfix-configuration-model-11 (work in > progress), June 2012. > > [I-D.ietf-ipfix-flow-selection-tech] > > > > Trammell, et al. Expires December 29, 2012 [Page 47] > > Internet-Draft IPFIX Aggregation June 2012 > > > D'Antonio, S., Zseby, T., Henke, C., and L. Peluso, "Flow > Selection Techniques", > draft-ietf-ipfix-flow-selection-tech-11 (work in > progress), April 2012. > > [iana-ipfix-assignments] > Internet Assigned Numbers Authority, "IP Flow Information > Export Information Elements > (http://www.iana.org/assignments/ipfix/ipfix.xml)". > > > Authors' Addresses > > Brian Trammell > Swiss Federal Institute of Technology Zurich > Gloriastrasse 35 > 8092 Zurich > Switzerland > > Phone: +41 44 632 70 13 > Email: trammell@tik.ee.ethz.ch > > > Arno Wagner > Consecom AG > Bleicherweg 64a > 8002 Zurich > Switzerland > > Email: arno@wagner.name > > > Benoit Claise > Cisco Systems, Inc. > De Kleetlaan 6a b1 > 1831 Diagem Once again, in existing RFCs - and in Cisco's internal directory - this is "Diegem 1831". > > Belgium > > Phone: +32 2 704 5622 > Email: bclaise@cisco.com > > > > > > > > > > > > Trammell, et al. Expires December 29, 2012 [Page 48] > --------------030603030609090505000903 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Dear Authors,

Here with an extensive and detailed review of draft-ietf-ipfix-a9n-04.

P.


 
IPFIX Working Group                                          B. Trammell
Internet-Draft                                                ETH Zurich
Intended status: Standards Track                               A. Wagner
Expires: December 29, 2012                                   Consecom AG
                                                               B. Claise
                                                     Cisco Systems, Inc.
                                                           June 27, 2012


  Flow Aggregation for the IP Flow Information Export (IPFIX) Protocol
                      draft-ietf-ipfix-a9n-04.txt

Abstract

   This document provides a common implementation-independent basis for
   the interoperable application of the IP Flow Information Export
   (IPFIX) Protocol to the handling of Aggregated Flows, which are IPFIX
   Flow representing packets from multiple Original Flows sharing some

s/Flow/Flows/


 

   set of common properties.  It does this through a detailed
   terminology and a descriptive Intermediate Aggregation Process
   architecture, including a specification of methods for Original Flow
   counting and counter distribution across intervals.

Status of this Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on December 29, 2012.

Copyright Notice

   Copyright (c) 2012 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of



Trammell, et al.        Expires December 29, 2012               [Page 1]

Internet-Draft              IPFIX Aggregation                  June 2012


   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
     1.1.  IPFIX Protocol Overview  . . . . . . . . . . . . . . . . .  5
     1.2.  IPFIX Documents Overview . . . . . . . . . . . . . . . . .  5
   2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  6
   3.  Use Cases for IPFIX Aggregation  . . . . . . . . . . . . . . .  7
   4.  Architecture for Flow Aggregation  . . . . . . . . . . . . . .  8
     4.1.  Aggregation within the IPFIX Architecture  . . . . . . . .  8
     4.2.  Intermediate Aggregation Process Architecture  . . . . . . 12
       4.2.1.  Correlation and Normalization  . . . . . . . . . . . . 14
   5.  IP Flow Aggregation Operations . . . . . . . . . . . . . . . . 15
     5.1.  Temporal Aggregation through Interval Distribution . . . . 15
       5.1.1.  Distributing Values Across Intervals . . . . . . . . . 16
       5.1.2.  Time Composition . . . . . . . . . . . . . . . . . . . 18
       5.1.3.  External Interval Distribution . . . . . . . . . . . . 19
     5.2.  Spatial Aggregation of Flow Keys . . . . . . . . . . . . . 19
       5.2.1.  Counting Original Flows  . . . . . . . . . . . . . . . 21
       5.2.2.  Counting Distinct Key Values . . . . . . . . . . . . . 22
     5.3.  Spatial Aggregation of Non-Key Fields  . . . . . . . . . . 22
       5.3.1.  Counter Statistics . . . . . . . . . . . . . . . . . . 22
       5.3.2.  Derivation of New Values from Flow Keys and
               non-Key fields . . . . . . . . . . . . . . . . . . . . 22
     5.4.  Aggregation Combination  . . . . . . . . . . . . . . . . . 23
   6.  Additional Considerations and Special Cases in Flow
       Aggregation  . . . . . . . . . . . . . . . . . . . . . . . . . 23
     6.1.  Exact versus Approximate Counting during Aggregation . . . 24
     6.2.  Delay and Loss introduced by the IAP . . . . . . . . . . . 24
     6.3.  Considerations for Aggregation of Sampled Flows  . . . . . 24
     6.4.  Considerations for Aggregation of Heterogeneous Flows  . . 24
   7.  Export of Aggregated IP Flows using IPFIX  . . . . . . . . . . 25
     7.1.  Time Interval Export . . . . . . . . . . . . . . . . . . . 25
     7.2.  Flow Count Export  . . . . . . . . . . . . . . . . . . . . 26
       7.2.1.  originalFlowsPresent . . . . . . . . . . . . . . . . . 26
       7.2.2.  originalFlowsInitiated . . . . . . . . . . . . . . . . 26
       7.2.3.  originalFlowsCompleted . . . . . . . . . . . . . . . . 26
       7.2.4.  deltaFlowCount . . . . . . . . . . . . . . . . . . . . 26
     7.3.  Distinct Host Export . . . . . . . . . . . . . . . . . . . 27
       7.3.1.  distinctCountOfSourceIPAddress . . . . . . . . . . . . 27
       7.3.2.  distinctCountOfDestinationIPAddress  . . . . . . . . . 27



Trammell, et al.        Expires December 29, 2012               [Page 2]

Internet-Draft              IPFIX Aggregation                  June 2012


       7.3.3.  distinctCountOfSourceIPv4Address . . . . . . . . . . . 27
       7.3.4.  distinctCountOfDestinationIPv4Address  . . . . . . . . 28
       7.3.5.  distinctCountOfSourceIPv6Address . . . . . . . . . . . 28
       7.3.6.  distinctCountOfDestinationIPv6Address  . . . . . . . . 28
     7.4.  Aggregate Counter Distribution Export  . . . . . . . . . . 28
       7.4.1.  Aggregate Counter Distribution Options Template  . . . 29
       7.4.2.  valueDistributionMethod Information Element  . . . . . 29
   8.  Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
     8.1.  Traffic Time-Series per Source . . . . . . . . . . . . . . 32
     8.2.  Core Traffic Matrix  . . . . . . . . . . . . . . . . . . . 36
     8.3.  Distinct Source Count per Destination Endpoint . . . . . . 41
     8.4.  Traffic Time-Series per Source with Counter
           Distribution . . . . . . . . . . . . . . . . . . . . . . . 43
   9.  Security Considerations  . . . . . . . . . . . . . . . . . . . 45
   10. IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 45
   11. Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 46
   12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 46
     12.1. Normative References . . . . . . . . . . . . . . . . . . . 46
     12.2. Informative References . . . . . . . . . . . . . . . . . . 46
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 48































Trammell, et al.        Expires December 29, 2012               [Page 3]

Internet-Draft              IPFIX Aggregation                  June 2012


1.  Introduction

   The assembly of packet data into Flows serves a variety of different
   purposes, as noted in the requirements [RFC3917] and applicability
   statement [RFC5472] for the IP Flow Information Export (IPFIX)
   protocol [I-D.ietf-ipfix-protocol-rfc5101bis].  Aggregation beyond
   the flow level, into records representing multiple Flows, is a common
   analysis and data reduction technique as well, with applicability to
   large-scale network data analysis, archiving, and inter-organization
   exchange.  This applicability in large-scale situations, in
   particular, led to the inclusion of aggregation as part of the IPFIX
   Mediators Problem Statement [RFC5982], and the definition of an
   Intermediate Aggregation Process in the Mediator framework [RFC6183].

   Aggregation is used for analysis and data reduction in a wide variety
   of applications, for example in traffic matrix calculation,
   generation of time series data for visualizations or anomaly
   detection, or data reduction for long-term trending and storage.
   Depending on the keys used for aggregation, it may additionally have
   an anonymizing affect on the data: for example, aggregation
   operations which eliminate IP addresses make it impossible to later
   identify nodes using those addresses.

Not necessarily. "may make it impossible..." ?


 


   Aggregation as defined and described in this document covers the
   applications defined in [RFC5982], including 5.1 "Adjusting Flow
   Granularity", 5.4 "Time Composition", and 5.5 "Spatial Composition".
   However, this document specifies a more flexible architecture for an
   Intermediate Aggregation Process than that envisioned by the original
   Mediator work, in Section 4.2.

Sounds like "Section 4.2" refers to the "original Mediator work" rather than to "this document".

Consider: "However, Section 4.2 of this document specifies a more flexible architecture for an Intermediate Aggregation Process than that envisioned by the original Mediator work."


 
   Instead of a focus on these specific
   limited use cases, the Intermediate Aggregation Process is specified
   to cover any activity commonly described as "flow aggregation".  This
   architecture is intended to describe any such activity without
   reference to the specific implementation of aggregation.

   An Intermediate Aggregation Process may be applied to data collected
   from multiple Observation Points, as it is natural to use aggregation
   for data reduction when concentrating measurement data.  This
   document specifically does not address the protocol issues that arise
   when combining IPFIX data from multiple Observation Points and
   exporting from a single Mediator, as these issues are general to
   IPFIX Mediation; they are therefore treated in detail in the Mediaton

s/Mediaton/Mediation/


 

   Protocol [I-D.ietf-ipfix-mediation-protocol] document.
"...Mediation Protocol document [I-D.ietf-ipfix-mediation-protocol]".


 


   Since Aggregated Flows as defined in the following section are
   essentially Flows, the IPFIX protocol
   [I-D.ietf-ipfix-protocol-rfc5101bis] can be used to export, and the
   IPFIX File Format [RFC5655] can be used to store, aggregated data
   "as-is"; there are no changes necessary to the protocol.  This



Trammell, et al.        Expires December 29, 2012               [Page 4]

Internet-Draft              IPFIX Aggregation                  June 2012


   document provides a common basis for the application of IPFIX to the
   handling of aggregated data, through a detailed terminology,
   Intermediate Aggregation Process architecture, and methods for
   Original Flow counting and counter distribution across intervals.

1.1.  IPFIX Protocol Overview

   In the IPFIX protocol, { type, length, value } tuples are expressed
   in templates containing { type, length } pairs, specifying which {
   value } fields are present in data records conforming to the
   Template, giving great flexibility as to what data is transmitted.
   Since Templates are sent very infrequently compared with Data
   Records, this results in significant bandwidth savings.  Various
   different data formats may be transmitted simply by sending new
   Templates specifying the { type, length } pairs for the new data
   format.  See [I-D.ietf-ipfix-protocol-rfc5101bis] for more
   information.

   The IPFIX Information Element Registry [iana-ipfix-assignments]
   defines a large number of standard Information Elements which provide
   the necessary { type } information for Templates.  The use of
   standard elements enables interoperability among different vendors'
   implementations.  Additionally, non-standard enterprise-specific
   elements may be defined for private use.

1.2.  IPFIX Documents Overview

   "Specification of the IPFIX Protocol for the Exchange of IP Traffic
   Flow Information" [I-D.ietf-ipfix-protocol-rfc5101bis] and its
   associated documents define the IPFIX Protocol, which provides
   network engineers and administrators with access to IP traffic flow
   information.

   "Architecture for IP Flow Information Export" [RFC5470] defines the
   architecture for the export of measured IP flow information out of an
   IPFIX Exporting Process to an IPFIX Collecting Process, and the basic
   terminology used to describe the elements of this architecture, per
   the requirements defined in "Requirements for IP Flow Information
   Export" [RFC3917].  The IPFIX Protocol document
   [I-D.ietf-ipfix-protocol-rfc5101bis] then covers the details of the
   method for transporting IPFIX Data Records and Templates via a
   congestion-aware transport protocol from an IPFIX Exporting Process
   to an IPFIX Collecting Process.

   This document specifies an Intermediate Process which may be applied
   at an IPFIX Mediator.

This sounds limiting. The process may be applied anywhere, eg even at the original OP prior to export.

I'd move the above sentence to the end of this paragraph, so the present work is introduced in context after having explained mediation.


 
  "IP Flow Information Export (IPFIX) Mediation:
   Problem Statement" [RFC5982] introduces the concept of IPFIX
   Mediators, and defines the use cases for which they were designed;



Trammell, et al.        Expires December 29, 2012               [Page 5]

Internet-Draft              IPFIX Aggregation                  June 2012


   "IP Flow Information Export (IPFIX) Mediation: Framework" [RFC6183]
   then provides an architectural framework for Mediators.  Protocol-
   level issues (e.g., template and observation domain handling across
   Mediators) are covered by "Specification of the Protocol for IPFIX
   Mediation" [I-D.ietf-ipfix-mediation-protocol].


2.  Terminology

   Terms used in this document that are defined in the Terminology
   section of the IPFIX Protocol [I-D.ietf-ipfix-protocol-rfc5101bis]
   document are to be interpreted as defined there.

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [RFC2119].

   In addition, this document defines the following terms

   Aggregated Flow:   A Flow, as defined by
      [I-D.ietf-ipfix-protocol-rfc5101bis], derived from a set of zero
      or more original Flows within a defined Aggregation Interval.  The

Zero things can't be aggregated. You can only say, "none were seen".


 

      primary difference between a Flow and an Aggregated Flow in the
      general case is that the time interval (i.e., the two-tuple of
      start and end times) of a Flow is derived from information about
      the timing of the packets comprising the Flow, while the time
      interval of an Aggregated Flow is often externally imposed.  Note
      that an Aggregated Flow is defined in the context of an
      Intermediate Aggregation Process only.  Once an Aggregated Flow is
      exported, it is essentially a Flow as in
      [I-D.ietf-ipfix-protocol-rfc5101bis] and can be treated as such.

   Intermediate Aggregation Process:   an Intermediate Process as in

Add "(IAP)" here, since that's the term used throughout the document.


 

      [RFC6183] that aggregates records, based upon a set of Flow Keys
      or functions applied to fields from the record.

   Aggregation Interval:   A time interval imposed upon an Aggregated
      Flow.  Intermediate Aggregation Processes may use a regular
      Aggregation Interval (e.g. "every five minutes", "every calendar
      month"), though regularity is not necessary.  Aggregation
      intervals may also be derived from the time intervals of the
      Original Flows being aggregated.

   Partially Aggregated Flow:   A Flow during processing within an
      Intermediate Aggregation Process; refers to an intermediate data
      structure during aggregation within the Intermediate Aggregation
      Process architecture detailed in Section 4.2.




Trammell, et al.        Expires December 29, 2012               [Page 6]

Internet-Draft              IPFIX Aggregation                  June 2012


   Original Flow:   A Flow given as input to an Intermediate Aggregation
      Process in order to generate Aggregated Flows.

   Contributing Flow:   An Original Flow that is partially or completely
      represented within an Aggregated Flow.  Each Aggregated Flow is
      made up of zero or more Contributing Flows, and an Original Flow
      may contribute to zero or more Aggregated Flows.

   Original Exporter:   When the Intermediate Aggregation Process is
      hosted in an IPFIX Mediator, the Original Exporter is the Exporter
      from which the Original Flows are received.

Does the meaning of "Original Exporter" change when the Intermediate Aggregation Process is _not_  hosted in an IPFIX Mediator?


 


   The terminology presented herein improves the precision of, but does
   not supersede or contradict the terms related to mediation and
   aggregation defined in the problem statement [RFC5982] and the

"Meditation Problem Statement [RFC5982]".


 

   framework [RFC6183] documents.  Within this document, the terminology

"Mediation Framework [RFC6183] documents."


 

   defined in this section is to be considered normative.


3.  Use Cases for IPFIX Aggregation

   Aggregation, as a common data reduction method used in traffic data
   analysis, has many applications.  When used with a regular
   Aggregation Interval and Original Flows containing timing
   information, it generates time series data from a collection of Flows
   with discrete intervals, as in the example in Section 8.1.  This time
   series data is itself useful for a wide variety of analysis tasks,
   such as generating input for network anomaly detection systems, or
   driving visualizations of volume per time for traffic with specific
   characteristics.  As a second example, traffic matrix calculation
   from flow data, as shown in Section 8.2 is inherently an aggregation
   action, by aggregating the Flow Key down to input or output
   interface, address prefix, or autonomous system.

Clarify that aggregating interface, address, or AS, is aggregation in space versus aggregation in time.


 


   Irregular or data-dependent Aggregation Intervals and key aggregation
   operations can also be used to provide adaptive aggregation of
   network flow data.  Here, full Flow Records can be kept for Flows of
   interest, while Flows deemed "less interesting" to a given
   application can be aggregated.  For example, in an IPFIX Mediator
   equipped with traffic classification capabilities for security
   purposes, potentially malicious Flows could be exported directly,
   while known-good or probably-good Flows (e.g. normal web browsing)
   could be exported simply as time series volumes per web server.

   Aggregation can also be applied to final analysis of stored Flow
   data, as shown in the example in Section 8.3.  All such aggregation
   applications in which timing information is not available or not
   important can be treated as if an infinite Aggregation Interval



Trammell, et al.        Expires December 29, 2012               [Page 7]

Internet-Draft              IPFIX Aggregation                  June 2012


   applies.

   Note that an Intermediate Aggregation Process which removes
   potentially sensitive information as identified in [RFC6235] may tend
   to have an anonymising effect on the Aggregated Flows, as well;

Remove the comma.


 

   however, any application of aggregation as part of a data protection
   scheme should ensure that all the issues raised in [RFC6235] are
   addressed, specifically Section 4 "Anonymization of IP Flow Data",
   Section 7.2 "IPFIX-Specific Anonymization Guidelines", and Section 9
   "Security Considerations".

   While much of the discussion in this document, and all of the
   examples, apply to the common case that the Original Flows to be
   aggregated are all of the same underlying type (i.e., are represented
   with identical or compatible Templates), and that each packet

What are "compatible" Templates ?

How does this work when there are zero things to be aggregated? ie, are zero things all of the same type?


 

   observed by the Metering Process on the far side of the Original

Where is "the far side" ?


 

   Exporter is represented, this is not a necessary assumption.
   Aggregation can also be applied as part of a technique applying both
   aggregation and correlation to pull together multiple views of the
   same traffic from different Observation Points using different
   Templates.  For example, consider a set of applications running at
   different Observation Points for different purposes -- one generating
   flows with round-trip-times for passive performance measurement, and
   one generating billing records.  Once correlated, these flows could
   used to produce Aggregated Flows containing both volume and
   performance information together.  The correlation and normalization
   operation described in Section 4.2.1 handles this specific case of
   correlation.  Flow correlation in the general case is outside the
   scope of this document.


4.  Architecture for Flow Aggregation

   This section specifies the architecture of the Intermediate
   Aggregation Process, and how it fits into the IPFIX Architecture.

4.1.  Aggregation within the IPFIX Architecture

   An Intermediate Aggregation Process could be deployed at any of three
   places within the IPFIX Architecture.  While aggregation is most
   commonly done within a Mediator which collects Original Flows from an
   Original Exporter and exports Aggregated Flows, aggregation can also
   occur before initial export, or after final collection, as shown in
   Figure 1.  The presence of an IAP at any of these points is of course
   optional.






Trammell, et al.        Expires December 29, 2012               [Page 8]

Internet-Draft              IPFIX Aggregation                  June 2012


   +===========================================+
   |  IPFIX Exporter        +----------------+ |
   |                        | Metering Proc. | |
   | +-----------------+    +----------------+ |
   | | Metering Proc.  | or |      IAP       | |
   | +-----------------+----+----------------+ |
   | |           Exporting Process           | |
   | +-|----------------------------------|--+ |
   +===|==================================|====+
       |                                  |
       |         (Aggregated Flow Export) |

Why label just one of the streams as "Aggregated Flow Export" ?
Why not label the other as regular flow export, and indicate below that both streams are AFE.


 

       |                                  |
   +===|===========================+      |
   |   |  Aggregating Mediator     |      |
   + +-V-------------------+       |      |
   | | Collecting Process  |       |      |
   + +---------------------+       |      |
   | |         IAP         |       |      |
   + +---------------------+       |      |
   | |  Exporting Process  |       |      |
   + +-|-------------------+       |      |
   +===|===========================+      |
       |                                  |
       |                                  |
   +===|==================================|=====+
   |   | Collector                        |     |
   | +-V----------------------------------V-+   |
   | |         Collecting Process           |   |
   | +------------------+-------------------+   |
   |                    |        IAP        |   |

Note that this IAP could be aggregating aggregated flows. Nothing wrong with that, though I don't think it's specifically mentioned.


 

   |                    +-------------------+   |
   |  (Aggregation      |   File Writer     |   |
       for Storage)     +-----------|-------+   |
   +================================|===========+
                                    |
                             +------V-----------+
                             |    IPFIX File    |
                             +------------------+

                 Figure 1: Potential Aggregation Locations

   The Mediator use case is further shown in Figures A and B in
   [RFC6183].

   Aggregation can be applied for either intermediate or final analytic
   purposes.  In certain circumstances, it may make sense to export
   Aggregated Flows directly from an original Exporting Process, for

Should "original EP" be defined terminology in this doc?


 

   example, if the Exporting Process is applied to drive a time-series



Trammell, et al.        Expires December 29, 2012               [Page 9]

Internet-Draft              IPFIX Aggregation                  June 2012


   visualization, or when flow data export bandwidth is restricted and
   flow or packet sampling is not an option.  Note that this case, where
   the Aggregation Process is essentially integrated into the Metering
   Process, is essentially covered by the IPFIX architecture [RFC5470]:
   the Flow Keys used are simply a subset of those that would normally
   be used, and time intervals may be chosen other than those available
   from the cache policies customarily offered by the Metering Process.
   A Metering Process in this arrangement MAY choose to simulate the
   generation of larger Flows in order to generate Original Flow counts,
   if the application calls for compatibility with an Aggregation
   Process deployed in a separate location.

   In the specific case that an Aggregation Process is employed for data
   reduction for storage purposes, it can take Original Flows from a
   Collecting Process or File Reader and pass Aggregated Flows to a File
   Writer for storage.

   Deployment of an Intermediate Aggregation Process within a Mediator
   [RFC5982] is a much more flexible arrangement.  Here, the Mediator
   consumes Original Flows and produces Aggregated Flows; this
   arrangement is suited to any of the use cases detailed in Section 3.
   In a Mediator, Original Flows from multiple sources can also be
   aggregated into a single stream of Aggregated Flows; the
   architectural specifics of this arrangement are not addressed in this
   document, which is concerned only with the aggregation operation
   itself; see [I-D.ietf-ipfix-mediation-protocol] for details.

   The data paths into and out of an Intermediate Aggregation Process
   are shown in Figure 2.






















Trammell, et al.        Expires December 29, 2012              [Page 10]

Internet-Draft              IPFIX Aggregation                  June 2012


     packets --+               IPFIX Messages      IPFIX Files
               |                     |                  |
               V                     V                  V
     +==================+ +====================+ +=============+
     | Metering Process | | Collecting Process | | File Reader |
     |                  | +====================+ +=============+
     | (Original Flows  |            |  Original Flows  |
     |  or direct aggr.)|            V                  V

What is "direct aggr." ?


 

     + - - - - - - - - -+======================================+
     |           Intermediate Aggregation Process (IAP)        |

This is the 6th time that "IAP" has been used, and the first time it has been explained.
Please define the term.


 

     +=========================================================+
               | Aggregated                  Aggregated |
               | Flows                            Flows |
               V                                        V
     +===================+                       +=============+
     | Exporting Process |                       | File Writer |
     +===================+                       +=============+
               |                                        |
               V                                        V
         IPFIX Messages                            IPFIX Files

           Figure 2: Data paths through the aggregation process

   Aggregation may also need to correlate original flows from multiple
   Metering Processes, each according to a different Template with
   different Flow Keys and values.  This arrangement is shown in
   Figure 3; in this case, the correlation and normalization operation
   described in Section 4.2.1 handles merging the Original Flows before

Missing text: "before..." what?


 
























Trammell, et al.        Expires December 29, 2012              [Page 11]

Internet-Draft              IPFIX Aggregation                  June 2012


    packets --+---------------------+------------------+
              |                     |                  |
              V                     V                  V
    +====================+ +====================+ +====================+
    | Metering Process 1 | | Metering Process 2 | | Metering Process n |
    +====================+ +====================+ +====================+
              |                     |  Original Flows  |
              V                     V                  V
    +==================================================================+
    | Intermediate Aggregation Process  +  correlation / normalization |
    +==================================================================+
              | Aggregated                  Aggregated |
              | Flows                            Flows |
              V                                        V
    +===================+                       +=============+
    | Exporting Process |                       | File Writer |
    +===================+                       +=============+
              |                                        |
              +------------> IPFIX Messages <----------+

   Figure 3: Aggregating Original Flows from multiple Metering Processes

4.2.  Intermediate Aggregation Process Architecture

   Within this document, an Intermediate Aggregation Process can be seen
   as hosting a function composed of four types of operations on
   Partially Aggregated Flows, as illustrated in Figure 4.  "Partially
   Aggregated Flows" as defined in Section 2 are essentially the
   intermediate results of aggregation, internal to the Intermediate
   Aggregation Process.





















Trammell, et al.        Expires December 29, 2012              [Page 12]

Internet-Draft              IPFIX Aggregation                  June 2012


           Original Flows  /   Original Flows requiring correlation
   +=============|===================|===================|=============+
   |             |   Intermediate    |    Aggregation    |   Process   |
   |             |                   V                   V             |
   |             |   +-----------------------------------------------+ |
   |             |   |   (optional) correlation and normalization    | |
   |             |   +-----------------------------------------------+ |
   |             |                          |                          |
   |             V                          V                          |
   |  +--------------------------------------------------------------+ |
   |  |                interval distribution (temporal)              | |
   |  +--------------------------------------------------------------+ |
   |           | ^                         | ^                |        |
   |           | |  Partially Aggregated   | |    Flows       |        |
   |           V |                         V |                |        |
   |  +-------------------+       +--------------------+      |        |
   |  |  key aggregation  |<------|  value aggregation |      |        |
   |  |     (spatial)     |------>|      (spatial)     |      |        |
   |  +-------------------+       +--------------------+      |        |
   |            |                          |                  |        |
   |            |   Partially Aggregated   |      Flows       |        |

Separating out "Partially Aggregated Flows" like this doesn't work for me.
Put "Flows" underneath "PA".


 

   |            V                          V                  V        |
   |  +--------------------------------------------------------------+ |
   |  |                     aggregate combination                    | |
   |  +--------------------------------------------------------------+ |
   |                                       |                           |
   +=======================================|===========================+
                                           V
                                   Aggregated Flows

    Figure 4: Conceptual model of aggregation operations within an IAP

The section below has irregular indentation: label, then 2 or 3 spaces, then text.


 

   Interval distribution  is a temporal aggregation operation which
      imposes an Aggregation Interval on the partially Aggregated Flow.
      This Aggregation Interval may be regular, irregular, or derived
      from the timing of the Original Flows themselves.  Interval
      distribution is discussed in detail in Section 5.1.

   Key aggregation   is a spatial aggregation operation which results in
      the addition, modification, or deletion of Flow Key fields in the
      Partially Aggregated Flows.  New Flow Keys may be derived from
      existing Flow Keys (e.g., looking up an AS number for an IP
      address), or "promoted" from specific non-Key fields (e.g., when
      aggregating Flows by packet count per Flow).  Key aggregation can
      also add new non-Key fields derived from Flow Keys that are
      deleted during key aggregation; mainly counters of unique reduced
      keys.  Key aggregation is discussed in detail in Section 5.2.




Trammell, et al.        Expires December 29, 2012              [Page 13]

Internet-Draft              IPFIX Aggregation                  June 2012


   Value aggregation   is a spatial aggregation operation which results
      in the addition, modification, or deletion of non-Key fields in
      the Partially Aggregated Flows.  These non-Key fields may be
      "demoted" from existing Key fields, or derived from existing Key
      or non-Key fields.  Value aggregation is discussed in detail in
      Section 5.3.

   Aggregate combination   combines multiple partially Aggregated Flows
      having undergone interval distribution, key aggregation, and value
      aggregation which share Flow Keys and Aggregation Intervals into a
      single Aggregated Flow per set of Flow Key values and Aggregation
      Interval.  Aggregate combination is discussed in detail in
      Section 5.4.

   Correlation and normalization  is required when accepting Original
      Flows from Metering Processes which export different views of
      essentially the same Flows before aggregation; the details of
      correlation and normalization are specified in Section 4.2.1,
      below.

   The first three of these operations may be carried out any number of
   times in any order, either on Original Flows or on the results of one
   of the operations above, with one caveat: since Flows carry their own
   interval data, any spatial aggregation operation implies a temporal
   aggregation operation, so at least one interval distribution step,
   even if implicit, is required by this architecture.  This is shown as
   the first step for the sake of simplicity in the diagram above.  Once
   all aggregation operations are complete, aggregate combination
   ensures that for a given Aggregation Interval, set of Flow Key
   values, and Observation Domain, only one Flow is produced by the
   Intermediate Aggregation Process.

   This model describes the operations within a single Intermediate
   Aggregation Process, and it is anticipated that most aggregation will
   be applied within a single process.  However, as the steps in the
   model may be applied in any order and aggregate combination is
   idempotent, any number of Intermediate Aggregation Processes
   operating in series can be modeled as a single process.  This allows
   aggregation operations to be flexibly distributed across any number
   of processes, should application or deployment considerations so
   dictate.

4.2.1.  Correlation and Normalization

   When accepting Original Flows from multiple Metering Processes, each
   of which provides a different view of the Original Flow as seen from
   the point of view of the IAP, an optional correlation and
   normalization operation combines each of these single Flow Records



Trammell, et al.        Expires December 29, 2012              [Page 14]

Internet-Draft              IPFIX Aggregation                  June 2012


   into a set of unified partially aggregated Flows before applying
   interval distribution.  These unified Flows appear as if they had
   been measured at a single Metering Process which used the union of
   the set of Flow Keys and non-key fields of all Metering Processes
   sending Original Flows to the IAP.

   Since, due to export errors or other slight irregularities in flow
   metering, the multiple views may not be completely consistent;
   normalization involves applying a set of aggregation application
   specific corrections in order to ensure consistency in the unified
   Flows.

   In general, correlation and normalization should take multiple views
   of essentially the same Flow, as determined by the configuration of
   the operation itself, and render them into a single unified Flow.
   Flows which are essentially different should not be unified by the
   correlation and normalization operation.  This operation therefore
   requires enough information about the configuration and deployment of
   Metering Processes from which it correlates Original Flows in order
   to make this distinction correctly and consistently.

   The exact steps performed to correlate and normalize flows in this
   step are application-, implementation-, and deployment-specific, and
   will not be further specified in this document.


5.  IP Flow Aggregation Operations

   As stated in Section 2, an Aggregated Flow is simply an IPFIX Flow
   generated from Original Flows by an Intermediate Aggregation Process.
   Here, we detail the operations by which this is achieved within an
   Intermediate Aggregation Process.

5.1.  Temporal Aggregation through Interval Distribution

   Interval distribution imposes a time interval on the resulting
   Aggregated Flows.  The selection of an interval is specific to the
   given aggregation application.  Intervals may be derived from the
   Original Flows themselves (e.g., an interval may be selected to cover
   the entire time containing the set of all Flows sharing a given Key,
   as in Time Composition described in Section 5.1.2) or externally
   imposed; in the latter case the externally imposed interval may be
   regular (e.g., every five minutes) or irregular (e.g., to allow for
   different time resolutions at different times of day, under different
   network conditions, or indeed for different sets of Original Flows).

   The length of the imposed interval itself has tradeoffs.  Shorter
   intervals allow higher-resolution aggregated data and, in streaming



Trammell, et al.        Expires December 29, 2012              [Page 15]

Internet-Draft              IPFIX Aggregation                  June 2012


   applications, faster reaction time.  Longer intervals generally lead
   to greater data reduction and simplified counter distribution.
   Specifically, counter distribution is greatly simplified by the
   choice of an interval longer than the duration of longest Original
   Flow, itself generally determined by the Original Flow's Metering
   Process active timeout; in this case an Original Flow can contribute
   to at most two Aggregated Flows, and the more complex value
   distribution methods become inapplicable.

   |                |                |                |
   | |<--Flow A-->| |                |                |
   |        |<--Flow B-->|           |                |
   |          |<-------------Flow C-------------->|   |
   |                |                |                |
   |   interval 0   |   interval 1   |   interval 2   |

              Figure 5: Illustration of interval distribution

   In Figure 5, we illustrate three common possibilities for interval
   distribution as applies with regular intervals to a set of three
   Original Flows.  For Flow A, the start and end times lie within the
   boundaries of a single interval 0; therefore, Flow A contributes to
   only one Aggregated Flow.  Flow B, by contrast, has the same duration
   but crosses the boundary between intervals 0 and 1; therefore, it
   will contribute to two Aggregated Flows, and its counters must be
   distributed among these Flows, though in the two-interval case this
   can be simplified somewhat simply by picking one of the two
   intervals, or proportionally distributing between them.  Only Flows
   like Flow A and Flow B will be produced when the interval is chosen
   to be longer than the duration of longest Original Flow, as above.
   More complicated is the case of Flow C, which contributes to more
   than two Aggregated Flows, and must have its counters distributed
   according to some policy as in Section 5.1.1.

This discussion applies equally to many other fields. eg, Figure 5 could show source ports, with the "intervals" grouping well-known ports and ephemeral ports. Flow A uses only a few source ports whereas Flow C uses many.

 
 

5.1.1.  Distributing Values Across Intervals

   In general, counters in Aggregated Flows are treated the same as in
   any Flow.  Each counter is independently calculated as if it were
   derived from the set of packets in the Original Flow.  For the most
   part, when aggregating Original Flows into Aggregated Flows, this is
   simply done by summation.

Not true: it depends on the counter's semantics. Delta counters can be summed. However, a total count would be superseded by a subsequent total count.


 


   When the Aggregation Interval is guaranteed to be longer than the
   longest Original Flow, a Flow can cross at most one Interval
   boundary, and will therefore contribute to at most two Aggregated
   Flows.  Most common in this case is to arbitrarily but consistently
   choose to account the Original Flow's counters either to the first or
   the last Aggregated Flow to which it could contribute.



Trammell, et al.        Expires December 29, 2012              [Page 16]

Internet-Draft              IPFIX Aggregation                  June 2012


   However, this becomes more complicated when the Aggregation Interval
   is shorter than the longest Original Flow in the source data.  In
   such cases, each Original Flow can incompletely cover one or more
   time intervals, and apply to one or more Aggregated Flows.  In this
   case, the Aggregation Process must distribute the counters in the
   Original Flows across the multiple Aggregated Flows.  There are

"must distribute" seems contrary to the "End Interval" and "Start Interval" schemes below.


 

   several methods for doing this, listed here in roughly increasing
   order of complexity and accuracy; most of these are necessary only in
   specialized cases.

   End Interval:   The counters for an Original Flow are added to the
      counters of the appropriate Aggregated Flow containing the end
      time of the Original Flow.

   Start Interval:   The counters for an Original Flow are added to the
      counters of the appropriate Aggregated Flow containing the start
      time of the Original Flow.

   Mid Interval:   The counters for an Original Flow are added to the
      counters of a single appropriate Aggregated Flow containing some
      timestamp between start and end time of the Original Flow.

   Simple Uniform Distribution:   Each counter for an Original Flow is
      divided by the number of time intervals the Original Flow covers
      (i.e., of appropriate Aggregated Flows sharing the same Flow
      Keys), and this number is added to each corresponding counter in
      each Aggregated Flow.

   Proportional Uniform Distribution:   This is like simple uniform
      distribution, but accounts for the fractional portions of a time
      interval covered by an Original Flow in the first and last time
      interval.  Each counter for an Original Flow is divided by the
      number of time _units_ the Original Flow covers, to derive a mean
      count rate.  This rate is then multiplied by the number of time
      units in the intersection of the duration of the Original Flow and
      the time interval of each Aggregated Flow.

   Simulated Process:   Each counter of the Original Flow is distributed
      among the intervals of the Aggregated Flows according to some
      function the Aggregation Process uses based upon properties of
      Flows presumed to be like the Original Flow.  For example, Flow
      Records representing bulk transfer might follow a more or less
      proportional uniform distribution, while interactive processes are
      far more bursty.

BTW, the case of a collector or mediator aggregating received flows presents another possibility: the flow could be received late (eg, delayed export), so rather than re-opening an old start / mid / end aggregation, the flow is simply included in the "current" aggregation. ie, real time aggregation, regardless of the flow timestamps.


 








Trammell, et al.        Expires December 29, 2012              [Page 17]

Internet-Draft              IPFIX Aggregation                  June 2012


   Direct:   The Aggregation Process has access to the original packet
      timings from the packets making up the Original Flow, and uses
      these to distribute or recalculate the counters.

   A method for exporting the distribution of counters across multiple
   Aggregated Flows is detailed in Section 7.4.  In any case, counters
   MUST be distributed across the multiple Aggregated Flows in such a
   way that the total count is preserved, within the limits of accuracy
   of the implementation.  This property allows data to be aggregated
   and re-aggregated with negligible loss of original count information.
   To avoid confusion in interpretation of the aggregated data, all the
   counters for a set of given Original Flows SHOULD be distributed via
   the same method.

Consider changing that to a "MUST".

As long as the method is consistent, is it necessary to know what method was used?


 


   More complex counter distribution methods generally require that the
   interval distribution process track multiple "current" time intervals
   at once.  This may introduce some delay into the aggregation
   operation, as an interval should only expire and be available for
   export when no additional Original Flows applying to the interval are
   expected to arrive at the Intermediate Aggregation Process.

   Note, however, that since there is no guarantee that Flows from the
   Original Exporter will arrive in any given order, whether for
   transport-specific reasons (i.e.  UDP reordering) or Metering Process

Or Exporting Process.


 

   implementation-specific reasons, even simpler distribution methods
   may need to deal with flows arriving in other than start time or end
   time order.  Therefore, the use of larger intervals does not obviate
   the need to buffer Partially Aggregated Flows within "current" time
   intervals, to ensure it can accept flow time intervals in any arrival

The subject is missing for "it". eg, "the need for an aggregation process to buffer", or "to ensure the aggregation process can accept".


 

   order.  More generally, the interval distribution process SHOULD
   accept flow start and end times in the Original Flows in any
   reasonable order.  The expiration of intervals in interval
   distribution operations is dependent on implementation and deployment
   requirements, and SHOULD be made configurable in contexts in which
   "reasonable order" is not obvious at implementation time.  This
   operation may lead to delay and loss introduced by the IAP, as
   detailed in Section 6.2.

5.1.2.  Time Composition

   Time Composition as in Section 5.4 of [RFC5982] (or interval
   combination) is a special case of aggregation, where interval
   distribution imposes longer intervals on Flows with matching keys and
   "chained" start and end times, without any key reduction, in order to
   join long-lived Flows which may have been split (e.g., due to an
   active timeout shorter than the actual duration of the Flow.)  Here,
   no Key aggregation is applied, and the Aggregation Interval is chosen
   on a per-Flow basis to cover the interval spanned by the set of



Trammell, et al.        Expires December 29, 2012              [Page 18]

Internet-Draft              IPFIX Aggregation                  June 2012


   aggregated Flows.  This may be applied alone in order to normalize
   split Flows, or in combination with other aggregation functions in
   order to obtain more accurate Original Flow counts.

5.1.3.  External Interval Distribution

   Note that much of the difficulty of interval distribution at an IAP
   can be avoided simply by configuring the original Exporters to
   synchronize the time intervals in the Original Flows with the desired
   aggregation interval.  The resulting Original Flows would then be
   split to align perfectly with the time intervals imposed during
   Interval Imposition (i.e., like Flow A in Figure 5), though this may
   reduce their usefulness for non-Aggregation purposes.  This approach
   allows the Intermediate Aggregation Process to use Start Interval or
   End Interval distribution, while having equivalent information to
   that available to Direct interval distribution.

5.2.  Spatial Aggregation of Flow Keys

   Key aggregation generates a new set of Flow Key values for the
   Aggregated Flows from the Original Flow Key and non-Key fields in the
   Original Flows, or from correlation of the Original Flow information
   with some external source.  There are two basic operations here.
   First, Aggregated Flow Keys may be derived directly from Original
   Flow Keys through reduction, or the dropping of fields or precision
   in the Original Flow Keys.  Second, Aggregated Flow Keys may be
   derived through replacement, e.g. by removing one or more fields from
   the Original Flow and replacing them with fields derived from the
   removed fields.  Replacement may refer to external information (e.g.,
   IP to AS number mappings).  Replacement may apply to Flow Keys as
   well as non-key fields.  For example, consider an application which
   aggregates Original Flows by packet count (i.e., generating an
   Aggregated Flow for all one-packet Flows, one for all two-packet
   Flows, and so on).  This application would promote the packet count
   to a Flow Key.

In this case, the non-key counter field can be promoted to a key field since it only contains a single value which is consistent across all the flows.

However, if the aggregation was "all small flows < 10 packets", then t would be inappropriate to promote the packet count to a key field.


 


   Key aggregation may also result in the addition of new non-Key fields
   to the Aggregated Flows, namely Original Flow counters and unique
   reduced key counters; these are treated in more detail in
   Section 5.2.1 and Section 5.2.2, respectively.

   In any key aggregation operation, reduction and/or replacement may be
   applied any number of times in any order.  Which of these operations
   are supported by a given implementation is implementation- and
   application-dependent.






Trammell, et al.        Expires December 29, 2012              [Page 19]

Internet-Draft              IPFIX Aggregation                  June 2012


   Original Flow Keys
   +---------+---------+----------+----------+-------+-----+
   | src ip4 | dst ip4 | src port | dst port | proto | tos |
   +---------+---------+----------+----------+-------+-----+
        |         |         |          |         |      |
     retain   mask /24      X          X         X      X
        V         V
   +---------+-------------+
   | src ip4 | dst ip4 /24 |
   +---------+-------------+
   Aggregated Flow Keys (by source address and destination class-C)

          Figure 6: Illustration of key aggregation by reduction

   Figure 6 illustrates an example reduction operation, aggregation by
   source address and destination class C network.  Here, the port,
   protocol, and type-of-service information is removed from the Flow
   Key, the source address is retained, and the destination address is
   masked by dropping the lower 8 bits.

The text and figures are a bit cramped here. Can you improve the layout by spacing things out a little?


 


   Original Flow Keys
   +---------+---------+----------+----------+-------+-----+
   | src ip4 | dst ip4 | src port | dst port | proto | tos |
   +---------+---------+----------+----------+-------+-----+
        |         |         |          |         |      |
   +-------------------+    X          X         X      X
   | ASN lookup table  |
   +-------------------+
        V         V
   +---------+---------+
   | src asn | dst asn |
   +---------+---------+
   Aggregated Flow Keys (by source and dest ASN)

        Figure 7: Illustration of key aggregation by reduction and
                                replacement

   Figure 7 illustrates an example reduction and replacement operation,
   aggregation by source and destination Border Gateway Protocol (BGP)
   Autonomous System Number (ASN) without ASN information available in
   the Original Flow.  Here, the port, protocol, and type-of-service
   information is removed from the Flow Keys, while the source and
   destination addresses are run though an IP address to ASN lookup
   table, and the Aggregated Flow Keys are made up of the resulting
   source and destination ASNs.






Trammell, et al.        Expires December 29, 2012              [Page 20]

Internet-Draft              IPFIX Aggregation                  June 2012


5.2.1.  Counting Original Flows

   When aggregating multiple Original Flows into an Aggregated Flow, it
   is often useful to know how many Original Flows are present in the
   Aggregated Flow.  This document introduces four new information
   elements in Section 7.2 to export these counters.

"Section 7.2 of this document introduces four new information elements to export these counters."


 


   There are two possible ways to count Original Flows, which we call
   here conservative and non-conservative.  Conservative flow counting
   has the property that each Original Flow contributes exactly one to
   the total flow count within a set of Aggregated Flows.  In other
   words, conservative flow counters are distributed just as any other
   counter during interval distribution, except each Original Flow is
   assumed to have a flow count of one.  When a count for an Original
   Flow must be distributed across a set of Aggregated Flows, and a
   distribution method is used which does not account for that Original
   Flow completely within a single Aggregated Flow, conservative flow
   counting requires a fractional representation.

   By contrast, non-conservative flow counting is used to count how many
   Contributing Flows are represented in an Aggregated Flow.  Flow
   counters are not distributed in this case.  An Original Flow which is
   present within N Aggregated Flows would add N to the sum of non-
   conservative flow counts, one to each Aggregated Flow.  In other
   words, the sum of conservative flow counts over a set of Aggregated
   Flows is always equal to the number of Original Flows, while the sum
   of non-conservative flow counts is strictly greater than or equal to
   the number of Original Flows.

   For example, consider Flows A, B, and C as illustrated in Figure 5.
   Assume that the key aggregation step aggregates the keys of these
   three Flows to the same aggregated Flow Key, and that start interval
   counter distribution is in effect.  The conservative flow count for
   interval 0 is 3 (since Flows A, B, and C all begin in this interval),
   and for the other two intervals is 0.  The non-conservative flow
   count for interval 0 is also 3 (due to the presence of Flows A, B,
   and C), for interval 1 is 2 (Flows B and C), and for interval 2 is 1
   (Flow C).  The sum of the conservative counts 3 + 0 + 0 = 3, the
   number of Original Flows; while the sum of the non-conservative
   counts 3 + 2 + 1 = 6.

   Note that the active and inactive timeouts used to generate Original
   Flows, as well as the cache policy used to generate those Flows, have
   an effect on how meaningful either the conservative or non-
   conservative flow count will be during aggregation.  In general, all
   the Original Exporters producing Original Flows to be aggregated
   SHOULD be aggregated using caches configured identically or
   similarly.  Original Exporters using the IPFIX Configuration Model

What does "identically or similarly" mean? In other words, how do we determine compliance with the SHOULD?


 




Trammell, et al.        Expires December 29, 2012              [Page 21]

Internet-Draft              IPFIX Aggregation                  June 2012


   SHOULD be configured to export Flows with equal or similar
   activeTimeout and inactiveTimeout configuration values, and the same
   cacheMode, as defined in [I-D.ietf-ipfix-configuration-model].

5.2.2.  Counting Distinct Key Values

   One common case in aggregation is counting distinct key values that
   were reduced away during key aggregation.  The most common use case
   for this is counting distinct hosts per Flow Key; for example, in
   host characterization or anomaly detection, distinct sources per
   destination or distinct destinations per source are common metrics.
   These new non-Key fields are added during key aggregation.

   For such applications, Information Elements for distinct counts of
   IPv4 and IPv6 addresses are defined in Section 7.3.  These are named
   distinctCountOf(KeyName).  Additional such Information Elements
   SHOULD be registered with IANA on an as-needed basis.

5.3.  Spatial Aggregation of Non-Key Fields

   Aggregation operations may also lead to the addition of value fields
   demoted from key fields, or derived from other value fields in the
   Original Flows.  Specific cases of this are treated in the
   subsections below.

5.3.1.  Counter Statistics

   Some applications of aggregation may benefit from computing different
   statistics than those native to each non-key field (i.e., union for
   flags, sum for counters).  For example, minimum and maximum packet

NB ambiguity whether the examples in the "ie" are the "native" or "different" statistics.


 

   counts per Flow, mean bytes per packet per Contributing Flow, and so
   on.  Certain Information Elements for these applications are already
   provided in the IANA IPFIX Information Elements registry
   (http://www.iana.org/assignments/ipfix/ipfix.html (e.g.
   minimumIpTotalLength).

   A complete specification of additional aggregate counter statistics
   is outside the scope of this document, and should be added in the
   future to the IANA IPFIX Information Elements registry on a per-
   application, as-needed basis.

5.3.2.  Derivation of New Values from Flow Keys and non-Key fields

   More complex operations may lead to other derived fields being
   generated from the set of values or Flow Keys reduced away during
   aggregation.  A prime example of this is sample entropy calculation.
   This counts distinct values and frequency, so is similar to distinct
   key counting as in Section 5.2.2, but may be applied to the



Trammell, et al.        Expires December 29, 2012              [Page 22]

Internet-Draft              IPFIX Aggregation                  June 2012


   distribution of values for any flow field.

   Sample entropy calculation provides a one-number normalized
   representation of the value spread and is useful for annomaly

s/annomaly/anomaly/


 

   detection.  The behaviour of entropy statistics is such that a small
   number of keys showing up very often drives the entropy value down
   towards zero, while a large number of keys, each showing up with
   lower frequency drives the entropy value up.

Add comma: "lower frequency,"


 


   Entropy statistics are generally useful for address-like keys, like

What does "address-like" mean?


 

   IP addresses, port numbers, AS numbers, etc.  They can also be done

Consider "done" -> "calculated" ?


 

   on flow length, flow duration fields and the like, even if this
   generally yields less distinct value shifts when the traffic mix
   changes.

   As a practical example, one host scanning a lot of other hosts will
   drive source IP entropy down and target IP entropy up.  A similar
   effect can be observed for ports.  This pattern can also be caused by
   the scan-traffic of a fast Internet worm.  A second example would be
   a DDoS flooding attack against a single target (or small number of
   targets) which drives source IP entropy up and target IP entropy
   down.

   A complete specification of additional derived values or entropy
   information elements is outside the scope of this document.  Any such
   Information Elements should be added in the future to the IANA IPFIX
   Information Elements registry on a per-application, as-needed basis.
   However, in the special case of entropy calculations, to support
   comparability of entropies of fields with different bit sizes,
   entropy SHOULD be represented as a float32 or float64 value
   normalized to the range [0..1].

You're hoping that future requesters / experts will remember to refer to this recommendation?
Are you citing this from IE police?


 


5.4.  Aggregation Combination

   Interval distribution and key aggregation together may generate
   multiple Partially Aggregated Flows covering the same time interval
   with the same set of Flow Key values.  The process of combining these
   Partially Aggregated Flows into a single Aggregated Flow is called
   aggregation combination.  In general, non-Key values from multiple
   Contributing Flows are combined using the same operation by which
   values are combined from packets to form Flows for each Information
   Element.  Counters are summed, averages are averaged, flags are
   unioned, and so on.

Disagree. Delta counters can be summed; total counters need the latest (newest) value.

However, averages cannot be averaged.

Suppose A1 = 0.25 and A2 = 0.75, what is their average? -> we can't know without knowing the base population size.

eg, if flow 1 sampled 25 out of 100 packets (ie, 0.25) and flow 2 sampled 150 out of 200 packets (0.75), the aggregate represents (25 + 150) out of (100 + 200) = 175/300 = 0.58.


 



6.  Additional Considerations and Special Cases in Flow Aggregation





Trammell, et al.        Expires December 29, 2012              [Page 23]

Internet-Draft              IPFIX Aggregation                  June 2012


6.1.  Exact versus Approximate Counting during Aggregation

   In certain circumstances, particularly involving aggregation by
   devices with limited resources, and in situations where exact
   aggregated counts are less important than relative magnitudes (e.g.
   driving graphical displays), counter distribution during key
   aggregation may be performed by approximate counting means (e.g.
   Bloom filters).  The choice to use approximate counting is
   implementation- and application-dependent.

Check spacing: "implementation- and application- dependent."


 


6.2.  Delay and Loss introduced by the IAP

   When accepting Original Flows in export order from traffic captured
   live, the Intermediate Aggregation Process wait for all Original

s/wait/waits/


 

   Flows which may contribute to a given interval during interval
   distribution.  This is generally dominated by the active timeout of
   the Metering Process measuring the Original Flows.  For example, with
   Metering Processes configured with a 5 minute active timeout, the
   Intermediate Aggregation Process introduces a delay of at least 5
   minutes to all exported Aggregated Flows to ensure it has received
   all Original Flows.

   In certain circumstances, additional delay at the original Exporter
   may cause an IAP to close an interval before the last Original
   Flow(s) accountable to the interval arrives; in this case the IAP
   SHOULD drop the late Original Flow(s).  Accounting of flows lost at
   an Intermediate Process due to such issues is covered in
   [I-D.ietf-ipfix-mediation-protocol].

6.3.  Considerations for Aggregation of Sampled Flows

   The accuracy of Aggregated Flows may also be affected by sampling of
   the Original Flows, or sampling of packets making up the Original
   Flows.  At the time of writing, the effect of sampling on flow
   aggregation is still an open research question.  However, to maximize
   the comparability of Aggregated Flows, aggregation of sampled Flows
   SHOULD only use Original Flows sampled using the same sampling rate
   and sampling algorithm, Flows created from packets sampled using the
   same sampling rate and sampling algorithm, or Original Flows which
   have been normalized as if they had the same sampling rate and
   algorithm before aggregation.  For more on packet sampling within
   IPFIX, see [RFC5476].  For more on Flow sampling within the IPFIX
   Mediator Framework, see [I-D.ietf-ipfix-flow-selection-tech].

6.4.  Considerations for Aggregation of Heterogeneous Flows

   Aggregation may be applied to Original Flows from different sources
   and of different types (i.e., represented using different, perhaps



Trammell, et al.        Expires December 29, 2012              [Page 24]

Internet-Draft              IPFIX Aggregation                  June 2012


   wildly-different Templates).  When the goal is to separate the
   heterogeneous Original Flows and aggregate them into heterogeneous
   Aggregated Flows, each aggregation should be done at its own
   Intermediate Aggregation Process.  The Observation Domain ID on the
   Messages containing the output Aggregated Flows can be used to
   identify the different Processes, and to segregate the output.

   However, when the goal is to aggregate these Flows into a single
   stream of Aggregated Flows representing one type of data, and if the
   Original Flows may represent the same original packet at two
   different Observation Points, the Original Flows should be correlated
   by the correlation and normalization operation within the IAP to
   ensure that each packet is only represented in a single Aggregated
   Flow or set of Aggregated Flows differing only by aggregation
   interval.


7.  Export of Aggregated IP Flows using IPFIX

   In general, Aggregated Flows are exported in IPFIX as any normal

Consider using "other" instead of "normal" to avoid the connotation that there are "abnormal" flows.


 

   Flow.  However, certain aspects of Aggregated Flow export benefit
   from additional guidelines, or new Information Elements to represent
   aggregation metadata or information generated during aggregation.
   These are detailed in the following subsections.

7.1.  Time Interval Export

   Since an Aggregated Flow is simply a Flow, the existing timestamp
   Information Elements in the IPFIX Information Model (e.g.,
   flowStartMilliseconds, flowEndNanoseconds) are sufficient to specify
   the time interval for aggregation.  Therefore, this document
   specifies no new aggregation-specific Information Elements for
   exporting time interval information.

More strongly: "Therefore, no new aggregation-specific Information Elements are required for exporting time interval information."


 


   Each Aggregated Flow carrying timing information SHOULD contain both
   an interval start and interval end timestamp.

Can this next paragraph be removed? The above text is sufficient.


 
   If an exporter of
   Aggregated Flows omits the interval end timestamp from each
   Aggregated Flow, the time interval for Aggregated Flows within an
   Observation Domain and Transport Session MUST be regular and
   constant.  However, note that this approach might lead to
   interoperability problems when exporting Aggregated Flows to non-
   aggregation-aware Collecting Processes and downstream analysis tasks;
   therefore, an Exporting Process capable of exporting only interval
   start timestamps MUST provide a configuration option to export
   interval end timestamps as well.

(removed to here)


 







Trammell, et al.        Expires December 29, 2012              [Page 25]

Internet-Draft              IPFIX Aggregation                  June 2012


7.2.  Flow Count Export

   The following four Information Elements are defined to count Original
   Flows as discussed in Section 5.2.1.

7.2.1.  originalFlowsPresent

   Description:   The non-conservative count of Original Flows
      contributing to this Aggregated Flow.  Non-conservative counts
      need not sum to the original count on re-aggregation.

   Abstract Data Type:   unsigned64

Sematics? Either totalCount or deltaCount. Same for the fields below too.


 


   ElementId:   TBD1

   Status:   Current

I'm sure it's not necessary to say "Status: Current", since it's very unlikely that we'd be introducing new but deprecated fields.

What does IE police have to say on this matter?


 


7.2.2.  originalFlowsInitiated

   Description:   The conservative count of Original Flows whose first
      packet is represented within this Aggregated Flow.  Conservative
      counts must sum to the original count on re-aggregation.

   Abstract Data Type:   unsigned64

   ElementId:   TBD2

   Status:   Current

7.2.3.  originalFlowsCompleted

   Description:   The conservative count of Original Flows whose last
      packet is represented within this Aggregated Flow.  Conservative
      counts must sum to the original count on re-aggregation.

   Abstract Data Type:   unsigned64

   ElementId:   TBD3

   Status:   Current

7.2.4.  deltaFlowCount

   Description:   The conservative count of Original Flows contributing
      to this Aggregated Flow; may be distributed via any of the methods
      described in Section 5.1.1.  This Information Element is
      compatible with Information Element 3 as used in NetFlow version
      9.

This is not a good description for inclusion in the IANA registry (which currently doesn't define element 3):

- "may be distributed via any of the methods described in Section 5.1.1." only makes sense within the context of this document.
- "This Information Element is compatible with Information Element 3 as used in NetFlow version 9." is suitable as a Note, but not as part of the description.


 




Trammell, et al.        Expires December 29, 2012              [Page 26]

Internet-Draft              IPFIX Aggregation                  June 2012


   Abstract Data Type:   unsigned64

   ElementId:   3

   Status:   Current

7.3.  Distinct Host Export

   The following four Information Elements represent the distinct counts
   of source and destination network-layer addresses, used to export
   distinct host counts reduced away during key aggregation.

7.3.1.  distinctCountOfSourceIPAddress

   Description:   The count of distinct source IP address values for
      Original Flows contributing to this Aggregated Flow, without
      regard to version.  This Information Element is preferred to the

"regard to _IP_ version".


 

      IP-version-specific counters, unless it is important to separate
      the counts by version.

   Abstract Data Type:   unsigned64

   ElementId:   TBD4

   Status:   Current

7.3.2.  distinctCountOfDestinationIPAddress

   Description:   The count of distinct destination IP address values
      for Original Flows contributing to this Aggregated Flow, without
      regard to version.  This Information Element is preferred to the

"regard to _IP_ version".


 

      version-specific counters below, unless it is important to
      separate the counts by version.

   Abstract Data Type:   unsigned64

   ElementId:   TBD5

   Status:   Current

7.3.3.  distinctCountOfSourceIPv4Address

   Description:   The count of distinct source IPv4 address values for
      Original Flows contributing to this Aggregated Flow.







Trammell, et al.        Expires December 29, 2012              [Page 27]

Internet-Draft              IPFIX Aggregation                  June 2012


   Abstract Data Type:   unsigned32

   ElementId:   TBD6

   Status:   Current

7.3.4.  distinctCountOfDestinationIPv4Address

   Description:   The count of distinct destination IPv4 address values
      for Original Flows contributing to this Aggregated Flow.

   Abstract Data Type:   unsigned32

   ElementId:   TBD7

   Status:   Current

7.3.5.  distinctCountOfSourceIPv6Address

   Description:   The count of distinct source IPv6 address values for
      Original Flows contributing to this Aggregated Flow.

   Abstract Data Type:   unsigned64

   ElementId:   TBD8

   Status:   Current

7.3.6.  distinctCountOfDestinationIPv6Address

   Description:   The count of distinct destination IPv6 address values
      for Original Flows contributing to this Aggregated Flow.

   Abstract Data Type:   unsigned64

   ElementId:   TBD9

   Status:   Current

It's a pity that six new IEs were required here, rather than a single "countOf" field + property. eg, "countOf" + "SourceIPv6Address".


 


7.4.  Aggregate Counter Distribution Export

   When exporting counters distributed among Aggregated Flows, as
   described in Section 5.1.1, the Exporting Process MAY export an
   Aggregate Counter Distribution Option Record for each Template
   describing Aggregated Flow records; this Options Template is
   described below.  It uses the valueDistributionMethod Information
   Element, also defined below.  Since in many cases distribution is
   simple, accounting the counters from Contributing Flows to the first



Trammell, et al.        Expires December 29, 2012              [Page 28]

Internet-Draft              IPFIX Aggregation                  June 2012


   Interval to which they contribute, this is the default situation, for
   which no Aggregate Counter Distribution Record is necessary;
   Aggregate Counter Distribution Records are only applicable in more
   exotic situations, such as using an Aggregation Interval smaller than
   the durations of Original Flows.

7.4.1.  Aggregate Counter Distribution Options Template

   This Options Template defines the Aggregate Counter Distribution
   Record, which allows the binding of a value distribution method to a
   Template ID.  Note that this Options Template causes the
   valueDistributionMethod to be implicitly scoped to the Observation
   Domain ID of the IPFIX Message containing the Aggregate Counter
   Distribution Record.  This is used to signal to the Collecting
   Process how the counters were distributed.  The fields are as below:

   +-------------------------+-----------------------------------------+
   | IE                      | Description                             |
   +-------------------------+-----------------------------------------+
   | templateId [scope]      | The Template ID of the Template         |
   |                         | defining the Aggregated Flows to which  |
   |                         | this distribution option applies.  This |
   |                         | Information Element MUST be defined as  |
   |                         | a Scope Field.                          |
   | valueDistributionMethod | The method used to distribute the       |
   |                         | counters for the Aggregated Flows       |
   |                         | defined by the associated Template.     |
   +-------------------------+-----------------------------------------+

Label this "Figure X" so it can be more easily referred to from future documents.


 


7.4.2.  valueDistributionMethod Information Element

   Description:   A description of the method used to distribute the
      counters from Contributing Flows into the Aggregated Flow records
      described by an associated scope, generally a Template.  The
      method is deemed to apply to all the non-key Information Elements
      in the referenced scope for which value distribution is a valid
      operation; if the originalFlowsInitiated and/or
      originalFlowsCompleted Information Elements appear in the
      Template, they are not subject to this distribution method, as
      they each infer their own distribution method.  This is intended
      to be a complete set of possible value distribution methods; it is

Do you mean to say it's a non-extensible?


 

      taken from the discussion Section 5.1.1 and encoded as follows:

"discussion _in_ Section 5.1.1."


 










Trammell, et al.        Expires December 29, 2012              [Page 29]

Internet-Draft              IPFIX Aggregation                  June 2012


   +-------+-----------------------------------------------------------+
   | Value | Description                                               |
   +-------+-----------------------------------------------------------+
   | 0     | Arbitrary: The counters for an Original Flow are          |
   |       | explicitly not distributed according to any defined       |
   |       | method.                                                   |
   |       | --------------------------------------------------------- |
   | 1     | Start Interval: The counters for an Original Flow are     |
   |       | added to the counters of the appropriate Aggregated Flow  |
   |       | containing the start time of the Original Flow.  This     |
   |       | should be assumed the default if value distribution       |
   |       | information is not available at a Collecting Process for  |
   |       | an Aggregated Flow.                                       |
   |       | --------------------------------------------------------- |
   | 2     | End Interval: The counters for an Original Flow are added |
   |       | to the counters of the appropriate Aggregated Flow        |
   |       | containing the end time of the Original Flow.             |
   |       | --------------------------------------------------------- |
   | 3     | Mid Interval: The counters for an Original Flow are added |
   |       | to the counters of a single appropriate Aggregated Flow   |
   |       | containing some timestamp between start and end time of   |
   |       | the Original Flow.                                        |
   |       | --------------------------------------------------------- |
   | 4     | Simple Uniform Distribution: Each counter for an Original |
   |       | Flow is divided by the number of time intervals the       |
   |       | Original Flow covers (i.e., of appropriate Aggregated     |
   |       | Flows sharing the same Flow Key), and this number is      |
   |       | added to each corresponding counter in each Aggregated    |
   |       | Flow.                                                     |
   |       | --------------------------------------------------------- |
   | 5     | Proportional Uniform Distribution: Each counter for an    |
   |       | Original Flow is divided by the number of time _units_    |
   |       | the Original Flow covers, to derive a mean count rate.    |
   |       | This mean count rate is then multiplied by the number of  |
   |       | time units in the intersection of the duration of the     |
   |       | Original Flow and the time interval of each Aggregated    |
   |       | Flow.  This is like simple uniform distribution, but      |
   |       | accounts for the fractional portions of a time interval   |
   |       | covered by an Original Flow in the first and last time    |
   |       | interval.                                                 |
   |       | --------------------------------------------------------- |










Trammell, et al.        Expires December 29, 2012              [Page 30]

Internet-Draft              IPFIX Aggregation                  June 2012


   | 6     | Simulated Process: Each counter of the Original Flow is   |
   |       | distributed among the intervals of the Aggregated Flows   |
   |       | according to some function the Aggregation Process uses   |
   |       | based upon properties of Flows presumed to be like the    |
   |       | Original Flow.  This is essentially an assertion that the |
   |       | Aggregation Process has no direct packet timing           |
   |       | information but is nevertheless not using one of the      |
   |       | other simpler distribution methods.  The Aggregation      |
   |       | Process specifically makes no assertion as to the         |
   |       | correctness of the simulation.                            |
   |       | --------------------------------------------------------- |
   | 7     | Direct: The Aggregation Process has access to the         |
   |       | original packet timings from the packets making up the    |
   |       | Original Flow, and uses these to distribute or            |
   |       | recalculate the counters.                                 |
   +-------+-----------------------------------------------------------+

   Abstract Data Type:   unsigned8

   ElementId:   TBD10

   Status:   Current


8.  Examples

   In these examples, the same data, described by the same template,
   will be aggregated multiple different ways; this illustrates the
   various different functions which could be implemented by
   Intermediate Aggregation Processes.  Templates are shown in IESpec
   format as introduced in [I-D.ietf-ipfix-ie-doctors].  The source data
   format is a simplified flow: timestamps, traditional 5-tuple, and
   octet count.  The template is shown in Figure 8.

   flowStartMilliseconds(152)[8]
   flowEndMilliseconds(153)[8]
   sourceIPv4Address(8)[4]
   destinationIPv4Address(12)[4]
   sourceTransportPort(7)[2]
   destinationTransportPort(11)[2]
   protocolIdentifier(4)[1]
   octetDeltaCount(1)[8]

                   Figure 8: Input template for examples

This isn't really a figure.


 


   The data records given as input to the examples in this section are
   shown below, in the format "flowStartMilliseconds-flowEndMilliseconds
   sourceIPv4Address:sourceTransportPort -> destinationIPv4Address:



Trammell, et al.        Expires December 29, 2012              [Page 31]

Internet-Draft              IPFIX Aggregation                  June 2012


   destinationTransportPort (protocolIdentifier) octetDeltaCount";
   timestamps are given in H:MM:SS.sss format.

This text should reflect the new format below.


 


start time  end time    source ip4  port  dest ip4       port prt octets
9:00:00.138 9:00:00.138 192.0.2.2   47113 192.0.2.131    53   17     119
9:00:03.246 9:00:03.246 192.0.2.2   22153 192.0.2.131    53   17      83
9:00:00.478 9:00:03.486 192.0.2.2   52420 198.51.100.2   443  6     1637
9:00:07.172 9:00:07.172 192.0.2.3   56047 192.0.2.131    53   17     111
9:00:07.309 9:00:14.861 192.0.2.3   41183 198.51.100.67  80   6    16838
9:00:03.556 9:00:19.876 192.0.2.2   17606 198.51.100.68  80   6    11538
9:00:25.210 9:00:25.210 192.0.2.3   47113 192.0.2.131    53   17     119
9:00:26.358 9:00:30.198 192.0.2.3   48458 198.51.100.133 80   6     2973
9:00:29.213 9:01:00.061 192.0.2.4   61295 198.51.100.2   443  6     8350
9:04:00.207 9:04:04.431 203.0.113.3 41256 198.51.100.133 80   6      778
9:03:59.624 9:04:06.984 203.0.113.3 51662 198.51.100.3   80   6      883
9:00:30.532 9:06:15.402 192.0.2.2   37581 198.51.100.2   80   6    15420
9:06:56.813 9:06:59.821 203.0.113.3 52572 198.51.100.2   443  6     1637
9:06:30.565 9:07:00.261 203.0.113.3 49914 197.51.100.133 80   6      561

s/197.51.100.133/ 198.51.100.133/


 

9:06:55.160 9:07:05.208 192.0.2.2   50824 198.51.100.2   443  6     1899
9:06:49.322 9:07:05.322 192.0.2.3   34597 198.51.100.3   80   6     1284
9:07:05.849 9:07:09.625 203.0.113.3 58907 198.51.100.4   80   6     2670
9:10:45.161 9:10:45.161 192.0.2.4   22478 192.0.2.131    53   17      75
9:10:45.209 9:11:01.465 192.0.2.4   49513 198.51.100.68  80   6     3374
9:10:57.094 9:11:00.614 192.0.2.4   64832 198.51.100.67  80   6      138
9:10:59.770 9:11:02.842 192.0.2.3   60833 198.51.100.69  443  6     2325
9:02:18.390 9:13:46.598 203.0.113.3 39586 198.51.100.17  80   6    11200
9:13:53.933 9:14:06.605 192.0.2.2   19638 198.51.100.3   80   6     2869
9:13:02.864 9:14:08.720 192.0.2.3   40429 198.51.100.4   80   6    18289

                     Figure 9: Input data for examples

This definitely isn't a figure; it's a table. Perhaps it's a table of figures? Ditto umpteen times below.


 


8.1.  Traffic Time-Series per Source

   Aggregating flows by source IP address in time series (i.e., with a
   regular interval) can be used in subsequent heavy-hitter analysis and
   as a source parameter for statistical anomaly detection techniques.
   Here, the Intermediate Aggregation Process imposes an interval,
   aggregates the key to remove all key fields other than the source IP

"the key _fields_" ?

You haven't indicated which fields are the keys.


 

   address, then combines the result into a stream of Aggregated Flows.
   The imposed interval of 5 minutes is longer than the majority of
   flows; for those flows crossing interval boundaries, the entire flow
   is accounted to the interval containing the start time of the flow.

   In this example the Partially Aggregated Flows after each conceptual
   operation in the Intermediate Aggregation Process are shown.  These
   are meant to be illustrative of the conceptual operations only, and
   not to suggest an implementation (indeed, the example shown here
   would not necessarily be the most efficient method for performing



Trammell, et al.        Expires December 29, 2012              [Page 32]

Internet-Draft              IPFIX Aggregation                  June 2012


   these operations).  Subsequent examples will omit the Partially
   Aggregated Flows for brevity.

   The input to this process could be any Flow Record containing a
   source IP address and octet counter; consider for this example the
   template and data from the introduction.  The Intermediate
   Aggregation Process would then output records containing just
   timestamps, source IP, and octetDeltaCount, as in Figure 10.

   flowStartMilliseconds(152)[8]
   flowEndMilliseconds(153)[8]
   sourceIPv4Address(8)[4]
   octetDeltaCount(1)[8]

           Figure 10: Output template for time series per source

   Assume the goal is to get 5-minute (300s) time series of octet counts
   per source IP address.  The aggregation operations would then be
   arranged as in Figure 11.

                    Original Flows
                          |
                          V
              +-----------------------+
              | interval distribution |
              |  * impose uniform     |
              |    300s time interval |
              +-----------------------+
                  |
                  | Partially Aggregated Flows
                  V
   +------------------------+
   |  key aggregation       |
   |   * reduce key to only |
   |     sourceIPv4Address  |
   +------------------------+
                  |
                  | Partially Aggregated Flows
                  V
             +-------------------------+
             |  aggregate combination  |
             |   * sum octetDeltaCount |
             +-------------------------+
                          |
                          V
                  Aggregated Flows

       Figure 11: Aggregation operations for time series per source



Trammell, et al.        Expires December 29, 2012              [Page 33]

Internet-Draft              IPFIX Aggregation                  June 2012


   After the interval distribution step, only the time intervals have
   changed; the Partially Aggregated flows are shown in Figure 12.  Note
   that interval distribution follows the default Start Interval policy;
   that is, the entire flow is accounted to the interval containing the
   flow's start time.

start time  end time    source ip4  port  dest ip4       port prt octets
9:00:00.000 9:05:00.000 192.0.2.2   47113 192.0.2.131    53   17     119
9:00:00.000 9:05:00.000 192.0.2.2   22153 192.0.2.131    53   17      83
9:00:00.000 9:05:00.000 192.0.2.2   52420 198.51.100.2   443  6     1637
9:00:00.000 9:05:00.000 192.0.2.3   56047 192.0.2.131    53   17     111
9:00:00.000 9:05:00.000 192.0.2.3   41183 198.51.100.67  80   6    16838
9:00:00.000 9:05:00.000 192.0.2.2   17606 198.51.100.68  80   6    11538
9:00:00.000 9:05:00.000 192.0.2.3   47113 192.0.2.131    53   17     119
9:00:00.000 9:05:00.000 192.0.2.3   48458 198.51.100.133 80   6     2973
9:00:00.000 9:05:00.000 192.0.2.4   61295 198.51.100.2   443  6     8350
9:00:00.000 9:05:00.000 203.0.113.3 41256 198.51.100.133 80   6      778
9:00:00.000 9:05:00.000 203.0.113.3 51662 198.51.100.3   80   6      883
9:00:00.000 9:05:00.000 192.0.2.2   37581 198.51.100.2   80   6    15420
9:00:00.000 9:05:00.000 203.0.113.3 39586 198.51.100.17  80   6    11200
9:05:00.000 9:10:00.000 203.0.113.3 52572 198.51.100.2   443  6     1637
9:05:00.000 9:10:00.000 203.0.113.3 49914 197.51.100.133 80   6      561
9:05:00.000 9:10:00.000 192.0.2.2   50824 198.51.100.2   443  6     1899
9:05:00.000 9:10:00.000 192.0.2.3   34597 198.51.100.3   80   6     1284
9:05:00.000 9:10:00.000 203.0.113.3 58907 198.51.100.4   80   6     2670
9:10:00.000 9:15:00.000 192.0.2.4   22478 192.0.2.131    53   17      75
9:10:00.000 9:15:00.000 192.0.2.4   49513 198.51.100.68  80   6     3374
9:10:00.000 9:15:00.000 192.0.2.4   64832 198.51.100.67  80   6      138
9:10:00.000 9:15:00.000 192.0.2.3   60833 198.51.100.69  443  6     2325
9:10:00.000 9:15:00.000 192.0.2.2   19638 198.51.100.3   80   6     2869
9:10:00.000 9:15:00.000 192.0.2.3   40429 198.51.100.4   80   6    18289

         Figure 12: Interval imposition for time series per source

   After the key aggregation step, all Flow Keys except the source IP
   address have been discarded, as shown in Figure 13.  This leaves
   duplicate Partially Aggregated flows to be combined in the final
   operation.













Trammell, et al.        Expires December 29, 2012              [Page 34]

Internet-Draft              IPFIX Aggregation                  June 2012


   start time  end time    source ip4  octets
   9:00:00.000 9:05:00.000 192.0.2.2      119
   9:00:00.000 9:05:00.000 192.0.2.2       83
   9:00:00.000 9:05:00.000 192.0.2.2     1637
   9:00:00.000 9:05:00.000 192.0.2.3      111
   9:00:00.000 9:05:00.000 192.0.2.3    16838
   9:00:00.000 9:05:00.000 192.0.2.2    11538
   9:00:00.000 9:05:00.000 192.0.2.3      119
   9:00:00.000 9:05:00.000 192.0.2.3     2973
   9:00:00.000 9:05:00.000 192.0.2.4     8350
   9:00:00.000 9:05:00.000 203.0.113.3    778
   9:00:00.000 9:05:00.000 203.0.113.3    883

The last two entries are missing here:
 

9:00:00.000 9:05:00.000 192.0.2.2   15420
9:00:00.000 9:05:00.000 203.0.113.3 11200

 

   9:05:00.000 9:10:00.000 203.0.113.3   1637
   9:05:00.000 9:10:00.000 203.0.113.3    561
   9:05:00.000 9:10:00.000 192.0.2.2     1899
   9:05:00.000 9:10:00.000 192.0.2.3     1284
   9:05:00.000 9:10:00.000 203.0.113.3   2670
   9:10:00.000 9:15:00.000 192.0.2.4       75
   9:10:00.000 9:15:00.000 192.0.2.4     3374
   9:10:00.000 9:15:00.000 192.0.2.4      138
   9:10:00.000 9:15:00.000 192.0.2.3     2325
   9:10:00.000 9:15:00.000 192.0.2.2     2869
   9:10:00.000 9:15:00.000 192.0.2.3    18289

           Figure 13: Key aggregation for time series per source

   Aggregate combination sums the counters per key and interval; the
   summations of the first two keys and intervals are shown in detail in
   Figure 14.

     9:00:00.000 9:05:00.000 192.0.2.2      119
     9:00:00.000 9:05:00.000 192.0.2.2       83
     9:00:00.000 9:05:00.000 192.0.2.2     1637
     9:00:00.000 9:05:00.000 192.0.2.2    11538
   + 9:00:00.000 9:05:00.000 192.0.2.2    15420
                                          -----
   = 9:00:00.000 9:05:00.000 192.0.2.2    28797

     9:00:00.000 9:05:00.000 192.0.2.3      111
     9:00:00.000 9:05:00.000 192.0.2.3    16838
     9:00:00.000 9:05:00.000 192.0.2.3      119
   + 9:00:00.000 9:05:00.000 192.0.2.3     2973
                                          -----
   = 9:00:00.000 9:05:00.000 192.0.2.3    20041

             Figure 14: Summation during aggregate combination

   Applying this to each set of Partially Aggregated Flows to produce



Trammell, et al.        Expires December 29, 2012              [Page 35]

Internet-Draft              IPFIX Aggregation                  June 2012


   the final Aggregated Flows shown in Figure 15 to be exported by the
   template in Figure 10.

   9:00:00.000-9:05:00.000 192.0.2.2    28797
   9:00:00.000-9:05:00.000 192.0.2.3    20041
   9:00:00.000-9:05:00.000 192.0.2.4     8350
   9:00:00.000-9:05:00.000 203.0.113.3  12861

   9:05:00.000-9:10:00.000 192.0.2.2     1899
   9:05:00.000-9:10:00.000 192.0.2.3     1284
   9:05:00.000-9:10:00.000 203.0.113.3   4868
   9:10:00.000-9:15:00.000 192.0.2.2     2869
   9:10:00.000-9:15:00.000 192.0.2.3    20614
   9:10:00.000-9:15:00.000 192.0.2.4     3587

          Figure 15: Aggregated Flows for time series per source

8.2.  Core Traffic Matrix

   Aggregating flows by source and destination autonomous system number
   in time series is used to generate core traffic matrices.  The core
   traffic matrix provides a view of the state of the routes within a
   network, and can be used for long-term planning of changes to network
   design based on traffic demand.  Here, imposed time intervals are
   generally much longer than active flow timeouts.  The traffic matrix
   is reported in terms of octets, packets, and flows, as each of these
   values may have a subtly different effect on capacity planning.

   This example demonstrates key aggregation using derived keys and
   original flow counting.  While some Original Flows may be generated

NB "original flow" and "Original Flows" ?


 

   by Exporting Processes on forwarding devices, and therefore contain
   the bgpSourceAsNumber and bgpDestinationAsNumber Information
   Elements, Original Flows from Exporting Processes on dedicated
   measurement devices will contain only a destinationIPv[46]Address.

Speculation. s/will/may only/.


 

   For these flows, the Mediator must look up a next hop AS from a IP to

"an IP"


 

   AS table, replacing source and destination addresses with AS numbers.
   The table used in this example is shown in Figure 16.  (Note that due
   to limited example address space, in this example we ignore the
   common practice of routing only blocks of /24 or larger).

   prefix            ASN
   192.0.2.0/25      64496
   192.0.2.128/25    64497
   198.51.100/24     64498
   203.0.113.0/24    64499

              Figure 16: Example Autonomous system number map

   The template for Aggregated Flows produced by this example is shown



Trammell, et al.        Expires December 29, 2012              [Page 36]

Internet-Draft              IPFIX Aggregation                  June 2012


   in Figure 17.

   flowStartMilliseconds(152)[8]
   flowEndMilliseconds(153)[8]
   bgpSourceAsNumber(16)[4]
   bgpDestinationAsNumber(17)[4]
   octetDeltaCount(1)[8]

               Figure 17: Output template for traffic matrix

   Assume the goal is to get 60-minute time series of octet counts per
   source/destination ASN pair.  The aggregation operations would then
   be arranged as in Figure 18.






































Trammell, et al.        Expires December 29, 2012              [Page 37]

Internet-Draft              IPFIX Aggregation                  June 2012


                    Original Flows
                          |
                          V
              +-----------------------+
              | interval distribution |
              |  * impose uniform     |
              |   3600s time interval |
              +-----------------------+
                  |
                  | Partially Aggregated Flows
                  V
   +------------------------+
   |  key aggregation       |
   |  * reduce key to only  |
   |    sourceIPv4Address + |
   |    destIPv4Address     |
   +------------------------+
                  |
                  V
   +------------------------+
   |  key aggregation       |
   |  * replace addresses   |
   |    with ASN from map   |
   +------------------------+
                  |
                  | Partially Aggregated Flows
                  V
             +-------------------------+
             |  aggregate combination  |
             |   * sum octetDeltaCount |
             +-------------------------+
                          |
                          V
                  Aggregated Flows

           Figure 18: Aggregation operations for traffic matrix

   After the interval distribution step, only the time intervals have
   changed; the Partially Aggregated flows are shown in Figure 19.  Note

For clarity, it's worth re-stating that the source data is per Figure 9.


 

   that the flows are identical to those in interval distribution step
   in the previous example, except the chosen interval (1 hour, 3600
   seconds) is different; therefore, all the flows fit into a single
   interval.








Trammell, et al.        Expires December 29, 2012              [Page 38]

Internet-Draft              IPFIX Aggregation                  June 2012


  start time  end time  source ip4  port  dest ip4       port prt octets
  9:00:00     10:00:00  192.0.2.2   47113 192.0.2.131    53   17     119
  9:00:00     10:00:00  192.0.2.2   22153 192.0.2.131    53   17      83
  9:00:00     10:00:00  192.0.2.2   52420 198.51.100.2   443  6     1637
  9:00:00     10:00:00  192.0.2.3   56047 192.0.2.131    53   17     111
  9:00:00     10:00:00  192.0.2.3   41183 198.51.100.67  80   6    16838
  9:00:00     10:00:00  192.0.2.2   17606 198.51.100.68  80   6    11538
  9:00:00     10:00:00  192.0.2.3   47113 192.0.2.131    53   17     119
  9:00:00     10:00:00  192.0.2.3   48458 198.51.100.133 80   6     2973
  9:00:00     10:00:00  192.0.2.4   61295 198.51.100.2   443  6     8350
  9:00:00     10:00:00  203.0.113.3 41256 198.51.100.133 80   6      778
  9:00:00     10:00:00  203.0.113.3 51662 198.51.100.3   80   6      883
  9:00:00     10:00:00  192.0.2.2   37581 198.51.100.2   80   6    15420
  9:00:00     10:00:00  203.0.113.3 52572 198.51.100.2   443  6     1637
  9:00:00     10:00:00  203.0.113.3 49914 197.51.100.133 80   6      561
  9:00:00     10:00:00  192.0.2.2   50824 198.51.100.2   443  6     1899
  9:00:00     10:00:00  192.0.2.3   34597 198.51.100.3   80   6     1284
  9:00:00     10:00:00  203.0.113.3 58907 198.51.100.4   80   6     2670
  9:00:00     10:00:00  192.0.2.4   22478 192.0.2.131    53   17      75
  9:00:00     10:00:00  192.0.2.4   49513 198.51.100.68  80   6     3374
  9:00:00     10:00:00  192.0.2.4   64832 198.51.100.67  80   6      138
  9:00:00     10:00:00  192.0.2.3   60833 198.51.100.69  443  6     2325
  9:00:00     10:00:00  203.0.113.3 39586 198.51.100.17  80   6    11200
  9:00:00     10:00:00  192.0.2.2   19638 198.51.100.3   80   6     2869
  9:00:00     10:00:00  192.0.2.3   40429 198.51.100.4   80   6    18289

             Figure 19: Interval imposition for traffic matrix

   The next step is to discard irrelevant key fields, and replace the
   source and destination addresses with source and destination AS

Per Figure 18, that's two steps.

NB the way it's written sounds like "get rid of X and replace it with Y", rather than the intended "get rid of X, then replace Y with Z".


 

   numbers in the map; the results of these key aggregation steps are
   shown in Figure 20.



















Trammell, et al.        Expires December 29, 2012              [Page 39]

Internet-Draft              IPFIX Aggregation                  June 2012


   start time  end time  source ASN  dest ASN  octets
   9:00:00     10:00:00  AS64496     AS64497      119
   9:00:00     10:00:00  AS64496     AS64497       83
   9:00:00     10:00:00  AS64496     AS64498     1637
   9:00:00     10:00:00  AS64496     AS64497      111
   9:00:00     10:00:00  AS64496     AS64498    16838
   9:00:00     10:00:00  AS64496     AS64498    11538
   9:00:00     10:00:00  AS64496     AS64497      119
   9:00:00     10:00:00  AS64496     AS64498     2973
   9:00:00     10:00:00  AS64496     AS64498     8350
   9:00:00     10:00:00  AS64499     AS64498      778
   9:00:00     10:00:00  AS64499     AS64498      883
   9:00:00     10:00:00  AS64496     AS64498    15420
   9:00:00     10:00:00  AS64499     AS64498     1637
   9:00:00     10:00:00  AS64499     AS64498      561
   9:00:00     10:00:00  AS64496     AS64498     1899
   9:00:00     10:00:00  AS64496     AS64498     1284
   9:00:00     10:00:00  AS64499     AS64498     2670
   9:00:00     10:00:00  AS64496     AS64497       75
   9:00:00     10:00:00  AS64496     AS64498     3374
   9:00:00     10:00:00  AS64496     AS64498      138
   9:00:00     10:00:00  AS64496     AS64498     2325
   9:00:00     10:00:00  AS64499     AS64498    11200
   9:00:00     10:00:00  AS64496     AS64498     2869
   9:00:00     10:00:00  AS64496     AS64498    18289

       Figure 20: Key aggregation for traffic matrix: reduction and
                                replacement

   Finally, aggregate combination sums the counters per key and
   interval.  The resulting Aggregated Flows containing the traffic
   matrix, shown in Figure 21, are then exported using the template in
   Figure 17.  Note that these aggregated flows represent a sparse
   matrix: AS pairs for which no traffic was received have no
   corresponding record in the output.

   start time  end time  source ASN  dest ASN  octets
   9:00:00     10:00:00  AS64496     AS64497      507
   9:00:00     10:00:00  AS64496     AS64498    86934
   9:00:00     10:00:00  AS64499     AS64498    17729

              Figure 21: Aggregated Flows for traffic matrix

   The output of this operation is suitable for re-aggregation: that is,
   traffic matrices from single links or observarion points can be

s/observarion/observation/


 

   aggregated through the same interval imposition and aggregate
   combination steps in order to build a traffic matrix for an entire
   network.



Trammell, et al.        Expires December 29, 2012              [Page 40]

Internet-Draft              IPFIX Aggregation                  June 2012


8.3.  Distinct Source Count per Destination Endpoint

   Aggregating flows by destination address and port, and counting
   distinct sources aggregated away, can be used as part of passive
   service inventory and host characterization approaches.  This example

What are "host characterization approaches"?

Did you mean "host characterization methodologies", or just "host characterization" ?


 

   shows aggregation as an analysis technique, performed on source data
   stored in an IPFIX File.  As the Transport Session in this File is
   bounded, removal of all timestamp information allows summarization of
   the entire time interval contained within the interval.  Removal of
   timing information during interval imposition is equivalent to an
   infinitely long imposed time interval.  This demonstrates both how
   infinite intervals work, and how unique counters work.  The
   aggregation operations are summarized in Figure 22.






































Trammell, et al.        Expires December 29, 2012              [Page 41]

Internet-Draft              IPFIX Aggregation                  June 2012


                    Original Flows
                          |
                          V
              +-----------------------+
              | interval distribution |
              |  * discard timestamps |
              +-----------------------+
                  |
                  | Partially Aggregated Flows
                  V
   +----------------------------+
   |  value aggregation         |
   |  * discard octetDeltaCount |
   +----------------------------+
                  |
                  | Partially Aggregated Flows
                  V
   +----------------------------+
   |  key aggregation           |
   |   * reduce key to only     |
   |     destIPv4Address +      |
   |     destTransportPort,     |
   |   * count distinct sources |
   +----------------------------+
                  |
                  | Partially Aggregated Flows
                  V
       +----------------------------------------------+
       |  aggregate combination                       |
       |   * no-op (distinct sources already counted) |
       +----------------------------------------------+
                          |
                          V
                  Aggregated Flows

            Figure 22: Aggregation operations for source count

   The template for Aggregated Flows produced by this example is shown
   in Figure 23.

   destinationIPv4Address(12)[4]
   destinationTransportPort(11)[2]
   distinctCountOfSourceIPAddress(TBD4)[8]

                Figure 23: Output template for source count

   Interval distribution, in this case, merely discards the timestamp
   information from the Original Flows, and as such is not shown.



Trammell, et al.        Expires December 29, 2012              [Page 42]

Internet-Draft              IPFIX Aggregation                  June 2012


   Likewise, the value aggregation step simply discards the
   octetDeltaCount value field.  The key aggregation step reduces the
   key to the destinationIPv4Address and destinationTransportPort,
   counting the distinct source addresses.  Since this is essentially
   the output of this aggregation function, the aggregate combination
   operation is a no-op; the resulting Aggregated Flows are shown in
   Figure 24.

Once again, it's worth re-stating that again, the data from Figure 9 (or table X, whichever) is the source data.


 


   dest ip4       port  dist src
   192.0.2.131    53           3
   198.51.100.2   80           1
   198.51.100.2   443          3
   198.51.100.67  80           2
   198.51.100.68  80           2
   198.51.100.133 80           2
   198.51.100.3   80           3
   198.51.100.4   80           2
   198.51.100.17  80           1
   198.51.100.69  443          1

This table seems to be completely wrong. Even the total counts is wrong - ie, add up the "dist src" = 20. Yet Figure 9 has 24 entries.

I think it should be:

198.51.100.17    80    4
198.51.100.2     80    1
198.51.100.2    443    4
198.51.100.3     80    3
198.51.100.4     80    2
198.51.100.68    80    4
198.51.100.69   443    1

I had serious deja vu here. I thought I had pointed this out already? Am I reviewing the wrong draft again?


 


               Figure 24: Aggregated flows for source count

8.4.  Traffic Time-Series per Source with Counter Distribution

   Returning to the example in Section 8.1, note that our source data
   contains some flows with durations longer than the imposed interval
   of five minutes.  The default method for dealing with such flows is
   to account them to the interval containing the flow's start time.

   In this example, the same data is aggregated using the same
   arrangement of operations and the same output template as the as in
   Section 8.1, but using a different counter distribution policy,
   Simple Uniform Distribution, as described in Section 5.1.1.  In order
   to do this, the Exporting Process first exports the Aggregate Counter
   Distribution Options Template, as in Figure 25.

   templateId(12)[2]{scope}
   valueDistribtutionMethod(TBD10)[1]

s/valueDistribtutionMethod/valueDistributionMethod/


 


        Figure 25: Aggregate Counter Distribution Options Template

   This is followed by an Aggregate Counter Distribution Record
   described by this Template; assuming the output template in Figure 10
   has ID 257, this would appear as in Figure 26.

There are too many "this" here to understand.


 


   templateId 257: valueDistributionMethod 4 (Simple Uniform)

Where is the figure?


 


             Figure 26: Aggregate Counter Distribution Record



Trammell, et al.        Expires December 29, 2012              [Page 43]

Internet-Draft              IPFIX Aggregation                  June 2012


   Following metadata export, the aggregation steps follow as before.
   However, two long flows are distributed across multiple intervals in
   the interval imposition step, as indicated with "*" in Figure 27.

It might help to use *1 and *2 to distinguish the two flows.


 

   Note the uneven distribution of the three-interval, 11200-octet flow
   into three Partially Aggregated Flows of 3733, 3733, and 3734 octets;
   this ensures no cumulative error is injected by the interval
   distribution step.

start time  end time    source ip4  port  dest ip4       port prt octets
9:00:00.000 9:05:00.000 192.0.2.2   47113 192.0.2.131    53   17     119
9:00:00.000 9:05:00.000 192.0.2.2   22153 192.0.2.131    53   17      83
9:00:00.000 9:05:00.000 192.0.2.2   52420 198.51.100.2   443  6     1637
9:00:00.000 9:05:00.000 192.0.2.3   56047 192.0.2.131    53   17     111
9:00:00.000 9:05:00.000 192.0.2.3   41183 198.51.100.67  80   6    16838
9:00:00.000 9:05:00.000 192.0.2.2   17606 198.51.100.68  80   6    11538
9:00:00.000 9:05:00.000 192.0.2.3   47113 192.0.2.131    53   17     119
9:00:00.000 9:05:00.000 192.0.2.3   48458 198.51.100.133 80   6     2973
9:00:00.000 9:05:00.000 192.0.2.4   61295 198.51.100.2   443  6     8350
9:00:00.000 9:05:00.000 203.0.113.3 41256 198.51.100.133 80   6      778
9:00:00.000 9:05:00.000 203.0.113.3 51662 198.51.100.3   80   6      883
9:00:00.000 9:05:00.000 192.0.2.2   37581 198.51.100.2   80   6     7710 *
9:00:00.000 9:05:00.000 203.0.113.3 39586 198.51.100.17  80   6     3733 *
9:05:00.000 9:10:00.000 203.0.113.3 52572 198.51.100.2   443  6     1637
9:05:00.000 9:10:00.000 203.0.113.3 49914 197.51.100.133 80   6      561
9:05:00.000 9:10:00.000 192.0.2.2   50824 198.51.100.2   443  6     1899
9:05:00.000 9:10:00.000 192.0.2.3   34597 198.51.100.3   80   6     1284
9:05:00.000 9:10:00.000 203.0.113.3 58907 198.51.100.4   80   6     2670
9:05:00.000 9:10:00.000 192.0.2.2   37581 198.51.100.2   80   6     7710 *
9:05:00.000 9:10:00.000 203.0.113.3 39586 198.51.100.17  80   6     3733 *
9:10:00.000 9:15:00.000 192.0.2.4   22478 192.0.2.131    53   17      75
9:10:00.000 9:15:00.000 192.0.2.4   49513 198.51.100.68  80   6     3374
9:10:00.000 9:15:00.000 192.0.2.4   64832 198.51.100.67  80   6      138
9:10:00.000 9:15:00.000 192.0.2.3   60833 198.51.100.69  443  6     2325
9:10:00.000 9:15:00.000 192.0.2.2   19638 198.51.100.3   80   6     2869
9:10:00.000 9:15:00.000 192.0.2.3   40429 198.51.100.4   80   6    18289
9:10:00.000 9:15:00.000 203.0.113.3 39586 198.51.100.17  80   6     3734 *

   Figure 27: Distirbuted interval imposition for time series per source

s/Distirbuted/Distributed/


 


   Subsequent steps are as in Section 8.1; the results, to be exported
   using Figure 10, are shown in Figure 28, with Aggregated Flows

"using the template shown in Figure 10".


 

   differing from the example in Section 8.1 indicated by "*".









Trammell, et al.        Expires December 29, 2012              [Page 44]

Internet-Draft              IPFIX Aggregation                  June 2012


   start time  end time    source ip4  octets
   9:00:00.000 9:05:00.000 192.0.2.2    21087 *
   9:00:00.000 9:05:00.000 192.0.2.3    20041
   9:00:00.000 9:05:00.000 192.0.2.4     8350
   9:00:00.000 9:05:00.000 203.0.113.3   9394 *

9394 should be 778 + 883 + 3733 = 5394.


 

   9:05:00.000 9:10:00.000 192.0.2.2     9609 *
   9:05:00.000 9:10:00.000 192.0.2.3     1284
   9:05:00.000 9:10:00.000 203.0.113.3   8601 *
   9:10:00.000 9:15:00.000 192.0.2.2     2869
   9:10:00.000 9:15:00.000 192.0.2.3    20594

20594 should be 2325 + 18289 = 20614.


 

   9:10:00.000 9:15:00.000 192.0.2.4     3587
   9:10:00.000 9:15:00.000 203.0.113.3   3734 *

As a check, the total octets in this figure is 109150, whereas the total in Figure 27 is 105170.
With the modified figures I've shown above, the two totals agree.


 


    Figure 28: Aggregated Flows for time series per source with counter
                               distribution


9.  Security Considerations

   This document specifies the operation of an Intermediate Aggregation
   Process with the IPFIX Protocol; the Security Considerations for the
   protocol itself in Section 11 [RFC-EDITOR NOTE: verify section
   number] of [I-D.ietf-ipfix-protocol-rfc5101bis] therefore apply.  In
   the common case that aggregation is performed on a Mediator, the
   Security Considerations for Mediators in Section 9 of [RFC6183] apply
   as well.

   As mentioned in Section 3, certain aggregation operations may tend to
   have an anyonymizing effect on flow data by obliterating sensitive

s/anyonymizing/anonymizing/


 

   identifiers.  Aggregation may also be combined with anonymization
   within a Mediator, or as part of a chain of Mediators, to further
   leverage this effect.  In any case in which an Intermediate
   Aggregation Process is applied as part of a data anonymization or
   protection scheme, or is used together with anonymization as
   described in [RFC6235], the Security Considerations in Section 9 of
   [RFC6235] apply.


10.  IANA Considerations

   This document specifies the creation of new IPFIX Information
   Elements in the IPFIX Information Element registry located at
   http://www.iana.org/assignments/ipfix, as defined in Section 7 above.
   IANA has assigned Information Element numbers to these Information
   Elements, and entered them into the registry.

   [NOTE for IANA: The text TBDn should be replaced with the respective
   assigned Information Element numbers where they appear in this



Trammell, et al.        Expires December 29, 2012              [Page 45]

Internet-Draft              IPFIX Aggregation                  June 2012


   document.  Note that the deltaFlowCount Information Element has been
   assigned the number 3, as it is compatible with the corresponding
   existing (reserved) NetFlow v9 Information Element.  Other
   Information Element numbers should be assigned outside the NetFlow V9
   compatibility range, as these Information Elements are not supported
   by NetFlow V9.]


11.  Acknowledgments

   Special thanks to Elisa Boschi for early work on the concepts laid
   out in this document.  Thanks to Paul Aitken, Lothar Braun, Christian
   Henke, and Rahul Patel for their reviews and valuable feedback.  This
   work is materially supported by the European Union Seventh Framework
   Programme under grant agreement 257315 (DEMONS).


12.  References

12.1.  Normative References

   [I-D.ietf-ipfix-protocol-rfc5101bis]
              Claise, B. and B. Trammell, "Specification of the IP Flow
              Information eXport (IPFIX) Protocol for the Exchange of
              Flow Information", draft-ietf-ipfix-protocol-rfc5101bis-01
              (work in progress), March 2012.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

12.2.  Informative References

   [RFC3917]  Quittek, J., Zseby, T., Claise, B., and S. Zander,
              "Requirements for IP Flow Information Export (IPFIX)",
              RFC 3917, October 2004.

   [RFC5103]  Trammell, B. and E. Boschi, "Bidirectional Flow Export
              Using IP Flow Information Export (IPFIX)", RFC 5103,
              January 2008.

   [RFC5153]  Boschi, E., Mark, L., Quittek, J., Stiemerling, M., and P.
              Aitken, "IP Flow Information Export (IPFIX) Implementation
              Guidelines", RFC 5153, April 2008.

   [RFC5470]  Sadasivan, G., Brownlee, N., Claise, B., and J. Quittek,
              "Architecture for IP Flow Information Export", RFC 5470,
              March 2009.




Trammell, et al.        Expires December 29, 2012              [Page 46]

Internet-Draft              IPFIX Aggregation                  June 2012


   [RFC5472]  Zseby, T., Boschi, E., Brownlee, N., and B. Claise, "IP
              Flow Information Export (IPFIX) Applicability", RFC 5472,
              March 2009.

   [RFC5476]  Claise, B., Johnson, A., and J. Quittek, "Packet Sampling
              (PSAMP) Protocol Specifications", RFC 5476, March 2009.

   [RFC5610]  Boschi, E., Trammell, B., Mark, L., and T. Zseby,
              "Exporting Type Information for IP Flow Information Export
              (IPFIX) Information Elements", RFC 5610, July 2009.

   [RFC5655]  Trammell, B., Boschi, E., Mark, L., Zseby, T., and A.
              Wagner, "Specification of the IP Flow Information Export
              (IPFIX) File Format", RFC 5655, October 2009.

   [RFC5835]  Morton, A. and S. Van den Berghe, "Framework for Metric
              Composition", RFC 5835, April 2010.

   [RFC5982]  Kobayashi, A. and B. Claise, "IP Flow Information Export
              (IPFIX) Mediation: Problem Statement", RFC 5982,
              August 2010.

   [RFC6183]  Kobayashi, A., Claise, B., Muenz, G., and K. Ishibashi,
              "IP Flow Information Export (IPFIX) Mediation: Framework",
              RFC 6183, April 2011.

   [RFC6235]  Boschi, E. and B. Trammell, "IP Flow Anonymization
              Support", RFC 6235, May 2011.

   [I-D.ietf-ipfix-mediation-protocol]
              Claise, B., Kobayashi, A., and B. Trammell, "Operation of
              the IP Flow Information Export (IPFIX) Protocol on IPFIX
              Mediators", draft-ietf-ipfix-mediation-protocol-01 (work
              in progress), June 2012.

   [I-D.ietf-ipfix-ie-doctors]
              Trammell, B. and B. Claise, "Guidelines for Authors and
              Reviewers of IPFIX Information Elements",
              draft-ietf-ipfix-ie-doctors-03 (work in progress),
              June 2012.

   [I-D.ietf-ipfix-configuration-model]
              Muenz, G., Claise, B., and P. Aitken, "Configuration Data
              Model for IPFIX and PSAMP",
              draft-ietf-ipfix-configuration-model-11 (work in
              progress), June 2012.

   [I-D.ietf-ipfix-flow-selection-tech]



Trammell, et al.        Expires December 29, 2012              [Page 47]

Internet-Draft              IPFIX Aggregation                  June 2012


              D'Antonio, S., Zseby, T., Henke, C., and L. Peluso, "Flow
              Selection Techniques",
              draft-ietf-ipfix-flow-selection-tech-11 (work in
              progress), April 2012.

   [iana-ipfix-assignments]
              Internet Assigned Numbers Authority, "IP Flow Information
              Export Information Elements
              (http://www.iana.org/assignments/ipfix/ipfix.xml)".


Authors' Addresses

   Brian Trammell
   Swiss Federal Institute of Technology Zurich
   Gloriastrasse 35
   8092 Zurich
   Switzerland

   Phone: +41 44 632 70 13
   Email: trammell@tik.ee.ethz.ch


   Arno Wagner
   Consecom AG
   Bleicherweg 64a
   8002 Zurich
   Switzerland

   Email: arno@wagner.name


   Benoit Claise
   Cisco Systems, Inc.
   De Kleetlaan 6a b1
   1831 Diagem

Once again, in existing RFCs - and in Cisco's internal directory - this is "Diegem 1831".


 

   Belgium

   Phone: +32 2 704 5622
   Email: bclaise@cisco.com











Trammell, et al.        Expires December 29, 2012              [Page 48]

--------------030603030609090505000903-- From hs@123.org Mon Jul 16 05:27: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 161FC21F86EA for ; Mon, 16 Jul 2012 05:27:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4AX76IJlU6Yp for ; Mon, 16 Jul 2012 05:27:54 -0700 (PDT) Received: from mo6-p05-ob.rzone.de (mo6-p05-ob.rzone.de [IPv6:2a01:238:20a:202:5305::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A31721F86E2 for ; Mon, 16 Jul 2012 05:27:54 -0700 (PDT) X-RZG-AUTH: :JH8HfU+kYd9xQ6m0ynnj9hHxvZXYXks+pm8dQxa2PdmCs29qNyJDXGPSHqedfmnO X-RZG-CLASS-ID: mo05 Received: from [192.168.1.207] ([213.218.5.34]) by smtp.strato.de (jored mo78) (RZmta 29.19 DYNA|AUTH) with ESMTPA id P01401o6GCB6rN for ; Mon, 16 Jul 2012 14:28:38 +0200 (CEST) Message-ID: <500408F6.9080003@123.org> Date: Mon, 16 Jul 2012 14:28:38 +0200 From: Hendrik Scholz User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:13.0) Gecko/20120615 Thunderbird/13.0.1 MIME-Version: 1.0 To: ipfix@ietf.org References: <50040877.8040400@123.org> In-Reply-To: <50040877.8040400@123.org> X-Forwarded-Message-Id: <50040877.8040400@123.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [IPFIX] Transport of I.D-xrblock-rtcp-xr-qoe style quality data 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, 16 Jul 2012 12:27:55 -0000 Hi, I've published draft-scholz-ipfix-rtp-audio-quality-00 which contains Information Elements for IPFIX to transport audio quality information. I am in touch with xrblock to have a look at the data and also update my draft to fix a multi channel issue which still has to be solved in the xrblock draft this is based on. Just FYI, Hendrik -- Hendrik Scholz From andrewf@plixer.com Mon Jul 16 08:19: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 8AF8111E8085 for ; Mon, 16 Jul 2012 08:19:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[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 ztdfBJTV+k7q for ; Mon, 16 Jul 2012 08:19:03 -0700 (PDT) Received: from smtp.plixer.com (smtp.plixer.com [66.186.184.193]) by ietfa.amsl.com (Postfix) with ESMTP id BD62511E8079 for ; Mon, 16 Jul 2012 08:19:02 -0700 (PDT) Received: from [10.100.1.132] ([65.175.140.2]) by smtp.plixer.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Mon, 16 Jul 2012 11:19:46 -0400 Message-ID: <50043112.90003@plixer.com> Date: Mon, 16 Jul 2012 11:19:46 -0400 From: Andrew Feren User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:16.0) Gecko/16.0 Thunderbird/16.0a1 MIME-Version: 1.0 To: IETF IPFIX Working Group Content-Type: multipart/alternative; boundary="------------080503020907000601080207" X-OriginalArrivalTime: 16 Jul 2012 15:19:46.0834 (UTC) FILETIME=[6F46D720:01CD6366] Subject: [IPFIX] initiatorOctets and responderOctets confusion 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, 16 Jul 2012 15:19:04 -0000 This is a multi-part message in MIME format. --------------080503020907000601080207 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi All, I was just looking at initiatorOctets (231) and responderOctets (232) on IANA's assignments page and I noticed a couple of issues. There are no sematics given. We should have the correct semantics added. I had thought the semantics would be deltaCounter (like octetDeltaCount), but the descriptions talk about "[t]he total number of layer 4 payload bytes in a flow [...]". I hope I am reading that incorrectly because if the semantics are not deltaCounter then section 4.10 in ie-doctors needs to be revisited. Is deltaCounter the correct semantics? Should the description be closer to the octetDeltaCount description? Something like: "The number of octets since the previous report (if any) in incoming packets from the initiator for this Flow at the Observation Point. The number of octets includes IP header(s) and IP payload. The initiator is the device which triggered the session creation, and remains the same for the life of the session." Same questions for initiatorPackets (298) and responderPackets (299). -Andrew --------------080503020907000601080207 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi All,

I was just looking at initiatorOctets (231) and responderOctets (232) on IANA's assignments page and I noticed a couple of issues.

There are no sematics given.  We should have the correct semantics added.  I had thought the semantics would be deltaCounter (like octetDeltaCount), but the descriptions talk about "[t]he total number of layer 4 payload bytes in a flow [...]".  I hope I am reading that incorrectly because if the semantics are not deltaCounter then section 4.10 in ie-doctors needs to be revisited.

Is deltaCounter the correct semantics?

Should the description be closer to the octetDeltaCount description?  Something like: 
"The number of octets since the previous report (if any) in incoming packets from the initiator for this Flow at the Observation Point.  The number of octets includes IP header(s) and IP payload. The initiator is the device which triggered the session creation, and remains the same for the life of the session."

Same questions for initiatorPackets (298) and responderPackets (299).

-Andrew
--------------080503020907000601080207-- From andrewf@plixer.com Mon Jul 16 12: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 B44C921F8731 for ; Mon, 16 Jul 2012 12:50:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.001, 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 HsY1CyWZosWp for ; Mon, 16 Jul 2012 12:50:03 -0700 (PDT) Received: from smtp.plixer.com (smtp.plixer.com [66.186.184.193]) by ietfa.amsl.com (Postfix) with ESMTP id 60C7A21F871A for ; Mon, 16 Jul 2012 12:50:03 -0700 (PDT) Received: from [10.100.1.132] ([65.175.140.2]) by smtp.plixer.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Mon, 16 Jul 2012 15:50:48 -0400 Message-ID: <50047098.4050402@plixer.com> Date: Mon, 16 Jul 2012 15:50:48 -0400 From: Andrew Feren User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:16.0) Gecko/16.0 Thunderbird/16.0a1 MIME-Version: 1.0 To: ipfix@ietf.org References: <201206111440.q5BEe6ps030247@smtp1.lax.icann.org> <4FDFB4DC.2010106@auckland.ac.nz> In-Reply-To: <4FDFB4DC.2010106@auckland.ac.nz> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 16 Jul 2012 19:50:48.0507 (UTC) FILETIME=[4BFD38B0:01CD638C] Subject: Re: [IPFIX] [IANA #579482] General Request for Assignment (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: Mon, 16 Jul 2012 19:50:04 -0000 Are the semantics for these really "identifier"? -Andrew On 06/18/2012 07:08 PM, Nevil Brownlee wrote: > > Hi again Amanda: > > These four have been discussed on the IPFIX list, they're OK as > submitted. They'll be > > 361 portRangeStart > 362 portRangeEnd > 363 portRangeStepSize > 364 portRangeNumPorts > > Cheers, Nevil > > > On 12/06/12 8:51 AM, Amanda Baber via RT wrote: >> Hi Nevil, >> >> Here's Paul's second request. >> >> thanks, >> Amanda >> >> === >> >> Contact Name: >> Paul Aitken >> >> Contact Email: >> paitken@cisco.com >> >> Type of Assignment: >> IPFIX Information Elements >> >> Registry: >> http://www.iana.org/assignments/ipfix/ipfix.xml#ipfix-information-elements >> >> >> Description: >> Please allocate the four new fields specified below, which may be used >> in various combinations to specify port ranges in IPFIX. >> >> Additional Info: >> Name: portRangeStart >> Type: unsigned16 >> Semantics: identifier >> Description: The port number identifying the start of a range of ports. >> A value of zero indicates that the range start is not specified, ie the >> range is defined in some other way. >> Additional information on defined TCP port numbers can be found at [IANA >> registry port-numbers]. >> >> Name: portRangeEnd >> Type: unsigned16 >> Semantics: identifier >> Description: The port number identifying the end of a range of ports. >> A value of zero indicates that the range end is not specified, ie the >> range is defined in some other way. >> Additional information on defined TCP port numbers can be found at [IANA >> registry port-numbers]. >> >> Name: portRangeStepSize >> Type: unsigned16 >> Semantics: identifier >> Description: The step size in a port range. The default step size is 1, >> which indicates contiguous ports. >> A value of zero indicates that the step size is not specified, ie the >> range is defined in some other way. >> >> Name: portRangeNumPorts >> Type: unsigned16 >> Semantics: identifier >> Description: The number of ports in a port range. >> A value of zero indicates that the number of ports is not specified, ie >> the range is defined in some other way. > > From paitken@cisco.com Mon Jul 16 13:21:09 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 23CCD21F8666 for ; Mon, 16 Jul 2012 13:21:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.349 X-Spam-Level: X-Spam-Status: No, score=-10.349 tagged_above=-999 required=5 tests=[AWL=0.250, 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 4IqQlqBSPUbm for ; Mon, 16 Jul 2012 13:21:08 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id 069AF21F8608 for ; Mon, 16 Jul 2012 13:21:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=paitken@cisco.com; l=3225; q=dns/txt; s=iport; t=1342470113; x=1343679713; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=pa/Dtqnfomc4Lza+pSGNCRsXUDA9ZEilc9E9wmGSnps=; b=jLfykoFQJp0G4y+8ZGMuygcoZkNPALtkLXHyyCBLHpIdSHLO2ew5fG0o b/jXrF6UaaB4MBkAwTlqolEApVdTy7nEZBSMo8LR3LGIq9L9t9VV67mfe ZpmvIMG5+PiuYF5e8MZhyHSc54DlRkcuzze/GlW9sbnFvuSOjXDLjMZzd o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAI53BFCQ/khN/2dsb2JhbABFuVGBB4IgAQEBAwEBAQEPASU2CgEFCwsYCRYPCQMCAQIBFTAGDQEFAgEBBRmHZQYLm2uRHY51i0CGRwOVO4VWiEqBZoJggV4 X-IronPort-AV: E=Sophos;i="4.77,596,1336348800"; d="scan'208";a="141209737" Received: from ams-core-4.cisco.com ([144.254.72.77]) by ams-iport-1.cisco.com with ESMTP; 16 Jul 2012 20:21:52 +0000 Received: from [10.61.86.113] (ams3-vpn-dhcp5746.cisco.com [10.61.86.113]) by ams-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id q6GKLqch018792; Mon, 16 Jul 2012 20:21:52 GMT Message-ID: <500477E0.5090402@cisco.com> Date: Mon, 16 Jul 2012 21:21:52 +0100 From: Paul Aitken User-Agent: Mozilla/5.0 (X11; Linux i686; rv:12.0) Gecko/20120430 Thunderbird/12.0.1 MIME-Version: 1.0 To: Andrew Feren References: <201206111440.q5BEe6ps030247@smtp1.lax.icann.org> <4FDFB4DC.2010106@auckland.ac.nz> <50047098.4050402@plixer.com> In-Reply-To: <50047098.4050402@plixer.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: ipfix@ietf.org Subject: Re: [IPFIX] [IANA #579482] General Request for Assignment (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: Mon, 16 Jul 2012 20:21:09 -0000 Andrew, > Are the semantics for these really "identifier"? Per RFC5610 and RFC6313, there are just 7 semantics to choose from. See http://www.iana.org/assignments/ipfix/ipfix.xml#ipfix-information-element-semantics. Note that a standards action is required to introduce new semantics. 361 and 362 are port numbers. Notice that the semantics for all the other port elements (sourceTransportPort, destinationTransportPort, udpSourcePort, udpDestinationPort, tcpSourcePort, tcpDestinationPort, collectorTransportPort, exporterTransportPort, postNAPTSourceTransportPort, and postNAPTDestinationTransportPort) are all "identifier", since the value identifies a port. 363 and 364 are simple numbers. If "identifier" is not appropriate for these, then "default" is the only other possibility. P. > On 06/18/2012 07:08 PM, Nevil Brownlee wrote: >> >> Hi again Amanda: >> >> These four have been discussed on the IPFIX list, they're OK as >> submitted. They'll be >> >> 361 portRangeStart >> 362 portRangeEnd >> 363 portRangeStepSize >> 364 portRangeNumPorts >> >> Cheers, Nevil >> >> >> On 12/06/12 8:51 AM, Amanda Baber via RT wrote: >>> Hi Nevil, >>> >>> Here's Paul's second request. >>> >>> thanks, >>> Amanda >>> >>> === >>> >>> Contact Name: >>> Paul Aitken >>> >>> Contact Email: >>> paitken@cisco.com >>> >>> Type of Assignment: >>> IPFIX Information Elements >>> >>> Registry: >>> http://www.iana.org/assignments/ipfix/ipfix.xml#ipfix-information-elements >>> >>> >>> Description: >>> Please allocate the four new fields specified below, which may be used >>> in various combinations to specify port ranges in IPFIX. >>> >>> Additional Info: >>> Name: portRangeStart >>> Type: unsigned16 >>> Semantics: identifier >>> Description: The port number identifying the start of a range of ports. >>> A value of zero indicates that the range start is not specified, ie the >>> range is defined in some other way. >>> Additional information on defined TCP port numbers can be found at >>> [IANA >>> registry port-numbers]. >>> >>> Name: portRangeEnd >>> Type: unsigned16 >>> Semantics: identifier >>> Description: The port number identifying the end of a range of ports. >>> A value of zero indicates that the range end is not specified, ie the >>> range is defined in some other way. >>> Additional information on defined TCP port numbers can be found at >>> [IANA >>> registry port-numbers]. >>> >>> Name: portRangeStepSize >>> Type: unsigned16 >>> Semantics: identifier >>> Description: The step size in a port range. The default step size is 1, >>> which indicates contiguous ports. >>> A value of zero indicates that the step size is not specified, ie the >>> range is defined in some other way. >>> >>> Name: portRangeNumPorts >>> Type: unsigned16 >>> Semantics: identifier >>> Description: The number of ports in a port range. >>> A value of zero indicates that the number of ports is not specified, ie >>> the range is defined in some other way. >> >> > > _______________________________________________ > IPFIX mailing list > IPFIX@ietf.org > https://www.ietf.org/mailman/listinfo/ipfix From andrewf@plixer.com Mon Jul 16 13:42: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 C253211E82B0 for ; Mon, 16 Jul 2012 13:42:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.953 X-Spam-Level: X-Spam-Status: No, score=-1.953 tagged_above=-999 required=5 tests=[AWL=-0.646, BAYES_00=-2.599, MISSING_HEADERS=1.292] 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 mMVW9zOBgFYH for ; Mon, 16 Jul 2012 13:42:33 -0700 (PDT) Received: from smtp.plixer.com (smtp.plixer.com [66.186.184.193]) by ietfa.amsl.com (Postfix) with ESMTP id C33AB11E80F0 for ; Mon, 16 Jul 2012 13:42:32 -0700 (PDT) Received: from [10.100.1.132] ([65.175.140.2]) by smtp.plixer.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Mon, 16 Jul 2012 16:43:18 -0400 Message-ID: <50047CE5.3080100@plixer.com> Date: Mon, 16 Jul 2012 16:43:17 -0400 From: Andrew Feren User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:16.0) Gecko/16.0 Thunderbird/16.0a1 MIME-Version: 1.0 CC: ipfix@ietf.org References: <201206111440.q5BEe6ps030247@smtp1.lax.icann.org> <4FDFB4DC.2010106@auckland.ac.nz> <50047098.4050402@plixer.com> <500477E0.5090402@cisco.com> In-Reply-To: <500477E0.5090402@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 16 Jul 2012 20:43:18.0069 (UTC) FILETIME=[A1463E50:01CD6393] Subject: Re: [IPFIX] [IANA #579482] General Request for Assignment (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: Mon, 16 Jul 2012 20:42:34 -0000 Hi Paul, On 07/16/2012 04:21 PM, Paul Aitken wrote: > Andrew, > >> Are the semantics for these really "identifier"? > > Per RFC5610 and RFC6313, there are just 7 semantics to choose from. > See > http://www.iana.org/assignments/ipfix/ipfix.xml#ipfix-information-element-semantics. > > Note that a standards action is required to introduce new semantics. Understood. > > 361 and 362 are port numbers. Notice that the semantics for all the > other port elements (sourceTransportPort, destinationTransportPort, > udpSourcePort, udpDestinationPort, tcpSourcePort, tcpDestinationPort, > collectorTransportPort, exporterTransportPort, > postNAPTSourceTransportPort, and postNAPTDestinationTransportPort) are > all "identifier", since the value identifies a port. I agree that 361 and 362 are port numbers which are identifiers. My thinking, however, was that none of these are really identifiers individually. Information Element Ids are identifiers too, but informationElementRangeBegin (342) and informationElementRangeEnd (343) have semantics of 'quantity' (which is neither 'default' nor 'identifier'. :-) Should informationElementRangeBegin and informationElementRangeEnd have semantics of 'default'? Now that I am typing this I think we covered some of this ground before in this thread (https://www.ietf.org/mail-archive/web/ipfix/current/msg06269.html). I don't yet have a strong opinion on what the right answer is. I just got curious while I was reviewing information elemnts that had been added since the last time I pulled the list. -Andrew > > 363 and 364 are simple numbers. If "identifier" is not appropriate for > these, then "default" is the only other possibility. > > P. > > >> On 06/18/2012 07:08 PM, Nevil Brownlee wrote: >>> >>> Hi again Amanda: >>> >>> These four have been discussed on the IPFIX list, they're OK as >>> submitted. They'll be >>> >>> 361 portRangeStart >>> 362 portRangeEnd >>> 363 portRangeStepSize >>> 364 portRangeNumPorts >>> >>> Cheers, Nevil >>> >>> >>> On 12/06/12 8:51 AM, Amanda Baber via RT wrote: >>>> Hi Nevil, >>>> >>>> Here's Paul's second request. >>>> >>>> thanks, >>>> Amanda >>>> >>>> === >>>> >>>> Contact Name: >>>> Paul Aitken >>>> >>>> Contact Email: >>>> paitken@cisco.com >>>> >>>> Type of Assignment: >>>> IPFIX Information Elements >>>> >>>> Registry: >>>> http://www.iana.org/assignments/ipfix/ipfix.xml#ipfix-information-elements >>>> >>>> >>>> Description: >>>> Please allocate the four new fields specified below, which may be used >>>> in various combinations to specify port ranges in IPFIX. >>>> >>>> Additional Info: >>>> Name: portRangeStart >>>> Type: unsigned16 >>>> Semantics: identifier >>>> Description: The port number identifying the start of a range of >>>> ports. >>>> A value of zero indicates that the range start is not specified, ie >>>> the >>>> range is defined in some other way. >>>> Additional information on defined TCP port numbers can be found at >>>> [IANA >>>> registry port-numbers]. >>>> >>>> Name: portRangeEnd >>>> Type: unsigned16 >>>> Semantics: identifier >>>> Description: The port number identifying the end of a range of ports. >>>> A value of zero indicates that the range end is not specified, ie the >>>> range is defined in some other way. >>>> Additional information on defined TCP port numbers can be found at >>>> [IANA >>>> registry port-numbers]. >>>> >>>> Name: portRangeStepSize >>>> Type: unsigned16 >>>> Semantics: identifier >>>> Description: The step size in a port range. The default step size >>>> is 1, >>>> which indicates contiguous ports. >>>> A value of zero indicates that the step size is not specified, ie the >>>> range is defined in some other way. >>>> >>>> Name: portRangeNumPorts >>>> Type: unsigned16 >>>> Semantics: identifier >>>> Description: The number of ports in a port range. >>>> A value of zero indicates that the number of ports is not >>>> specified, ie >>>> the range is defined in some other way. >>> >>> >> >> _______________________________________________ >> IPFIX mailing list >> IPFIX@ietf.org >> https://www.ietf.org/mailman/listinfo/ipfix > From paitken@cisco.com Mon Jul 16 14:03: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 4A09611E8091 for ; Mon, 16 Jul 2012 14:03:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.371 X-Spam-Level: X-Spam-Status: No, score=-10.371 tagged_above=-999 required=5 tests=[AWL=0.227, 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 BC8AEtOaS0jP for ; Mon, 16 Jul 2012 14:03:36 -0700 (PDT) Received: from ams-iport-4.cisco.com (ams-iport-4.cisco.com [144.254.224.147]) by ietfa.amsl.com (Postfix) with ESMTP id E7BBE11E808A for ; Mon, 16 Jul 2012 14:03:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=paitken@cisco.com; l=7767; q=dns/txt; s=iport; t=1342472661; x=1343682261; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to; bh=beVDsRaY6LihJbZnnVNF1U3oIbZgBD1Y6V/u0pa0Tiw=; b=fChYzYCHhlvtkvvNxk2c3h8WOcepz+K57xk5rFfq9hJmK5lWA9X2+g5J tC+Kb0mez7IYxfKPQcoprgNnDFtYvGLUoXxSVPvCECxiTbe6Q7We7U37q PqVnUkEyE9FdMQBtLW97Q8p/GfHo16JQfTbtoVre3dz20BOLmt5bipwD9 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EAHGABFCQ/khN/2dsb2JhbABFuVGBB4IgAQEBAwESARREDgULCyElDwJGBg0BBwEBHodlBgubbqAYi1oKhiMDlTuBEoREiEqBZoJggV4 X-IronPort-AV: E=Sophos;i="4.77,596,1336348800"; d="scan'208,217";a="6682846" Received: from ams-core-4.cisco.com ([144.254.72.77]) by ams-iport-4.cisco.com with ESMTP; 16 Jul 2012 21:04:20 +0000 Received: from [10.61.86.113] (ams3-vpn-dhcp5746.cisco.com [10.61.86.113]) by ams-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id q6GL4Jmm025805; Mon, 16 Jul 2012 21:04:20 GMT Message-ID: <500481D4.40500@cisco.com> Date: Mon, 16 Jul 2012 22:04:20 +0100 From: Paul Aitken User-Agent: Mozilla/5.0 (X11; Linux i686; rv:12.0) Gecko/20120430 Thunderbird/12.0.1 MIME-Version: 1.0 To: Andrew Feren References: <201206111440.q5BEe6ps030247@smtp1.lax.icann.org> <4FDFB4DC.2010106@auckland.ac.nz> <50047098.4050402@plixer.com> <500477E0.5090402@cisco.com> <50047CE5.3080100@plixer.com> In-Reply-To: <50047CE5.3080100@plixer.com> Content-Type: multipart/alternative; boundary="------------050403080906030408090006" Cc: ipfix@ietf.org Subject: Re: [IPFIX] [IANA #579482] General Request for Assignment (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: Mon, 16 Jul 2012 21:03:37 -0000 This is a multi-part message in MIME format. --------------050403080906030408090006 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Andrew, >> 361 and 362 are port numbers. Notice that the semantics for all the >> other port elements (sourceTransportPort, destinationTransportPort, >> udpSourcePort, udpDestinationPort, tcpSourcePort, tcpDestinationPort, >> collectorTransportPort, exporterTransportPort, >> postNAPTSourceTransportPort, and postNAPTDestinationTransportPort) >> are all "identifier", since the value identifies a port. > > I agree that 361 and 362 are port numbers which are identifiers. My > thinking, however, was that none of these are really identifiers > individually. Information Element Ids are identifiers too, but > informationElementRangeBegin (342) and informationElementRangeEnd > (343) have semantics of 'quantity' (which is neither 'default' nor > 'identifier'. :-) 5101 says: 3.2.1 . quantity A quantity value represents a discrete measured value pertaining to the record. This is distinguished from counters that represent an ongoing measured value whose "odometer" reading is captured as part of a given record.*If no semantic qualifier is given, the Information Elements that have an integral data type should behave as a quantity.* 3.2.4 . identifier An integral value that serves as an identifier. Specifically, *mathematical operations on two identifiers (aside from the equality operation) are meaningless.* For example, Autonomous System ID 1 * Autonomous System ID 2 is meaningless. (My bolding). So, per 3.2.1, the default semantic is "quantity". However, since mathematical operations on port numbers are meaningless (other than equality and comparisons), my feeling is that "identifier" is more appropriate. Thus the clue is in the definition, "The port number *identifying* the start of a range of ports." -> it's a number which identifies a port, rather than the value of some physical property of the port. However, if the WG disagrees then I'm not strongly opposed to changing it. > Should informationElementRangeBegin and informationElementRangeEnd > have semantics of 'default'? Good question. It seems there should be consistency here. > Now that I am typing this I think we covered some of this ground > before in this thread > (https://www.ietf.org/mail-archive/web/ipfix/current/msg06269.html). What was the outcome of that thread? I found, "lets discuss this in Paris". However, I don't recall it being on the WG agenda. > I don't yet have a strong opinion on what the right answer is. I just > got curious while I was reviewing information elemnts that had been > added since the last time I pulled the list. How often do you update? I have multiple tickets open with IANA. I'll try to announce to the WG list when I request new fields. However, note that WG discussion / consensus isn't part of the 5102 / expert review process. P. --------------050403080906030408090006 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Andrew,

361 and 362 are port numbers. Notice that the semantics for all the other port elements (sourceTransportPort, destinationTransportPort, udpSourcePort, udpDestinationPort, tcpSourcePort, tcpDestinationPort, collectorTransportPort, exporterTransportPort, postNAPTSourceTransportPort, and postNAPTDestinationTransportPort) are all "identifier", since the value identifies a port.

I agree that 361 and 362 are port numbers which are identifiers.  My thinking, however, was that none of these are really identifiers individually.  Information Element Ids are identifiers too, but informationElementRangeBegin (342) and informationElementRangeEnd (343) have semantics of 'quantity' (which is neither 'default' nor 'identifier'.  :-)


5101 says:

3.2.1.  quantity
   A quantity value represents a discrete measured value pertaining to
   the record.  This is distinguished from counters that represent an
   ongoing measured value whose "odometer" reading is captured as part
   of a given record.  If no semantic qualifier is given, the
   Information Elements that have an integral data type should behave as
   a quantity.

3.2.4.  identifier
   An integral value that serves as an identifier.  Specifically,
   mathematical operations on two identifiers (aside from the equality
   operation) are meaningless.  For example, Autonomous System ID 1 *
   Autonomous System ID 2 is meaningless.

(My bolding).

So, per 3.2.1, the default semantic is "quantity". However, since mathematical operations on port numbers are meaningless (other than equality and comparisons), my feeling is that "identifier" is more appropriate.

Thus the clue is in the definition, "The port number identifying the start of a range of ports." -> it's a number which identifies a port, rather than the value of some physical property of the port.

However, if the WG disagrees then I'm not strongly opposed to changing it.


Should informationElementRangeBegin and informationElementRangeEnd have semantics of 'default'?

Good question. It seems there should be consistency here.


Now that I am typing this I think we covered some of this ground before in this thread (https://www.ietf.org/mail-archive/web/ipfix/current/msg06269.html).

What was the outcome of that thread? I found, "lets discuss this in Paris". However, I don't recall it being on the WG agenda.


I don't yet have a strong opinion on what the right answer is.  I just got curious while I was reviewing information elemnts that had been added since the last time I pulled the list.

How often do you update? I have multiple tickets open with IANA. I'll try to announce to the WG list when I request new fields. However, note that WG discussion / consensus isn't part of the 5102 / expert review process.

P.
--------------050403080906030408090006-- From paitken@cisco.com Mon Jul 16 14:18: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 C99C811E814E for ; Mon, 16 Jul 2012 14:18:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.39 X-Spam-Level: X-Spam-Status: No, score=-10.39 tagged_above=-999 required=5 tests=[AWL=0.208, 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 NXLFsPeFYCch for ; Mon, 16 Jul 2012 14:18:14 -0700 (PDT) Received: from ams-iport-4.cisco.com (ams-iport-4.cisco.com [144.254.224.147]) by ietfa.amsl.com (Postfix) with ESMTP id 79E2411E80D0 for ; Mon, 16 Jul 2012 14:18:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=paitken@cisco.com; l=4785; q=dns/txt; s=iport; t=1342473539; x=1343683139; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to; bh=tJ6WTXOXz6kYZSnvAnxAdWZJD8C6p/jaNUyLGY6fQUo=; b=XDIMtvr1KHTWOQq0xbIi9HupnQiE9aIKOSGH+REPY1t4zCVwuF7/a5kh hyGGT7tPHO4bGtax949p+H4pqW5ASHqrCgEPy/7zm0pxJhl4zqBHq1EyQ bSVQhXxL0x7dT4zDB0VIGcdM9ZQl5r1M0E1W0JtFXASWvRyZA0Q+IdUH1 g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAP+DBFCQ/khN/2dsb2JhbABFuVGBB4IgAQEBAwESAWUBBQsLBB0WDwkDAgECAUUGDQEHAQEVCYdlBgucJ6AUBIJBj0YDlTuFVohKgWaCYA X-IronPort-AV: E=Sophos;i="4.77,596,1336348800"; d="scan'208,217";a="6683109" Received: from ams-core-4.cisco.com ([144.254.72.77]) by ams-iport-4.cisco.com with ESMTP; 16 Jul 2012 21:18:58 +0000 Received: from [10.61.86.113] (ams3-vpn-dhcp5746.cisco.com [10.61.86.113]) by ams-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id q6GLIv4Z028411; Mon, 16 Jul 2012 21:18:58 GMT Message-ID: <50048542.5020505@cisco.com> Date: Mon, 16 Jul 2012 22:18:58 +0100 From: Paul Aitken User-Agent: Mozilla/5.0 (X11; Linux i686; rv:12.0) Gecko/20120430 Thunderbird/12.0.1 MIME-Version: 1.0 To: Andrew Feren References: <50043112.90003@plixer.com> In-Reply-To: <50043112.90003@plixer.com> Content-Type: multipart/alternative; boundary="------------050506030205070902090406" Cc: IETF IPFIX Working Group Subject: Re: [IPFIX] initiatorOctets and responderOctets confusion 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, 16 Jul 2012 21:18:15 -0000 This is a multi-part message in MIME format. --------------050506030205070902090406 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Andrew, > I was just looking at initiatorOctets (231) and responderOctets (232) > on IANA's assignments page > and I noticed a > couple of issues. > > There are no sematics given. We should have the correct semantics added. Agreed. > I had thought the semantics would be deltaCounter (like > octetDeltaCount), but the descriptions talk about "[t]he total number > of layer 4 payload bytes in a flow [...]". I hope I am reading that > incorrectly because if the semantics are not deltaCounter then section > 4.10 in ie-doctors needs to be revisited. I believe the semantics are "totalCounter" and IE-doctors needs revised. > Is deltaCounter the correct semantics? A first glance at the cisco implementation suggests not. However, I'm checking with the implementation team to be quite sure. > Should the description be closer to the octetDeltaCount description? > Something like: > "The number of octets since the previous report (if any) in incoming > packets from the initiator for this Flow at the Observation Point. > The number of octets includes IP header(s) and IP payload. The > initiator is the device which triggered the session creation, and > remains the same for the life of the session." Not if they're total counters, as suggested by the descriptions and cisco definition that I saw. > Same questions for initiatorPackets (298) and responderPackets (299). Same answer: the definitions say "total", and I believe the semantics should be "totalCounter". Once I have confirmation, I'll open a case with IANA to have these corrected. Thanks for pointing this out. P. --------------050506030205070902090406 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Andrew,

I was just looking at initiatorOctets (231) and responderOctets (232) on IANA's assignments page and I noticed a couple of issues.

There are no sematics given.  We should have the correct semantics added.

Agreed.


I had thought the semantics would be deltaCounter (like octetDeltaCount), but the descriptions talk about "[t]he total number of layer 4 payload bytes in a flow [...]".  I hope I am reading that incorrectly because if the semantics are not deltaCounter then section 4.10 in ie-doctors needs to be revisited.

I believe the semantics are "totalCounter" and IE-doctors needs revised.


Is deltaCounter the correct semantics?

A first glance at the cisco implementation suggests not. However, I'm checking with the implementation team to be quite sure.


Should the description be closer to the octetDeltaCount description?  Something like: 
"The number of octets since the previous report (if any) in incoming packets from the initiator for this Flow at the Observation Point.  The number of octets includes IP header(s) and IP payload. The initiator is the device which triggered the session creation, and remains the same for the life of the session."

Not if they're total counters, as suggested by the descriptions and cisco definition that I saw.


Same questions for initiatorPackets (298) and responderPackets (299).

Same answer: the definitions say "total", and I believe the semantics should be "totalCounter".

Once I have confirmation, I'll open a case with IANA to have these corrected.

Thanks for pointing this out.

P.
--------------050506030205070902090406-- From andrewf@plixer.com Mon Jul 16 14:55:23 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 2D6D511E8232 for ; Mon, 16 Jul 2012 14:55:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.738 X-Spam-Level: X-Spam-Status: No, score=-1.738 tagged_above=-999 required=5 tests=[AWL=-0.430, BAYES_00=-2.599, MISSING_HEADERS=1.292] 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 sZ-tGjSwNyLR for ; Mon, 16 Jul 2012 14:55:22 -0700 (PDT) Received: from smtp.plixer.com (smtp.plixer.com [66.186.184.193]) by ietfa.amsl.com (Postfix) with ESMTP id D49F011E825E for ; Mon, 16 Jul 2012 14:55:21 -0700 (PDT) Received: from [10.100.1.132] ([65.175.140.2]) by smtp.plixer.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Mon, 16 Jul 2012 17:56:06 -0400 Message-ID: <50048DF6.8050009@plixer.com> Date: Mon, 16 Jul 2012 17:56:06 -0400 From: Andrew Feren User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:16.0) Gecko/16.0 Thunderbird/16.0a1 MIME-Version: 1.0 CC: ipfix@ietf.org References: <201206111440.q5BEe6ps030247@smtp1.lax.icann.org> <4FDFB4DC.2010106@auckland.ac.nz> <50047098.4050402@plixer.com> <500477E0.5090402@cisco.com> <50047CE5.3080100@plixer.com> <500481D4.40500@cisco.com> In-Reply-To: <500481D4.40500@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 16 Jul 2012 21:56:06.0950 (UTC) FILETIME=[CD549460:01CD639D] Subject: Re: [IPFIX] [IANA #579482] General Request for Assignment (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: Mon, 16 Jul 2012 21:55:23 -0000 Paul, On 07/16/2012 05:04 PM, Paul Aitken wrote: [ snip ] > >> Now that I am typing this I think we covered some of this ground >> before in this thread >> (https://www.ietf.org/mail-archive/web/ipfix/current/msg06269.html). > > What was the outcome of that thread? I found, "lets discuss this in > Paris". However, I don't recall it being on the WG agenda. I don't recall any final outcome of that thread. > > >> I don't yet have a strong opinion on what the right answer is. I >> just got curious while I was reviewing information elemnts that had >> been added since the last time I pulled the list. > > How often do you update? I have multiple tickets open with IANA. I'll > try to announce to the WG list when I request new fields. However, > note that WG discussion / consensus isn't part of the 5102 / expert > review process. No fixed schedule. I generally pull the list at the start of each major release cycle. I may also merge changes from IANA for a minor release if I get a bug report for an information element that is missing or not decoding correctly. I'll keep an eye out for your other new fields. Thanks, -Andrew From paitken@cisco.com Mon Jul 16 15:33: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 5382421F85D2 for ; Mon, 16 Jul 2012 15:33:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.406 X-Spam-Level: X-Spam-Status: No, score=-10.406 tagged_above=-999 required=5 tests=[AWL=0.192, 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 HWwQYcXFiNMd for ; Mon, 16 Jul 2012 15:33:04 -0700 (PDT) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by ietfa.amsl.com (Postfix) with ESMTP id D4BBA11E8320 for ; Mon, 16 Jul 2012 15:33:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=paitken@cisco.com; l=5650; q=dns/txt; s=iport; t=1342478028; x=1343687628; h=message-id:date:from:mime-version:to:subject:references: in-reply-to; bh=s/lqplnFZ6KI0YvkLg/AlNllPEhsLADm1agmEAv9dTE=; b=eRU/467WnZ09R8uJGpLjVxk/98GlbtnjlaUdfP0dnvkoG6A1oJUjLGvH TUHenVA9S/lR/C+/qsZBSm7oD4+AR5jNUNZvOTibO6gn6dvbJxV2S9yGK /bMemoG/r0DO1BiOnoavfqTLP5aDMfQsFrZLjTUpQ61xZ4W+RKjO+R7w1 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFABKWBFCQ/khN/2dsb2JhbABFhWmzZ4EHgiABAQEEEgEQVAENBBwDAQIKFgsCAgkDAgECATsCCAYNBgIBAQUZh2sLnBqNGZMAi0CFNYESA5U7gRKERIhKgWaCYA X-IronPort-AV: E=Sophos;i="4.77,597,1336348800"; d="scan'208,217";a="75341609" Received: from ams-core-4.cisco.com ([144.254.72.77]) by ams-iport-2.cisco.com with ESMTP; 16 Jul 2012 22:33:47 +0000 Received: from [10.61.86.113] (ams3-vpn-dhcp5746.cisco.com [10.61.86.113]) by ams-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id q6GMXkFa009025 for ; Mon, 16 Jul 2012 22:33:47 GMT Message-ID: <500496CB.7050207@cisco.com> Date: Mon, 16 Jul 2012 23:33:47 +0100 From: Paul Aitken User-Agent: Mozilla/5.0 (X11; Linux i686; rv:12.0) Gecko/20120430 Thunderbird/12.0.1 MIME-Version: 1.0 To: IETF IPFIX Working Group References: <20120716221906.13681.65783.idtracker@ietfa.amsl.com> In-Reply-To: <20120716221906.13681.65783.idtracker@ietfa.amsl.com> X-Forwarded-Message-Id: <20120716221906.13681.65783.idtracker@ietfa.amsl.com> Content-Type: multipart/alternative; boundary="------------050306080208070000070800" Subject: [IPFIX] Fwd: New Version Notification for draft-aitken-ipfix-unobserved-fields-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, 16 Jul 2012 22:33:06 -0000 This is a multi-part message in MIME format. --------------050306080208070000070800 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Dear IPFIXers, In this revision I've added a new section discussing why a "general default value" isn't possible and noted that the ability to indicate Unobserved Fields provides a side benefit of allowing the Metering Process to indicate that it has begun to monitor a new flow but does not yet have anything to export. Also the usual minor clarifications and error corrections. I've received a lot of positive feedback about the need for this mechanism in IPFIX. P. -------- Original Message -------- Subject: New Version Notification for draft-aitken-ipfix-unobserved-fields-01.txt Date: Mon, 16 Jul 2012 15:19:06 -0700 From: internet-drafts@ietf.org To: paitken@cisco.com A new version of I-D, draft-aitken-ipfix-unobserved-fields-01.txt has been successfully submitted by Paul Aitken and posted to the IETF repository. Filename: draft-aitken-ipfix-unobserved-fields Revision: 01 Title: Reporting Unobserved Fields in IPFIX Creation date: 2012-07-16 WG ID: Individual Submission Number of pages: 13 URL: http://www.ietf.org/internet-drafts/draft-aitken-ipfix-unobserved-fields-01.txt Status: http://datatracker.ietf.org/doc/draft-aitken-ipfix-unobserved-fields Htmlized: http://tools.ietf.org/html/draft-aitken-ipfix-unobserved-fields-01 Diff: http://tools.ietf.org/rfcdiff?url2=draft-aitken-ipfix-unobserved-fields-01 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 --------------050306080208070000070800 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit Dear IPFIXers,

In this revision I've added a new section discussing why a "general default value" isn't possible and noted that the ability to indicate Unobserved Fields provides a side benefit of allowing the Metering Process to indicate that it has begun to monitor a new flow but does not yet have anything to export. Also the usual minor clarifications and error corrections.

I've received a lot of positive feedback about the need for this mechanism in IPFIX.

P.


-------- Original Message --------
Subject: New Version Notification for draft-aitken-ipfix-unobserved-fields-01.txt
Date: Mon, 16 Jul 2012 15:19:06 -0700
From: internet-drafts@ietf.org
To: paitken@cisco.com 


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

Filename:	 draft-aitken-ipfix-unobserved-fields
Revision:	 01
Title:		 Reporting Unobserved Fields in IPFIX
Creation date:	 2012-07-16
WG ID:		 Individual Submission
Number of pages: 13
URL:             http://www.ietf.org/internet-drafts/draft-aitken-ipfix-unobserved-fields-01.txt
Status:          http://datatracker.ietf.org/doc/draft-aitken-ipfix-unobserved-fields
Htmlized:        http://tools.ietf.org/html/draft-aitken-ipfix-unobserved-fields-01
Diff:            http://tools.ietf.org/rfcdiff?url2=draft-aitken-ipfix-unobserved-fields-01

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
--------------050306080208070000070800-- From paitken@cisco.com Tue Jul 17 14:02: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 4ACCA11E80A4 for ; Tue, 17 Jul 2012 14:02:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -11.12 X-Spam-Level: X-Spam-Status: No, score=-11.12 tagged_above=-999 required=5 tests=[AWL=0.879, BAYES_00=-2.599, GB_I_LETTER=-2, J_CHICKENPOX_21=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 XuR6AvwRafKz for ; Tue, 17 Jul 2012 14:02:55 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id 5F6A011E80A2 for ; Tue, 17 Jul 2012 14:02:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=paitken@cisco.com; l=50887; q=dns/txt; s=iport; t=1342559022; x=1343768622; h=message-id:date:from:mime-version:to:subject: content-transfer-encoding; bh=WNkkxjDsPxhESppOrDz68wf+dKDNV1B++fo0odqF1Kc=; b=MFNwMYeEv4iFhqKtCsPe3b9wnonZyPh34dlM1+WwKBaCwlU59DH/cien 1LeRDriO10YuK3mTaM5lNtYf45fuHIuSx9j2w6f9ZvfluV831otqq6aLj dQqms3K1QsFfbXkdV6ioRA0oollKbVGlQSDs5RaZr2diQp0i6cQkfSHiG c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AscQAJ7SBVCQ/khR/2dsb2JhbAA7CrEuh1aBB4IgAQEBAxMBBwEMES8EAwoGNwwKGAMCAQIBSwEMCAEBEAcHh2UGC50coCiLQBAQgweDKAOVPYEShEaISoFmgmCBVg X-IronPort-AV: E=Sophos;i="4.77,604,1336348800"; d="scan'208";a="141260824" Received: from ams-core-1.cisco.com ([144.254.72.81]) by ams-iport-1.cisco.com with ESMTP; 17 Jul 2012 21:03:40 +0000 Received: from [10.55.93.221] (dhcp-10-55-93-221.cisco.com [10.55.93.221]) by ams-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id q6HL3bhg005505; Tue, 17 Jul 2012 21:03:37 GMT Message-ID: <5005D329.8060509@cisco.com> Date: Tue, 17 Jul 2012 22:03:37 +0100 From: Paul Aitken User-Agent: Mozilla/5.0 (X11; Linux i686; rv:12.0) Gecko/20120430 Thunderbird/12.0.1 MIME-Version: 1.0 To: Brian Trammell , IETF IPFIX Working Group Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [IPFIX] draft-ietf-ipfix-ie-doctors-02 review 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, 17 Jul 2012 21:02:58 -0000 Brian, all, While reviewing draft-ietf-ipfix-ie-doctors-03 I've found several issues which I thought I had already pointed out. I discovered that I reviewed -02 in April, though only up to section 6 - and therefore never sent my feedback. Here's what I had; feedback on -03 is coming. P. Here's a review of draft-ietf-ipfix-ie-doctors-02. I have several concerns with the document (marked **), together with some editorial comments. Please see inline. P. > IPFIX Working Group B. Trammell > Internet-Draft ETH Zurich > Intended status: BCP B. Claise > Expires: September 8, 2012 Cisco Systems, Inc. > March 7, 2012 > > > Guidelines for Authors and Reviewers of IPFIX Information Elements > draft-ietf-ipfix-ie-doctors-02.txt > > Abstract > > 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. > > Status of this Memo > > This Internet-Draft is submitted in full conformance with the > provisions of BCP 78 and BCP 79. > > Internet-Drafts are working documents of the Internet Engineering > Task Force (IETF). Note that other groups may also distribute > working documents as Internet-Drafts. The list of current Internet- > Drafts is athttp://datatracker.ietf.org/drafts/current/. > > Internet-Drafts are draft documents valid for a maximum of six months > and may be updated, replaced, or obsoleted by other documents at any > time. It is inappropriate to use Internet-Drafts as reference > material or to cite them other than as "work in progress." > > This Internet-Draft will expire on September 8, 2012. > > Copyright Notice > > Copyright (c) 2012 IETF Trust and the persons identified as the > document authors. All rights reserved. > > This document is subject to BCP 78 and the IETF Trust's Legal > Provisions Relating to IETF Documents > (http://trustee.ietf.org/license-info) in effect on the date of > publication of this document. Please review these documents > carefully, as they describe your rights and restrictions with respect > to this document. Code Components extracted from this document must > include Simplified BSD License text as described in Section 4.e of > the Trust Legal Provisions and are provided without warranty as > described in the Simplified BSD License. > > > > Trammell& Claise Expires September 8, 2012 [Page 1] > > Internet-Draft IPFIX IE-DOCTORS March 2012 > > > Table of Contents > > 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 > 1.1. Intended Audience and Usage . . . . . . . . . . . . . . . 3 > 1.2. Overview of relevant IPFIX documents . . . . . . . . . . . 4 > 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 > 3. How to apply IPFIX . . . . . . . . . . . . . . . . . . . . . . 5 > 4. Defining new Information Elements . . . . . . . . . . . . . . 6 > 4.1. Information Element naming . . . . . . . . . . . . . . . . 7 > 4.2. Information Element data types . . . . . . . . . . . . . . 7 > 4.3. Information Element numbering . . . . . . . . . . . . . . 8 > 4.4. Ancillary Information Element properties . . . . . . . . . 9 > 4.5. Internal structure in Information Elements . . . . . . . . 9 > 4.6. Information Element multiplicity . . . . . . . . . . . . . 10 > 4.7. Enumerated Values and Subregistries . . . . . . . . . . . 11 > 4.8. Reversibility as per RFC 5103 . . . . . . . . . . . . . . 11 > 4.9. Promotion of Enterprise-Specific Information Elements . . 11 > 4.10. Avoiding Bad Ideas in Information Element Design . . . . . 12 > 5. The Information Element Lifecycle . . . . . . . . . . . . . . 13 > 5.1. The IE-DOCTORS process . . . . . . . . . . . . . . . . . . 13 > 5.2. Revising Information Elements . . . . . . . . . . . . . . 14 > 5.3. Deprecating Information Elements . . . . . . . . . . . . . 15 > 5.4. Versioning the entire IANA Registry . . . . . . . . . . . 16 > 6. When not to define new Information Elements . . . . . . . . . 16 > 6.1. Maximizing reuse of existing Information Elements . . . . 16 > 6.2. Applying enterprise-specific Information Elements . . . . 18 > 7. Information Element Definition Checklist . . . . . . . . . . . 18 > 8. Applying IPFIX to non-Flow Applications . . . . . . . . . . . 21 > 9. Writing Internet-Drafts for IPFIX Applications . . . . . . . . 22 > 9.1. Example Information Element Definition . . . . . . . . . . 22 > 9.2. Defining Recommended Templates . . . . . . . . . . . . . . 23 > 10. A Textual Format for Specifying Information Elements and > Templates . . . . . . . . . . . . . . . . . . . . . . . . . . 24 > 10.1. Information Element Specifiers . . . . . . . . . . . . . . 24 > 10.2. Specifying Templates . . . . . . . . . . . . . . . . . . . 26 > 10.3. Specifying IPFIX Structured Data . . . . . . . . . . . . . 27 > 11. Security Considerations . . . . . . . . . . . . . . . . . . . 27 > 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28 > 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 29 > 14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 29 > 14.1. Normative References . . . . . . . . . . . . . . . . . . . 29 > 14.2. Informative References . . . . . . . . . . . . . . . . . . 30 > Appendix A. Example Information Element Definitions . . . . . . . 31 > A.1. sipResponseStatus . . . . . . . . . . . . . . . . . . . . 31 > A.2. duplicatePacketDeltaCount . . . . . . . . . . . . . . . . 31 > A.3. ambientTemperature . . . . . . . . . . . . . . . . . . . . 32 > Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 32 > > > > > Trammell& Claise Expires September 8, 2012 [Page 2] > > Internet-Draft IPFIX IE-DOCTORS March 2012 > > > 1. Introduction > > This document provides guidelines for the extension of the > applicability of the IP Flow Information Export (IPFIX) protocol to > network operations and management purposes outside the initial scope > defined in "IPFIX Applicability Statement" [RFC5472]. These new > applications are largely defined by creating new Information Elements > beyond those in the IANA IPFIX Information Element Registry > [iana-ipfix-assignments]. New applications may be further specified > through additional RFCs defining and describing their usage. > > We intend this document to enable the expansion of the applicability > of IPFIX to new areas by experts in the working group or area > directorate concerned with the technical details of the protocol or > application to be measured or managed using IPFIX. This expansion > would occur with the consultation of IPFIX experts informally called > 'IE-Doctors'. It provides guidelines both for those defining new > Information Elements as well as the IE-Doctors reviewing them. > > 1.1. Intended Audience and Usage > > This document is meant for two separate audiences. For IETF > contributors extending the applicability of IPFIX, it provides > specifications and best practices to be used in deciding which > Information Elements are necessary for a given existing or new > application, defining these Information Elements, and deciding > whether an RFC should be published to further describe the > application. For the IPFIX experts appointed as IE-Doctors, and for > IANA personnel changing the Information Element registry, it defines Consistently say "IANA registry" or "IANA IPFIX Information Element registry", else clarify each instance of "registry" with "[iana-ipfix-assignments]". See below for a note on "IANA registry". > a set of acceptance criteria against which these proposed Information > Elements should be evaluated. > > This document is not intended to guide the extension of the IPFIX > protocol itself, e.g. through new export mechanisms, data types, or > the like; these activities should be pursued through the publication > of standards-track RFCs by the IPFIX Working Group. > > This document, together with > [I-D.ietf-ipfix-information-model-rfc5102bis], defines the procedures > for management of the IANA IPFIX Information Element Registry > [iana-ipfix-assignments]. The practices outlined in this document > are intended to guide experts when reviewing additions or changes to > the Information Elements in the registry under Expert Review as eg here you said "registry" without saying either IANA or [iana-ipfix-assignments]. So which registry are you talking about? > defined in [RFC5226]. > > > > > > > > Trammell& Claise Expires September 8, 2012 [Page 3] > > Internet-Draft IPFIX IE-DOCTORS March 2012 > > > 1.2. Overview of relevant IPFIX documents > > [I-D.ietf-ipfix-protocol-rfc5101bis] defines the IPFIX Protocol, the > IPFIX-specific terminology used by this document, and the data type > encodings for each of the data types supported by IPFIX. > > [I-D.ietf-ipfix-information-model-rfc5102bis] defines the basis of > the IPFIX Information Model, referring to [iana-ipfix-assignments] > for the specific Information Element definitions. It states that new > Information Elements may be added to the Information Model on Expert > Review basis, delegates the appointment of experts to an IESG Area > Director, and refers to this document for details on the extension > process. This document is intended to further codify the best Be careful with "this document" (above, twice), because it's not clear whether you mean 5102bis or IE-doctors. > practices to be followed by these experts, in order to improve the > efficiency of this process. > > [RFC5103] defines a method for exporting bidirectional flow > information using IPFIX; this document should be followed when Again, "this document" is ambiguous. > extending IPFIX to represent information about bidirectional network > interactions in general. Additionally, new Information Elements > should be annotated for their reversibility or lack thereof as per > this document. Again... > [RFC5610] defines a method for exporting information about > Information Elements inline within IPFIX. In doing so, it explicitly > defines a set of restrictions on the use of data types and semantics > which are implied in [I-D.ietf-ipfix-protocol-rfc5101bis] and Is it the restrictions or the (data types and semantics) which are implied? > [I-D.ietf-ipfix-information-model-rfc5102bis]; these restrictions > must be observed in the definition of new Information Elements, as in > Section 4.4. > > > 2. Terminology > > Capitalized terms used in this document that are defined in the > Terminology section of [I-D.ietf-ipfix-protocol-rfc5101bis] are to be > interpreted as defined there. > > An "application", as used in this document, refers to a candidate > protocol, task, or domain to which IPFIX export, collection, and/or > storage is applied, beyond those within the IPFIX Applicability > statement [RFC5472]. By this definition, PSAMP [RFC5476] was the > first new IPFIX application after the publication of the IPFIX > protocol itself. > > "IANA registry", as used in this document, unless otherwise noted, IANA has lots of registries, even for IPFIX, so it'd be good to explicitly call out the registy in the text, eg "IANA's IPFIX Information Elements registry" ? > refers to the IANA IPFIX Information Element Registry > [iana-ipfix-assignments]. > > > > Trammell& Claise Expires September 8, 2012 [Page 4] > > Internet-Draft IPFIX IE-DOCTORS March 2012 > > > The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", > "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this > document are to be interpreted as described in [RFC2119]. > > > 3. How to apply IPFIX > > Though originally specified for the export of IP flow information, > the message format, template mechanism, and data model specified by > IPFIX lead to it being applicable to a wide variety of network > management situations. In addition to flow information export, for > which it was designed, and packet information export as specified by > PSAMP [RFC5476], any application with the following characteristics > is a good candidate for an IPFIX application: > > o The application's data flow is fundamentally unidirectional. > IPFIX is a "push" protocol, supporting only the export of > information from a sender (an Exporting Process) to a receiver (a > Collecting Process). Request-response interactions are not > supported by IPFIX. > > o The application handles discrete event information, or information > to be periodically reported. IPFIX is particularly well suited to > representing events, which can be scoped in time. > > o The application handles information about network entities. > IPFIX's information model is network-oriented, so network > management applications have many opportunities for information > model reuse. > > o The application requires a small number of arrangements of data > structures relative to the number of records it handles. The > template-driven self-description mechanism used by IPFIX excels at > handling large volumes of identically structured data, compared to > representations which define structure inline with data (such as > XML). > > Most applications meeting these criteria can be supported over IPFIX. > Once it's been determined that IPFIX is a good fit, the next step is It's == "it is", so this doesn't scan correctly. > determining which Information Elements are necessary to represent the > information required by the application. Especially for network- > centric applications, the IPFIX Information Element registry may > already contain all the necessary Information Elements (see > Section 6.1 for guidelines on maximizing Information Element reuse). > In this case, no additional work within the IETF is necessary: simply > define Templates and start exporting. > > It is expected, however, that most applications will be able to reuse > > > > Trammell& Claise Expires September 8, 2012 [Page 5] > > Internet-Draft IPFIX IE-DOCTORS March 2012 > > > some existing Information Elements, but may need to define some > additional Information Elements to support all their requirements; in > this case, see Section 4 for best practices to be followed in > defining Information Elements. > > Optionally, a Working Group or individual contributor may choose to > publish an RFC detailing the new IPFIX application. Such an RFC Do WGs and ICs publish RFCs? > should contain discussion of the new application, the Information > Element definitions as in Section 4, as well as suggested Templates > and examples of the use of those Templates within the new application > as in Section 9.2. Section 10 defines a compact textual Information > Element notation to be used in describing these suggested Templates > and/or the use of IPFIX Structured Data [RFC6313] within the new > application. > > > 4. Defining new Information Elements > > In many cases, a new application will require nothing more than a new > Information Element or set of Information Elements to be exportable > using IPFIX. An Information Element meeting the following criteria, > as evaluated by appointed IPFIX experts, is eligible for inclusion in > the Information Element registry: > > o The Information Element MUST be sufficiently unique within the > registry. Its description MUST represent a substantially > different meaning from that of any existing Information Element. > A proposed Information Element which is a substantial duplicate of > an existing Information Element is to be represented using the > existing Information Element. ** Disagree. If the new app wants to extend the existing IE in a new and non-backwards compatible way, while avoiding splitting export across two IEs (ie, old values in the existing IE, new values in the TBD IE), then it would clone + extend the existing IE. Therefore it would necessarily be "a substantial duplicate of an existing Information Element". > o The Information Element SHOULD contain minimal internal structure; > complex information should be represented with multiple simple > Information Elements to be exported in parallel, as in > Section 4.5. ** Seriously disagree. Multiple IEs are unrelated, and may be re-ordered, aggregated, or removed by some intermediate process. Structured data would be required to group the discrete IEs together into a single entity. > o The Information Element SHOULD be generally applicable to the > application at hand, which SHOULD be of general interest to the > community. Information Elements representing information about > proprietary or nonstandard applications SHOULD be represented > using enterprise-specific Information Elements as detailed in > section 3.2 [RFC-EDITOR NOTE: verify section number] of > [I-D.ietf-ipfix-protocol-rfc5101bis]. > > The definition of new Information Elements requires a descriptive > name, a specification of the data type as one from the IPFIX Data > Type Registry, and a human-readable description written in English. Note that the Data Type registry is also extensible, so a new IE could define a new data type. eg, as done in mib-variable-export. > This section provides guidelines on each of these components of an > > > > Trammell& Claise Expires September 8, 2012 [Page 6] > > Internet-Draft IPFIX IE-DOCTORS March 2012 > > > Information Element definition, referring to existing documentation > such as [I-D.ietf-ipfix-information-model-rfc5102bis] as appropriate. > > 4.1. Information Element naming > > Information Element Names should be defined in accordance with > section 2.3 [RFC-EDITOR NOTE: verify section number] of > [I-D.ietf-ipfix-information-model-rfc5102bis]; the most important > naming conventions are repeated here for convenience. > > o Names of Information Elements SHOULD be descriptive. > > o Names of Information Elements MUST be unique within the registry. > > o Names of Information Elements MUST start with non-capitalized > letters. > > o Composed names MUST use capital letters for the first letter of > each component except for the first one. All other letters are aka camel case. > non-capitalized, even for acronyms. Exceptions are made for > acronyms containing non-capitalized letters, such as 'IPv4' and > 'IPv6'. Examples are "sourceMacAddress" and > "destinationIPv4Address." > > In addition, new Information Elements pertaining to a specific > protocol SHOULD name the protocol in the first word in order to ease > searching by name (e.g. "sipMethod" for a SIP method, as would be > used in a logging format for SIP based on IPFIX). Similarly, new > Information Elements pertaining to a specific application SHOULD name > the application in the first word. > > 4.2. Information Element data types > > IPFIX provides a set of data types covering most primitives used in > network measurement and management applications. The most > appropriate data type should be chosen for the Information Element > type, out of the IPFIX informationElementDataTypes subregistry at > [iana-ipfix-assignments]. Note that the data types registry is extensible. > Information Elements representing an integral value with a natural > width SHOULD be defined with the appropriate integral data type. > This applies especially to values taken directly from fixed-width > fields in a measured protocol. For example, tcpControlBits, the TCP > flags byte, is an unsigned8, and tcpSequenceNumber is an unsigned32. > > Information Elements representing counters or identifiers SHOULD be > defined as signed64 or unsigned64, as appropriate, to maximize the > range of values available; applications can to use reduced-size typo, "can to". > Trammell& Claise Expires September 8, 2012 [Page 7] > > Internet-Draft IPFIX IE-DOCTORS March 2012 > > > encoding as defined in Section 6.2 [RFC-EDITOR NOTE: verify section > number] of [I-D.ietf-ipfix-protocol-rfc5101bis] in cases where fewer > than 2^64 values are necessary. > > Information Elements representing time values MUST be defined with > appropriate precision. For example, a Information Element for a time > measured at second-level precision should be defined as having a > dateTimeSeconds data type, instead of dateTimeMilliseconds. > > Information Elements of type string or octetArray which have a length > constraints (fixed length, minimum and/or maximum length) MUST note > this length in their description. > > The type of an Information Element MUST match the type of the data it > represents. More specifically, information that could be represented > as a String, but which better matches one of the other data types > (e.g. an integral type for a number or enumerated type, an address > type for an address) MUST be represented by the best-matching type, > even if the data was represented using a different type in the > source. In other words, an IPFIX application that exports Options > Template Records mapping IP addresses to additional information about > each host from an external database MUST use Information Elements of > an address type to represent the addresses, even if the source > database represented these as strings. > > This document does not cover the addition of new Data Types or Data > Type Semantics to the IPFIX Protocol. As such changes have important > interoperability considerations and require implementation on both > Collecting and Exporting Processes, they require a Standards Action > as per [RFC5610]. However, note that the set of primitive types > provided by IPFIX are applicable to most any appropriate application, > so extending the type system is generally not necessary. > > 4.3. Information Element numbering > > Each Information Element have a unique identifier in the IANA typo: have -> has > registry. > > In general, when adding newly registered Information Elements to the > registry, IANA SHOULD assign the lowest available Information Element > identifier (the value column in [iana-ipfix-assignments] in the range > 128-32767, noting that prior noncontiguous allocation may lead to > unassigned Information Elements with lower Information Element > identifiers than some presently assigned Information Elements. This > is the case with the PSAMP Information Model [RFC5477], which > assigned a block of Information Elements identifiers starting at 300. > > Information Element identifiers in the range 1-128 MUST NOT be > > > > Trammell& Claise Expires September 8, 2012 [Page 8] > > Internet-Draft IPFIX IE-DOCTORS March 2012 > > > assigned unless the Information Element is compatible with the > NetFlow v9 protocol as described in [RFC3954]. Such Information > Elements may ONLY be requested by a NetFlow v9 expert, to be > designated by the IESG to consult with IANA on NetFlow v9 > compatibility with IPFIX. ** AFAIK no such experts have been designated. This would be a blocker for us. See suggestion from Benoit. > 4.4. Ancillary Information Element properties > > Information Elements to which special semantics apply SHOULD define The semantics should be defined by the requester, not by the IE. > these semantics with one of the values in the Information Element > Semantics registry, as described in Section 3.2 [RFC-EDITOR NOTE: > verify section number] of > [I-D.ietf-ipfix-information-model-rfc5102bis], subject to the > restrictions given in Section 3.10 of [RFC5610]; in other words, the > semantics and the type MUST be consistent. > > When defining Information Elements representing a dimensioned > quantity or entity count, the units of that quantity SHOULD be > defined in the units field. This field takes its values from the > IANA Information Element Units registry. If an Information Element > expresses a quantity in units not yet in this registry, then the unit > MUST be added to the Units registry at the same time the Information > Element is added to the Information Element registry. Is units a controlled registry (standards action) ? It's worth (re)stating this clearly for each of the IANA / IPFIX registries. > Additionally, when the range of values an Information Element can > take is smaller than the range implied by its data type, the range > SHOULD be defined within the Information Element registry. > > 4.5. Internal structure in Information Elements > > The definition of Information Elements with internal structure with > the structure defined in the Description field is NOT RECOMMENDED, > except in the following cases: > > o The Information Element is a direct copy of a structured entity in > a measured protocol (e.g. the tcpControlBits Information Element > for the flags byte from the TCP header) > > o The Information Element represents a section of a packet of > protocol entity, in raw form as captured from the wire (e.g. the > mplsLabelStackSection Information Element for the MPLS label > stack) > > o The Information Element represents a set of flags which are > tightly semantically related, where representing the flags as > separate one-byte booleans would be inefficient, and which should > always appear together in a data record (e.g., the > anonymizationFlags Information Element for specifying optional > > > > Trammell& Claise Expires September 8, 2012 [Page 9] > > Internet-Draft IPFIX IE-DOCTORS March 2012 > > > features of anonymization techniques) > > In other cases, candidate Information Elements with internal > structure SHOULD be decomposed into multiple primitive Information > Elements to be used in parallel. For more complicated semantics, > where the structure is not identical from Data Record to Data Record, > or where there is semantic dependency between multiple decomposed > primitive Information Elements, use the IPFIX Structured Data > [RFC6313] extension instead. > > As an example of information element decomposition, consider an > application-level identifier called an "endpoint", which represents a > {host, port, protocol} tuple. Instead of allocating an opaque, > structured "source endpoint" Information Element, the source endpoint > should be represented by three separate Information Elements: "source > address", "source port", "transport protocol". In this example, the > required information elements already exist in the Information > Element registry: sourceIPv4Address or sourceIPv6Address, > sourceTransportPort, protocolIdentifier. Indeed, as well as being > good practice, this normalization down to non-structured Information > Elements also increases opportunities for reuse as in Section 6.1. ** Now the CP receives three discrete IEs, with nothing to indicate that together they represent an endpoint. Worse, some intermediate process could re-order, aggregate or remove the discrete fields without knowing that they were required to identify an endpoint. The only solution is to use SD to group the fields together and prevent them from being modified along the way. > The decomposition of data with internal structure SHOULD avoid the > definition of Information Elements with a meaning too specific to be > generally useful, or that would result in either the export of > meaningless data or a multitude of templates to handle different > multiplicities. More information on multiplicities is given in the > following section. > > 4.6. Information Element multiplicity > > Some Information Elements may represent information with a > multiplicity other than one; i.e., items that may occur multiple > times within the data to be represented in a single IPFIX record. In > this case, there are several options, depending on the circumstances: > > o As specified in section 8 [RFC-EDITOR NOTE: verify section number] > of [I-D.ietf-ipfix-protocol-rfc5101bis]: "if an Information > Element is required more than once in a Template, the different > occurrences of this Information Element SHOULD follow the logical > order of their treatments by the Metering Process." In other > words, in cases where the items have a natural order (e.g., the > order in which they occur in the packet), and the multiplicity is > the same for each record, the information can be modeled by > containing multiple instances of the Information Element > representing a single item within the Template Record describing > the Data Records. > > > > > Trammell& Claise Expires September 8, 2012 [Page 10] > > Internet-Draft IPFIX IE-DOCTORS March 2012 > > > o In cases where the items have a variable multiplicity, a basicList > of the Information Element representing a single item can be used > as in the IPFIX Structured Data [RFC6313] extension. > > o If the multiple-item structure is taken directly from bytes > observed on the wire by the Metering Process or otherwise taken > from the application being measured, the multiple-item structure > can be exported as a variable-length octetArray Information > Element holding the raw content. Please give an example to clarify this last point. > Specifically, new Information Element SHOULD NOT encode any > multiplicity or ordinality information into the definition of the > Information Element itself. > > 4.7. Enumerated Values and Subregistries > > When defining an Information Element that takes an enumerated value > from a set of values which may change in the future, this enumeration > MUST be defined by an IANA registry or subregistry. For situations > where an existing registry defines the enumeration (e.g., the IANA > Protocol Numbers registry for the protocolIdentifier Information > Element), that registry MUST be used. Otherwise, a new IPFIX > subregistry MUST be defined for the enumerated value, to be modified > subject to Expert Review [RFC5226]. > > 4.8. Reversibility as per RFC 5103 > > [RFC5103] defines a method for exporting bidirectional flows using a > special Private Enterprise Number to define reverse-direction > variants of IANA Information Elements, and a set of criteria for > determining whether an Information Element may be reversed using this > method. Since almost all Information Elements are reversible, > [RFC5103] enumerates those which Information Elements which were > defined at the time of its publication which are NOT reversible. > > New non-reversible Information Elements SHOULD contain a note in the > description stating that they are not reversible. Why isn't that a MUST? > 4.9. Promotion of Enterprise-Specific Information Elements > > Some Information Elements may start their lifecycle outside the IANA > registry as enterprise-specific Information Elements scoped to a > Private Enterprise Number. One stated goal of enterprise-specific > Information Elements is pre-standards product delivery and > experimentation; should these experiments be successful and the > Information Elements generally useful, these SHOULD subsequently > registered with IANA. > > > > > Trammell& Claise Expires September 8, 2012 [Page 11] > > Internet-Draft IPFIX IE-DOCTORS March 2012 > > > In order to support transition from experimental registration to IANA > registration, the IANA registry provides an optional "enterprise- > specific IE reference" column for each Information Element. In cases The registry doesn't currently contain such fields. I've emailed you a better idea where it doesn't need to. > of promoted enterprise-specific Information Elements, this column in > the registry SHOULD contain the private enterprise and Information > Element numbers of the enterprise-specific version of the Information > Element. > > 4.10. Avoiding Bad Ideas in Information Element Design > > In general, the existence of a similarly-defined Information Element > in the IANA registry sets a precedent which may be followed to > determine whether a given proposed Information Element "fits" within > the registry. Indeed, the rules specified by this document could be > interpreted to mean "make new Information Elements that look like > existing Information Elements". However, for reasons of history, > there are several Information Elements within the IANA registry which > do not follow best practices in Information Element design. These > Information Elements are not necessarily so flawed so as to require > deprecation, but they should be explicitly ignored when looking for > guidance as to whether a new Information Element should be added. > > Before registering a new Information Element, it must be determined > that it would be sufficiently unique within the registry. This > evaluation has not always been done in the past, and the existence of > the Information Elements defined without this evaluation should not > be taken as an example that such Information Element definition > practices should be followed in the future. Specific examples of > such Information Elements include initiatorOctets and responderOctets > (which duplicate octetDeltaCount and its reverse per [RFC5103]) and > initiatorPackets and responderPackets (the same, for > packetDeltaCount). ** Disagree. octetDeltaCount and packetDeltaCount are directionless, while initiator* and responder* have inherent direction - thus the need for these fields. > As mentioned in Section 4.2, the type of an Information Element > SHOULD match the type of data the Information Element represents. An > example of how not to do this is presented by the p2pTechnology, > tunnelTechnology, and encryptedTechnology Information Elements: these > represent a three-state enumeration using a String. The example set > by these Information Elements SHOULD NOT be followed in the > definition of new Information Elements. Note that I proposed an improvement to this scheme. I'll try not to take it personally that all the bad examples were added by me, because I'm the only one who's added any new non-RFC IEs at all. > As mentioned in Section 4.6, an Information Element definition SHOULD > NOT include any ordinality or multiplicity information. The only > example of this within the IANA registry the following list of > assigned IPFIX Information Elements: mplsTopLabelStackSection, > mplsLabelStackSection2, mplsLabelStackSection3, > mplsLabelStackSection4, mplsLabelStackSection5, > mplsLabelStackSection6 mplsLabelStackSection7, > > > > Trammell& Claise Expires September 8, 2012 [Page 12] > > Internet-Draft IPFIX IE-DOCTORS March 2012 > > > mplsLabelStackSection8, mplsLabelStackSection9, and > mplsLabelStackSection10. The only distinction between those almost- > identical Information Elements is the position within the MPLS stack. > This Information Element design pattern met an early requirement of > the definition of IPFIX which was not carried forward into the final > specification -- namely, that no semantic dependency was allowed > between Information Elements in the same Record -- and as such SHOULD > NOT be followed in the definition of new Information Elements. In > this case, since the size of the MPLS stack will vary from flow to > flow, it should be exported using IPFIX Structured Data [RFC6313] > where supported, as a basicList of MPLS label entries, or as a raw > MPLS label stack using the variable-length mplsLabelStackSection > Information Element. > > > 5. The Information Element Lifecycle > > Once an Information Element or set of Information Elements has been > identified for a given application, Information Element > specifications in accordance with Section 4 are submitted to IANA to > follow the IE-DOCTORS process, as defined below. This process is > also used for other changes to the registry, such as deprecation or Which registry is that? > revision, as described later in this section. > > 5.1. The IE-DOCTORS process > > Requests to change the IANA Information Element registry or a linked > subregistry are submitted to IANA, which forwards the request to a How are requests submitted to IANA? > designated group of experts (IE-DOCTORS) appointed by the IETF > Operations Area Directors. This group of experts reviews the request > for such things as compliance with this document, compliance with > other applicable IPFIX-related RFCs, and consistency with the > currently defined set of Information Elements. > > Authors are expected to review compliance with the specifications in > this document to check their submissions before sending them to IANA. > > IE-DOCTORS reviewers should endeavor to complete referred reviews in > a timely manner. If the request is acceptable, the IE-DOCTORS Please define "a timely manner". Without a definition, it's not worth saying. > signify their approval to IANA, which changes the IANA Information > Element registry. If the request is not acceptable, the IE-DOCTORS > can coordinate with the requestor to change the request to be Or withdraw the request, presumably? s/requestor/requester/ ? > compliant. The IE-DOCTORS may also choose in exceptional > circumstances to reject clearly frivolous or inappropriate change > requests outright. What recourse do requesters have if their application is rejected? > > > > > > Trammell& Claise Expires September 8, 2012 [Page 13] > > Internet-Draft IPFIX IE-DOCTORS March 2012 > > > 5.2. Revising Information Elements > > The Information Element status field in the Information Element > Registry is defined in [I-D.ietf-ipfix-information-model-rfc5102bis] > to allow Information Elements to be 'current', 'deprecated' or > 'obsolete'. No Information Elements are as of this writing > deprecated or obsolete, and > [I-D.ietf-ipfix-information-model-rfc5102bis] does not define any > policy for using them. Additionally, no policy is defined for For using what - deprecated/obsolete IEs, or the deprecated/obsolete status? > revising Information Element registry entries or addressing errors > therein. To be certain, changes and deprecations within the > Information Element registry are not encouraged, and should be > avoided to the extent possible. However, in recognition that change > is inevitable, this section is intended to remedy this situation. > > The primary requirement in the definition of a policy for managing > changes to existing Information Elements is avoidance of > interoperability problems; IPFIX experts appointed to review changes > to the Information Element Registry MUST work to maintain > interoperability above all else. Changes to Information Elements > already in use may only be done in an interoperable way; necessary > changes which cannot be done in a way to allow interoperability with > unchanged implementations MUST result in deprecation. > > A change to an Information Element is held to be interoperable only > when: > > o it involves the correction of an error which is obviously only > editorial; or > > o it corrects an ambiguity in the Information Element's definition, > which itself leads to non-interoperability (e.g., a prior change > to ipv6ExtensionHeaders); or > > o it expands the Information Element's data type without changing > how it is represented (e.g., changing unsigned32 to unsigned64, as > with a prior change to selectorId); or Note that this could have caused interop issues. However, nobody said they had implemented or were using it at the time, so it was possible to change. > o it defines a previously undefined or reserved enumerated value, or > one or more previously reserved bits in an Information Element > with flag semantics; or > > o it expands the set of permissible values in the Information > Element's range; or Again, that could cause interop issues. eg, you claim your collector supports IPFIX. I also claim to export IPFIX, and export some bits that you didn't know about when you wrote the collector. Your collector can't interpret those bits... > o it harmonizes with an external reference which was itself > corrected. > > > > > Trammell& Claise Expires September 8, 2012 [Page 14] > > Internet-Draft IPFIX IE-DOCTORS March 2012 > > > A non-interoperable Information Element change may also be made if it > can be reasonably assumed in the eyes of the appointed experts that > no unchanged implementation of the Information Element exists; this > can be held to happen if a non-interoperable change to an Information > Element defined shortly before is proposed to the IPFIX mailing list "Element _is_ defined" ? > by the original proposer of the Information Element, and no objection > is raised within a reasonable amount of time, to be defined by the > expert reviewers. > > If a change is permissible, it is sent to IANA, which passes it to So, the requester decides whether the change is permissible? > the appointed experts for review; if there is no objection to the > change from any appointed expert, IANA makes the change in the > Information Element Registry. The requestor of the change is > appended to the Requestor in the registry. The registry should record the original requester + date + modifier + date + details of modification. See below. > Each Information Element in the IANA registry has a revision number, > starting at zero. Each change to an Information Element following > this process increments the revision number by one. Since any > revision must be interoperable according to the criteria above, there > is no need for the IANA registry to store information about old > revisions. I'd prefer revision dates, so changes since the last time can easily be discovered. Info about old revisions should be stored, so I can discover exactly what an IPFIX device does / doesn't support when it's claimed to support IPFIX as at 1-1-2012, eg. > 5.3. Deprecating Information Elements > > Changes that are not permissible by these criteria may only be > handled by deprecation. An Information Element MAY be deprecated and > replaced when: > > o the Information Element definition has an error or shortcoming > which cannot be permissibly changed as above; or > > o the deprecation harmonizes with an external reference which was > itself deprecated through that reference's accepted deprecation > method; or > > o changes in the IPFIX Protocol or its extensions, or in community > understanding thereof, allow the information represented by the > Information Element to be represented in a more efficient or > convenient way. Deprecation in this circumstance additionally > requires the assent of the IPFIX Working Group, and should be > specified in the Internet Draft(s) defining the protocol change. > > A request for deprecation is sent to IANA, which passes it to the IE- > DOCTORS for review, as above. When deprecating an Information For clarity, say "as in 5.1 above". > Element, the Information Element description MUST be updated to > explain the deprecation, as well as to refer to any new Information > Elements created to replace the deprecated Information Element. The > revision number of an Information Element is incremented upon > > > > Trammell& Claise Expires September 8, 2012 [Page 15] > > Internet-Draft IPFIX IE-DOCTORS March 2012 > > > deprecation. > > Deprecated Information Elements SHOULD continue to be supported by > Collecting Processes, but SHOULD NOT be exported by Exporting ** ** That's impossible. If someone causes a certain IE to be deprecated, none of the existing implementations is going to change. They're going to carry right on exporting the same info they always have been. Then new releases which don't make any change in the area of the deprecated IE will continue to export the deprecated IE to avoid the situation where existing devices export IE#x while new devices export IE#y, although these are both observing the same thing. Besides, collectors which haven't been updated since the deprecation won't understand IE#y, so the updated EP will now be seen to be "broken". Even those CPs which have been updated may not equate x with y, or translate between them - so there could be issues comparing or processing pre-change data with post-change data. > Processes. The use of deprecated Information Elements SHOULD result > in a log entry or human-readable warning at the Exporting and > Collecting Processes. How do you propose that existing implementations become aware of the deprecation? > After a period of time determined in the eyes > of the IE-DOCTORS experts to be reasonable in order to allow deployed > Exporting Processes to be updated to account for the deprecation, a > deprecated Information Element may be made obsolete. Obsolete > Information Elements MUST NOT be supported by either Exporting or > Collecting Processes. The receipt of obsolete Information Elements ** ** Nope, not happening. I can't force my customers to upgrade just because some 3rd party says so. > SHOULD be logged by the Collecting Process. > > Names of deprecated Information Elements MUST NOT be reused. Names > of obsolete Information Elements MAY be reused, but this is NOT > RECOMMENDED, as it may cause confusion among users. For simplicity, just say "not reused" here too. > 5.4. Versioning the entire IANA Registry > > Consider a typical Collector implementation, which regularly > downloads the entire registry in order to be compliant with the > latest of set of supported IEs. While a registry revision number Consider an implementation which does not, because it's not connected to public networks, or because the operator is concerned about the risks of installing such an update. > might seems advantageous for the Collector at first glance (avoiding > the one by one comparison of all IE revisions), it is not necessary, > as the IPFIX IANA registry specifies the date at which the registry > was last updated in the "Last Updated" field. For purposes of > identifying the latest set of Information Element versions specified > in registry, the last revision date of the Information Element > registry (available in the registry XML source, or from the Last- > Modified: header of [iana-ipfix-assignments]) SHOULD be used. That date tells whether the registry was updated. However, without individual IE versioning, we can't know which IE(s) the update applies to. > > 6. When not to define new Information Elements P. From paitken@cisco.com Tue Jul 17 15:41: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 AE38F11E80D0 for ; Tue, 17 Jul 2012 15:41:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.329 X-Spam-Level: X-Spam-Status: No, score=-10.329 tagged_above=-999 required=5 tests=[AWL=-0.030, BAYES_00=-2.599, GB_I_LETTER=-2, MANGLED_PENIS=2.3, 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 TI7H0BAifv4S for ; Tue, 17 Jul 2012 15:41:34 -0700 (PDT) Received: from ams-iport-4.cisco.com (ams-iport-4.cisco.com [144.254.224.147]) by ietfa.amsl.com (Postfix) with ESMTP id BFA0911E80B5 for ; Tue, 17 Jul 2012 15:41:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=paitken@cisco.com; l=94044; q=dns/txt; s=iport; t=1342564940; x=1343774540; h=message-id:date:from:mime-version:to:subject: content-transfer-encoding; bh=VfSiBfnG7Y5wRGZRHJFYkhd630J+ziA72KQCL1D4yXI=; b=d6hyK6+mCl2DlAc1x+khuVJEPqkdvsVWPXSA7r9pyByHOqyt63paaGMy Ei4AOuosrEqKUkZ1O5Nwckri/tAI6xDpXXMuk0i/eix/ZRDWA9zH1W4Co faB5zEOy4hobVt55UxBNT9WxwRlwXbOtUdmNHYWLuU1YdG/lhC87ijrbq M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AskQAJjpBVCQ/khN/2dsb2JhbABFsS+HVoEHgiABAQEDEwEHAR0vBAMDAQYGCSENDAoYAwIBAgEJQgEMBgIBAQULDodlBgudJKAqBIs8FAyDB4MoA5U9gRKERohKgWaCYIFVAQg X-IronPort-AV: E=Sophos;i="4.77,605,1336348800"; d="scan'208";a="6711062" Received: from ams-core-4.cisco.com ([144.254.72.77]) by ams-iport-4.cisco.com with ESMTP; 17 Jul 2012 22:42:18 +0000 Received: from [10.55.93.221] (dhcp-10-55-93-221.cisco.com [10.55.93.221]) by ams-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id q6HMgFw2020257; Tue, 17 Jul 2012 22:42:16 GMT Message-ID: <5005EA47.2090309@cisco.com> Date: Tue, 17 Jul 2012 23:42:15 +0100 From: Paul Aitken User-Agent: Mozilla/5.0 (X11; Linux i686; rv:12.0) Gecko/20120430 Thunderbird/12.0.1 MIME-Version: 1.0 To: Brian Trammell , IETF IPFIX Working Group Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [IPFIX] review of draft-ietf-ipfix-ie-doctors-03 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, 17 Jul 2012 22:41:46 -0000 Brian, All, Here with a complete review of draft-ietf-ipfix-ie-doctors-03. P. > IPFIX Working Group B. Trammell > Internet-Draft ETH Zurich > Intended status: BCP B. Claise > Expires: December 13, 2012 Cisco Systems, Inc. > June 11, 2012 > > > Guidelines for Authors and Reviewers of IPFIX Information Elements > draft-ietf-ipfix-ie-doctors-03.txt > > Abstract > > 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. > > Status of this Memo > > This Internet-Draft is submitted in full conformance with the > provisions of BCP 78 and BCP 79. > > Internet-Drafts are working documents of the Internet Engineering > Task Force (IETF). Note that other groups may also distribute > working documents as Internet-Drafts. The list of current Internet- > Drafts is at http://datatracker.ietf.org/drafts/current/. > > Internet-Drafts are draft documents valid for a maximum of six months > and may be updated, replaced, or obsoleted by other documents at any > time. It is inappropriate to use Internet-Drafts as reference > material or to cite them other than as "work in progress." > > This Internet-Draft will expire on December 13, 2012. > > Copyright Notice > > Copyright (c) 2012 IETF Trust and the persons identified as the > document authors. All rights reserved. > > This document is subject to BCP 78 and the IETF Trust's Legal > Provisions Relating to IETF Documents > (http://trustee.ietf.org/license-info) in effect on the date of > publication of this document. Please review these documents > carefully, as they describe your rights and restrictions with respect > to this document. Code Components extracted from this document must > include Simplified BSD License text as described in Section 4.e of > the Trust Legal Provisions and are provided without warranty as > described in the Simplified BSD License. > > > > Trammell& Claise Expires December 13, 2012 [Page 1] > > Internet-Draft IPFIX IE-DOCTORS June 2012 > > > Table of Contents > > 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 > 1.1. Intended Audience and Usage . . . . . . . . . . . . . . . 3 > 1.2. Overview of relevant IPFIX documents . . . . . . . . . . . 4 > 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 > 3. How to apply IPFIX . . . . . . . . . . . . . . . . . . . . . . 5 > 4. Defining new Information Elements . . . . . . . . . . . . . . 6 > 4.1. Information Element naming . . . . . . . . . . . . . . . . 7 > 4.2. Information Element data types . . . . . . . . . . . . . . 7 > 4.3. Information Element numbering . . . . . . . . . . . . . . 8 > 4.4. Ancillary Information Element properties . . . . . . . . . 9 > 4.5. Internal structure in Information Elements . . . . . . . . 9 > 4.6. Information Element multiplicity . . . . . . . . . . . . . 10 > 4.7. Enumerated Values and Subregistries . . . . . . . . . . . 11 > 4.8. Reversibility as per RFC 5103 . . . . . . . . . . . . . . 11 > 4.9. Promotion of Enterprise-Specific Information Elements . . 11 > 4.10. Avoiding Bad Ideas in Information Element Design . . . . . 12 > 5. The Information Element Lifecycle . . . . . . . . . . . . . . 13 > 5.1. The IE-DOCTORS process . . . . . . . . . . . . . . . . . . 13 > 5.2. Revising Information Elements . . . . . . . . . . . . . . 14 > 5.3. Deprecating Information Elements . . . . . . . . . . . . . 15 > 5.4. Versioning the entire IANA Registry . . . . . . . . . . . 16 > 6. When not to define new Information Elements . . . . . . . . . 16 > 6.1. Maximizing reuse of existing Information Elements . . . . 16 > 6.2. Applying enterprise-specific Information Elements . . . . 18 > 7. Information Element Definition Checklist . . . . . . . . . . . 18 > 8. Applying IPFIX to non-Flow Applications . . . . . . . . . . . 21 > 9. Writing Internet-Drafts for IPFIX Applications . . . . . . . . 21 > 9.1. Example Information Element Definition . . . . . . . . . . 22 > 9.2. Defining Recommended Templates . . . . . . . . . . . . . . 23 > 10. A Textual Format for Specifying Information Elements and > Templates . . . . . . . . . . . . . . . . . . . . . . . . . . 24 > 10.1. Information Element Specifiers . . . . . . . . . . . . . . 24 > 10.2. Specifying Templates . . . . . . . . . . . . . . . . . . . 26 > 10.3. Specifying IPFIX Structured Data . . . . . . . . . . . . . 27 > 11. Security Considerations . . . . . . . . . . . . . . . . . . . 27 > 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28 > 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 29 > 14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 29 > 14.1. Normative References . . . . . . . . . . . . . . . . . . . 29 > 14.2. Informative References . . . . . . . . . . . . . . . . . . 30 > Appendix A. Example Information Element Definitions . . . . . . . 31 > A.1. sipResponseStatus . . . . . . . . . . . . . . . . . . . . 31 > A.2. duplicatePacketDeltaCount . . . . . . . . . . . . . . . . 32 > A.3. ambientTemperature . . . . . . . . . . . . . . . . . . . . 32 > Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 33 > > > > > Trammell& Claise Expires December 13, 2012 [Page 2] > > Internet-Draft IPFIX IE-DOCTORS June 2012 > > > 1. Introduction > > This document provides guidelines for the extension of the > applicability of the IP Flow Information Export (IPFIX) protocol to > network operations and management purposes outside the initial scope > defined in "IPFIX Applicability Statement" [RFC5472]. These new > applications are largely defined by creating new Information Elements > beyond those in the IANA IPFIX Information Element Registry > [iana-ipfix-assignments]. New applications may be further specified > through additional RFCs defining and describing their usage. > > We intend this document to enable the expansion of the applicability > of IPFIX to new areas by experts in the working group or area > directorate concerned with the technical details of the protocol or > application to be measured or managed using IPFIX. This expansion > would occur with the consultation of IPFIX experts informally called > 'IE-Doctors'. It provides guidelines both for those defining new Although I personally prefer lowercase, the main usage throughout the doc is "IE-DOCTORS". > Information Elements as well as the IE-Doctors reviewing them. Again, "IE-DOCTORS". Else, change the remainder of the doc. > > 1.1. Intended Audience and Usage > > This document is meant for two separate audiences. For IETF > contributors extending the applicability of IPFIX, it provides > specifications and best practices to be used in deciding which > Information Elements are necessary for a given existing or new > application, defining these Information Elements, and deciding > whether an RFC should be published to further describe the > application. For the IPFIX experts appointed as IE-Doctors, and for From here on, it's exclusively "IE-DOCTORS". > IANA personnel changing the Information Element registry, it defines > a set of acceptance criteria against which these proposed Information > Elements should be evaluated. > > This document is not intended to guide the extension of the IPFIX > protocol itself, e.g. through new export mechanisms, data types, or > the like; these activities should be pursued through the publication > of standards-track RFCs by the IPFIX Working Group. > > This document, together with > [I-D.ietf-ipfix-information-model-rfc5102bis], defines the procedures > for management of the IANA IPFIX Information Element Registry > [iana-ipfix-assignments]. The practices outlined in this document > are intended to guide experts when reviewing additions or changes to > the Information Elements in the registry under Expert Review as > defined in [RFC5226]. > > > > > > > > Trammell& Claise Expires December 13, 2012 [Page 3] > > Internet-Draft IPFIX IE-DOCTORS June 2012 > > > 1.2. Overview of relevant IPFIX documents > > [I-D.ietf-ipfix-protocol-rfc5101bis] defines the IPFIX Protocol, the > IPFIX-specific terminology used by this document, and the data type > encodings for each of the data types supported by IPFIX. > > [I-D.ietf-ipfix-information-model-rfc5102bis] defines the basis of > the IPFIX Information Model, referring to [iana-ipfix-assignments] > for the specific Information Element definitions. It states that new > Information Elements may be added to the Information Model on Expert > Review basis, delegates the appointment of experts to an IESG Area > Director, and refers to this document for details on the extension > process. This document is intended to further codify the best > practices to be followed by these experts, in order to improve the > efficiency of this process. > > [RFC5103] defines a method for exporting bidirectional flow > information using IPFIX; this document should be followed when > extending IPFIX to represent information about bidirectional network > interactions in general. Additionally, new Information Elements > should be annotated for their reversibility or lack thereof as per > this document. > > [RFC5610] defines a method for exporting information about > Information Elements inline within IPFIX. In doing so, it explicitly > defines a set of restrictions on the use of data types and semantics > which are implied in [I-D.ietf-ipfix-protocol-rfc5101bis] and > [I-D.ietf-ipfix-information-model-rfc5102bis]; these restrictions > must be observed in the definition of new Information Elements, as in > Section 4.4. > > > 2. Terminology > > Capitalized terms used in this document that are defined in the > Terminology section of [I-D.ietf-ipfix-protocol-rfc5101bis] are to be > interpreted as defined there. > > An "application", as used in this document, refers to a candidate > protocol, task, or domain to which IPFIX export, collection, and/or > storage is applied, beyond those within the IPFIX Applicability > statement [RFC5472]. By this definition, PSAMP [RFC5476] was the > first new IPFIX application after the publication of the IPFIX > protocol itself. > > "IANA registry", as used in this document, unless otherwise noted, > refers to the IANA IPFIX Information Element Registry > [iana-ipfix-assignments]. > > > > Trammell& Claise Expires December 13, 2012 [Page 4] > > Internet-Draft IPFIX IE-DOCTORS June 2012 > > > The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", > "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this > document are to be interpreted as described in [RFC2119]. > > > 3. How to apply IPFIX > > Though originally specified for the export of IP flow information, > the message format, template mechanism, and data model specified by > IPFIX lead to it being applicable to a wide variety of network > management situations. In addition to flow information export, for > which it was designed, and packet information export as specified by > PSAMP [RFC5476], any application with the following characteristics > is a good candidate for an IPFIX application: > > o The application's data flow is fundamentally unidirectional. > IPFIX is a "push" protocol, supporting only the export of > information from a sender (an Exporting Process) to a receiver (a > Collecting Process). Request-response interactions are not > supported by IPFIX. > > o The application handles discrete event information, or information > to be periodically reported. IPFIX is particularly well suited to > representing events, which can be scoped in time. > > o The application handles information about network entities. > IPFIX's information model is network-oriented, so network > management applications have many opportunities for information > model reuse. > > o The application requires a small number of arrangements of data > structures relative to the number of records it handles. The > template-driven self-description mechanism used by IPFIX excels at > handling large volumes of identically structured data, compared to > representations which define structure inline with data (such as > XML). > > Most applications meeting these criteria can be supported over IPFIX. > Once it's been determined that IPFIX is a good fit, the next step is > determining which Information Elements are necessary to represent the > information required by the application. Especially for network- > centric applications, the IPFIX Information Element registry may > already contain all the necessary Information Elements (see > Section 6.1 for guidelines on maximizing Information Element reuse). > In this case, no additional work within the IETF is necessary: simply > define Templates and start exporting. Is requesting new IEs from IANA work within the IETF? > > It is expected, however, that most applications will be able to reuse > > > > Trammell& Claise Expires December 13, 2012 [Page 5] > > Internet-Draft IPFIX IE-DOCTORS June 2012 > > > some existing Information Elements, but may need to define some > additional Information Elements to support all their requirements; in > this case, see Section 4 for best practices to be followed in > defining Information Elements. > > Optionally, a Working Group or individual contributor may choose to > publish an RFC detailing the new IPFIX application. Such an RFC > should contain discussion of the new application, the Information > Element definitions as in Section 4, as well as suggested Templates > and examples of the use of those Templates within the new application > as in Section 9.2. Section 10 defines a compact textual Information > Element notation to be used in describing these suggested Templates > and/or the use of IPFIX Structured Data [RFC6313] within the new > application. > > > 4. Defining new Information Elements > > In many cases, a new application will require nothing more than a new > Information Element or set of Information Elements to be exportable > using IPFIX. An Information Element meeting the following criteria, > as evaluated by appointed IPFIX experts, is eligible for inclusion in Who are the "appointed IPFIX experts" ? Preferably, avoid using both "experts" and "IE-Doctors" except once to clarify that doctors == experts. > the Information Element registry: > > o The Information Element MUST be sufficiently unique within the > registry. Its description MUST represent a substantially > different meaning from that of any existing Information Element. > A proposed Information Element which is a substantial duplicate of > an existing Information Element is to be represented using the > existing Information Element. This is too vague. How much is "substantial" ? > > o The Information Element SHOULD contain minimal internal structure; > complex information should be represented with multiple simple > Information Elements to be exported in parallel, as in > Section 4.5. I've been advocating the opposite principle, since multiple fields can potentially be re-arranged or removed by intermediate processes which are unaware of their intended inter-relationships, thus leading to loss of the complex information. Structured data should be used. > > o The Information Element SHOULD be generally applicable to the > application at hand, which SHOULD be of general interest to the > community. Information Elements representing information about > proprietary or nonstandard applications SHOULD be represented > using enterprise-specific Information Elements as detailed in > section 3.2 [RFC-EDITOR NOTE: verify section number] of > [I-D.ietf-ipfix-protocol-rfc5101bis]. > > The definition of new Information Elements requires a descriptive > name, a specification of the data type as one from the IPFIX Data Remove "as one" ? > Type Registry, and a human-readable description written in English. > This section provides guidelines on each of these components of an > > > > Trammell& Claise Expires December 13, 2012 [Page 6] > > Internet-Draft IPFIX IE-DOCTORS June 2012 > > > Information Element definition, referring to existing documentation > such as [I-D.ietf-ipfix-information-model-rfc5102bis] as appropriate. > > 4.1. Information Element naming > > Information Element Names should be defined in accordance with > section 2.3 [RFC-EDITOR NOTE: verify section number] of > [I-D.ietf-ipfix-information-model-rfc5102bis]; the most important > naming conventions are repeated here for convenience. > > o Names of Information Elements SHOULD be descriptive. > > o Names of Information Elements MUST be unique within the registry. > > o Names of Information Elements MUST start with non-capitalized > letters. > > o Composed names MUST use capital letters for the first letter of > each component except for the first one. All other letters are > non-capitalized, even for acronyms. Exceptions are made for > acronyms containing non-capitalized letters, such as 'IPv4' and > 'IPv6'. Examples are "sourceMacAddress" and > "destinationIPv4Address." > > In addition, new Information Elements pertaining to a specific > protocol SHOULD name the protocol in the first word in order to ease > searching by name (e.g. "sipMethod" for a SIP method, as would be > used in a logging format for SIP based on IPFIX). Similarly, new > Information Elements pertaining to a specific application SHOULD name > the application in the first word. > > 4.2. Information Element data types > > IPFIX provides a set of data types covering most primitives used in > network measurement and management applications. The most > appropriate data type should be chosen for the Information Element > type, out of the IPFIX informationElementDataTypes subregistry at > [iana-ipfix-assignments]. > > Information Elements representing an integral value with a natural > width SHOULD be defined with the appropriate integral data type. > This applies especially to values taken directly from fixed-width > fields in a measured protocol. For example, tcpControlBits, the TCP > flags byte, is an unsigned8, and tcpSequenceNumber is an unsigned32. > > Information Elements representing counters or identifiers SHOULD be > defined as signed64 or unsigned64, as appropriate, to maximize the > range of values available; applications can to use reduced-size > > > > Trammell& Claise Expires December 13, 2012 [Page 7] > > Internet-Draft IPFIX IE-DOCTORS June 2012 > > > encoding as defined in Section 6.2 [RFC-EDITOR NOTE: verify section > number] of [I-D.ietf-ipfix-protocol-rfc5101bis] in cases where fewer > than 2^64 values are necessary. > > Information Elements representing time values MUST be defined with > appropriate precision. For example, a Information Element for a time > measured at second-level precision should be defined as having a > dateTimeSeconds data type, instead of dateTimeMilliseconds. > > Information Elements of type string or octetArray which have length > constraints (fixed length, minimum and/or maximum length) MUST note > these constraints in their description. > > The type of an Information Element MUST match the type of the data it > represents. More specifically, information that could be represented > as a String, but which better matches one of the other data types Why is "String" capitalised? > (e.g. an integral type for a number or enumerated type, an address > type for an address) MUST be represented by the best-matching type, > even if the data was represented using a different type in the > source. In other words, an IPFIX application that exports Options > Template Records mapping IP addresses to additional information about > each host from an external database MUST use Information Elements of > an address type to represent the addresses, even if the source > database represented these as strings. > > This document does not cover the addition of new Data Types or Data > Type Semantics to the IPFIX Protocol. As such changes have important > interoperability considerations and require implementation on both > Collecting and Exporting Processes, they require a Standards Action > as per [RFC5610]. However, note that the set of primitive types > provided by IPFIX are applicable to most any appropriate application, Typo, "most any". > so extending the type system is generally not necessary. > > 4.3. Information Element numbering > > Each Information Element have a unique identifier in the IANA s/have/has/ > registry. > > In general, when adding newly registered Information Elements to the > registry, IANA SHOULD assign the lowest available Information Element > identifier (the value column in [iana-ipfix-assignments] in the range > 128-32767, noting that prior noncontiguous allocation may lead to What should they do when that range is exhausted? (Or preferably, prior to that.) > unassigned Information Elements with lower Information Element > identifiers than some presently assigned Information Elements. This > is the case with the PSAMP Information Model [RFC5477], which > assigned a block of Information Elements identifiers starting at 300. This no longer applies: all IDs between 128 and 364+ are assigned, with the exception of 312 and 315 which should soon be assigned for layer2 fields (see ietf-ipfix-data-link-layer-monitoring), and 359/360 which have been assigned without updating the registry. (IANA is a bit slow about that.) > > Information Element identifiers in the range 1-127 MUST NOT be > > > > Trammell& Claise Expires December 13, 2012 [Page 8] > > Internet-Draft IPFIX IE-DOCTORS June 2012 > > > assigned unless the Information Element is compatible with the > NetFlow V9 protocol as described in [RFC3954]. Such Information > Elements may ONLY be requested by a NetFlow v9 expert, to be > designated by the IESG to consult with IANA on NetFlow v9 > compatibility with IPFIX. Hopefully the necessary IESG actions are listed later in the document. > > 4.4. Ancillary Information Element properties > > Information Elements to which special semantics apply SHOULD define > these semantics with one of the values in the Information Element > Semantics registry, as described in Section 3.2 [RFC-EDITOR NOTE: > verify section number] of > [I-D.ietf-ipfix-information-model-rfc5102bis], subject to the > restrictions given in Section 3.10 of [RFC5610]; in other words, the > semantics and the type MUST be consistent. > > When defining Information Elements representing a dimensioned > quantity or entity count, the units of that quantity SHOULD be > defined in the units field. This field takes its values from the > IANA Information Element Units registry. If an Information Element > expresses a quantity in units not yet in this registry, then the unit > MUST be added to the Units registry at the same time the Information > Element is added to the Information Element registry. Clarify whether the addition of new units requries, or does not require, a standards action. > > Additionally, when the range of values an Information Element can > take is smaller than the range implied by its data type, the range > SHOULD be defined within the Information Element registry. > > 4.5. Internal structure in Information Elements > > The definition of Information Elements with internal structure with > the structure defined in the Description field is NOT RECOMMENDED, > except in the following cases: > > o The Information Element is a direct copy of a structured entity in > a measured protocol (e.g. the tcpControlBits Information Element > for the flags byte from the TCP header) > > o The Information Element represents a section of a packet of > protocol entity, in raw form as captured from the wire (e.g. the > mplsLabelStackSection Information Element for the MPLS label > stack) > > o The Information Element represents a set of flags which are > tightly semantically related, where representing the flags as > separate one-byte booleans would be inefficient, and which should > always appear together in a data record (e.g., the > anonymizationFlags Information Element for specifying optional > > > > Trammell& Claise Expires December 13, 2012 [Page 9] > > Internet-Draft IPFIX IE-DOCTORS June 2012 > > > features of anonymization techniques) > > In other cases, candidate Information Elements with internal > structure SHOULD be decomposed into multiple primitive Information > Elements to be used in parallel. For more complicated semantics, > where the structure is not identical from Data Record to Data Record, > or where there is semantic dependency between multiple decomposed > primitive Information Elements, use the IPFIX Structured Data > [RFC6313] extension instead. > > As an example of information element decomposition, consider an > application-level identifier called an "endpoint", which represents a > {host, port, protocol} tuple. Instead of allocating an opaque, > structured "source endpoint" Information Element, the source endpoint > should be represented by three separate Information Elements: "source > address", "source port", "transport protocol". In this example, the This might cause multiple instances of the same IEs in the data record. (eg, if there are already "source address" and "source port" IEs in the flow). I'm often asked whether this is allowed; AFAIK it's not explicitly stated in any IPFIX docs. See below. Further, this decomposition may lead to confusion about which "source address" and "source port" to combine with the "transport protocol" to re-form the "endpoint", since the data record may be: { ..., source address, source port, transport protocol, source address, source port, ... } Or worse, if the original flow already contained all three (address, port, protocol), then the endpoint decomposition would make the data record look like it contained 2 x "endpoint": { ..., source address, source port, transport protocol, source address, source port, transport protocol, ... } So the decomposed element SHOULD be grouped in a structured data - and that becomes a MUST if there are any other instances of those IEs in the data record. > required information elements already exist in the Information > Element registry: sourceIPv4Address or sourceIPv6Address, > sourceTransportPort, protocolIdentifier. Indeed, as well as being > good practice, this normalization down to non-structured Information > Elements also increases opportunities for reuse as in Section 6.1. > > The decomposition of data with internal structure SHOULD avoid the > definition of Information Elements with a meaning too specific to be > generally useful, or that would result in either the export of > meaningless data or a multitude of templates to handle different Not clear what "too specific to be generally useful" and "meaningless data" mean. > multiplicities. More information on multiplicities is given in the > following section. > > 4.6. Information Element multiplicity > > Some Information Elements may represent information with a > multiplicity other than one; i.e., items that may occur multiple > times within the data to be represented in a single IPFIX record. In > this case, there are several options, depending on the circumstances: > > o As specified in section 8 [RFC-EDITOR NOTE: verify section number] > of [I-D.ietf-ipfix-protocol-rfc5101bis]: "if an Information > Element is required more than once in a Template, the different > occurrences of this Information Element SHOULD follow the logical > order of their treatments by the Metering Process." In other > words, in cases where the items have a natural order (e.g., the > order in which they occur in the packet), and the multiplicity is > the same for each record, the information can be modeled by > containing multiple instances of the Information Element > representing a single item within the Template Record describing > the Data Records. > > > > > Trammell& Claise Expires December 13, 2012 [Page 10] > > Internet-Draft IPFIX IE-DOCTORS June 2012 > > > o In cases where the items have a variable multiplicity, a basicList > of the Information Element representing a single item can be used > as in the IPFIX Structured Data [RFC6313] extension. Clarify that given the decomposition above, it would be utterly wrong to encode the multiple "source address" and "source port" instances in 2 x basicList. - most especially in the first case I gave, where one pair of "source address" and "source port" instances are unrelated to the other pair which come from the decomposition. > > o If the multiple-item structure is taken directly from bytes > observed on the wire by the Metering Process or otherwise taken > from the application being measured, the multiple-item structure > can be exported as a variable-length octetArray Information > Element holding the raw content. > > Specifically, new Information Element SHOULD NOT encode any > multiplicity or ordinality information into the definition of the > Information Element itself. > > 4.7. Enumerated Values and Subregistries > > When defining an Information Element that takes an enumerated value > from a set of values which may change in the future, this enumeration > MUST be defined by an IANA registry or subregistry. For situations > where an existing registry defines the enumeration (e.g., the IANA > Protocol Numbers registry for the protocolIdentifier Information > Element), that registry MUST be used. Otherwise, a new IPFIX > subregistry MUST be defined for the enumerated value, to be modified > subject to Expert Review [RFC5226]. > > 4.8. Reversibility as per RFC 5103 > > [RFC5103] defines a method for exporting bidirectional flows using a > special Private Enterprise Number to define reverse-direction > variants of IANA Information Elements, and a set of criteria for > determining whether an Information Element may be reversed using this > method. Since almost all Information Elements are reversible, > [RFC5103] enumerates those which Information Elements which were > defined at the time of its publication which are NOT reversible. > > New non-reversible Information Elements SHOULD contain a note in the > description stating that they are not reversible. This information MUST be captured in IANA's IPFIX registry. It currently is not, so all existing IEs must be reviewed for reversibility. > > 4.9. Promotion of Enterprise-Specific Information Elements > > Some Information Elements may start their lifecycle outside the IANA > registry as enterprise-specific Information Elements scoped to a > Private Enterprise Number. One stated goal of enterprise-specific > Information Elements is pre-standards product delivery and > experimentation; should these experiments be successful and the > Information Elements generally useful, these SHOULD subsequently > registered with IANA. > > > > > Trammell& Claise Expires December 13, 2012 [Page 11] > > Internet-Draft IPFIX IE-DOCTORS June 2012 > > > In order to support transition from experimental registration to IANA > registration, the IANA registry provides an optional "enterprise- You're talking about a new version of the registry which isn't yet public? ** It needs to be public so it can be reviewed prior to this document being approved. > specific IE reference" column for each Information Element. In cases > of promoted enterprise-specific Information Elements, this column in > the registry MAY contain the private enterprise and Information > Element numbers of the enterprise-specific version(s) of the > Information Element. NB there may be multiple ES versions, where different companies were developing essentially the same thing. > > 4.10. Avoiding Bad Ideas in Information Element Design > > In general, the existence of a similarly-defined Information Element > in the IANA registry sets a precedent which may be followed to > determine whether a given proposed Information Element "fits" within > the registry. Indeed, the rules specified by this document could be > interpreted to mean "make new Information Elements that look like > existing Information Elements". However, for reasons of history, > there are several Information Elements within the IANA registry which > do not follow best practices in Information Element design. These > Information Elements are not necessarily so flawed so as to require > deprecation, but they should be explicitly ignored when looking for > guidance as to whether a new Information Element should be added. Perhaps that should be indicated by a special status in the registry, because the registry - rather than this document - will be the primary reference and guide for new IEs. > > Before registering a new Information Element, it must be determined > that it would be sufficiently unique within the registry. This > evaluation has not always been done in the past, and the existence of > the Information Elements defined without this evaluation should not > be taken as an example that such Information Element definition > practices should be followed in the future. Specific examples of > such Information Elements include initiatorOctets and responderOctets > (which duplicate octetDeltaCount and its reverse per [RFC5103]) and > initiatorPackets and responderPackets (the same, for > packetDeltaCount). Not necessarily: it's possible that these represent total counts rather than delta counts. I'm currently checking this internally within Cisco. > > As mentioned in Section 4.2, the type of an Information Element > SHOULD match the type of data the Information Element represents. An > example of how not to do this is presented by the p2pTechnology, > tunnelTechnology, and encryptedTechnology Information Elements: these > represent a three-state enumeration using a String. The example set > by these Information Elements SHOULD NOT be followed in the > definition of new Information Elements. > > As mentioned in Section 4.6, an Information Element definition SHOULD > NOT include any ordinality or multiplicity information. The only > example of this within the IANA registry the following list of > assigned IPFIX Information Elements: mplsTopLabelStackSection, > mplsLabelStackSection2, mplsLabelStackSection3, > mplsLabelStackSection4, mplsLabelStackSection5, > mplsLabelStackSection6 mplsLabelStackSection7, > > > > Trammell& Claise Expires December 13, 2012 [Page 12] > > Internet-Draft IPFIX IE-DOCTORS June 2012 > > > mplsLabelStackSection8, mplsLabelStackSection9, and > mplsLabelStackSection10. The only distinction between those almost- > identical Information Elements is the position within the MPLS stack. > This Information Element design pattern met an early requirement of > the definition of IPFIX which was not carried forward into the final > specification -- namely, that no semantic dependency was allowed > between Information Elements in the same Record -- and as such SHOULD > NOT be followed in the definition of new Information Elements. In > this case, since the size of the MPLS stack will vary from flow to > flow, it should be exported using IPFIX Structured Data [RFC6313] > where supported, as a basicList of MPLS label entries, or as a raw There's no existing IE on which to base that basicList. A basicList of mplsTopLabelType would be wrong. > MPLS label stack using the variable-length mplsLabelStackSection > Information Element. > > > 5. The Information Element Lifecycle > > Once an Information Element or set of Information Elements has been > identified for a given application, Information Element > specifications in accordance with Section 4 are submitted to IANA to How are requests submitted to IANA? > follow the IE-DOCTORS process, as defined below. This process is > also used for other changes to the registry, such as deprecation or > revision, as described later in this section. > > 5.1. The IE-DOCTORS process > > Requests to change the IANA Information Element registry or a linked > subregistry are submitted to IANA, which forwards the request to a > designated group of experts (IE-DOCTORS) appointed by the IESG. This How does the IESG appoint / evaluate / remove doctors? > group of experts reviews the request for such things as compliance > with this document, compliance with other applicable IPFIX-related > RFCs, and consistency with the currently defined set of Information > Elements. > > Authors are expected to review compliance with the specifications in > this document to check their submissions before sending them to IANA. > > IE-DOCTORS reviewers should endeavor to complete referred reviews in > a timely manner. If the request is acceptable, the IE-DOCTORS > signify their approval to IANA, which changes the IANA Information > Element registry. If the request is not acceptable, the IE-DOCTORS > can coordinate with the requestor to change the request to be Typo, "requester". > compliant. The IE-DOCTORS may also choose in exceptional > circumstances to reject clearly frivolous or inappropriate change > requests outright. Do requesters have no right of appeal? > > > > > > > Trammell& Claise Expires December 13, 2012 [Page 13] > > Internet-Draft IPFIX IE-DOCTORS June 2012 > > > 5.2. Revising Information Elements > > The Information Element status field in the Information Element > Registry is defined in [I-D.ietf-ipfix-information-model-rfc5102bis] > to allow Information Elements to be 'current', 'deprecated' or > 'obsolete'. No Information Elements are as of this writing > deprecated or obsolete, and > [I-D.ietf-ipfix-information-model-rfc5102bis] does not define any > policy for using them. Additionally, no policy is defined for > revising Information Element registry entries or addressing errors > therein. To be certain, changes and deprecations within the > Information Element registry are not encouraged, and should be > avoided to the extent possible. However, in recognition that change > is inevitable, this section is intended to remedy this situation. > > The primary requirement in the definition of a policy for managing > changes to existing Information Elements is avoidance of > interoperability problems; IPFIX experts appointed to review changes > to the Information Element Registry MUST work to maintain > interoperability above all else. Changes to Information Elements > already in use may only be done in an interoperable way; necessary > changes which cannot be done in a way to allow interoperability with > unchanged implementations MUST result in deprecation. > > A change to an Information Element is held to be interoperable only > when: > > o it involves the correction of an error which is obviously only > editorial; or > > o it corrects an ambiguity in the Information Element's definition, > which itself leads to non-interoperability severe enough to > prevent the Information Element's usage as originally defined > (e.g., a prior change to ipv6ExtensionHeaders); or > > o it expands the Information Element's data type without changing > how it is represented (e.g., changing unsigned32 to unsigned64, as > with a prior change to selectorId); or Then why don't we revise the registry to say "u64" for all current 8/16/32 bit fields? > > o it defines a previously undefined or reserved enumerated value, or > one or more previously reserved bits in an Information Element > with flag semantics; or > > o it expands the set of permissible values in the Information > Element's range; or This may introduce non-interoperability, eg an exporting process implementing the new value while the collecting process does not. > > o it harmonizes with an external reference which was itself > corrected. > > > > Trammell& Claise Expires December 13, 2012 [Page 14] > > Internet-Draft IPFIX IE-DOCTORS June 2012 > > > If a change is permissible, it is sent to IANA, which passes it to > the appointed experts for review; if there is no objection to the Who is deciding what's permissible, and who are the experts? ie, if ie-doctors decide the permissibility, then the experts are some other group? Else, if the experts are IE-doctors then (a) say so, and (b) who's deciding permissibility? > change from any appointed expert, IANA makes the change in the > Information Element Registry. The requestor of the change is Typo, "requester". > appended to the Requestor in the registry. Typo, "Requester". > > Each Information Element in the IANA registry has a revision number, > starting at zero. Each change to an Information Element following > this process increments the revision number by one. Since any > revision must be interoperable according to the criteria above, there > is no need for the IANA registry to store information about old > revisions. These revision numbers aren't in the current registry. Do you propose to start all fields from 1? > > 5.3. Deprecating Information Elements > > Changes that are not permissible by these criteria may only be > handled by deprecation. An Information Element MAY be deprecated and Not so: it may be perfectly fine to retain the old IE and provide new functionality through one or more new IEs. > replaced when: > > o the Information Element definition has an error or shortcoming > which cannot be permissibly changed as above; or > > o the deprecation harmonizes with an external reference which was > itself deprecated through that reference's accepted deprecation > method; or > > o changes in the IPFIX Protocol or its extensions, or in community > understanding thereof, allow the information represented by the > Information Element to be represented in a more efficient or > convenient way. Deprecation in this circumstance additionally > requires the assent of the IPFIX Working Group, and should be > specified in the Internet Draft(s) defining the protocol change. The IPFIX WG is fluid and non-permanent. How is the WG's assent assessed? > > A request for deprecation is sent to IANA, which passes it to the IE- > DOCTORS for review, as above. When deprecating an Information > Element, the Information Element description MUST be updated to > explain the deprecation, as well as to refer to any new Information > Elements created to replace the deprecated Information Element. The > revision number of an Information Element is incremented upon > deprecation. Should the date of deprecation also be recorded? > > Deprecated Information Elements SHOULD continue to be supported by > Collecting Processes, but SHOULD NOT be exported by Exporting > Processes. The use of deprecated Information Elements SHOULD result Good luck with that: once you've got devices in the field, you have no control over what customers will do with them. Old code may continue to be run in perpetuity. > in a log entry or human-readable warning at the Exporting and > Collecting Processes. After a period of time determined in the eyes > of the IE-DOCTORS experts to be reasonable in order to allow deployed > Exporting Processes to be updated to account for the deprecation, a > > > > Trammell& Claise Expires December 13, 2012 [Page 15] > > Internet-Draft IPFIX IE-DOCTORS June 2012 > > > deprecated Information Element may be made obsolete. Obsolete > Information Elements MUST NOT be supported by either Exporting or Again, good luck with that. > Collecting Processes. The receipt of obsolete Information Elements > SHOULD be logged by the Collecting Process. > > Names of deprecated or obsolete Information Elements MUST NOT be > reused. > > 5.4. Versioning the entire IANA Registry > > Consider a typical Collector implementation, which regularly > downloads the entire registry in order to be compliant with the > latest of set of supported IEs. While a registry revision number > might seems advantageous for the Collector at first glance (avoiding > the one by one comparison of all IE revisions), it is not necessary, > as the IPFIX IANA registry specifies the date at which the registry > was last updated in the "Last Updated" field. For purposes of > identifying the latest set of Information Element versions specified > in registry, the last revision date of the Information Element > registry (available in the registry XML source, or from the Last- > Modified: header of [iana-ipfix-assignments]) SHOULD be used. Can't document.lastModified be used? > > > 6. When not to define new Information Elements > > Due to the limited number space of Information Elements in the IANA > registry, avoiding redundancy and clutter in the Information Element > registry is important in defining new applications. New Information > Elements SHOULD NOT be added to the Information Element registry > unless there is an intent to implement and deploy applications using > them; research or experimental applications SHOULD use enterprise- > specific Information Elements as in Section 6.2 instead. > > The subsections below provide guidelines for reuse of existing > Information Elements, as well as guidelines on using enterprise- > specific Information Elements instead of adding Information Elements > in the registry. > > 6.1. Maximizing reuse of existing Information Elements > > Whenever possible, new applications should prefer usage of existing > IPFIX Information Elements to the creation of new Information > Elements. IPFIX already provides Information Elements for every > common Layer 4 and Layer 3 packet header field in the IETF protocol > suite, basic Layer 2 information, basic counters, timestamps and time > ranges, and so on. When defining a new Information Element similar > to an existing one, reviewers shall ensure that the existing one is > not applicable. Is this a specification, or is "shall" a SHOULD? > > > > Trammell& Claise Expires December 13, 2012 [Page 16] > > Internet-Draft IPFIX IE-DOCTORS June 2012 > > > Note that this guideline to maximize reuse does not imply that an > Information Element that represents the same information from a > packet as a existing Information Element should not be added to the > registry. For example, consider the ipClassOfService (Element ID 5), > ipDiffServCodePoint (Element ID 98), and ipPrecedence (Element ID > 196) Information Elements. These all represent subsets of the same > field in an IP version 4 packet header, but different uses of these > bits. The representation in one or another of these Information > Elements contains information in itself as to how the bits were > interpreted by the Metering Process. > > On the other hand, simply changing the context in which an > Information Element will be used is insufficient reason for the > definition of a new Information Element. For example, an extension > of IPFIX to log detailed information about HTTP transactions > alongside network-level information should not define > httpClientAddress and httpServerAddress Information Elements, > preferring instead the use of sourceIPv[46]Address and > destinationIPv[46]Address. > > Applications dealing with bidirectional interactions should use > Bidirectional Flow Support for IPFIX [RFC5103] to represent these > interactions. > > Existing timestamp and time range Information Elements should be > reused for any situation requiring simple time stamping of an event: > for single observations, the observationTime* Information Elements > from PSAMP are provided, and for events with a duration, the > flowStart* and flowEnd* Information Elements suffice. This > arrangement allows minimal generic time handling by existing > Collecting Processes and analysis workflows. New timestamp > Information Elements should ONLY be defined for semantically distinct > timing information (e.g., an IPFIX-exported record containing > information about an event to be scheduled in the future). > > In all cases the use of absolute timestamp Information Elements (e.g. > flowStartMilliseconds) is RECOMMENDED, as these Information Elements > allow for maximum flexibility in processing with minimal overhead. > Timestamps based on the export time header in the enclosing IPFIX > Message (e.g. flowStartTimeDeltaMicroseconds) MAY be used if high- > precision timing is important, export bandwidth or storage space is > limited, timestamps comprise a relatively large fraction of record > size, and the application naturally groups records into IPFIX > Messages. Timestamps based on information which must be exported in > a separate Data Record defined by an Options Template (e.g. > flowStartSysUpTime) MAY be used only in the context of an existing > practice of using runtime-defined epochs for the given application. > New applications SHOULD avoid these structures when possible. > > > > Trammell& Claise Expires December 13, 2012 [Page 17] > > Internet-Draft IPFIX IE-DOCTORS June 2012 > > > 6.2. Applying enterprise-specific Information Elements > > IPFIX provides a mechanism for defining enterprise-specific > Infomation Elements, as in Section 3.2 [RFC-EDITOR NOTE: verify Typo, "Information". > section number] of [I-D.ietf-ipfix-protocol-rfc5101bis]. These are > scoped to a vendor's or organization's Structure of Management > Information (SMI) Private Enterprise Number, and are under complete > control of the organization assigning them. > > For situations in which interoperability is unimportant, new > information SHOULD be exported using enterprise-specific Information > Elements instead of adding new Information Elements to the registry. > These situations include: > > o export of implementation-specific information, or > > o export of information derived in a commercially-sensitive or > proprietary method, or > > o export of information or meta-information specific to a > commercially-sensitive or proprietary application. Also non-standard and research information. > > While work within the IETF generally does not fall into these > categories, enterprise-specific Information Elements are also useful > for pre-standardization testing of a new IPFIX application. While > performing initial development and interoperability testing of a new > application, the Information Elements used by the application SHOULD > NOT be submitted to IANA for inclusion in the registry. Instead, > these experimental Information Elements SHOULD be represented as > enterprise-specific until their definitions are finalized, then > transitioned from enterprise-specific to IANA-defined upon > finalization. To support this transition, the IANA registry provides > an experimental IE reference as defined in Section 4.9. > > > 7. Information Element Definition Checklist > > The following three checklists, condensed from the rest of this > document, can be used when defining and reviewing Information > Elements; they refer back to the section of this document from which > they are taken. These checklists are intended for the definition of > new Information Elements; revision should follow the process defined > in Section 5.2, and deprecation should follow the process defined in > Section 5.3. > > Though many of the considerations in this document require the > subjective judgement of Information Element authors, reviewers, and Typo, "judgment". If "reviewers" = "IE-Doctors" then say so. > IANA, certain parts of the process may be made simpler through tool > > > > Trammell& Claise Expires December 13, 2012 [Page 18] > > Internet-Draft IPFIX IE-DOCTORS June 2012 > > > support. Items on these checklists which could be easily automated > or assisted by tools are annotated with "(tool support)". Other Discuss development of these tools on the mailing list. eg, student summer project? > items on these checklists require some level of subjective judgement; Typo, "judgment". > checks for semantic uniqueness may additionally be supported by > textual analysis of descriptions in the future. > > Checklist 1 contains conditions which MUST be met by all proposed > Information Elements: > > o The name MUST be unique within the registry, and not reuse the > name of any current, deprecated, or obsolete Information Element. > (Section 4.1) (tool support) > > o The description MUST be sufficiently semantically unique within > the registry, representing a substantially different meaning from > any current, deprecated, or obsolete Information Element. > (Section 4) > > o The name MUST start with a non-capitalized letter. (Section 4.1) > (tool support) > > o Names composed of more than on word MUST use capital letters for > the first letter of each component except for the first one; all > other letters are non-capitalized, even for acronyms. Exceptions > are made for acronyms containing non-capitalized letter, such as s/letter/letters/ > 'IPv4' and 'IPv6'. (Section 4.1) (tool support) > > o The data type MUST match the type of the data being represented. > (Section 4.2) > > o Data type semantics MUST be appropriate for the data type. > (Section 4.4) (tool support) > > o The Information Element identifier assigned by IANA MUST be > unique. (Section 4.3) (tool support) > > o The Information Element identifier assigned by IANA MUST NOT be in > the range 1-127 unless it is compatible with the counterpart > Information Element used in NetFlow V9 [RFC3954]. (Section 4.3) > Please separate the lists more clearly. > Checklist 2 contains conditions which MUST be met by proposed > Information Elements with certain properties, as noted: > > o Time values MUST be defined with appropriate precision. > (Section 4.2) > > o Strings and octet arrays with length restrictions MUST note those > length restrictions in their descriptions. (Section 4.2) > > > > Trammell& Claise Expires December 13, 2012 [Page 19] > > Internet-Draft IPFIX IE-DOCTORS June 2012 > > > o Enumerations MUST refer to an IANA registry or subregistry. If no Or another external standards based enumeration, surely? > suitable registry or subregistry exists, a new subregistry of the > IPFIX Information Element registry MUST be created for the > enumeration, to be modified subject to Expert Review [RFC5226]. > (Section 4.7) Again, please clearly separate the lists. > > Checklist 3 contains conditions which SHOULD be met by proposed > Information Elements: > > o The name of an Information Element pertaining to a specific > protocol SHOULD contain the name of the protocol as the first > word. (Section 4.1) > > o The name of an Information Element pertaining to a specific > application SHOULD contain the name of the application as the > first word. (Section 4.1) What if those rules conflict? Does protocol override application, or vice versa? > > o Information Elements representing integral values SHOULD use a > data type for the appropriate width for the value. (Section 4.2) > > o Information Elements representing counters or identifiers SHOULD > be represented as signed64 or unsigned64, as appropriate. > (Section 4.2) Are 32/16/8 now deprecated types? > > o An Information Element SHOULD NOT contain internal structure, > subject to the exceptions in Section 4.5; candidate Information > Elements with internal structure SHOULD be decomposed into > multiple Information Elements. (Section 4.5) > > o An Infomation Element SHOULD NOT contain multiplicity or Typo, "Information". > ordinality information within the definition of the Information > Element itself. (Section 4.6) > > o Data type semantics SHOULD be defined, if appropriate. > (Section 4.4) (tool support) > > o Units SHOULD be defined, if appropriate, with new units added to > the Information Element Units subregistry if necessary. > (Section 4.4) (tool support) > > o Ranges SHOULD be defined, if appropriate. (Section 4.4) (tool > support) > > o Non-reversible Information Elements (see [RFC5103]) SHOULD note > non-reversibility in the description. (Section 4.8) > > o Information Elements created to replace enterprise-specific > Information Elements used for experimental or testing purposes > > > > Trammell& Claise Expires December 13, 2012 [Page 20] > > Internet-Draft IPFIX IE-DOCTORS June 2012 > > > SHOULD contain a reference to the enterprise-specific Information > Element they replace. (Section 4.9) I'm not 100% convinced about the usefulness of the enterprise-specific information in a standards document (ie, IANA's IPFIX registry). Presumably the ES info was only applicable within the enterprise, or perhaps in conjunction with a small / closed set of partners for testing - so why should it be of any relevance to the wider community? > > o The Information Element Identifier assigned by IANA for IEs not > compatible with their counterparts in NetFlow V9 SHOULD be the > lowest available identifier above 128. (Section 4.3) (tool > support) > > o Information Elements to be registered with IANA SHOULD BE intended > for implementation and deployment on production networks. > > > 8. Applying IPFIX to non-Flow Applications > > At the core of IPFIX is its definition of a Flow, a set of packets > sharing some common properties crossing an observation point within a > certain time window. However, the reliance on this definition does > not preclude the application of IPFIX to domains which are not > obviously handling flow data according to it. Most network What is "it" ? > management data collection tasks, those to which IPFIX is most > applicable, have at their core the movement of packets from one place > to another; by a liberal interpretation of the common properties > defining the flow, then, almost any event handled by these can be > held to concern data records conforming to the IPFIX definition of a > Flow. > > Non-flow information defining associations or key-value pairs, on the > other hand, are defined by IPFIX Options Templates. Here, the > Information Elements within an Options Template Record are divided > into Scope Information Elements which define the key, and non-scope > Informatin Elements which define the values associated with that key. Typo, "Information". > Unlike Flows, Data Records defined by Options Template are not > necessarily scoped in time; these Data Records are generally held to > be in effect until a new set of values for a specific set of keys is > exported. While this mechanism is often used by IPFIX to export > metadata about the collection infrastructure, it is applicable to any > association information. > > An IPFIX application can mix Data Records described either type of > template in an IPFIX Message or Message stream, and exploit > relationships among the Flow Keys, values, and Scopes to create > interrelated data structures. See [RFC5473] for an example > application of this. > > > 9. Writing Internet-Drafts for IPFIX Applications > > When a new application is complex enough to require additional > > > > Trammell& Claise Expires December 13, 2012 [Page 21] > > Internet-Draft IPFIX IE-DOCTORS June 2012 > > > clarification or specification as to the use of the defined > Information Elements, this may be given in an Internet-Draft. > Internet-Drafts for new IPFIX applications are best submitted to a > Working Group with expertise in the area of the new application, or > as independent submissions. > > When defining new Information Elements in an Internet-Draft, the > Internet-Draft SHOULD contain a section (or subsection) for each > Information Element, which contains the attributes in Section 4 in > human-readable form. An example subsection is given below. These Some drafts have included XML. Is this useful for IANA / implementers? > Information Element descriptions SHOULD NOT assign Information > Element numbers, instead using placeholder identifiers for these > numbers (e.g. "AAA", "BBB", "CCC", or "TBD1", "TBD2", "TBD3") and a Personally, I'd prefer that "TBD" be recommended, because it's easy to search and highlight all the TBD's in a draft - which isn't possible with AAA / BBB / CCC or other random indicators. > note to IANA in the IANA Considerations section to replace those > placeholders in the document with Information Element numbers when > the numbers are assigned. The use of these placeholder definitions > allows references to the numbers in e.g. box-and-line diagrams or > template definitions as in Section 10. And allow enough space in your diagrams for the replaced IDs to fit. > > 9.1. Example Information Element Definition > > This is an example of an Information Element definition which would > appear in an Internet-Draft. The name appears in the section title. > > Description: Description goes here. The description is also obligatory. > > Data Type: Data type goes here; obligatory > > Data Type Semantics: Data type semantics, if any, go here; optional > > Units: Units, if any, go here; optional > > Range: Range, if not implied by the data type, goes here; optional > > References: References to other RFCs or documents outside the IETF, > in which additional information is given, or which are referenced > by the description, go here; optional What if an IE requires citing a WIP draft? > > ElementId: ElementId, if known, or TBD to be filled in by IANA at > publication time. > > Replaces Enterprise-Specific Element: If the Information Element > replaces an existing enterprise-specific Information Element, the > PEN and Information Element number go here, separated by a slash > (e.g. 35566/123) as in Section 10. In the examples below, I saw that this format is unclear: the numbers are ambiguous (cf British versus American date formats). > > > > > > > Trammell& Claise Expires December 13, 2012 [Page 22] > > Internet-Draft IPFIX IE-DOCTORS June 2012 > > > 9.2. Defining Recommended Templates > > New IPFIX applications SHOULD NOT, in the general case, define fixed > templates for export, as this throws away much of the flexibility > afforded by IPFIX. However, fixed template export is permissible in > the case that the export implementation must operate in a resource > constrained environment, and/or that the application is replacing an > existing fixed-format binary export format in a maximally compatible > way. In any case, Collecting Processes for such applications SHOULD > support reordered Templates or Templates with additional Information > Elements. Especially considering that an intermediate IPFIX mediation process could do anything to that template. > > An Internet-Draft clarifying the use of new Information Elements > SHOULD include any recommended Template or Options Template Records > necessary for supporting the application, as well as examples of > records exported using these Template Records. In defining these > Template Records, such Internet-Drafts SHOULD mention, subject to > rare exceptions as above: > > o that the order of Information Elements within a Template is not > significant; See what I said earlier about decomposition which results in multiple instances of an IE in a data record: in that case order is crucial (unless structured data is used), though this may not be at all obvious at first glance. > > o that Templates on the wire for the application may also contain > additional Information Elements beyond those specified in the > recommended Template; > > o that a stream of IPFIX Messages supporting the application may > also contain Data Records not described by the recommended > Templates; and > > o that any reader of IPFIX Messages supporting the application MUST > accept these conditions. > > Definitions of recommended Template Records for flow-like > information, where the Flow Key is well-defined, SHOULD indicate > which of the Information Elements in the recommended Template are > Flow Keys. > > Recommended Templates are defined, for example, in [RFC5476] for > PSAMP packet reports (section 6.4) and extended packet reports > (section 6.5). Recommended Options Templates are defined extensively > throughout the IPFIX documents, including in the protocol document > itself [I-D.ietf-ipfix-protocol-rfc5101bis] for exporting export > statistics; in the file format [RFC5655] for exporting file metadata; > and in Mediator intermediate process definitions such as [RFC6235] > for intermediate process metadata. The discussion in these examples > is a good model for recommended template definitions. > > > > > Trammell& Claise Expires December 13, 2012 [Page 23] > > Internet-Draft IPFIX IE-DOCTORS June 2012 > > > 10. A Textual Format for Specifying Information Elements and Templates > > Example Templates given in existing IPFIX documents are generally > expressed using bitmap diagrams of the respective Templates. These > are illustrative of the wire representation of simple Templates, but > not particularly readable for more complicated recommended Templates, > provide no support for rapid implementation of new Templates, and do > not adequately convey the optional nature of ordering and additional > Information Elements as above. Therefore, we define a RECOMMENDED > textual format for specifying Information Elements and Templates in > Internet-Drafts in this section. > > Here we define a simple textual syntax for describing IPFIX > Information Elements and IPFIX Templates, with human readability, > human writability, compactness, and ease of parser/generator > implementation without requiring external XML support as design > goals. It is intended both for use in human communication (e.g., in > new Internet-Drafts containing higher-level descriptions of IPFIX > Templates, or describing sets of new IPFIX Information Elements for > supporting new applications of the protocol) as well as at runtime by > IPFIX implementations. > > 10.1. Information Element Specifiers > > The basis of this format is the textual Information Element > Specifier, or IESpec. An IESpec contains each of the four important > aspects of an Information Element: its name, its number, its type, > and its size, separated by simple markup based on various types of > brackets. Fully-qualified IESpecs may be used to specify existing or > new Information Elements within an Information Model, while either > fully-qualified or partial IESpecs may be used to define fields in a > Template. > > Bare words are used for Information Element names, and each aspect of > information associated with an Information Element is associated with > a type of brackets: > > o () parentheses for Information Element numbers, > > o<> angles for Information Element data types, and > > o [] square brackets for Information Element sizes. > > o {} curly braces contain an optional space-separated list of > context identifiers to be associated with an Information Element, > as described in more detail in Section 10.2 > > The symbol + is reserved for Information Element nesting within > > > > Trammell& Claise Expires December 13, 2012 [Page 24] > > Internet-Draft IPFIX IE-DOCTORS June 2012 > > > structured data elements; these are described in and Section 10.3, > respectively. > > Whitespace in IESpecs is insignificant; spaces can be added after > each element in order, e.g., to align columns for better readability. > > The basic form of a fully-qualified IESpec for an IANA-registered > Information Element is as follows: > > name(number)[size] > > where 'name' is the name of the Information Element in UTF-8, > 'number' is the Information Element as a decimal integer, 'type' is > the name of the data type as in the IANA informationElementDataTypes > registry, and 'size' is the length of the Information Element in > octets as a decimal integer, where 65535 or the string 'v' signifies > a variable-length Information Element. [size] may be omitted; in this > case, the data type's native or default size is assumed. > > The basic form of a fully-qualified IESpec for an enterprise-specific > Information Element is as follows: > > name(pen/number)[size] > > where 'pen' is the Private Enterprise Number as a decimal integer. > > A fully-qualified IESpec is intended to express enough information > about an Information Element to decode and display Data Records > defined by Templates containing that Information Element. Range, > unit, semantic, and description information, as in [RFC5610], is not > supported by this syntax. > > Example fully-qualified IESpecs follow: > > octetDeltaCount(1)[8] > > octetDeltaCount(1) (unsigned64 is natively 8 octets > long) > > sourceIPv4Address(8) > > wlanSSID(146)[v] > > sipRequestURI(35566/403)[65535] > > A partial IESpec is any IESpec that is not fully-qualified; these are > useful when defining templates. A partial IESpec is assumed to take > missing values from its canonical definition, for example, the IANA > > > > Trammell& Claise Expires December 13, 2012 [Page 25] > > Internet-Draft IPFIX IE-DOCTORS June 2012 > > > registry. At minimum, a partial IESpec must contain a name, or a > number. Any name, number, or type information given with a partial > IESpec must match the values given in the Information Model; however, > size information in a partial IESpec overrides size information in > the Information Model; in this way, IESpecs can be used to express > reduced-length encoding for Information Elements. > > Example partial IESpecs follow: > > o octetDeltaCount > > o octetDeltaCount[4] (reduced-length encoding) > > o (1) > > o (1)[4] (reduced length encoding; note that this is exactly > equivalent to an Information Element specifier in a Template) > > 10.2. Specifying Templates > > A Template can then be defined simply as an ordered, newline- > separated sequence of IESpecs. IESpecs in example Templates > illustrating a new application of IPFIX SHOULD be fully-qualified. > Flow Keys may be optionally annotated by appending the {key} context > to the end of each Flow Key specifier. A template counting packets > and octets per five-tuple with millisecond precision in IESpec syntax > is shown below. > > flowStartMilliseconds(152)[8] > flowEndMilliseconds(153)[8] > octetDeltaCount(1)[8] > packetDeltaCount(2)[8] > sourceIPv4Address(8)[4]{key} > destinationIPv4Address(12)[4]{key} > sourceTransportPort(7)[2]{key} > destinationTransportPort(11)[2]{key} > protocolIdentifier(4)[1]{key} > > Sample flow template in IESpec syntax Label this (eg, "Figure 1" or "Table 1") so it can easily be xref'd from future docs. Also for the examples below. > > An Options Template is specified similarly. Scope is specified > appending the {scope} context to the end of each IESpec for a Scope > IE. Due to the way Information Elements are represented in Options > Templates, all {scope} IESpecs must appear before any non-scope > IESpec. The Flow Key Options Template defined in section 4.4 [RFC- > EDITOR NOTE: verify section number] of > [I-D.ietf-ipfix-protocol-rfc5101bis] in IESpec syntax is shown below: > > > > > Trammell& Claise Expires December 13, 2012 [Page 26] > > Internet-Draft IPFIX IE-DOCTORS June 2012 > > > templateId(145)[2]{scope} > flowKeyIndicator(173)[8] > > Flow Key Options Template in IESpec syntax > > 10.3. Specifying IPFIX Structured Data > > IESpecs can also be used to illustrate the structure of the > information exported using the IPFIX Structured Data extension > [RFC6313]. Here, the semantics of the structured data elements are > specified using contexts, and the information elements within each > structured data element follow the structured data element, prefixed > with + to show they are contained therein. Arbitrary nesting of > structured data elements is possible by using multiple + signs in the > prefix. For example, a basic list of IP addresses with "one or more" > semantics would be expressed using partially qualified IESpecs as > follows: > > basicList{oneOrMoreOf} > +sourceIPv4Address(8)[4] > > Sample basicList in IESpec syntax > > And an example subTemplateList itself containing a basicList is shown > below: > > subTemplateList{allOf} > +basicList{oneOrMoreOf} > ++sourceIPv4Address(8)[4] > +destinationIPv4Address(12)[4] > > Sample subTemplateList in IESpec syntax What would a subTemplateMultiList look like? > This describes a subTemplateMultilist containing all of the expressed > set of source-destination pairs, where the source address itself > could be one of any number in a basicList (e.g., in the case of SCTP > multihoming). > > The contexts associable with structured data Information Elements are > the semantics, as defined in section 4.4 of [RFC6313]; a structured > data Information Element without any context is taken to have > undefined semantics. More information on the application of > structured data is available in [RFC6313]. > > > 11. Security Considerations > > The security aspects of new Information Elements must be considered > > > > Trammell& Claise Expires December 13, 2012 [Page 27] > > Internet-Draft IPFIX IE-DOCTORS June 2012 > > > in order not to give a potential attacker too much information. For > example, the "A Framework for Packet Selection and Reporting" > [RFC5474] concluded in section 12.3.2 that the hash functions private > parameters should not exported within IPFIX. > > If some security considerations are specific to an Information > Element, they MUST be mentioned in the Information Element > description. For example, the ipHeaderPacketSection in the IPFIX > registry mentions: "This Information Element, which may have a > variable length, carries a series of octets from the start of the IP > header of a sampled packet. With sufficient length, this element > also reports octets from the IP payload, subject to [RFC2804]. See > the Security Considerations section." > > These security considerations SHOULD also be stressed in an > accompanying Internet-Draft, as in Section 9. For example, the This sounds like a draft is required in order to express the security considerations. > "Packet Sampling (PSAMP) Protocols Specification" [RFC5476] > specifies: "In the basic Packet Report, a PSAMP Device exports some > number of contiguous bytes from the start of the packet, including > the packet header (which includes link layer, network layer and other > encapsulation headers) and some subsequent bytes of the packet > payload. The PSAMP Device SHOULD NOT export the full payload of > conversations, as this would mean wiretapping [RFC2804]. The PSAMP > Device MUST respect local privacy laws." > > Internet Drafts which define Information Elements SHOULD list and s/SHOULD/MUST/ > discuss any security impact of those Information Elements in their > Security Considerations sections. > > > 12. IANA Considerations > > With respect to the management of the IPFIX Information Element > registry and associated subregistries located at > [iana-ipfix-assignments], this document defines a process for IANA in > Section 5.1, and includes a set of guidelines for IANA for applying > this process in Section 4, Section 5, and Section 6. > > The IE-DOCTORS experts and the NetFlow V9 expert mentioned within > this document are to be appointed by the IESG. Should that be in an "IESG Considerations" section? > > In addition, in order to support more effective management of the > Information Element lifecycle as defined in Section 5, this document > specifies the addition of three new columns for the registry: Which registry? Cite the reference. > > > > > > > > Trammell& Claise Expires December 13, 2012 [Page 28] > > Internet-Draft IPFIX IE-DOCTORS June 2012 > > > Revision: a serial revision number for each Information Element, > beginning at 0 for all presently existing and newly created > Information Elements. This column is to be managed by IANA in > order to support the process defined in Section 5.2, and need not > be present in any Information Element definition. > > Date: the date at which the Information Element was created or last > modified. This column is to be managed by IANA in order to > support the process defined in Section 5.2, and need not be > present in any Information Element definition. Why are both data and revision required? > > Enterprise-specific reference: for Information Elements which where > deployed as enterprise-specific Information Elements for > experimentation and testing, and subsequently registered in the > IANA registry, specifies the private enterprise number (PEN)/IE > number pair(s) of the equivalent experimental Information > Element(s). Note that this column may contain more than one entry > per Information Element. This column SHOULD be present in any > Information Element definition referencing an enterprise-specific > Information Element, as in Section 4.9. I'm unconvinced of the value of this information. > > [IANA NOTE: Note that the examples in Appendix A are NOT to be added > to the IPFIX Information Element registry upon the publication of > this document.] > > > 13. Acknowledgements > > Thanks to Paul Aitken, Andrew Feren, and Dan Romascanu > for their valuable reviews and feedback. This work is > materially supported by the European Union Seventh Framework > Programme under grant agreement 257315 (DEMONS). > > > 14. References > > 14.1. Normative References > > [I-D.ietf-ipfix-protocol-rfc5101bis] > Claise, B. and B. Trammell, "Specification of the IP Flow > Information eXport (IPFIX) Protocol for the Exchange of > Flow Information", draft-ietf-ipfix-protocol-rfc5101bis-01 > (work in progress), March 2012. > > [I-D.ietf-ipfix-information-model-rfc5102bis] > Claise, B. and B. Trammell, "Information Model for IP Flow > Information eXport (IPFIX)", > draft-ietf-ipfix-information-model-rfc5102bis-01 (work in > > > > Trammell& Claise Expires December 13, 2012 [Page 29] > > Internet-Draft IPFIX IE-DOCTORS June 2012 > > > progress), March 2012. > > [RFC5103] Trammell, B. and E. Boschi, "Bidirectional Flow Export > Using IP Flow Information Export (IPFIX)", RFC 5103, > January 2008. > > [RFC5610] Boschi, E., Trammell, B., Mark, L., and T. Zseby, > "Exporting Type Information for IP Flow Information Export > (IPFIX) Information Elements", RFC 5610, July 2009. > > [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate > Requirement Levels", BCP 14, RFC 2119, March 1997. > > [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an > IANA Considerations Section in RFCs", BCP 26, RFC 5226, > May 2008. > > [RFC6313] Claise, B., Dhandapani, G., Aitken, P., and S. Yates, > "Export of Structured Data in IP Flow Information Export > (IPFIX)", RFC 6313, July 2011. > > 14.2. Informative References > > [RFC2804] IAB and IESG, "IETF Policy on Wiretapping", RFC 2804, > May 2000. > > [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, > A., Peterson, J., Sparks, R., Handley, M., and E. > Schooler, "SIP: Session Initiation Protocol", RFC 3261, > June 2002. > > [RFC3954] Claise, B., "Cisco Systems NetFlow Services Export Version > 9", RFC 3954, October 2004. > > [RFC5472] Zseby, T., Boschi, E., Brownlee, N., and B. Claise, "IP > Flow Information Export (IPFIX) Applicability", RFC 5472, > March 2009. > > [RFC5473] Boschi, E., Mark, L., and B. Claise, "Reducing Redundancy > in IP Flow Information Export (IPFIX) and Packet Sampling > (PSAMP) Reports", RFC 5473, March 2009. > > [RFC5474] Duffield, N., Chiou, D., Claise, B., Greenberg, A., > Grossglauser, M., and J. Rexford, "A Framework for Packet > Selection and Reporting", RFC 5474, March 2009. > > [RFC5476] Claise, B., Johnson, A., and J. Quittek, "Packet Sampling > (PSAMP) Protocol Specifications", RFC 5476, March 2009. > > > > Trammell& Claise Expires December 13, 2012 [Page 30] > > Internet-Draft IPFIX IE-DOCTORS June 2012 > > > [RFC5477] Dietz, T., Claise, B., Aitken, P., Dressler, F., and G. > Carle, "Information Model for Packet Sampling Exports", > RFC 5477, March 2009. > > [RFC5560] Uijterwaal, H., "A One-Way Packet Duplication Metric", > RFC 5560, May 2009. > > [RFC5655] Trammell, B., Boschi, E., Mark, L., Zseby, T., and A. > Wagner, "Specification of the IP Flow Information Export > (IPFIX) File Format", RFC 5655, October 2009. > > [RFC6235] Boschi, E. and B. Trammell, "IP Flow Anonymization > Support", RFC 6235, May 2011. > > [iana-ipfix-assignments] > Internet Assigned Numbers Authority, "IP Flow Information > Export Information Elements > (http://www.iana.org/assignments/ipfix/ipfix.xml)". > > > Appendix A. Example Information Element Definitions > > This section contains a few example Information Element definitions > as they would appear in an Internet-Draft. Note the conformance of > these examples to the guidelines in Section 4. > > The sipResponseStatus Information Element (Appendix A.1) illustrates > the addition of an Information Element representing Layer 7 > application information, with a reference to the registry containing > the allowable values. The duplicatePacketDeltaCount Information > Element (Appendix A.2) illustrates the addition of a new metric, with > a reference to the RFC defining the metric. The ambientTemperature > Information Element (Appendix A.3) illustrates the addition of a new > measured value outside the area of traditional networking > applications. > > A.1. sipResponseStatus > > Description: The SIP Response code as an integer, as in the > Response Codes registry at > http://www.iana.org/assignments/sip-parameters defined in > [RFC3261] and amended in subsequent RFCs. The presence of this > Information Element in a SIP Message record marks it as describing > a SIP response; if absent, the record describes a SIP request. What distinguishes a "SIP Message record" in IPFIX? To be clear: "if absent, the SIP Message record describes..." > > > > > > > > Trammell& Claise Expires December 13, 2012 [Page 31] > > Internet-Draft IPFIX IE-DOCTORS June 2012 > > > Data Type: unsigned16 > > Data Type Semantics: identifier > > References: [RFC3261] > > ElementId: TBD > > Replaces Enterprise-Specific Element: 35566 / 412 This format isn't clear: which is the enterprise ID and which is the element ID? > > A.2. duplicatePacketDeltaCount > > Description: The number of uncorrupted and identical additional > copies of each individual packet in the Flow arriving at the > destination since the previous Data Record for this Flow (if any), > as measured at the Observation Point. This is measured as the > Type-P-one-way-packet-duplication metric defined in section 3 of > [RFC5560]. > > Data Type: unsigned64 > > Data Type Semantics: deltaCounter > > Units: packets > > References: [RFC5560] > > ElementId: TBD > > A.3. ambientTemperature > > Description: An ambient temperature observed by measurement > equipment at an Observation Point, positioned such that it > measures the temperature of the surroundings (i.e., not including > any heat generated by the measuring or measured equipment), > expressed in degrees Celsius. > > Data Type: float > > Units: degrees Celsius > > Range: -273.15 - +inf Should range be expressed with the word "to" rather than a hyphen, which is easily confused with a minus sign? eg, range "-123 - -456" is less easily parsed than "-123 to -456". > > ElementId: TBD > > > > > > > > Trammell& Claise Expires December 13, 2012 [Page 32] > > Internet-Draft IPFIX IE-DOCTORS June 2012 > > > Authors' Addresses > > Brian Trammell > Swiss Federal Institute of Technology Zurich > Gloriastrasse 35 > 8092 Zurich > Switzerland > > Phone: +41 44 632 70 13 > Email: trammell@tik.ee.ethz.ch > > > Benoit Claise > Cisco Systems, Inc. > De Kleetlaan 6a b1 > 1831 Diagem Once again, in existing RFCs - and in Cisco's internal directory - this is "Diegem 1831". > Belgium > > Phone: +32 2 704 5622 > Email: bclaise@cisco.com > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Trammell& Claise Expires December 13, 2012 [Page 33] > Thanks, P. From trammell@tik.ee.ethz.ch Thu Jul 19 02:00: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 267A221F86F4 for ; Thu, 19 Jul 2012 02:00:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.936 X-Spam-Level: X-Spam-Status: No, score=-5.936 tagged_above=-999 required=5 tests=[AWL=0.063, BAYES_00=-2.599, J_CHICKENPOX_21=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 3r5XcWpX8gRN for ; Thu, 19 Jul 2012 02:00:26 -0700 (PDT) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) by ietfa.amsl.com (Postfix) with ESMTP id F058C21F86C9 for ; Thu, 19 Jul 2012 02:00:25 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id 03AFAD930B; Thu, 19 Jul 2012 11:01:16 +0200 (MEST) X-Virus-Scanned: by amavisd-new on smtp.ee.ethz.ch Received: from smtp.ee.ethz.ch ([127.0.0.1]) by localhost (.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with LMTP id u3xTeLx-sehA; Thu, 19 Jul 2012 11:01:15 +0200 (MEST) Received: from pb-10243.ethz.ch (pb-10243.ethz.ch [82.130.102.152]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: briant) by smtp.ee.ethz.ch (Postfix) with ESMTPSA id C17D1D9309; Thu, 19 Jul 2012 11:01:15 +0200 (MEST) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=iso-8859-1 From: Brian Trammell In-Reply-To: <5005D329.8060509@cisco.com> Date: Thu, 19 Jul 2012 11:01:15 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <87A0FD38-83A1-464E-8898-65FFEC9B12FA@tik.ee.ethz.ch> References: <5005D329.8060509@cisco.com> To: Paul Aitken X-Mailer: Apple Mail (2.1278) Cc: IETF IPFIX Working Group Subject: Re: [IPFIX] draft-ietf-ipfix-ie-doctors-02 review X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jul 2012 09:00:28 -0000 Hi, Paul,=20 Applying editorial comments without comment; thanks! Replies to concerns = and other important points inline. Comments on issues not already = handled in the -03 review to follow in a separate message... On Jul 17, 2012, at 11:03 PM, Paul Aitken wrote: >> =20 >> 4. Defining new Information Elements >>=20 >> In many cases, a new application will require nothing more than a = new >> Information Element or set of Information Elements to be = exportable >> using IPFIX. An Information Element meeting the following = criteria, >> as evaluated by appointed IPFIX experts, is eligible for inclusion = in >> the Information Element registry: >>=20 >> o The Information Element MUST be sufficiently unique within the >> registry. Its description MUST represent a substantially >> different meaning from that of any existing Information = Element. >> A proposed Information Element which is a substantial duplicate = of >> an existing Information Element is to be represented using the >> existing Information Element. >=20 > ** Disagree. If the new app wants to extend the existing IE in a new = and non-backwards compatible way, while avoiding splitting export across = two IEs (ie, old values in the existing IE, new values in the TBD IE), = then it would clone + extend the existing IE. Therefore it would = necessarily be "a substantial duplicate of an existing Information = Element". While I think the desire to create a new IE to export the same data = without consideration for backward compatibility is a bit misguided at = best -- such things should be handled through the creation of = subregistries or though the process in section 5.2 -- I don't think = there's disagreement here; a new IE would not be a "substantial = duplicate" since it would be able to represent completely new values as = well. >> o The Information Element SHOULD contain minimal internal = structure; >> complex information should be represented with multiple simple >> Information Elements to be exported in parallel, as in >> Section 4.5. >=20 > ** Seriously disagree. Multiple IEs are unrelated, and may be = re-ordered, aggregated, or removed by some intermediate process. > Structured data would be required to group the discrete IEs together = into a single entity. This single entity is called a Data Record. Or am I missing something?=20= Yes, Data Records are not inviolate, but sticking inscrutable structure = into an IE is not the way to keep a rogue ImP from hosing your data; = that's a deployment/configuration time issue. >> o The Information Element SHOULD be generally applicable to the >> application at hand, which SHOULD be of general interest to the >> community. Information Elements representing information about >> proprietary or nonstandard applications SHOULD be represented >> using enterprise-specific Information Elements as detailed in >> section 3.2 [RFC-EDITOR NOTE: verify section number] of >> [I-D.ietf-ipfix-protocol-rfc5101bis]. >>=20 >> The definition of new Information Elements requires a descriptive >> name, a specification of the data type as one from the IPFIX Data >> Type Registry, and a human-readable description written in = English. >=20 > Note that the Data Type registry is also extensible, so a new IE could = define a new data type. > eg, as done in mib-variable-export. Explicitly per 5610, and implicitly per 5101, this requires a Standards = Action. Mibvar is a (potential) standards action, not a simple IE = definition. >>=20 >> Information Element identifiers in the range 1-128 MUST NOT be >>=20 >>=20 >>=20 >> Trammell& Claise Expires September 8, 2012 [Page = 8] >>=20 >> Internet-Draft IPFIX IE-DOCTORS March = 2012 >>=20 >>=20 >> assigned unless the Information Element is compatible with the >> NetFlow v9 protocol as described in [RFC3954]. Such Information >> Elements may ONLY be requested by a NetFlow v9 expert, to be >> designated by the IESG to consult with IANA on NetFlow v9 >> compatibility with IPFIX. >=20 > ** AFAIK no such experts have been designated. This would be a blocker = for us. > See suggestion from Benoit. No; the document specifies the expert must be designated, and the IESG = appoints one. I don't see the problem here. >> As an example of information element decomposition, consider an >> application-level identifier called an "endpoint", which = represents a >> {host, port, protocol} tuple. Instead of allocating an opaque, >> structured "source endpoint" Information Element, the source = endpoint >> should be represented by three separate Information Elements: = "source >> address", "source port", "transport protocol". In this example, = the >> required information elements already exist in the Information >> Element registry: sourceIPv4Address or sourceIPv6Address, >> sourceTransportPort, protocolIdentifier. Indeed, as well as being >> good practice, this normalization down to non-structured = Information >> Elements also increases opportunities for reuse as in Section 6.1. >=20 > ** Now the CP receives three discrete IEs, with nothing to indicate = that together they represent an endpoint. >=20 > Worse, some intermediate process could re-order, aggregate or remove = the discrete fields without knowing that they were required to identify = an endpoint. >=20 > The only solution is to use SD to group the fields together and = prevent them from being modified along the way. Er, no. This is precisely a notional endpoint as in any common Flow Data = Record you can export in IPFIX: the fact that they appear together in a = _record_ means they identify and endpoint! Again, I really, really don't understand the apparent fear of rogue ImPs = breaking fine structure in Data Records. >>=20 >> 4.8. Reversibility as per RFC 5103 >>=20 >> [RFC5103] defines a method for exporting bidirectional flows using = a >> special Private Enterprise Number to define reverse-direction >> variants of IANA Information Elements, and a set of criteria for >> determining whether an Information Element may be reversed using = this >> method. Since almost all Information Elements are reversible, >> [RFC5103] enumerates those which Information Elements which were >> defined at the time of its publication which are NOT reversible. >>=20 >> New non-reversible Information Elements SHOULD contain a note in = the >> description stating that they are not reversible. >=20 > Why isn't that a MUST? In case, for instance (see below), the application for which the IE is = defined is somehow completely oblivious to 5103. >> 4.10. Avoiding Bad Ideas in Information Element Design >>=20 >> In general, the existence of a similarly-defined Information = Element >> in the IANA registry sets a precedent which may be followed to >> determine whether a given proposed Information Element "fits" = within >> the registry. Indeed, the rules specified by this document could = be >> interpreted to mean "make new Information Elements that look like >> existing Information Elements". However, for reasons of history, >> there are several Information Elements within the IANA registry = which >> do not follow best practices in Information Element design. These >> Information Elements are not necessarily so flawed so as to = require >> deprecation, but they should be explicitly ignored when looking = for >> guidance as to whether a new Information Element should be added. >>=20 >> Before registering a new Information Element, it must be = determined >> that it would be sufficiently unique within the registry. This >> evaluation has not always been done in the past, and the existence = of >> the Information Elements defined without this evaluation should = not >> be taken as an example that such Information Element definition >> practices should be followed in the future. Specific examples of >> such Information Elements include initiatorOctets and = responderOctets >> (which duplicate octetDeltaCount and its reverse per [RFC5103]) = and >> initiatorPackets and responderPackets (the same, for >> packetDeltaCount). >=20 > ** Disagree. octetDeltaCount and packetDeltaCount are directionless, = while initiator* and responder* have inherent direction - thus the need = for these fields. octetDeltaCount and packetDeltaCount are not directionless in the = presence of 5103. Indeed, I'd argue that even without 5103, = octetDeltaCount and packetDeltaCount implicitly carry the (non-stated) = "observation direction", but I freely admit that's a penumbral = interpretation. The presence of these fields in the registry raises an ambiguity: I have = biflows I want to export, and I only care about packet and octet counts = as values. What do I do? I use these fields, probably, because they look = simpler than all this special Enterprise-Specific IE hackery. Oh, wait, = now I want to export TCP flags in both directions. What do I do now? Or = even more subtly, I want delta counter semantics instead of total = counter counter semantics. What do I do now? As below, I'll try not to take it personally as an author of 5103 that = people implementing biflow export have somehow managed to miss a = standards-track RFC on how to export biflows in IPFIX and have therefore = defined an (incompatible and potentially incomparable) set of IEs for = doing exactly the same thing. >> As mentioned in Section 4.2, the type of an Information Element >> SHOULD match the type of data the Information Element represents. = An >> example of how not to do this is presented by the p2pTechnology, >> tunnelTechnology, and encryptedTechnology Information Elements: = these >> represent a three-state enumeration using a String. The example = set >> by these Information Elements SHOULD NOT be followed in the >> definition of new Information Elements. >=20 > Note that I proposed an improvement to this scheme. Indeed; IIRC it's even reasonably backward compatible. I would hope that = the IE Doctors process could be used to rev the IEs to make them better. > I'll try not to take it personally that all the bad examples were = added by me, because I'm the only one who's added any new non-RFC IEs at = all. :) Nothing personal meant here, of course; these examples were compiled = on a review of recent additions, and finding that some of them managed = to violate (what I thought were) presumptive rules that hadn't even been = stated yet. >> 5.1. The IE-DOCTORS process >>=20 >> Requests to change the IANA Information Element registry or a = linked >> subregistry are submitted to IANA, which forwards the request to a >=20 > How are requests submitted to IANA? I presume via email, though I'm not sure we want to put specific = directions about how IANA's process works into a BCP. =20 >=20 >> designated group of experts (IE-DOCTORS) appointed by the IETF >> Operations Area Directors. This group of experts reviews the = request >> for such things as compliance with this document, compliance with >> other applicable IPFIX-related RFCs, and consistency with the >> currently defined set of Information Elements. >>=20 >> Authors are expected to review compliance with the specifications = in >> this document to check their submissions before sending them to = IANA. >>=20 >> IE-DOCTORS reviewers should endeavor to complete referred reviews = in >> a timely manner. If the request is acceptable, the IE-DOCTORS >=20 > Please define "a timely manner". Without a definition, it's not worth = saying. This was, IIRC, the result of a conversation in the WG, where it was = suggested that time limits in an RFC without allowances for extenuating = circumstances, the cycles of work in the IETF, IANA's workflow, etc., = would be unnecessarily bureaucratic. >> compliant. The IE-DOCTORS may also choose in exceptional >> circumstances to reject clearly frivolous or inappropriate change >> requests outright. >=20 > What recourse do requesters have if their application is rejected? I presume this would be handled as in section 7 of RFC 5226, which in = turn refers to section 6.5.4 of RFC 2026. We can note this, certainly. >> A change to an Information Element is held to be interoperable = only >> when: >>=20 >> o it involves the correction of an error which is obviously only >> editorial; or >>=20 >> o it corrects an ambiguity in the Information Element's = definition, >> which itself leads to non-interoperability (e.g., a prior = change >> to ipv6ExtensionHeaders); or >>=20 >> o it expands the Information Element's data type without changing >> how it is represented (e.g., changing unsigned32 to unsigned64, = as >> with a prior change to selectorId); or >=20 > Note that this could have caused interop issues. However, nobody said = they had implemented or were using it at the time, so it was possible to = change. Hm, point. I'd thought this would only cause interop issues if RLE = wasn't properly implemented, but RLE doesn't specify what to do for, = well, _increased_ length encoding. >> o it defines a previously undefined or reserved enumerated value, = or >> one or more previously reserved bits in an Information Element >> with flag semantics; or >>=20 >> o it expands the set of permissible values in the Information >> Element's range; or >=20 > Again, that could cause interop issues. eg, you claim your collector = supports IPFIX. I also claim to export IPFIX, and export some bits that = you didn't know about when you wrote the collector. Your collector can't = interpret those bits... Indeed. As with above, for any enumerated-value IE which you could = possibly extend, the collector should be defensive against new values. = To review in 5101-bis: whether this is covered. >> o it harmonizes with an external reference which was itself >> corrected. >> the appointed experts for review; if there is no objection to the >> change from any appointed expert, IANA makes the change in the >> Information Element Registry. The requestor of the change is >> appended to the Requestor in the registry. >=20 > The registry should record the original requester + date + modifier + = date + details of modification. See below. >=20 >=20 >> Each Information Element in the IANA registry has a revision = number, >> starting at zero. Each change to an Information Element following >> this process increments the revision number by one. Since any >> revision must be interoperable according to the criteria above, = there >> is no need for the IANA registry to store information about old >> revisions. >=20 > I'd prefer revision dates, so changes since the last time can easily = be discovered. Last revision dates are stored in the registry as per the current = revision of the document. > Info about old revisions should be stored, so I can discover exactly = what an IPFIX device does / doesn't support when it's claimed to support = IPFIX as at 1-1-2012, eg. Keep in mind that any given exporter or collector will probably only = care about a subset of the IEs. This brings up the question of what = "supports IPFIX" means. If my collector only knows about IPv4, can it = reject records with IPv6 addresses and still "support IPFIX"? If I don't = care about Layer 2, do I need to recognize the Layer 2 IEs? If I = implement 5103, do I also have to handle initiatorOctets and = responderOctets? I would hope all the answers to these questions are = "no", because otherwise we're not going to have any "implementations of = IPFIX". We can certainly talk to IANA about keeping old versions, but I strongly = suggest they be stored in a separate registry; the main registry should = be for current IE defs. Otherwise it would appear as though the intent = were to specifically support picking and choosing of IE revisions. >> Deprecated Information Elements SHOULD continue to be supported by >> Collecting Processes, but SHOULD NOT be exported by Exporting >=20 > ** ** That's impossible. If someone causes a certain IE to be = deprecated, none of the existing implementations is going to change. = They're going to carry right on exporting the same info they always have = been. Deprecation is always tricky. You're right, we can only specify. The = best we can do here is "SHOULD NOT". > Then new releases which don't make any change in the area of the = deprecated IE will continue to export the deprecated IE to avoid the = situation where existing devices export IE#x while new devices export = IE#y, although these are both observing the same thing. >=20 > Besides, collectors which haven't been updated since the deprecation = won't understand IE#y, so the updated EP will now be seen to be = "broken". Even those CPs which have been updated may not equate x with = y, or translate between them - so there could be issues comparing or = processing pre-change data with post-change data. This is a fundamental problem in any protocol without feature = negotiation. >> Processes. The use of deprecated Information Elements SHOULD = result >> in a log entry or human-readable warning at the Exporting and >> Collecting Processes. >=20 > How do you propose that existing implementations become aware of the = deprecation? Well, I presume the implementors will continue paying attention to the = registry, at the very least, if the implementations are being actively = kept current. >> After a period of time determined in the eyes >> of the IE-DOCTORS experts to be reasonable in order to allow = deployed >> Exporting Processes to be updated to account for the deprecation, = a >> deprecated Information Element may be made obsolete. Obsolete >> Information Elements MUST NOT be supported by either Exporting or >> Collecting Processes. The receipt of obsolete Information = Elements >=20 > ** ** Nope, not happening. I can't force my customers to upgrade just = because some 3rd party says so. "MUST NOT be supported by new implementations of either Exporting or = Collecting Processes"? The point here is that if we're going to support deprecation (which was = clearly the intent of the WG, given its inclusion in 5102), there may be = a mismatch between the deployed and specified environment WRT supported = IEs. >> SHOULD be logged by the Collecting Process. >=20 >> 5.4. Versioning the entire IANA Registry >>=20 >> Consider a typical Collector implementation, which regularly >> downloads the entire registry in order to be compliant with the >> latest of set of supported IEs. While a registry revision number >=20 > Consider an implementation which does not, because it's not connected = to public networks, or because the operator is concerned about the risks = of installing such an update. Point. Indeed, this entire section should be removed; it serves to = continue a discussion that, IIRC, was done in the WG in Prague. >> might seems advantageous for the Collector at first glance = (avoiding >> the one by one comparison of all IE revisions), it is not = necessary, >> as the IPFIX IANA registry specifies the date at which the = registry >> was last updated in the "Last Updated" field. For purposes of >> identifying the latest set of Information Element versions = specified >> in registry, the last revision date of the Information Element >> registry (available in the registry XML source, or from the Last- >> Modified: header of [iana-ipfix-assignments]) SHOULD be used. On to the next review, then... Best regards, Brian From paitken@cisco.com Thu Jul 19 05:15:27 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 AA08421F85CD for ; Thu, 19 Jul 2012 05:15:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.484 X-Spam-Level: X-Spam-Status: No, score=-10.484 tagged_above=-999 required=5 tests=[AWL=0.115, 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 RP0ToMwEfcGi for ; Thu, 19 Jul 2012 05:15:26 -0700 (PDT) Received: from ams-iport-3.cisco.com (ams-iport-3.cisco.com [144.254.224.146]) by ietfa.amsl.com (Postfix) with ESMTP id 5913F21F85D9 for ; Thu, 19 Jul 2012 05:15:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=paitken@cisco.com; l=1737; q=dns/txt; s=iport; t=1342700179; x=1343909779; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=LYSf+tKDRMMSYFuCNamAeoBaO5M5xVzKM+lMwURUxD4=; b=OIJQqvjt5q75bXgcSA3s0t6S1B2FjKayt4WxqlrRh3xqs6Q2NEssxmGW lLPw2c9YLDW43ToxlrYAz1tAzSHMviBFMTOhs0KMjIudgXPCLoTgC9VhA Bz/4zrwQJ0Iw8EBVI59tG1zXoYgMkbFBHydVDpydPINSIArOMCUfmsG/S c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AnAOAEP5B1CQ/khR/2dsb2JhbABFsWqHVoEHgiEBAQQSASVAARAsFg8JAwIBAgFFBg0BBwEBHodrniegBotzhmkDlUSFWYhKgWaCYIFX X-IronPort-AV: E=Sophos;i="4.77,615,1336348800"; d="scan'208";a="6751179" Received: from ams-core-1.cisco.com ([144.254.72.81]) by ams-iport-3.cisco.com with ESMTP; 19 Jul 2012 12:16:18 +0000 Received: from [10.61.105.10] (dhcp-10-61-105-10.cisco.com [10.61.105.10]) by ams-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id q6JCGIq5016148; Thu, 19 Jul 2012 12:16:18 GMT Message-ID: <5007FA93.2090004@cisco.com> Date: Thu, 19 Jul 2012 13:16:19 +0100 From: Paul Aitken User-Agent: Mozilla/5.0 (X11; Linux i686; rv:12.0) Gecko/20120430 Thunderbird/12.0.1 MIME-Version: 1.0 To: Brian Trammell References: <6C4C3778-56DD-47C7-9FE5-A3886EB3C127@tik.ee.ethz.ch> In-Reply-To: <6C4C3778-56DD-47C7-9FE5-A3886EB3C127@tik.ee.ethz.ch> X-Forwarded-Message-Id: <6C4C3778-56DD-47C7-9FE5-A3886EB3C127@tik.ee.ethz.ch> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: IETF IPFIX Working Group Subject: [IPFIX] IE-doctors: transitioning IEs X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jul 2012 12:15:27 -0000 Brian, In my IE-doctors reviews, I expressed some reservation about recording Enterprise-Specific information in IANA's IPFIX registry as specified in this text: In order to support transition from experimental registration to IANA registration, the IANA registry provides an optional "enterprise- specific IE reference" column for each Information Element. In cases of promoted enterprise-specific Information Elements, this column in the registry SHOULD contain the private enterprise and Information Element numbers of the enterprise-specific version of the Information Element. I've had a similar, but automated, idea in the back of my mind to for some years: an upgraded device could export a table mapping oldIE to newIE, where either of these IEs can be IANA standard or Enterprise Specific. The table would be interpreted as "(if) I used to export oldIE, now I export newIE", so the Collecting Process can readily re-map exported data over the Exporting Process software change boundary. If the Collecting Process never received any oldIE elements, it can disregard the information. With the IE doctors / IANA registry idea, the information has to be in the registry and the Collecting Process has to have read the new registry. So both the Exporting Process and Collecting Process must be updated. With my idea, only the Exporting Process is updated, and it informs the Collecting Process. I drafted a -00 on this last year which requires a little more work, so I've not published it yet. Of course the two mechanisms are complementary rather than mutually exclusive. It's a question of which issues we're trying to solve. P. From trammell@tik.ee.ethz.ch Thu Jul 19 05:44: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 48F5A21F8777 for ; Thu, 19 Jul 2012 05:44:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.241 X-Spam-Level: X-Spam-Status: No, score=-6.241 tagged_above=-999 required=5 tests=[AWL=0.358, 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 PBF-cxHlTXzL for ; Thu, 19 Jul 2012 05:44:43 -0700 (PDT) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) by ietfa.amsl.com (Postfix) with ESMTP id 33C7821F8722 for ; Thu, 19 Jul 2012 05:44:42 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id C5453D930B; Thu, 19 Jul 2012 14:45:34 +0200 (MEST) X-Virus-Scanned: by amavisd-new on smtp.ee.ethz.ch Received: from smtp.ee.ethz.ch ([127.0.0.1]) by localhost (.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with LMTP id XfkrYotei3EE; Thu, 19 Jul 2012 14:45:34 +0200 (MEST) Received: from pb-10243.ethz.ch (pb-10243.ethz.ch [82.130.102.152]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: briant) by smtp.ee.ethz.ch (Postfix) with ESMTPSA id 8A101D9309; Thu, 19 Jul 2012 14:45:34 +0200 (MEST) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=iso-8859-1 From: Brian Trammell In-Reply-To: <5007FA93.2090004@cisco.com> Date: Thu, 19 Jul 2012 14:45:34 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <6C4C3778-56DD-47C7-9FE5-A3886EB3C127@tik.ee.ethz.ch> <5007FA93.2090004@cisco.com> To: Paul Aitken X-Mailer: Apple Mail (2.1278) Cc: IETF IPFIX Working Group Subject: Re: [IPFIX] IE-doctors: transitioning IEs X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jul 2012 12:44:44 -0000 Hi, Paul, I'm not much of a fan of sticking enterprise-specific references in the = registry, actually. It was suggested that this is a problem (indeed, I = believe it is), and this is indeed a solution to it -- but it seems like = a much cleaner mechanism for doing this would be to allow the actual = devices doing the exporting to annotate the output data with an IE map = (much like type information export as in RFC 5610). One clarifying point: the Collecting Process, of course, needs to be = updated too, in order to understand the Options providing the IE map. = But this only happens once, as opposed to the registry-based solution = which requires the CP to be regularly updated (or to automatically = query) the IANA registry. Removing a whole column and subset of sections from the ie-doctors at = this late date may be a little problematic procedurally; I'm not sure of = the right thing to do, and would turn to our chairs and AD for = guidance... Cheers, Brian On Jul 19, 2012, at 2:16 PM, Paul Aitken wrote: > Brian, >=20 > In my IE-doctors reviews, I expressed some reservation about recording = Enterprise-Specific information in IANA's IPFIX registry as specified in = this text: >=20 > In order to support transition from experimental registration to = IANA > registration, the IANA registry provides an optional "enterprise- > specific IE reference" column for each Information Element. In = cases > of promoted enterprise-specific Information Elements, this column = in > the registry SHOULD contain the private enterprise and Information > Element numbers of the enterprise-specific version of the = Information > Element. >=20 >=20 > I've had a similar, but automated, idea in the back of my mind to for = some years: an upgraded device could export a table mapping oldIE to = newIE, where either of these IEs can be IANA standard or Enterprise = Specific. >=20 > The table would be interpreted as "(if) I used to export oldIE, now I = export newIE", so the Collecting Process can readily re-map exported = data over the Exporting Process software change boundary. If the = Collecting Process never received any oldIE elements, it can disregard = the information. >=20 > With the IE doctors / IANA registry idea, the information has to be in = the registry and the Collecting Process has to have read the new = registry. So both the Exporting Process and Collecting Process must be = updated. >=20 > With my idea, only the Exporting Process is updated, and it informs = the Collecting Process. >=20 > I drafted a -00 on this last year which requires a little more work, = so I've not published it yet. >=20 > Of course the two mechanisms are complementary rather than mutually = exclusive. It's a question of which issues we're trying to solve. >=20 > P. >=20 >=20 From andrewf@plixer.com Thu Jul 19 07:35: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 E856021F857A for ; Thu, 19 Jul 2012 07:35:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.276 X-Spam-Level: X-Spam-Status: No, score=-2.276 tagged_above=-999 required=5 tests=[AWL=0.323, 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 v1vt94JMepWP for ; Thu, 19 Jul 2012 07:35:12 -0700 (PDT) Received: from smtp.plixer.com (smtp.plixer.com [66.186.184.193]) by ietfa.amsl.com (Postfix) with ESMTP id 751AF21F8551 for ; Thu, 19 Jul 2012 07:35:10 -0700 (PDT) Received: from [10.100.1.132] ([65.175.140.2]) by smtp.plixer.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Thu, 19 Jul 2012 10:35:53 -0400 Message-ID: <50081B48.7030704@plixer.com> Date: Thu, 19 Jul 2012 10:35:52 -0400 From: Andrew Feren User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:16.0) Gecko/16.0 Thunderbird/16.0a1 MIME-Version: 1.0 To: ipfix@ietf.org References: <5005D329.8060509@cisco.com> <87A0FD38-83A1-464E-8898-65FFEC9B12FA@tik.ee.ethz.ch> In-Reply-To: <87A0FD38-83A1-464E-8898-65FFEC9B12FA@tik.ee.ethz.ch> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 19 Jul 2012 14:35:53.0213 (UTC) FILETIME=[CCC16AD0:01CD65BB] Subject: Re: [IPFIX] draft-ietf-ipfix-ie-doctors-02 review X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jul 2012 14:35:13 -0000 On 07/19/2012 05:01 AM, Brian Trammell wrote: [ snip ] >>> After a period of time determined in the eyes >>> of the IE-DOCTORS experts to be reasonable in order to allow deployed >>> Exporting Processes to be updated to account for the deprecation, a >>> deprecated Information Element may be made obsolete. Obsolete >>> Information Elements MUST NOT be supported by either Exporting or >>> Collecting Processes. The receipt of obsolete Information Elements >> ** ** Nope, not happening. I can't force my customers to upgrade just because some 3rd party says so. > "MUST NOT be supported by new implementations of either Exporting or Collecting Processes"? > > The point here is that if we're going to support deprecation (which was clearly the intent of the WG, given its inclusion in 5102), there may be a mismatch between the deployed and specified environment WRT supported IEs. > > I have to side with Paul on this one. Saying that a collecting process MUST NOT support obsoleted IEs seems to me to violate the robustness principle. An argument can be made that new exporters SHOULD / MUST NOT send deprecated IEs, but I think more than that is too much. To give a specific example of the shelf life of the obsolete. Wikipedia tells me that NetFlow v1 is obsolete (and it has been for years), but I still see NetFlow v1 exports on some customer networks. -Andrew From trammell@tik.ee.ethz.ch Thu Jul 19 07:45:10 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 4D7B621F8717 for ; Thu, 19 Jul 2012 07:45:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.266 X-Spam-Level: X-Spam-Status: No, score=-6.266 tagged_above=-999 required=5 tests=[AWL=0.333, 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 sF1Xpjh5-O0k for ; Thu, 19 Jul 2012 07:45:08 -0700 (PDT) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) by ietfa.amsl.com (Postfix) with ESMTP id 4B8F521F86FD for ; Thu, 19 Jul 2012 07:45:08 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id DAC05D9314; Thu, 19 Jul 2012 16:45:53 +0200 (MEST) X-Virus-Scanned: by amavisd-new on smtp.ee.ethz.ch Received: from smtp.ee.ethz.ch ([127.0.0.1]) by localhost (.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with LMTP id ZE9-nkmcJIKF; Thu, 19 Jul 2012 16:45:53 +0200 (MEST) Received: from pb-10243.ethz.ch (pb-10243.ethz.ch [82.130.102.152]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: briant) by smtp.ee.ethz.ch (Postfix) with ESMTPSA id 98B35D930B; Thu, 19 Jul 2012 16:45:53 +0200 (MEST) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: Brian Trammell In-Reply-To: <50081B48.7030704@plixer.com> Date: Thu, 19 Jul 2012 16:45:52 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <0AB730D8-6F83-4E95-8E17-0301FA317564@tik.ee.ethz.ch> References: <5005D329.8060509@cisco.com> <87A0FD38-83A1-464E-8898-65FFEC9B12FA@tik.ee.ethz.ch> <50081B48.7030704@plixer.com> To: Andrew Feren X-Mailer: Apple Mail (2.1278) Cc: ipfix@ietf.org Subject: Re: [IPFIX] draft-ietf-ipfix-ie-doctors-02 review X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jul 2012 14:45:10 -0000 Hi, Andrew, Essentially, if this is the argument (which I'm not saying I disagree = with), then we should drop obsolete as a status, and just stay with = deprecated -- there's no point in distinguishing "don't use it" from = "REALLY don't use it" unless we specify that use of deprecated IEs is a = warning and use of obsolete IEs is an error. Especially since we'll never reclaim number or namespace anyway, why not = just collapse to one "dead" status? Cheers, Brian On Jul 19, 2012, at 4:35 PM, Andrew Feren wrote: > On 07/19/2012 05:01 AM, Brian Trammell wrote: >=20 > [ snip ] >>>> After a period of time determined in the eyes >>>> of the IE-DOCTORS experts to be reasonable in order to allow = deployed >>>> Exporting Processes to be updated to account for the = deprecation, a >>>> deprecated Information Element may be made obsolete. Obsolete >>>> Information Elements MUST NOT be supported by either Exporting = or >>>> Collecting Processes. The receipt of obsolete Information = Elements >>> ** ** Nope, not happening. I can't force my customers to upgrade = just because some 3rd party says so. >> "MUST NOT be supported by new implementations of either Exporting or = Collecting Processes"? >>=20 >> The point here is that if we're going to support deprecation (which = was clearly the intent of the WG, given its inclusion in 5102), there = may be a mismatch between the deployed and specified environment WRT = supported IEs. >>=20 >>=20 > I have to side with Paul on this one. Saying that a collecting = process MUST NOT support obsoleted IEs seems to me to violate the = robustness principle. An argument can be made that new exporters SHOULD = / MUST NOT send deprecated IEs, but I think more than that is too much. >=20 > To give a specific example of the shelf life of the obsolete. = Wikipedia tells me that NetFlow v1 is obsolete (and it has been for = years), but I still see NetFlow v1 exports on some customer networks. >=20 > -Andrew > _______________________________________________ > IPFIX mailing list > IPFIX@ietf.org > https://www.ietf.org/mailman/listinfo/ipfix From n.brownlee@auckland.ac.nz Wed Jul 25 21:19: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 64B8111E8098 for ; Wed, 25 Jul 2012 21:19:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.569 X-Spam-Level: X-Spam-Status: No, score=-106.569 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, 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 7oeFYIntVks3 for ; Wed, 25 Jul 2012 21:19:36 -0700 (PDT) Received: from mx2.auckland.ac.nz (mx2.auckland.ac.nz [130.216.12.44]) by ietfa.amsl.com (Postfix) with ESMTP id 2BFDF11E8097 for ; Wed, 25 Jul 2012 21:19:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=n.brownlee@auckland.ac.nz; q=dns/txt; s=uoa; t=1343276376; x=1374812376; h=message-id:date:from:mime-version:to:subject: content-transfer-encoding; bh=OUdMLWMEOCiNQNRahE95d2gT8DlFY3xvmZ91iO5sMGI=; b=iEmySz9gEhBaN/oQl6OQvKfwYL7VnUt0xcvOQT919nQaRgRaPqsQeLPn +fx55gAqOzlrxkQZ4zNFbR+OrTr8V89KfmGUtuFmGE/Yvx+MM/JR14tNM xFfe/uELLTW1UTr/ZudFyFbCH7QB1mIiCXUGCXsjQwse2xD1XuHXfeCn4 c=; X-IronPort-AV: E=Sophos;i="4.77,658,1336305600"; d="scan'208";a="134906988" X-Ironport-HAT: UNIVERSITY - $RELAY-THROTTLE X-Ironport-Source: 130.216.38.131 - Outgoing - Outgoing-SSL Received: from nevil-laptop1.sfac.auckland.ac.nz (HELO [130.216.38.131]) ([130.216.38.131]) by mx2-int.auckland.ac.nz with ESMTP; 26 Jul 2012 16:19:33 +1200 Message-ID: <5010C554.7070904@auckland.ac.nz> Date: Thu, 26 Jul 2012 16:19:32 +1200 From: Nevil Brownlee User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: IPFIX Working Group Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [IPFIX] Agenda for Vancouver, -02 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: Thu, 26 Jul 2012 04:19:37 -0000 Hi all: Here's my latest draft of our agenda. I suspect that quite a few of our draft authors/editors won't be there in person - please would you all discuss who will be able to present your drafts, and let me know. As always, please email me your slides at least one day before the meeting! Cheers, Nevil =========================================== IP Flow Information Export WG (ipfix) Agenda for IETF 84, Vancouver >>> DRAFT-02 <<< Thursday, 2 August, 1300-1500, Regency A =========================================== Chairs: Juergen Quittek Nevil Brownlee AGENDA: 1. Agenda review = 5 min 2. Update from last meeting / WG Status (Nevil) = 10 min IPFIX MIB RFC 6615 (Obsoletes 5815) published June 2012 IPFIX Configuration Model draft-ietf-ipfix-configuration-model-10, 18 Jul 11 Waiting on PSAMP MIB PSAMP MIB draft-ietf-ipfix-psamp-mib-06.txt, 10 Jul 12 Approved Flow Selection Techniques draft-ietf-ipfix-flow-selection-tech-11, 23 Apr 12 Authors working on new draft IPFIX Aggregation (Brian Trammell) draft-ietf-ipfix-a9n-05, 6 Jul 12 <<< Nevil to do write-up draft-claise-export-application-info-in-ipfix-09 has been sent to IESG as an Individual submission, currently has one DISCUSS 3. Current charter work items = 70 min a) IEs for Data Link Layer Traffic Measurement (Paul Aitken) draft-ipfix-data-link-layer-monitoring-00, 6 Jul 12 b) Guidelines for Information Elements (Brian Trammell) draft-ietf-ipfix-ie-doctors-03, needs new version c) Information Model for IP Flow Information eXport (IPFIX) (Brian Trammell) draft-ietf-ipfix-information-model-rfc5102bis-03, 13 Jul 12 d) Specification of the IP Flow Information eXport (IPFIX) Protocol for the Exchange of Flow Information (Brian Trammell) draft-ietf-ipfix-protocol-rfc5101bis-02, 28 Jun 12 e) Exporting MIB objects (Paul Aitken) draft-ipfix-mib-variable-export-00, 6 Jul 12 f) Protocol for PFIX Mediation (Brian Trammell) draft-ietf-ipfix-mediation-protocol-02, 6 Jul 12 4. Other drafts (if time allows) = 20 min a) Reporting Unobserved Fields in IPFIX (Paul Aitken) draft-aitken-ipfix-unobserved-fields-01, 16 Jul 12 b) VoIP Information Elements in IPFIX (Hendrik Scholtz & Aamer Akhter) draft-akhter-opsawg-perfmon-ipfix-02, 27 Mar 12 draft-scholz-ipfix-rtp-audio-quality-00, 9 Jul 12 6. Any Other Business = 5 min Presentation slides will be available at https://datatracker.ietf.org/public/meeting_materials.cgi?meeting_num=84 (search for IPFIX in the Operations and Management Area) Participation via jabber is offered at ipfix@jabber.ietf.org -- --------------------------------------------------------------------- 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 iesg-secretary@ietf.org Sun Jul 29 14:54:42 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 CDB3D11E80BF; Sun, 29 Jul 2012 14:54:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.585 X-Spam-Level: X-Spam-Status: No, score=-102.585 tagged_above=-999 required=5 tests=[AWL=0.014, 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 pr8zjXzx-sDT; Sun, 29 Jul 2012 14:54:42 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB83411E80D6; Sun, 29 Jul 2012 14:54:41 -0700 (PDT) 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: 4.32 Message-ID: <20120729215441.14820.66675.idtracker@ietfa.amsl.com> Date: Sun, 29 Jul 2012 14:54:41 -0700 Cc: ipfix chair , ipfix mailing list , RFC Editor Subject: [IPFIX] Protocol Action: 'Definitions of Managed Objects for Packet Sampling' to Proposed Standard (draft-ietf-ipfix-psamp-mib-06.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: Sun, 29 Jul 2012 21:54:43 -0000 The IESG has approved the following document: - 'Definitions of Managed Objects for Packet Sampling' (draft-ietf-ipfix-psamp-mib-06.txt) as Proposed Standard This document is the product of the IP Flow Information Export Working Group. The IESG contact persons are Ronald Bonica and Benoit Claise. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-ipfix-psamp-mib/ Technical Summary This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes extensions to the IPFIX MIB module [RFC5815]. For IPFIX implementations that use packet Sampling (PSAMP) techniques as described in [RFC5475], this memo defines the PSAMP MIB module containing managed objects for providing information on applied packet selection functions and their parameters. Working Group Summary This document was originally intended to be a stand-alone MIB; once the WG had decided to produce an IPFIX MIB, PSAMP was left to be added as an extension to the IPFIX MIB. No controversy arose during the work on this MIB. Document Quality As well as its WGLC, this MIB was reviewed by Christian Henke and Benoit Claise. No issues were found. Personnel Shepherd is Nevil Browning. AD is Ron Bonica. From paitken@cisco.com Mon Jul 30 03:52:09 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 AB54C21F86F8 for ; Mon, 30 Jul 2012 03:52:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.491 X-Spam-Level: X-Spam-Status: No, score=-10.491 tagged_above=-999 required=5 tests=[AWL=0.108, 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 axoE+gzW8MGN for ; Mon, 30 Jul 2012 03:52:09 -0700 (PDT) Received: from ams-iport-3.cisco.com (ams-iport-3.cisco.com [144.254.224.146]) by ietfa.amsl.com (Postfix) with ESMTP id 057FE21F86F4 for ; Mon, 30 Jul 2012 03:52:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=paitken@cisco.com; l=244; q=dns/txt; s=iport; t=1343645528; x=1344855128; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=4ahWTamTVslDWUVkr5vWLcD7cJk9TegkK6kbM2ES9eQ=; b=Orb7m6If2uXylZPTBZr8iSplkWCsAjmZanaEqt+s0LyaDpHSD6kQkp3B 1nm8lF02A1H7d8Pz542GKy/QKPj+Od+NBq64FtakdrtfViCu/yShhwZ7V wX7+GC84nV1VkE6JU8hFrc+SEi4NQiXbuU0cIF41NpZ2U4ytTIbpHnxsn s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AmIHAK1mFlCQ/khR/2dsb2JhbABFDo1cq22BB4IgAQEBAwESASVAAQULCw4TFg8JAwIBAgFFBg0BBwEBHodlBpo/n1WSMgOVSYVbiEyBZoImOg X-IronPort-AV: E=Sophos;i="4.77,679,1336348800"; d="scan'208";a="6998485" Received: from ams-core-1.cisco.com ([144.254.72.81]) by ams-iport-3.cisco.com with ESMTP; 30 Jul 2012 10:52:06 +0000 Received: from [10.55.80.227] (dhcp-10-55-80-227.cisco.com [10.55.80.227]) by ams-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id q6UAq6YS003762; Mon, 30 Jul 2012 10:52:06 GMT Message-ID: <50166761.9070902@cisco.com> Date: Mon, 30 Jul 2012 11:52:17 +0100 From: Paul Aitken User-Agent: Mozilla/5.0 (X11; Linux i686; rv:13.0) Gecko/20120615 Thunderbird/13.0.1 MIME-Version: 1.0 To: Nevil Brownlee References: <5010C554.7070904@auckland.ac.nz> In-Reply-To: <5010C554.7070904@auckland.ac.nz> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: IPFIX Working Group Subject: Re: [IPFIX] Agenda for Vancouver, -02 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: Mon, 30 Jul 2012 10:52:09 -0000 Nevil, > Here's my latest draft of our agenda. I suspect that quite a few of > our draft authors/editors won't be there in person What arrangements are there for remote attendees? ie, can we get two-way audio? Video? Thanks, P. From aakhter@cisco.com Mon Jul 30 08:50: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 153D021F8462; Mon, 30 Jul 2012 08:50:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, 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 p3oYDwXr9-Ij; Mon, 30 Jul 2012 08:50:13 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id 06B9521F8491; Mon, 30 Jul 2012 08:50:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=aakhter@cisco.com; l=4974; q=dns/txt; s=iport; t=1343663413; x=1344873013; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=YMN1j7ayExurZfDFxuWcbpcnRjbr2uP/iQ4mA+VTTXc=; b=e4b4bNxCMM0wKtTVTPqdzHwpRv0x61KvD2TMGAwykkzhOYNyt3svv5+m F3M0bSFv/+ljUpeyxqjTAwBBsYOVbtjDIubo/YhljdnM0gi8eU3k9JR14 QNGA7bez51dBvghWYdIqP8nIRKn36QreTtGmruht/KmZYs3a2MeBh8y+8 E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAMesFlCtJXHA/2dsb2JhbABFuVaBB4IgAQEBBBIBJz8MBAIBCBEEAQELFBAyHQgBAQQBDQUIGodrmnmfdYtQFIVuYAOLMZBfh2CBZoJfgVY X-IronPort-AV: E=Sophos;i="4.77,679,1336348800"; d="scan'208";a="106668134" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-8.cisco.com with ESMTP; 30 Jul 2012 15:50:11 +0000 Received: from xhc-rcd-x12.cisco.com (xhc-rcd-x12.cisco.com [173.37.183.86]) by rcdn-core2-5.cisco.com (8.14.5/8.14.5) with ESMTP id q6UFoAls010322 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 30 Jul 2012 15:50:10 GMT Received: from xmb-rcd-x15.cisco.com ([169.254.5.162]) by xhc-rcd-x12.cisco.com ([173.37.183.86]) with mapi id 14.02.0298.004; Mon, 30 Jul 2012 10:50:10 -0500 From: "Aamer Akhter (aakhter)" To: "Jan Novak (janovak)" , "'ipfix@ietf.org'" , "'opsawg@ietf.org'" Thread-Topic: Comments on draft-akhter-opsawg-perfmon-ipfix-02 Thread-Index: Ac0zc8BXTR41oCKqTcOQDS4l95WyzAEhILoQDYLiRuA= Date: Mon, 30 Jul 2012 15:50:09 +0000 Message-ID: <75C0E47A1889264493A2DCB2869AC0960F50A853@xmb-rcd-x15.cisco.com> References: <201205161453.q4GErZNl015927@alpd052.aldc.att.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [64.102.41.104] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19070.006 x-tm-as-result: No--47.978000-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: 'Al Morton' , "'pmol@ietf.org'" Subject: Re: [IPFIX] Comments on draft-akhter-opsawg-perfmon-ipfix-02 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, 30 Jul 2012 15:50:14 -0000 Hi Jan, Thank-you for the review. Please find my comments below. We Hendrik and I w= ill be publishing -03 shortly.=20 -----Original Message----- From: Jan Novak (janovak)=20 Sent: Tuesday, May 22, 2012 4:58 AM To: Aamer Akhter (aakhter); ipfix@ietf.org; opsawg@ietf.org Cc: Al Morton; pmol@ietf.org Subject: Comments on draft-akhter-opsawg-perfmon-ipfix-02 Hi Amer, I have reviewed your draft draft-akhter-opsawg-perfmon-ipfix-02.txt. There seems to be a lot of text overlap with your methodology document - se= ction 1,3, 4 could probably be abbreviated or omitted leaving the document = just with raw IPFIX IE specifications or just add the IE specification as s= ub-sections or a new section into the first document ??=20 AA> I agree that there is overlap, but it was retained for readability. But= I see your point regarding keeping the focus on the IEs in the IPFIX versi= on of the draft. Will strip some of the detail in the IPFIX version. Section 2 uses definitions from RFC5610 - I think those you use there are d= efined in RFC5102 as DataTypeSemantic, units and range while RFC5610 specifies how this information should be exported - here you are de= fining the IE itself so you should use the definitions from RFC5102 AA> I think I had used RFC5610 as it seemed to be a bit more specific about= it (eg rangeBegin and rangeEnd rather than just range). But we are fine e= ither way depending on feedback. Also the methodology documents already speaks in terms of IPFIX IEs while y= ou are trying to specify some performance metrics - the methodology could h= ave names and an exact definitions of the metric and then a reference which= IE represents the particular metric AA> will update the methodology doc with exact definitions and reference th= e IEs.=20 RFC5102 section 2.1 specifies a template for IEs with a MUST so the MUST en= tries should be literally followed in your IEs spec - namely name, elementID, description, dataType and status. RFC5102 section 2.1 specifies MAY entries for the template - like DataTypeS= emantic, units, name - might be preferable to follow the naming as well You interchanged ElementId with name - ElementId should be the numerical ID= of the particular IE, while name of the IE is actually missing AA> Jan, can you look again? I see name (eg. perfPacketExpected) and Elemen= t ID (eg. TBDperfPacketExpected). The TBDperfPacketExpected is actually a p= lace holder for the IANA defined value. Is there still a problem? Instead of using Observation Point - wouldn't be the scope of the element a= ppropriate ?? Or if not then scope should be actually added - are the metri= cs (like perfPacketLoss) applicable to all the traffic seen by the UUT (or = more specifically passing through the Observation Point) or to just individual flows ?? This should also be part of the parti= cular metric definition. AA> We're open to adding scope (as defined as which set of packets would th= is be applicable to). Would you agree that this is more of a methodology it= em than a IE item? Will your IEs be enterprise IEs or IANA ones ?? AA> The idea is to ask for IANA allocation. Section 4.1.2 - Units packets ?? AA> fixed Section 4.1.3 - there is a mis-match between the definition and the range - it should be limited to 0 - 100 + a value when the rate is unknown This d= efinition is also missing in section 4.1.3 of your methodology AA> there is a discussion going on regarding how to represent the unknown.= =20 AA> For the moment, I'll mark the high end as 0x64 (100d). But there also n= eeds to be agreement on how to represent float16, or we go directly to floa= t32. Sections 4.3.1, 4.3.2 - the values are just numbers/ids so units shouldn't = be octets but "none" ?? AA> agree. Copy-paste errors. The IPFIX guys here have had few discussions regarding IE definitions explo= sions with all the needs like this - have you thought using RFC6313 now (st= ructured data) ?? AA> only in the case of the unknown-- which has been purposely left out of = this document as there is another doc working on that. Is there a specific = set of IEs that would be suited to structured data? I am not sure I would use RFC2321 as a reference work :-). AA> someone checked :-) huic-ipfix-sipfix is not a work in progress - the ID expired 3 years ago. AA> This was merely to acknowledge prior work. I can take it out if needed. ie-doctors is a WG doc version 2 now - draft-ietf-ipfix-ie-doctors-02.txt AA> hopefully the xml tool will resolve this. pmol-metrics-framework is RFC 6390 AA> removed from ipfix draft, fixed in methodology draft. The document would benefit from running it through spell checker. AA> thanks and done :-) Rgds, Jan The climate of Edinburgh is such that the weak succumb young ....=20 and the strong envy them. Dr. Johnson From n.brownlee@auckland.ac.nz Tue Jul 31 10:01:08 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 5FED321F86D1 for ; Tue, 31 Jul 2012 10:01:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, 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 rR8LCW-qnYJu for ; Tue, 31 Jul 2012 10:01:01 -0700 (PDT) Received: from mx2.auckland.ac.nz (mx2.auckland.ac.nz [130.216.12.44]) by ietfa.amsl.com (Postfix) with ESMTP id EEE4921F8704 for ; Tue, 31 Jul 2012 10:01:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=n.brownlee@auckland.ac.nz; q=dns/txt; s=uoa; t=1343754061; x=1375290061; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=I0YqleqSOIdeJgTVH8pOozhiOBFJGhvIBZwodXwtFs0=; b=odTgWz76JX9J1dvqiA5bXOOdxBkhu8V48sNO80j5gH4obQscJo0EaEfu x1OleZ187A5x8JCZcfxT5/P/Xee/HO98RkAvWE6P0+OnjOJnZl+HI75BC rUWhFGisVkgcmYd7SKmnZvy9+/xkRhQsWYMKBCA53pbdqsJI+HfEt2Sxz A=; X-IronPort-AV: E=Sophos;i="4.77,688,1336305600"; d="scan'208";a="135933285" X-Ironport-HAT: None - $RELAY-AUTH X-Ironport-Source: 130.129.20.231 - Outgoing - Outgoing-SSL Received: from dhcp-14e7.meeting.ietf.org (HELO [130.129.20.231]) ([130.129.20.231]) by mx2-int.auckland.ac.nz with ESMTP; 01 Aug 2012 05:00:58 +1200 Message-ID: <50180F47.40705@auckland.ac.nz> Date: Wed, 01 Aug 2012 05:00:55 +1200 From: Nevil Brownlee User-Agent: Mozilla/5.0 (X11; Linux i686; rv:13.0) Gecko/20120615 Thunderbird/13.0.1 MIME-Version: 1.0 To: Paul Aitken References: <5010C554.7070904@auckland.ac.nz> <50166761.9070902@cisco.com> In-Reply-To: <50166761.9070902@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: IPFIX Working Group Subject: Re: [IPFIX] Agenda for Vancouver, -02 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: Tue, 31 Jul 2012 17:01:08 -0000 Hi Paul: I'll post the IPFIX meeting agenda sometime tomorrow. Meantime, we have remote participation by Meetecho, which should allow two-way audio - their web tutorial page is at http://ietf84.conf.meetecho.com/index.php/Web_Client Cheers, Nevil On 30/07/12 22:52, Paul Aitken wrote: > Nevil, > >> Here's my latest draft of our agenda. I suspect that quite a few of >> our draft authors/editors won't be there in person > > What arrangements are there for remote attendees? ie, can we get two-way > audio? Video? > > Thanks, > P. -- --------------------------------------------------------------------- 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